This page is part of the FHIR Specification (v0.05: DSTU 1 Draft). 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

Status: An infrastructure resource. This is an approved resource, and its status is 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

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

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 aquisition 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

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 proferred 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

<Conformance xmlns="http://hl7.org/fhir">
 <id><!-- 1..1 id ConformanceStatement Id --></id>
 <date><!-- 1..1 dateTime Publication Date --></date>
 <publisher>  <!-- 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>  <!-- 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>  <!-- 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>  <!-- 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>
   <search>  <!-- Only if supported -->
    <documentation><!-- 0..1 string General guidance on searching --></documentation>
    <param>  <!-- 1..* Search params supported -->
     <name><!-- 1..1 string Name of search parameter --></name>
     <documentation><!-- 0..1 string contents and meaning of search parameter --></documentation>
    </param>
   </search>
  </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 conformance profile for human interpretation --></text>
</Conformance>

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

Terminology Bindings

• Conformance.rest.mode has the definition RestfulConformanceMode: "The mode of a restful conformance statement". Possible values:

  client	The application acts as a server for this resource
  server	The application acts as a client for this resource

• Conformance.rest.resource.type and Conformance.messaging.event.focus share the definition of any defined Resource Type name
• Conformance.rest.resource.operation.code has the definition RestfulOperation: "Operations supported by REST". Possible values:

  read	Read the current state of the resource
  vread	Read the state of a specific version of the resource
  update	Update an existing resource by its id (or create it if it is new)
  delete	Delete a resource
  history	Retrieve the update history for the resource
  validate	Check that the content would be acceptable as an update
  updates	Get a list of prior updates to resources of this type, optionally with some filter criteria
  create	Create a new resource with a server assigned id

• Conformance.messaging.event.code has the definition of the Event List in the messaging framework
• Conformance.messaging.event.mode has the definition ConformanceEventMode: "The mode of a message conformance statement". Possible values:

  sender	The application sends requests and receives responses
  receiver	The application receives requests and sends responses

• Conformance.messaging.event.protocol has the definition MessageTransport: "How messages are delivered" (sid = urn:hl7-org:sid/fhir/CodeList). Possible values:

  http	The application sends or receives messages using HTTP POST (may be over http or https)
  ftp	The application sends or receives messages using File Transfer Protocol
  mllp	The application sends or receivers messages using HL7's Minimal Lower Level Protocol

• Conformance.document.mode has the definition DocumentMode: "Whether the application produces or consumes documents". Possible values:

  producer	The application produces documents of the specified type
  consumer	The application consumes documents of the specified type

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:

• 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 profile 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

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

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

(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.05 generated on Sun, Sep 9, 2012 03:28+1000. License