This page is part of the FHIR Specification (v0.06: DSTU 1 Ballot 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

Resource Conformance - Content 2.9

Status: Approved infrastructure resource. Draft for comment

A conformance statement about how an application or implementation supports FHIR or the set of requirements for a desired implementation.

The resource name as it appears in a RESTful URL is /conformance/

Conformance statements are used in one of three ways:

Describe an actual implementation 2.9.1

In this scenario, the conformance statement describes the capabilities of a deployed and configured solution available at a particular access point or set of access points. The statement describes exactly how to interface with that deployed solution and thus provides for a degree of self-configuration of software solutions.

This is the type of profile that FHIR restful solutions are expected to make available on invocation of the conformance operation. It is also the type of statement that forms a basis for the testing, certification or commissioning of specific software installations.

A conformance statement is identified as being an implementation statement through the presence of the implementation element.

Describe software solution capabilities 2.9.2

In this scenario, the conformance statement describes the generic capabilities of a software application or component solution. The solution might be available for purchase or other acquisition and might be deployed and configured at any number of independent sites. Because it is not dependent on any particular implementation, the profile cannot provide specific details such as endpoint addresses. It may also need to document various configurations in which the application can be set up or describe the degree of customizability associated with the solution.

This type of statement may be used as a marketing tool by software and system developers to formally describe their capabilities. It can also be used as the basis for conformance testing of software solutions independent of a particular installation.

A conformance statement is identified as being a software solution statement through the presence of the software element.

Describe a desired solution 2.9.3

In this scenario, the conformance statement describes the capabilities of a desired system. It might be used as part of an architectural design process to document needed system capabilities, or might be used as part of an RFP process to formally document the requirements of a requested solution and to document the criteria by which proposals will be evaluated.

A conformance statement is identified as being a requirements statement through the presence of the proposal element.

These three types of profiles can be used together. A requirements statement can be compared against the solution statements proffered by respondents to an RFP. A solution statement for a software package forms the starting point for the implementation statement associated with a particular installation of that software package.

Conformance Statements provide for a degree of automatic configuration and adaptation. However, capturing absolutely every variation that could impact the interoperability of two systems, let alone keeping that detailed information up-to-date as systems evolve through maintenance and upgrades is rarely practical. Therefore, conformance statements should be seen as an interim step. They provide a degree of automation. However, they also provide a great deal of human-readable content that can minimize the need for direct communication between the operators of the systems being configured to interoperate.

Resource Content 2.9.4

<Conformance xmlns="http://hl7.org/fhir">
 <date><!-- 1..1 dateTime Publication Date --></date>
 <publisher>  <!-- 1..1 Publisher of the statement -->
  <name><!-- 1..1 string Publishing Organization --></name>
  <address><!-- 0..1 Address Address of Organization --></address>
  <contact><!-- 0..* Contact Contacts for Organization --></contact>
 </publisher>
 <implementation>  <!-- 0..1 If profile is for implementation -->
  <description><!-- 1..1 string What implementation is covered? --></description>
  <url><!-- 0..1 uri Base URL for interfaces --></url>
 </implementation>
 <software>  <!-- 0..1 If profile is for software offered -->
  <name><!-- 1..1 string Name software is known by --></name>
  <version><!-- 0..1 string Version covered by this statement --></version>
  <releaseDate><!-- 0..1 dateTime Date this version released --></releaseDate>
 </software>
 <proposal>  <!-- 0..1 If profile is for proposal -->
  <description><!-- 1..1 string Details of proposal or requirements document --></description>
 </proposal>
 <version><!-- 1..1 id FHIR Version --></version>
 <acceptUnknown><!-- 1..1 boolean True if application accepts unknown elements --></acceptUnknown>
 <rest>  <!-- 0..* If the endpoint is a RESTful one -->
  <mode><!-- 1..1 code client | server --></mode>
  <documentation><!-- 0..1 string Security, etc. --></documentation>
  <resource>  <!-- 1..* Resource served on the REST interface -->
   <type><!-- 1..1 code Resource type --></type>
   <profile><!-- 0..1 uri Profile describing resource support --></profile>
   <operation>  <!-- 1..* What operations are supported? -->
    <code><!-- 1..1 code read | vread | update | etc. --></code>
    <documentation><!-- 0..1 string Anything special about operation behavior --></documentation>
   </operation>
   <history><!-- 0..1 boolean Whether vRead can return past versions --></history>
  </resource>
 </rest>
 <messaging>  <!-- 0..* If messaging is supported -->
  <endpoint><!-- 0..1 uri Actual endpoint being described --></endpoint>
  <documentation><!-- 0..1 string Messaging interface behavior details --></documentation>
  <event>  <!-- 1..* Declare support for this event -->
   <code><!-- 1..1 code Event type --></code>
   <mode><!-- 1..1 code sender | receiver --></mode>
   <protocol><!-- 0..* Coding http | ftp |MLLP | etc. --></protocol>
   <focus><!-- 1..1 code Resource that's focus of message --></focus>
   <request><!-- 0..1 uri Profile that describes the request --></request>
   <response><!-- 0..1 uri Profile that describes the response --></response>
   <documentation><!-- 0..1 string Endpoint-specific event documentation --></documentation>
  </event>
 </messaging>
 <document>  <!-- 0..* document definition -->
  <mode><!-- 1..1 code producer | consumer --></mode>
  <documentation><!-- 0..1 string Description of document support --></documentation>
  <profile><!-- 1..1 uri Constraint on a resource used in the document --></profile>
 </document>
 <extension><!-- 0..* Extension  See Extensions  --></extension>
 <text><!-- 1..1 Narrative Text summary of resource (for human interpretation) --></text>
</Conformance>

Alternate definitions: Schema/Schematron, RDF (to do), XML, XMI (to do), Resource Profile

Terminology Bindings

Path	Details	Strength
Conformance.rest.mode	The mode of a restful conformance statement (see http://hl7.org/fhir/restful-conformance-mode for values)	complete/required
Conformance.rest.resource.type Conformance.messaging.event.focus	Any defined Resource Type name	complete/required
Conformance.rest.resource.operation.code	Operations supported by REST (see http://hl7.org/fhir/restful-operation for values)	complete/required
Conformance.messaging.event.code	the Event List in the messaging framework	complete/required
Conformance.messaging.event.mode	The mode of a message conformance statement (see http://hl7.org/fhir/message-conformance-event-mode for values)	complete/required
Conformance.messaging.event.protocol	How messages are delivered (see http://hl7.org/fhir/message-transport for values)	complete/required
Conformance.document.mode	Whether the application produces or consumes documents (see http://hl7.org/fhir/document-mode for values)	complete/required

Constraints

• Must have one and only one of software, implementation or proposal (xpath: count(f:software | f:implementation | f:proposal) = 1)
• A Conformance profile must have at least one of rest, messaging, or document (xpath: exists(f:rest) or exists(f:messaging) or exists(f:document))
• Messaging end point is required (and is only permitted) when statement is for an implementation (xpath on /messaging: exists(f:endpoint) = exists(parent::f:Conformance/f:implementation))

Notes: 2.9.5

• This conformance resource provides for an application to describe its use of the RESTful paradigm messaging events, or FHIR documents. Usually, an application would only describe one, but more than one may be described
• RESTful conformance rules:
  • RESTful servers are required to provide this resource on demand. Servers SHALL specify what resource types and operations are supported, and SHOULD also specify profiles for each resource type.
  • RESTful clients SHOULD publish a conformance statement
  • Resource Types or operations that are not listed are not supported
• Messaging conformance rules:
  • The interpretation of request and resource depends on the mode. If the mode is sender, then request specifies what the application sends, and response specifies what it accepts. If the mode is "receiver", then this is reversed
  • If a request or response is not specified for an event, then no rules are made for it
  • Events that are not listed are not supported
• Document conformance rules:
  • Ideally, the criteria in different document profiles should be able to distinguish between multiple document profiles, so that there is no ambiguity concerning which profile any given document conforms to. However this is not always possible

Search Parameters 2.9.6

Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.

$page : integer	Starting offset of the first record to return in the search set	single
$count : integer	Number of return records requested. The server is not bound to conform	single
$id : token	The logical resource id associated with the resource (must be supported by all servers)	single
publisher : string	part of a publisher name	union
software : string	part of a the name of a software application	union
version : token	the version of FHIR	union
resource : token	name of a resource mentioned in a conformance profile	union
event : qtoken	event code in a conformance statement	union
mode : token	mode - restful (server/client) or messaging (sender/receiver)	single
profile : qtoken	a profile id invoked in a conformance statement	union
date : date	date equal to the conformance statement publication date	single
date-before : date	date before or equal to the conformance statement publication date	single
date-after : date	date after or equal to the conformance statement publication date	single

(See Searching).

---

This is an old version of FHIR retained for archive purposes. Do not use for anything else
Implementers are welcome to experiment with the content defined here, but should note that the contents are subject to change without prior notice.
© HL7.org 2011 - 2012. FHIR v0.06 generated on Tue, Dec 4, 2012 00:04+1100. License