This page is part of the FHIR Specification (v5.0.0-draft-final: Final QA Preview for R5 - see ballot notes). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2
FHIR Infrastructure Work Group | Maturity Level: 5 | Standards Status: Trial Use |
Some of the time when using a FHIR interface, requests to create or update resource instances will behave exactly as the initiator requested. The desired record(s) will be created or revised within the target system and a subsequent query of the data would show the exact same information as was submitted. However, FHIR systems are not guaranteed to behave this way. Without any other agreement between exchange partners, FHIR systems are not obligated to store and return data as it was received. In fact, for some interoperability paradigms, they're not obligated to store any data at all. This page discusses some of the considerations around system behavior, including differences in expectations for systems interoperating using REST, messaging, documents and services.
The most common reason for differences between what data is submitted to a system and what data can be extracted from it is that the system doesn't support all of the data elements present in the instance received. In the base resource, no systems are required to support any particular set of extensions or even any particular subset of core elements.
For elements that are part of the resource, the expectation is that "most" systems will support the element. i.e. most systems will support capturing a patient's name, gender and date of birth. But "most" does not mean "all". It is possible to be fully FHIR conformant and claim to support the Patient resource, but be incapable of storing any of those data elements. There are use-cases where names may be unnecessary (e.g. agricultural veterinary systems, anonymized reporting, etc.) and similar use-cases for almost every data element. No FHIR resource elements start off as mustSupport and very few resource elements start off with a minimum cardinality other than "0".
In the case of extensions, the very nature of a concept being an extension means that the designers of the specification expected that fewer than "most" systems would support the element, though support might vary widely by context. An extension might be used by 100% of systems in some country, discipline, etc. and not used by any systems in another context. In any event, there is no guarantee that an arbitrary receiver will recognize and be able to persist any given extension.
In order to know whether a particular data element is likely to be stored by a given server, a client should check the Capability statement of that server. If, for a given resource, the StructureDefinition pointed to indicates that the element or extension is "mustSupport=true", and the server is capable of storing and returning data in general, then it would be expected that the system will be capable of storing and returning that data element. (Some servers such as decision support systems might not be capable of storing or returning any received data.)
All of these concerns around possibly not storing resource elements or extensions can hold whether the data is sent using REST, Messaging or Services. However, with documents, a consuming system is expected to accept the entire contents of the document without losing any information or altering it in any way.
Even if a system supports all of the data elements provided, not all systems will actually persist the data received or be capable of returning it in response to a query. mustSupport indicates that a system supports an element but does not prescribe exactly what the system must do with supported elements. Data might be persisted, displayed, relayed, analyzed, tabulated or used in a variety of other fashions. The behavior of a given system should be unsurprising given its context, but it is still important to recognize that not all systems will persist the data they receive.
Even if a system stores a given data element, that does not mean it will always include that element when responding to queries. Systems will have access permission rules that restrict who can see a given resource instance and, occasionally, who can see a particular data element within a resource. Systems responding to queries might suppress records or may adjust the content of resource instances to exclude data elements the querying system is not permitted to see.
Some servers may add additional data elements (or more commonly, extensions) based on information they have generated or inferred from data in the resource, from other resources or other information of which the server is aware. i.e. an instance queried after being created or updated might have more information present than was included on the originally submitted record
Servers receiving updates from multiple sources may choose to be selective about what sources they choose to trust for updates to certain information. For example, a patient registry system might choose to only allow updates to name, gender and date of birth from administrative systems but not clinical systems. If a system filters out patient address information from being disclosed to a system when it queries, it will likely choose to not replace or eliminate the addresses it has on file when it receives an update from that system.
One approach commonly followed by HL7 version 2 messaging interfaces is to not update any elements not included in an instance. For example, if a Patient instance were received with no telecom or contact information, all existing telecom and contact information would be retained and only those elements included in the instance would be updated. Technically, this same approach can be followed with FHIR, however it would be atypical and unexpected. Also, unlike HL7 V2 , FHIR does not have a defined construct to use to indicate that a particular data element should explicitly be set to empty if processing a PUT in a mode where omitted elements are typically retained. Systems wishing to fully emulate HL7 V2 behavior will need to use an extension to mirror this behavior.
One of the types of changes that can occur when a resource is created or updated is 'de-containing' a resource - i.e. taking a reference to a contained resource and turning it into a reference to a distinct resource based on pre-existing server information. Typically, this can occur when the server has access to business logic - specifically, statements about uniqueness that can be verified against some repository - that the client does not. However care should always be taken that the re-identification that occurs is reliable between invocations so that 'de-containment' is consistent.
While changing data prior to storage or prior to returning query results is possible, it should not be considered "normal" behavior. It creates several challenges:
FHIR does provide a couple of mechanisms that can help with the issue of a system that has received only partial data overwriting data that was filtered from its record:
UPDATE
or CREATE
request that
is tagged as SUBSETTED>
, and, if so, how to process such a request. It is important that the server
implementation considers how to avoid accidental loss of data to which the updating client did not have access,
and also to consider the possibility that a client update might invalidate data the client was unaware of.
Note that using either of the above mechanisms may constitute a security breach in circumstances where the individual or system accessing the data should not know that the record being reviewed has been modified in any way. (The presence of digital signatures would present a similar issue.)