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

6.12 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.12.1 Scope and Usage

Conformance statements are used in one of three ways:

6.12.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.12.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.12.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.12.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.12.3 Resource Content

Conformance (Resource)The identifier that is used to identify this conformance statement when it is referenced in a specification, model, design or an instance (should be globally unique OID, UUID, or URI)identifier : string 0..1The identifier that is used to identify this version of the conformance statement when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the profile author manually and the value should be a timestampversion : string 0..1A free text natural language name identifying the conformance statementname : string 0..1Name of Organization publishing this conformance statementpublisher : string 1..1Contacts for Organization relevant to this conformance statement. The contacts may be a website, email, phone numbers, etctelecom : Contact 0..*A free text natural language description of the conformance statement and its use. Typically, this is used when the profile describes a desired rather than an actual solution, for example as a formal expression of requirements as part of an RFPdescription : string 0..1The status of this conformance statement (this element modifies the meaning of other elements)status : code 0..1 <<The status of this conformance statementConformanceStatementStatus>>A flag to indicate that this conformance statement is authored for testing purposes (or education/evaluation/marketing), and is not intended to be used for genuine usageexperimental : boolean 0..1The date when the conformance statement was publisheddate : dateTime 1..1The version of the FHIR specification on which this conformance statement is basedfhirVersion : id 1..1A flag that indicates whether the application accepts unknown elements as part of a resourceacceptUnknown : boolean 1..1A list of the formats supported by this implementationformat : code 1..* <<The mime type of an attachmentMimeType>>A list of profiles supported by the system. For a server, "supported by the system" means the system hosts/produces a set of recourses, conformant to a particular profile, and allows its clients to search using this profile and to find appropriate data. For a client, it means the system will search by this profile and process data according to the guidance implicit in the profileprofile : Resource(Profile) 0..*SoftwareName software is known byname : string 1..1The version identifier for the software covered by this statementversion : string 0..1Date this version of the software releasedreleaseDate : dateTime 0..1ImplementationInformation about the specific installation that this conformance statement relates todescription : string 1..1A base URL for the implementation. This forms the base for REST interfaces as well as the mailbox and document interfacesurl : uri 0..1RestIdentifies whether this portion of the statement is describing ability to initiate or receive restful operationsmode : code 1..1 <<The mode of a RESTful conformance statementRestfulConformanceMode>>Information about the system's restful capabilities that apply across all applications, such as securitydocumentation : string 0..1A list of profiles that this server implements for accepting documents in the mailbox. If this list is empty, then documents are not accepted. The base specification has the profile identifier "http://hl7.org/fhir/documents/mailbox". Other specifications can declare their own identifier for this purposedocumentMailbox : uri 0..*SecurityServer adds CORS headers when responding to requests - this enables javascript applications to yuse the servercors : boolean 0..1Types of security services are supported/required by the systemservice : CodeableConcept 0..* <<Types of security services used with FHIRRestfulSecurityService>>General description of how security worksdescription : string 0..1CertificateMime type for certificatetype : code 0..1 <<The mime type of an attachmentMimeType>>Actual certificateblob : base64Binary 0..1ResourceA type of resource exposed via the restful interfacetype : code 1..1 <<One of the resource types defined as part of FHIRResourceType>>A specification of the profile that describes the solution's support for the resource, including any constraints on cardinality, bindings, lengths or other limitationsprofile : Resource(Profile) 0..1A flag for whether the server is able to return past versions as part of the vRead operationreadHistory : boolean 0..1A flag to indicate that the server allows the client to create new identities on the server. If the update operation is used (client) or allowed (server) to a new location where a resource doesn't already exist. This means that the server allows the client to create new identities on the serverupdateCreate : boolean 0..1A list of _include values supported by the serversearchInclude : string 0..*OperationCoded identifier of the operation, supported by the system resourcecode : code 1..1 <<Operations supported by REST at the type or instance levelRestfulOperationType>>Guidance specific to the implementation of this operation, such as 'delete is a logical delete' or 'updates are only allowed with version id' or 'creates permitted from pre-authorized certificates only'documentation : string 0..1SearchParamThe name of the search parameter used in the interfacename : string 1..1A formal reference to where this parameter was first defined, so that a client can be confident of the meaning of the search parameterdefinition : uri 0..1The type of value a search parameter refers to, and how the content is interpretedtype : code 1..1 <<Data types allowed to be used for search parametersSearchParamType>>This allows documentation of any distinct behaviors about how the search parameter is used. For example, text matching algorithmsdocumentation : string 0..1Types of resource (if a resource is referenced)target : code 0..* <<One of the resource types defined as part of FHIRResourceType>>Chained names supportedchain : string 0..*OperationA coded identifier of the operation, supported by the systemcode : code 1..1 <<Operations supported by REST at the system levelRestfulOperationSystem>>Guidance specific to the implementation of this operation, such as limitations on the kind of transactions allowed, or information about system wide search is implementeddocumentation : string 0..1QueryThe name of a query, which is used in the _query parameter when the query is calledname : string 1..1Identifies the custom query, defined either in FHIR core or another profiledefinition : uri 1..1Additional information about how the query functions in this particular implementationdocumentation : string 0..1MessagingAn address to which messages and/or replies are to be sentendpoint : uri 0..1Length if the receiver's reliable messaging cache (if a receiver) or how long the cache length on the receiver should be (if a sender)reliableCache : integer 0..1Documentation about the system's messaging capabilities for this endpoint not otherwise documented by the conformance statement. For example, process for becoming an authorized messaging exchange partnerdocumentation : string 0..1EventA coded identifier of a supported messaging eventcode : Coding 1..1 <<One of the message events defined as part of FHIRMessageEvent>>The impact of the content of the messagecategory : code 0..1 <<The impact of the content of a messageMessageSignificanceCategory>>The mode of this event declaration - whether application is sender or receivermode : code 1..1 <<The mode of a message conformance statementConformanceEventMode>>A list of the messaging transport protocol(s) identifiers, supported by this endpointprotocol : Coding 0..* <<The protocol used for message transportMessageTransport>>A resource associated with the event. This is the resource that defines the eventfocus : code 1..1 <<One of the resource types defined as part of FHIRResourceType>>Information about the request for this eventrequest : Resource(Profile) 1..1Information about the response for this eventresponse : Resource(Profile) 1..1Guidance on how this event is handled, such as internal system trigger points, business rules, etcdocumentation : string 0..1DocumentMode of this document declaration - whether application is producer or consumermode : code 1..1 <<Whether the application produces or consumes documentsDocumentMode>>A description of how the application supports or uses the specified document profile. For example, when are documents created, what action is taken with consumed documents, etcdocumentation : string 0..1A constraint on a resource used in the documentprofile : Resource(Profile) 1..1Software that is covered by this conformance statement. It is used when the profile describes the capabilities of a particular software version, independent of an installationsoftware0..1Identifies a specific implementation instance that is described by the conformance statement - i.e. a particular installation, rather than the capabilities of a software programimplementation0..1Certificates associated with security profilescertificate0..*Information about security of implementationsecurity0..1Identifies a restful operation supported by the solutionoperation1..*Additional search parameters for implementations to support and/or make use ofsearchParam0..*A specification of the restful capabilities of the solution for a specific resource typeresource1..*A specification of restful operations supported by the systemoperation0..*Identifies which of the parameters for the named query are supportedparameter0..*Definition of a named query and its parameters and their meaningquery0..*A definition of the restful capabilities of the solution, if anyrest0..*A description of the solution's support for an event at this end pointevent1..*A description of the messaging capabilities of the solutionmessaging0..*A document definitiondocument0..* 
<Conformance xmlns="http://hl7.org/fhir"> doco
 <!-- 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>  <!-- ?? 0..1 Software that is covered by this conformance statement § -->
  <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>  <!-- ?? 0..1 If this describes a specific instance § -->
  <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>  <!-- ?? 0..* If the endpoint is a RESTful one -->
  <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>  <!-- ?? 0..* If messaging is supported -->
  <endpoint value="[uri]"/><!-- ?? 0..1 Actual endpoint being described -->
  <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>  <!-- ?? 0..* Document definition -->
  <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

6.12.3.1 Terminology Bindings

PathDefinitionTypeReference
Conformance.status The status of this conformance statementFixedhttp://hl7.org/fhir/conformance-statement-status
Conformance.format
Conformance.rest.security.certificate.type 		The mime type of an attachmentIncompleteBCP 13 (RFCs 2045, 2046, 2047, 4288, 4289 and 2049)
Conformance.rest.mode The mode of a RESTful conformance statementFixedhttp://hl7.org/fhir/restful-conformance-mode
Conformance.rest.security.service Types of security services used with FHIRFixedhttp://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 FHIRIncompletehttp://hl7.org/fhir/resource-types
Conformance.rest.resource.operation.code Operations supported by REST at the type or instance levelFixedhttp://hl7.org/fhir/type-restful-operation
Conformance.rest.resource.searchParam.type Data types allowed to be used for search parametersFixedhttp://hl7.org/fhir/search-param-type
Conformance.rest.operation.code Operations supported by REST at the system levelFixedhttp://hl7.org/fhir/system-restful-operation
Conformance.messaging.event.code One of the message events defined as part of FHIRIncompletehttp://hl7.org/fhir/message-events
Conformance.messaging.event.category The impact of the content of a messageFixedhttp://hl7.org/fhir/message-significance-category
Conformance.messaging.event.mode The mode of a message conformance statementFixedhttp://hl7.org/fhir/message-conformance-event-mode
Conformance.messaging.event.protocol The protocol used for message transportFixedhttp://hl7.org/fhir/message-transport
Conformance.document.mode Whether the application produces or consumes documentsFixedhttp://hl7.org/fhir/document-mode

6.12.3.2 Constraints

6.12.4 Notes:

6.12.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.12.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.12.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:

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:

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:

  1. Mark resources with the tag declaring the profile(s) they conform to (this enables indexing by the profile)
  2. (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.12.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.

NameTypeDescriptionPaths
_idtokenThe logical resource id associated with the resource (must be supported by all servers)
_languagetokenThe language of the resource
datedateThe conformance statement publication dateConformance.date
descriptionstringText search in the description of the conformance statementConformance.description
eventtokenEvent code in a conformance statementConformance.messaging.event.code
fhirversiontokenThe version of FHIRConformance.version
formattokenformats supported (xml | json | mime type)Conformance.format
identifiertokenThe identifier of the conformance statementConformance.identifier
modetokenMode - restful (server/client) or messaging (sender/receiver)Conformance.rest.mode
namestringName of the conformance statementConformance.name
profilereferenceA profile id invoked in a conformance statementConformance.rest.resource.profile
(Profile)
publisherstringName of the publisher of the conformance statementConformance.publisher
resourcetokenName of a resource mentioned in a conformance statementConformance.rest.resource.type
securitytokenInformation about security of implementationConformance.rest.security
softwarestringPart of a the name of a software applicationConformance.software.name
statustokenThe current status of the conformance statementConformance.status
supported-profilereferenceProfiles supported by the systemConformance.profile
(Profile)
versiontokenThe version identifier of the conformance statementConformance.version
comments powered by Disqus