Conformance - FHIR v0.0.82

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.7 Resource Conformance - Formal Definitions

Formal definitions for the elements in the Conformance resource.

Conformance
Definition	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.
Control	1..1
Invariants	Defined on this element 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)))
Conformance.identifier
Definition	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).
Control	0..1
Type	string
Summary	true
Conformance.version
Definition	The 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 timestamp.
Control	0..1
Type	string
Summary	true
Comments	There may be multiple different instances of a conformance statement that have the same identifier but different versions.
Conformance.name
Definition	A free text natural language name identifying the conformance statement.
Control	0..1
Type	string
Summary	true
Comments	The name is not expected to be globally unique.
Conformance.publisher
Definition	Name of Organization publishing this conformance statement.
Control	1..1
Type	string
Summary	true
Conformance.telecom
Definition	Contacts for Organization relevant to this conformance statement. The contacts may be a website, email, phone numbers, etc.
Control	0..*
Type	Contact
Summary	true
Conformance.description
Definition	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 RFP.
Control	0..1
Type	string
Summary	true
Comments	This field cmay include the purpose of this conformance statement, comments about its context etc. This does not need to be populated if the description is adequately implied by the software or implementation details.
Invariants	Affect this element Inv-2: A Conformance statement SHALL have at least one of description, software, or implementation (xpath: count(f:software \| f:implementation \| f:description) > 0)
Conformance.status
Definition	The status of this conformance statement.
Control	0..1
Binding	ConformanceStatementStatus: The status of this conformance statement (see http://hl7.org/fhir/conformance-statement-status for values)
Type	code
Is Modifier	true
Summary	true
Comments	This is not intended for use with actual conformance statements, but where conformance statements are used to describe possible or desired systems.
Conformance.experimental
Definition	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 usage.
Control	0..1
Type	boolean
Summary	true
Comments	Allows filtering of conformance statements that are appropriate for use vs. not.
Conformance.date
Definition	The date when the conformance statement was published.
Control	1..1
Type	dateTime
Summary	true
Conformance.software
Definition	Software that is covered by this conformance statement. It is used when the profile describes the capabilities of a particular software version, independent of an installation.
Control	0..1
Summary	true
Invariants	Affect this element Inv-2: A Conformance statement SHALL have at least one of description, software, or implementation (xpath: count(f:software \| f:implementation \| f:description) > 0)
Conformance.software.name
Definition	Name software is known by.
Control	1..1
Type	string
Summary	true
Conformance.software.version
Definition	The version identifier for the software covered by this statement.
Control	0..1
Type	string
Summary	true
Comments	If possible, version should be specified, as statements are likely to be different for different versions of software.
Conformance.software.releaseDate
Definition	Date this version of the software released.
Control	0..1
Type	dateTime
Summary	true
Conformance.implementation
Definition	Identifies a specific implementation instance that is described by the conformance statement - i.e. a particular installation, rather than the capabilities of a software program.
Control	0..1
Summary	true
Invariants	Affect this element Inv-2: A Conformance statement SHALL have at least one of description, software, or implementation (xpath: count(f:software \| f:implementation \| f:description) > 0)
Conformance.implementation.description
Definition	Information about the specific installation that this conformance statement relates to.
Control	1..1
Type	string
Summary	true
Conformance.implementation.url
Definition	A base URL for the implementation. This forms the base for REST interfaces as well as the mailbox and document interfaces.
Control	0..1
Type	uri
Summary	true
Conformance.fhirVersion
Definition	The version of the FHIR specification on which this conformance statement is based.
Control	1..1
Type	id
Summary	true
Conformance.acceptUnknown
Definition	A flag that indicates whether the application accepts unknown elements as part of a resource.
Control	1..1
Type	boolean
Summary	true
Comments	This is not about extensions, but about unknown elements in a resource - these can only arise as later versions of the specification are published, because this is the only place where such elements can be defined. Hence this element is about inter-version compatibility.
Conformance.format
Definition	A list of the formats supported by this implementation.
Control	1..*
Binding	MimeType: see BCP 13 (RFCs 2045, 2046, 2047, 4288, 4289 and 2049)
Type	code
Comments	"xml" or "json" are allowed, which describe the simple encodings described in the specification (and imply appropriate bundle support). Otherwise, mime types are legal here.
Conformance.profile
Definition	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 profile.
Control	0..*
Type	Resource(Profile)
Comments	Supported profiles are different to the profiles that apply to a particular resource in rest.resource.profile. The resource profile is a general statement of what features of the resource are supported overall by the system - the sum total of the facilities it supports. A supported profile is a deeper statement about the functionality of the data and services provided by the server (or used by the client). A typical case is a laboratory system that produces a set of different reports- this is the list of types of data that it publishes. A key aspect of declaring profiles here is the question of how the client converts knowledge that the server publishes this data into working with the data; the client can inspect individual resources to determine whether they conform to a particular profile, but how does it find the ones that does? It does so by searching using the _profile parameter, so any resources listed here must be valid values for the _profile resource (using the identifier in the target profile). Typical supported profiles cross resource types to describe a network of related resources, so they are listed here rather than by resource. However they do not need to describe more than one resource.
Conformance.rest
Definition	A definition of the restful capabilities of the solution, if any.
Control	0..*
Comments	Multiple repetitions allow definition of both client and / or server behaviors or possibly behaviors under different configuration settings (for software or requirements statements).
Invariants	Defined on this element Inv-9: A given resource can only be described once per RESTful mode (xpath: count(f:resource)=count(distinct-values(f:resource/f:type/@value))) Inv-10: A given query can only be described once per RESTful mode (xpath: count(f:query)=count(distinct-values(f:query/f:name/@value))) Affect this element 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))
Conformance.rest.mode
Definition	Identifies whether this portion of the statement is describing ability to initiate or receive restful operations.
Control	1..1
Binding	RestfulConformanceMode: The mode of a RESTful conformance statement (see http://hl7.org/fhir/restful-conformance-mode for values)
Type	code
Conformance.rest.documentation
Definition	Information about the system's restful capabilities that apply across all applications, such as security.
Control	0..1
Type	string
Conformance.rest.security
Definition	Information about security of implementation.
Control	0..1
Conformance.rest.security.cors
Definition	Server adds CORS headers when responding to requests - this enables javascript applications to yuse the server.
Control	0..1
Type	boolean
Comments	The easiest CORS headers to add are Access-Control-Allow-Origin: * & Access-Control-Request-Method: GET, POST, PUT, DELETE.
Conformance.rest.security.service
Definition	Types of security services are supported/required by the system.
Control	0..*
Binding	RestfulSecurityService: Types of security services used with FHIR (see http://hl7.org/fhir/restful-security-service for values)
Type	CodeableConcept
Conformance.rest.security.description
Definition	General description of how security works.
Control	0..1
Type	string
Conformance.rest.security.certificate
Definition	Certificates associated with security profiles.
Control	0..*
Conformance.rest.security.certificate.type
Definition	Mime type for certificate.
Control	0..1
Binding	MimeType: see BCP 13 (RFCs 2045, 2046, 2047, 4288, 4289 and 2049)
Type	code
Conformance.rest.security.certificate.blob
Definition	Actual certificate.
Control	0..1
Type	base64Binary
Conformance.rest.resource
Definition	A specification of the restful capabilities of the solution for a specific resource type.
Control	1..*
Comments	Max of one repetition per resource type.
Invariants	Defined on this element Inv-11: Operation codes must be unique in the context of a resource (xpath: count(f:operation)=count(distinct-values(f:operation/f:code/@value))) Inv-12: Search parameter names must be unique in the context of a resource (xpath: count(f:searchParam)=count(distinct-values(f:searchParam/f:name/@value)))
Conformance.rest.resource.type
Definition	A type of resource exposed via the restful interface.
Control	1..1
Binding	ResourceType: Any defined Resource Type name
Type	code
Conformance.rest.resource.profile
Definition	A specification of the profile that describes the solution's support for the resource, including any constraints on cardinality, bindings, lengths or other limitations.
Control	0..1
Type	Resource(Profile)
Comments	The profile applies to all resources of this type - i.e. it is the superset of what is supported by the system.
Conformance.rest.resource.operation
Definition	Identifies a restful operation supported by the solution.
Control	1..*
Conformance.rest.resource.operation.code
Definition	Coded identifier of the operation, supported by the system resource.
Control	1..1
Binding	RestfulOperationType: Operations supported by REST at the type or instance level (see http://hl7.org/fhir/type-restful-operation for values)
Type	code
Conformance.rest.resource.operation.documentation
Definition	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'.
Control	0..1
Type	string
Requirements	REST allows a degree of variability in the implementation of RESTful solutions that is useful for exchange partners to be aware of.
Conformance.rest.resource.readHistory
Definition	A flag for whether the server is able to return past versions as part of the vRead operation.
Control	0..1
Type	boolean
Comments	It is useful to support the vRead operation for current operations, even if past versions aren't available.
Conformance.rest.resource.updateCreate
Definition	A 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 server.
Control	0..1
Type	boolean
Comments	Allowing the clients to create new identities on the server means that the system administrator needs to have confidence that the clients do not create clashing identities between them. Obviously, there is only one client, this won't happen. While creating identities on the client means that the clients need to be managed, it's much more convenient for many scenarios.
Conformance.rest.resource.searchInclude
Definition	A list of _include values supported by the server.
Control	0..*
Type	string
Comments	If this list is empty, the server does not support includes.
Conformance.rest.resource.searchParam
Definition	Additional search parameters for implementations to support and/or make use of.
Control	0..*
Conformance.rest.resource.searchParam.name
Definition	The name of the search parameter used in the interface.
Control	1..1
Type	string
Comments	Parameter names cannot overlap with standard parameter names, and standard parameters cannot be redefined.
Conformance.rest.resource.searchParam.definition
Definition	A formal reference to where this parameter was first defined, so that a client can be confident of the meaning of the search parameter.
Control	0..1
Type	uri
Comments	This SHALL be populated for all search parameters not defined as part of the core FHIR specification. The uri is the uri of the profile defining the parameter followed by "#" followed by the structure name and search parameter name.
Conformance.rest.resource.searchParam.type
Definition	The type of value a search parameter refers to, and how the content is interpreted.
Control	1..1
Binding	SearchParamType: Data types allowed to be used for search parameters (see http://hl7.org/fhir/search-param-type for values)
Type	code
Comments	While this can be looked up from the definition, it is included here as a convenience for systems that auto-generate a query interface based on the server conformance statement. It SHALL be the same as the type in the search parameter definition.
Conformance.rest.resource.searchParam.documentation
Definition	This allows documentation of any distinct behaviors about how the search parameter is used. For example, text matching algorithms.
Control	0..1
Type	string
Conformance.rest.resource.searchParam.target
Definition	Types of resource (if a resource is referenced).
Control	0..*
Binding	ResourceType: Any defined Resource Type name
Type	code
Comments	This SHALL be the same as or a proper subset of the resources listed in the search parameter definition.
Conformance.rest.resource.searchParam.chain
Definition	Chained names supported.
Control	0..*
Type	string
Conformance.rest.operation
Definition	A specification of restful operations supported by the system.
Control	0..*
Conformance.rest.operation.code
Definition	A coded identifier of the operation, supported by the system.
Control	1..1
Binding	RestfulOperationSystem: Operations supported by REST at the system level (see http://hl7.org/fhir/system-restful-operation for values)
Type	code
Conformance.rest.operation.documentation
Definition	Guidance specific to the implementation of this operation, such as limitations on the kind of transactions allowed, or information about system wide search is implemented.
Control	0..1
Type	string
Conformance.rest.query
Definition	Definition of a named query and its parameters and their meaning.
Control	0..*
Invariants	Defined on this element Inv-13: Search parameter names must be unique in the context of a query (xpath: count(f:parameter)=count(distinct-values(f:parameter/f:name/@value)))
Conformance.rest.query.name
Definition	The name of a query, which is used in the _query parameter when the query is called.
Control	1..1
Type	string
Conformance.rest.query.definition
Definition	Identifies the custom query, defined either in FHIR core or another profile.
Control	1..1
Type	uri
Conformance.rest.query.documentation
Definition	Additional information about how the query functions in this particular implementation.
Control	0..1
Type	string
Conformance.rest.query.parameter
Definition	Identifies which of the parameters for the named query are supported.
Control	0..*
Type	See Conformance.rest.resource.searchParam
Comments	This SHALL be a proper subset of the parameters defined on the query definition.
Conformance.rest.documentMailbox
Definition	A 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 purpose.
Control	0..*
Type	uri
Comments	If a server accepts messages on the /Mailbox end-point, it declares this in the messaging elements.
Conformance.messaging
Definition	A description of the messaging capabilities of the solution.
Control	0..*
Comments	Multiple repetitions allow the documentation of multiple endpoints per solution.
Invariants	Defined on this element Inv-3: Messaging end point is required (and is only permitted) when statement is for an implementation (xpath: exists(f:endpoint) = exists(parent::f:Conformance/f:implementation)) Inv-6: The set of events per messaging endpoint must be unique by the combination of code & mode (xpath: 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))) Affect this element 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))
Conformance.messaging.endpoint
Definition	An address to which messages and/or replies are to be sent.
Control	0..1
Type	uri
Comments	For solutions that do not use network addresses for routing, it can be just an identifier.
Invariants	Affect this element Inv-3: Messaging end point is required (and is only permitted) when statement is for an implementation (xpath: exists(f:endpoint) = exists(parent::f:Conformance/f:implementation))
Conformance.messaging.reliableCache
Definition	Length if the receiver's reliable messaging cache (if a receiver) or how long the cache length on the receiver should be (if a sender).
Control	0..1
Type	integer
Comments	If this value is missing then the application does not implement (receiver) or depend on (sender) reliable messaging.
Conformance.messaging.documentation
Definition	Documentation 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 partner.
Control	0..1
Type	string
Conformance.messaging.event
Definition	A description of the solution's support for an event at this end point.
Control	1..*
Comments	The same event may be listed up to two times - once as sender and once as receiver.
To Do	Need to add follow-ups and need to do more to flesh out messaging dynamic model.
Conformance.messaging.event.code
Definition	A coded identifier of a supported messaging event.
Control	1..1
Binding	MessageEvent: the Event List in the messaging framework
Type	Coding
To Do	May need a profile id as well if profiles can define message events.
Conformance.messaging.event.category
Definition	The impact of the content of the message.
Control	0..1
Binding	MessageSignificanceCategory: The impact of the content of a message (see http://hl7.org/fhir/message-significance-category for values)
Type	code
Conformance.messaging.event.mode
Definition	The mode of this event declaration - whether application is sender or receiver.
Control	1..1
Binding	ConformanceEventMode: The mode of a message conformance statement (see http://hl7.org/fhir/message-conformance-event-mode for values)
Type	code
Conformance.messaging.event.protocol
Definition	A list of the messaging transport protocol(s) identifiers, supported by this endpoint.
Control	0..*
Binding	MessageTransport: The protocol used for message transport (see http://hl7.org/fhir/message-transport for values)
Type	Coding
To Do	Loosen this to "extensible" once tooling supports that.
Conformance.messaging.event.focus
Definition	A resource associated with the event. This is the resource that defines the event.
Control	1..1
Binding	ResourceType: Any defined Resource Type name
Type	code
Comments	This SHALL be provided if the event type supports multiple different resource types.
Conformance.messaging.event.request
Definition	Information about the request for this event.
Control	1..1
Type	Resource(Profile)
Conformance.messaging.event.response
Definition	Information about the response for this event.
Control	1..1
Type	Resource(Profile)
Conformance.messaging.event.documentation
Definition	Guidance on how this event is handled, such as internal system trigger points, business rules, etc.
Control	0..1
Type	string
Conformance.document
Definition	A document definition.
Control	0..*
Invariants	Affect this element 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))
Conformance.document.mode
Definition	Mode of this document declaration - whether application is producer or consumer.
Control	1..1
Binding	DocumentMode: Whether the application produces or consumes documents (see http://hl7.org/fhir/document-mode for values)
Type	code
Conformance.document.documentation
Definition	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, etc.
Control	0..1
Type	string
Conformance.document.profile
Definition	A constraint on a resource used in the document.
Control	1..1
Type	Resource(Profile)
Comments	The first resource is the document resource.