Conformance
This specification creates the possibility of many different interactions, but applications are not required to support any of them. To manage this complexity, each application must make a conformance statement. The conformance statement describes, on a per resource basis:
- The purpose of supporting the resource
- Which interactions are supported
- How the content model is supported and extended
- What transaction are supported
- When transaction elements are required, and what parts are required
- What parameters are supported for searching and updates
- digital signature support
To meet these requirements, this page defines a fixed xml format to represent the conformance statemnt. The conformance statement may be used at run time to assist with application to application negotiation, or it may be used at design time or even purchase time to assist implementers to understand the capabilities of the system.
There is also an aggregated form of the conformance statement to gather the conformance statements for each resource type into a single XML document.
Content Model
<conformance xmlns="...">
<application mand type="string">Identity of the application (incl. version)<application>
<type mand type="string">Client|Server<type>
<resource mand type="string">Formal Name of the resource type<resource>
<purpose mand type="string">General human readable reason for supporting the resource</purpose>
<interactions mand type="string">space separated list of interactions supported</interactions>
<!--
Content models. There is a content model for each transaction. In
addition, there is a general content model that applies if no transaction specific model is
specified. Sections are optional, but a content model must be defined for each transaction
listed above.
-->
<default opt>
<content opt>
<element>
<name mand type="string">Name of the element as specified in RfH</name>
<!-- read and write status must both be specified -->
<read mand type="string">One of: Required | Ignored | Rejected | Optional </read>
<write mand type="string">One of: Always | Never | Sometimes </write>
<minOccurs mand type="integer">Minimum number (if present)</minOccurs>
<maxOccurs mand type="integer|string">Maximum number or "*" (if present)</maxOccurs>
<text mand type="string">One of: Data | Text | Either </text>
<valueSet opt type="string">Value set id (if coded)</valueSet>
<filter opt type="boolean">true if can use as filter in URLs</filter>
<fixedValue opt >
<[type] mand>[as defined for type]</[type]>
</fixedValue>
<element>
<!-- nested elements - same content model -->
</element>
</element>
</content>
<transaction>
<!--
Defines the content model of the transaction element, if there is one. The default transaction
definition applies to create/update/delete and other transactions unless overridden. The
content is the same as the content model above (nested element definitions)
-->
</transaction>
</default>
<interactions>
<interaction>
<name mand type="string">Name of the interaction</name>
<!--
Content model same as for default element: a
content and optionally a transaction element
-->
</interaction
<interactions>
</conformance>
Notes:
- A server will always return the type "Server". "Client" conformance profiles are published manually
The aggregated form is the takes the same form as that conformance statement above, but where the elements represent the aggregated form.
Example
(To Do) Note: the details in the example have not been sychronised with the latest specification as found above.
Example: patient support for a laboratory reporting application. Simple, just enough to support the reporting functionality.
<statement xmlns="...">
<type>Server<type>
<resource>Patient<resource>
<purpose>In support of laboratory report provision functionality</purpose>
<interactions>read search updates conformance</interactions>
<!-- basic search support, just by MRN and name -->
<search>
<param name="identifiers.identifier.identifier.id"/>
<param name="names.name.part.value"/>
<param name="name"/>
<param name="n"/>
<param name="count"/>
</search>
<!-- only support filtering updates since last date -->
<filter>
<param name="date"/>
<param name="n"/>
<param name="count"/>
</filter>
<write>
<!-- there is no read for this application; it only writes - note
that would mean it gets the patient details by e.g. HL7 v2 -->
<element name="patient" state="always"> <!-- root is always always -->
<element name="id" state="always"/>
<element name="created" state="always"/>
<element name="updated" state="always"/>
<element name="status" state="always" fixed="active"/>
<!-- this application doesn't support linking patients.
That may be an issue for potential users of the application... -->
<element name="links" state="never"/> !!! as text !!!
<!-- always one identifier: the institutions MRN -->
<element name="identifiers" state="always">
<element name="identifier" state="always" max="1" min="1">
<element name="use" state="never"/>
<element name="type" state="always" fixed="mrn"/>
<element name="identifier" state="always">
<element name="system" state="always" fixed="patient master URL"/>
<element name="id" state="always"/>
<element name="quality" state="always" fixed="checked"/>
<element name="period" state="never"/>
<element name="assigner" state="never"/>
</element>
</element>
</element>
<element name="institution" state="never"/>
<!-- always one name - family, and possibly one given -->
<element name="names state="always">
<element name="name" state="always" min="1" max="1">
<element name="use" state="never"/>
<element name="part" min="1" max="2">
<element name="use" state="never"/>
<element name="type" state="always" values="given family"/>
<element name="value" state="always" search="true" filter="true"/>
<element name="code" state="never"/>
<element name="system" state="never"/>
</element>
<element name="period" state="never"/>
</element>
</element>
<!-- always one Address. two address lines + suburb -->
<element name="addresses state="always">
<element name="address" state="always" min="1" max="1">
<element name="use" state="never"/>
<element name="part" min="3" max="5">
<element name="use" state="never"/>
<element name="type" state="always" values="addressline suburb zip state"/>
<element name="value" state="always" search="true" filter="true"/>
<element name="code" state="never"/>
<element name="system" state="never"/>
</element>
<element name="period" state="never"/>
</element>
</element>
<element name="contacts state="never"/>
<!-- maybe a date of birth -->
<element name="dob" state="sometimes" precision="8"/ >
<!-- none of the rest of the model -->
<element name="dod" state="never"/>
<element name="birthplace" state="never"/>
<element name="languages" state="never"/>
<element name="citizenships" state="never"/>
<element name="employments" state="never"/>
<element name="student" state="never"/>
<element name="qualification" state="never"/>
</element>
</write>
</statement>
| When Providing: | |
| structure | Only structure will be produced |
| generated | Structure is produced, and a generated narrative is provided |
| narrative | Only narrative will be produced |
| both | Either structure or narrative may be provided |
| When Consuming: | |
| structure | Only structure will be processed. Narrative will be ignored |
| narrative | Only narrative will be processed. Structure will be ignored |
| both | Either structure or narrative is acceptable |
TODO: grab control over images and formatting or not? capture the notion of only in error or not? extend the XML descriptive syntax to say which can be texted?
© 2011 