6.15 Resource Conformance - Content
A conformance statement is a set of requirements for a desired implementation or a description of how a target application fulfills those requirements in a particular implementation.
## 6.15.1 Scope and Usage
Conformance statements are used in one of three ways:
### 6.15.1.1 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.
### 6.15.1.2 Describe software solution capabilities
In this scenario, the conformance statement describes 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.
### 6.15.1.3 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 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.
## 6.15.2 Background and Context
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.
6.15.3
Resource Content
Structure
| Name | Card. | Type | Description & Constraints |
|---|---|---|---|
  Conformance | Resource | A conformance statement A Conformance statement SHALL have at least one of description, software, or implementationA Conformance statement SHALL have at least one of rest, messaging or documentThe set of documents must be unique by the combination of profile & modeThe set of end points listed for messaging must be uniqueIf there is more than one messaging element, endpoint must be specified for each oneThere can only be one REST declaration per mode | |
  identifier | 0..1 | string | Logical id to reference this statement |
| version | 0..1 | string | Logical id for this version of the statement |
| name | 0..1 | string | Informal name for this conformance statement |
| publisher | 1..1 | string | Publishing Organization |
 telecom | 0.. | Contact | Contacts for Organization |
| description | 0..1 | string | Human description of the conformance statement |
| status | 0..1 | code | draft | active | retired ConformanceStatementStatus (Required) |
| experimental | 0..1 | boolean | If for testing purposes, not real usage |
| date | 1..1 | dateTime | Publication Date |
 software | Element | Software that is covered by this conformance statement | |
 name | 1..1 | string | A name the software is known by |
| version | 0..1 | string | Version covered by this statement |
 releaseDate | 0..1 | dateTime | Date this version released |
| implementation | Element | If this describes a specific instance | |
| description | 1..1 | string | Describes this specific instance |
| url | 0..1 | uri | Base URL for the installation |
| fhirVersion | 1..1 | id | FHIR Version |
| acceptUnknown | 1..1 | boolean | True if application accepts unknown elements |
| format | 1.. | code | formats supported (xml | json | mime type) MimeType (Required) |
 profile | 0.. | Profile | Profiles supported by the system |
| rest | Element | If the endpoint is a RESTful one A given query can only be described once per RESTful modeA given resource can only be described once per RESTful mode | |
| mode | 1..1 | code | client | server RestfulConformanceMode (Required) |
| documentation | 0..1 | string | General description of implementation |
| security | Element | Information about security of implementation | |
| cors | 0..1 | boolean | Adds CORS Headers (http://enable-cors.org/) |
| service | 0.. | CodeableConcept | OAuth | OAuth2 | NTLM | Basic | Kerberos RestfulSecurityService (Incomplete) |
| description | 0..1 | string | General description of how security works |
| certificate | Element | Certificates associated with security profiles | |
 type | 0..1 | code | Mime type for certificate MimeType (Required) |
| blob | 0..1 | base64Binary | Actual certificate |
| resource | Element | Resource served on the REST interface Operation codes must be unique in the context of a resourceSearch parameter names must be unique in the context of a resource | |
| type | 1..1 | code | A resource type that is supported ResourceType (Required) |
| profile | 0..1 | Profile | What structural features are supported |
| operation | Element | What operations are supported? | |
| code | 1..1 | code | read | vread | update | delete | history-instance | validate | history-type | create | search-type RestfulOperationType (Required) |
| documentation | 0..1 | string | Anything special about operation behavior |
| readHistory | 0..1 | boolean | Whether vRead can return past versions |
| updateCreate | 0..1 | boolean | If allows/uses update to a new location |
| searchInclude | 0.. | string | _include values supported by the server |
| searchParam | Element | Additional search params defined | |
| name | 1..1 | string | Name of search parameter |
| definition | 0..1 | uri | Source of definition for parameter |
| type | 1..1 | code | number | date | string | token | reference | composite | quantity SearchParamType (Required) |
| documentation | 0..1 | string | Server-specific usage |
| target | 0.. | code | Types of resource (if a resource reference) ResourceType (Required) |
| chain | 0.. | string | Chained names supported |
| operation | Element | What operations are supported? | |
| code | 1..1 | code | transaction | search-system | history-system RestfulOperationSystem (Required) |
| documentation | 0..1 | string | Anything special about operation behavior |
| query | Element | Definition of a named query Search parameter names must be unique in the context of a query | |
| name | 1..1 | string | Special named queries (_query=) |
| definition | 1..1 | uri | Where query is defined |
| documentation | 0..1 | string | Additional usage guidance |
 parameter | 0.. | see searchParam | Parameter for the named query |
| documentMailbox | 0.. | uri | How documents are accepted in /Mailbox |
| messaging | Element | If messaging is supported Messaging end point is required (and is only permitted) when statement is for an implementationThe set of events per messaging endpoint must be unique by the combination of code & mode | |
| endpoint | 0..1 | uri | Actual endpoint being described |
| reliableCache | 0..1 | integer | Reliable Message Cache Length |
| documentation | 0..1 | string | Messaging interface behavior details |
| event | Element | Declare support for this event | |
| code | 1..1 | Coding | Event type MessageEvent (Incomplete) |
| category | 0..1 | code | Consequence | Currency | Notification MessageSignificanceCategory (Required) |
| mode | 1..1 | code | sender | receiver ConformanceEventMode (Required) |
| protocol | 0.. | Coding | http | ftp | mllp + MessageTransport (Incomplete) |
| focus | 1..1 | code | Resource that’s focus of message ResourceType (Required) |
| request | 1..1 | Profile | Profile that describes the request |
| response | 1..1 | Profile | Profile that describes the response |
| documentation | 0..1 | string | Endpoint-specific event documentation |
| document | Element | Document definition | |
| mode | 1..1 | code | producer | consumer DocumentMode (Required) |
| documentation | 0..1 | string | Description of document support |
| profile | 1..1 | Profile | Constraint on a resource used in the document |
XML Template
<Conformance xmlns="http://hl7.org/fhir">
<!– from Resource: extension, modifierExtension, language, text, and contained –>
<identifier value="[string]"/><!– 0..1 Logical id to reference this statement § –>
<version value="[string]"/><!– 0..1 Logical id for this version of the statement § –>
<name value="[string]"/><!– 0..1 Informal name for this conformance statement § –>
<publisher value="[string]"/><!– 1..1 Publishing Organization § –>
<telecom><!– 0..* Contact Contacts for Organization § –></telecom>
<description value="[string]"/><!–0..1 Human description of the conformance statement § –>
<status value="[code]"/><!– 0..1 draft | active | retired § –>
<experimental value="[boolean]"/><!– 0..1 If for testing purposes, not real usage § –>
<date value="[dateTime]"/><!– 1..1 Publication Date § –>
<software> <!–
<name value="[string]"/><!– 1..1 A name the software is known by § –>
<version value="[string]"/><!– 0..1 Version covered by this statement § –>
<releaseDate value="[dateTime]"/><!– 0..1 Date this version released § –>
</software>
<implementation> <!–
<description value="[string]"/><!– 1..1 Describes this specific instance § –>
<url value="[uri]"/><!– 0..1 Base URL for the installation § –>
</implementation>
<fhirVersion value="[id]"/><!– 1..1 FHIR Version § –>
<acceptUnknown value="[boolean]"/><!– 1..1 True if application accepts unknown elements § –>
<format value="[code]"/><!– 1..* formats supported (xml | json | mime type) –>
<profile><!– 0..* Resource(Profile) Profiles supported by the system –></profile>
<rest> <!–
<mode value="[code]"/><!– 1..1 client | server –>
<documentation value="[string]"/><!– 0..1 General description of implementation –>
<security> <!– 0..1 Information about security of implementation –>
<cors value="[boolean]"/><!– 0..1 Adds CORS Headers (http://enable-cors.org/) –>
<service><!– 0..* CodeableConcept OAuth | OAuth2 | NTLM | Basic | Kerberos –></service>
<description value="[string]"/><!– 0..1 General description of how security works –>
<certificate> <!– 0..* Certificates associated with security profiles –>
<type value="[code]"/><!– 0..1 Mime type for certificate –>
<blob value="[base64Binary]"/><!– 0..1 Actual certificate –>
</certificate>
</security>
<resource> <!– 1..* Resource served on the REST interface –>
<type value="[code]"/><!– 1..1 A resource type that is supported –>
<profile><!– 0..1 Resource(Profile) What structural features are supported –></profile>
<operation> <!– 1..* What operations are supported? –>
<code value="[code]"/><!– 1..1 read | vread | update | delete | history-instance | validate | history-type | create | search-type –>
<documentation value="[string]"/><!– 0..1 Anything special about operation behavior –>
</operation>
<readHistory value="[boolean]"/><!– 0..1 Whether vRead can return past versions –>
<updateCreate value="[boolean]"/><!– 0..1 If allows/uses update to a new location –>
<searchInclude value="[string]"/><!– 0..* _include values supported by the server –>
<searchParam> <!– 0..* Additional search params defined –>
<name value="[string]"/><!– 1..1 Name of search parameter –>
<definition value="[uri]"/><!– 0..1 Source of definition for parameter –>
<type value="[code]"/><!– 1..1 number | date | string | token | reference | composite | quantity –>
<documentation value="[string]"/><!– 0..1 Server-specific usage –>
<target value="[code]"/><!– 0..* Types of resource (if a resource reference) –>
<chain value="[string]"/><!– 0..* Chained names supported –>
</searchParam>
</resource>
<operation> <!– 0..* What operations are supported? –>
<code value="[code]"/><!– 1..1 transaction | search-system | history-system –>
<documentation value="[string]"/><!– 0..1 Anything special about operation behavior –>
</operation>
<query> <!– 0..* Definition of a named query –>
<name value="[string]"/><!– 1..1 Special named queries (_query=) –>
<definition value="[uri]"/><!– 1..1 Where query is defined –>
<documentation value="[string]"/><!– 0..1 Additional usage guidance –>
<parameter><!– 0..* Content as for Conformance.rest.resource.searchParam Parameter for the named query –></parameter>
</query>
<documentMailbox value="[uri]"/><!– 0..* How documents are accepted in /Mailbox –>
</rest>
<messaging> <!–
<endpoint value="[uri]"/><!–
<reliableCache value="[integer]"/><!– 0..1 Reliable Message Cache Length –>
<documentation value="[string]"/><!– 0..1 Messaging interface behavior details –>
<event> <!– 1..* Declare support for this event –>
<code><!– 1..1 Coding Event type –></code>
<category value="[code]"/><!– 0..1 Consequence | Currency | Notification –>
<mode value="[code]"/><!– 1..1 sender | receiver –>
<protocol><!– 0..* Coding http | ftp | mllp + –></protocol>
<focus value="[code]"/><!– 1..1 Resource that’s focus of message –>
<request><!– 1..1 Resource(Profile) Profile that describes the request –></request>
<response><!– 1..1 Resource(Profile) Profile that describes the response –></response>
<documentation value="[string]"/><!– 0..1 Endpoint-specific event documentation –>
</event>
</messaging>
<document> <!–
<mode value="[code]"/><!– 1..1 producer | consumer –>
<documentation value="[string]"/><!– 0..1 Description of document support –>
<profile><!– 1..1 Resource(Profile) Constraint on a resource used in the document –></profile>
</document>
</Conformance>
Alternate definitions: Schema/Schematron,
Resource Profile (XML, JSON)
6.15.3.1
Terminology Bindings
| Path | Definition | Type | Reference |
|---|---|---|---|
| Conformance.status | The status of this conformance statement | Fixed | http://hl7.org/fhir/conformance-statement-status |
| Conformance.format Conformance.rest.security.certificate.type | The mime type of an attachment | Incomplete | BCP 13 (RFCs 2045, 2046, 2047, 4288, 4289 and 2049) |
| Conformance.rest.mode | The mode of a RESTful conformance statement | Fixed | http://hl7.org/fhir/restful-conformance-mode |
| Conformance.rest.security.service | Types of security services used with FHIR | Fixed | http://hl7.org/fhir/restful-security-service |
| Conformance.rest.resource.type Conformance.rest.resource.searchParam.target Conformance.messaging.event.focus | One of the resource types defined as part of FHIR | Incomplete | http://hl7.org/fhir/valueset/resource-types |
| Conformance.rest.resource.operation.code | Operations supported by REST at the type or instance level | Fixed | http://hl7.org/fhir/type-restful-operation |
| Conformance.rest.resource.searchParam.type | Data types allowed to be used for search parameters | Fixed | http://hl7.org/fhir/search-param-type |
| Conformance.rest.operation.code | Operations supported by REST at the system level | Fixed | http://hl7.org/fhir/system-restful-operation |
| Conformance.messaging.event.code | One of the message events defined as part of FHIR | Incomplete | http://hl7.org/fhir/valueset/message-events |
| Conformance.messaging.event.category | The impact of the content of a message | Fixed | http://hl7.org/fhir/message-significance-category |
| Conformance.messaging.event.mode | The mode of a message conformance statement | Fixed | http://hl7.org/fhir/message-conformance-event-mode |
| Conformance.messaging.event.protocol | The protocol used for message transport | Fixed | http://hl7.org/fhir/message-transport |
| Conformance.document.mode | Whether the application produces or consumes documents | Fixed | http://hl7.org/fhir/document-mode |
6.15.3.2 Constraints
- Inv-1: A Conformance statement SHALL have at least one of rest, messaging or document (xpath: exists(f:rest) or exists(f:messaging) or exists(f:document))
- Inv-2: A Conformance statement SHALL have at least one of description, software, or implementation (xpath: count(f:software | f:implementation | f:description) > 0)
- Inv-4: If there is more than one messaging element, endpoint must be specified for each one (xpath: count(f:messaging)<=1 or not(f:messaging[not(f:endpoint)]))
- Inv-5: The set of end points listed for messaging must be unique (xpath: count(f:messaging/f:endpoint)=count(distinct-values(f:messaging/f:endpoint/@value)))
- Inv-7: The set of documents must be unique by the combination of profile & mode (xpath: count(f:document[f:mode=’producer’])=count(distinct-values(f:document[f:mode=’producer’]/f:profile/@value)) and count(f:document[f:mode=’consumer’])=count(distinct-values(f:document[f:mode=’consumer’]/f:profile/@value)))
- Inv-8: There can only be one REST declaration per mode (xpath: count(f:rest)=count(distinct-values(f:rest/f:mode/@value)))
- Inv-9: On Conformance.rest: A given resource can only be described once per RESTful mode (xpath on f:Conformance/f:rest: count(f:resource)=count(distinct-values(f:resource/f:type/@value)))
- Inv-10: On Conformance.rest: A given query can only be described once per RESTful mode (xpath on f:Conformance/f:rest: count(f:query)=count(distinct-values(f:query/f:name/@value)))
- Inv-11: On Conformance.rest.resource: Operation codes must be unique in the context of a resource (xpath on f:Conformance/f:rest/f:resource: count(f:operation)=count(distinct-values(f:operation/f:code/@value)))
- Inv-12: On Conformance.rest.resource: Search parameter names must be unique in the context of a resource (xpath on f:Conformance/f:rest/f:resource: count(f:searchParam)=count(distinct-values(f:searchParam/f:name/@value)))
- Inv-13: On Conformance.rest.query: Search parameter names must be unique in the context of a query (xpath on f:Conformance/f:rest/f:query: count(f:parameter)=count(distinct-values(f:parameter/f:name/@value)))
- Inv-3: On Conformance.messaging: Messaging end point is required (and is only permitted) when statement is for an implementation (xpath on f:Conformance/f:messaging: exists(f:endpoint) = exists(parent::f:Conformance/f:implementation))
- Inv-6: On Conformance.messaging: The set of events per messaging endpoint must be unique by the combination of code & mode (xpath on f:Conformance/f:messaging: count(f:event[f:mode=’sender’])=count(distinct-values(f:event[f:mode=’sender’]/f:code/@value)) and count(f:event[f:mode=’receiver’])=count(distinct-values(f:event[f:mode=’receiver’]/f:code/@value)))
6.15.4
Notes:
- The 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](http.html#conformance). 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
- The search parameters that a server supports (or a client makes use of) are specified in the resource profile that the conformance statement references
Resource Types or operations that are not listed are not supported* Messaging conformance rules:
- The interpretation of request and response 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:
- Document Profiles should directly constrain the Document.information.class & type elements so so that there is no ambiguity concerning which profile any given document conforms to* Other service based use of resources: Due to the variability of these services, the Conformance resource does not attempt to describe service based use of resources. The various service specifications will need to describe this usage in their own way
6.15.4.1 Supporting Profiles
A conformance profile declares two different kinds of profiles for the functionality it describes.
The Resource Profiles are specified using Conformance.rest.resource.profile element and the System Profiles are specified using Conformance.profile element.
6.15.4.1.1 Resource Profiles
These profiles describe the general features that are supported by the system for each kind of
resource. Typically, this is the superset of all the different use-cases implemented by the system.
This is a resource-level perspective of the system functionality.
6.15.4.1.2 System Profiles
These profiles describe the information handled/produced by the system on a per use case basis.
Some examples of the uses for system profiles:
- A Laboratory service producing a set of different reports - general chemistry, blood count, etc. Typical labs would support several hundred different reports
- A care manager which handles a set of different types of care plans and associated clinical resources
- A medications formulary that handles several different levels of sophistication in its medication representations
Typically, these profiles are a series of variations on the same set of resources - different use cases leading to handling
the resources that represent them differently. These use-cases described above all pertain to system that produce and publish
data, but the same concept applies to systems that consume data. For instance:
- An expert service that provides analysis on several different sets of data conforming to a particular pattern - tests x,y and z with particular codes and units
For producer and a consumer systems to exchange data successfully based on
one of these system supported profiles, it’s not enough to know that the
systems happen to have system profiles that overlap for the use case
of interest; the consumer must be able to filter the total set of resources
made available by the producer system and deal only with the ones relevant
to the use case.
As an example consider a laboratory system generating 1000s of reports
a day. 1% of those reports are a particular endocrine report that a
decision support system knows how to process. Both systems declare that
they support the particular endocrine profile, but how does the expert
system actually find the endocrine reports that it knows how to process?
One possible option is for the expert system to receive every single
report coming from the lab system, check whether it conforms to the
profile or not, and then decide whether to process it. Checking whether
a resource conforms to a particular profile or not is a straight
forward operation (on option is to use the provided tools for this),
but this is very inefficient way - the expert system has to receive
and process 100 times many resources as it uses. To help a consumer
find the correct set of reports for a use-case, the producer of the
resources also SHALL:
- Mark resources with the tag declaring the profile(s) they conform to (this enables indexing by the profile)
- (if a server) support searching by the _profile parameter for the declared profiles
Beyond these requirements, a producer of resources SHOULD ensure that any data that would reasonably be expected
to conform to the declared profiles SHOULD be published in this form.
DSTU note: there are many uninvestigated issues associated with system profiles.
HL7 is actively seeking feedback from users who experiment with system profiles, and users
should be prepared for changes to features and obligations in this area in the future.
6.15.5 Search Parameters
Search parameters for this resource. The standard parameters also apply. See Searching for more information about searching in REST, messaging, and services.
| Name | Type | Description | Paths |
| _id | token | The logical resource id associated with the resource (must be supported by all servers) | |
| _language | token | The stated language of the resource | |
| date | date | The conformance statement publication date | Conformance.date |
| description | string | Text search in the description of the conformance statement | Conformance.description |
| event | token | Event code in a conformance statement | Conformance.messaging.event.code |
| fhirversion | token | The version of FHIR | Conformance.version |
| format | token | formats supported (xml | json | mime type) | Conformance.format |
| identifier | token | The identifier of the conformance statement | Conformance.identifier |
| mode | token | Mode - restful (server/client) or messaging (sender/receiver) | Conformance.rest.mode |
| name | string | Name of the conformance statement | Conformance.name |
| profile | reference | A profile id invoked in a conformance statement | Conformance.rest.resource.profile (Profile) |
| publisher | string | Name of the publisher of the conformance statement | Conformance.publisher |
| resource | token | Name of a resource mentioned in a conformance statement | Conformance.rest.resource.type |
| security | token | Information about security of implementation | Conformance.rest.security |
| software | string | Part of a the name of a software application | Conformance.software.name |
| status | token | The current status of the conformance statement | Conformance.status |
| supported-profile | reference | Profiles supported by the system | Conformance.profile (Profile) |
| version | token | The version identifier of the conformance statement | Conformance.version |
</div> <!-- /inner-wrapper -->
</div> <!-- /row -->
</div> <!-- /container -->
</div> <!-- /segment-content -->
<div id="segment-footer" class="segment"> <!-- segment-footer -->
<div class="container"> <!-- container -->
<div class="inner-wrapper">
© HL7.org 2011 - 2014. FHIR DSTU (v0.2.1-2606) generated on Wed, Jul 2, 2014 16:27+0800. <!-- [QA Report](qa.html) --> <!-- achive note -->
<span style="color: #FFFF77">
Links: [What's a DSTU?](dstu.html) |
[Version History](history.html) |
[Compare to DSTU](http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fhl7.org%2Fimplement%2Fstandards%2Ffhir%2Fconformance.html&doc2=http%3A%2F%2Fhl7.org%2Fimplement%2Fstandards%2FFHIR-Develop%2Fconformance.html) |
[License](license.html) |
[Propose a change](http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemAdd&tracker_id=677)
</span>
</div> <!-- /inner-wrapper -->
</div> <!-- /container -->
</div> <!-- /segment-footer -->