Embedded Files
Home ＞ Infrastructure ＞ Conformance [conformance]
Resource Conformance - Content6.12
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 [root]/conformance/
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.
Conformance statements are used in one of three ways:
Describe an actual implementation6.12.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 capabilities6.12.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 solution6.12.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.
Resource Content6.12.4
<Conformance xmlns="http://hl7.org/fhir"> <!-- from Resource: extension, narrative, 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 | experimental | review | production | withdrawn | superseded § --> <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 Name 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) --> <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 --> <service><!-- 0..* CodeableConcept What type of security services are supported/required --></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 Resource type --> <profile><!-- 0..1 Resource(Profile) Resource Profiles supported --></profile> <operation> <!-- 1..* What operations are supported? --> <code value="[code]"/><!-- 1..1 read | vread | update | etc. --> <documentation value="[string]"/><!-- 0..1 Anything special about operation behavior --> </operation> <readHistory value="[boolean]"/><!-- 0..1 Whether vRead can return past versions --> <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 --> <source value="[uri]"/><!-- 0..1 Source of definition --> <type value="[code]"/><!-- 1..1 Type of search parameter --> <documentation value="[string]"/><!-- 1..1 Contents and meaning of search parameter --> <xpath value="[string]"/><!-- 0..1 XPath that extracts the parameter set --> <target value="[code]"/><!-- 0..* Types of resource (if a resource reference) --> <chain value="[string]"/><!-- 0..* Chained names supported --> </searchParam> </resource> <batch value="[boolean]"/><!-- 0..1 If batches are supported --> <history value="[boolean]"/><!-- 0..1 If a system wide history list is supported --> <query> <!-- 0..* Definition of a named query --> <name value="[string]"/><!-- 1..1 Name of the query (_query=) --> <documentation value="[string]"/><!-- 1..1 Describes the named query --> <parameter><!-- 0..* Content as for Conformance.rest.resource.searchParam Parameter for the named query --></parameter> </query> </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 value="[code]"/><!-- 1..1 Event type --> <mode value="[code]"/><!-- 1..1 sender | receiver --> <protocol><!-- 0..* Coding http | ftp |MLLP | etc. --></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
Terminology Bindings 6.12.4.1
Constraints6.12.4.2
- Inv-1: A Conformance statement must have at least one of rest, messaging or document (xpath: exists(f:rest) or exists(f:messaging) or exists(f:document))
- Inv-2: Must have at least one of description, software, or implementation (xpath: count(f:software | f:implementation | f:description) > 0)
- 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))
Notes:6.12.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
- 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
Search Parameters 6.12.6
Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.
Google Sites
Report abuse