This page is part of the FHIR Specification (v0.4.0: DSTU 2 Draft). 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

?.? Creates and Updates in FHIR

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.

?.?.1 Data element support

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's 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-case where names may be unnecessary (e.g. aggricultural 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 "1".

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 very widely by context. An extension might be used by 100% of systems in some country, discipline, etc. while be used by absolutely no 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 Conformance statement of that server. If, for a given resource, the Profile pointed to indicates that the element or extension is "mustSupport=true", then it is likely that the system will be capable of storing and returning that data element.

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.

?.?.2 System behavior

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, tabulate or used in a variety of other fashions. The behavior of a given system should be unsurprising given its context, but it's still important to recognize that not all systems will persist the data they receive.

?.?.3 Access permissions

Even if a system stores a given data element, that doesn't mean it will always include that element when responding to queries. Systems will have access permssion 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.

?.?.4 Generated and inferred data

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

?.?.5 Data integration

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. This same approach can be followed with FHIR, however, 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. Systems wishing to fully emulate v2 behavior will need to use an extension to mirror this behavior.

?.?.6 Ramifications of storage variations

While changing data from what is submitted in update and create requests is possible, it should not be considered "standard" behavior. It creates several challenges:

• Digital signatures will no longer be valid. Any change to submitted data will break standard signatures. In theory, this could be mitigated by using a custom canonicalization for the signature that excludes maliable elements. However, this would require both sender and receiver to agree on the alternate signature canonicalization. The signature would still be considered invalid by systems that weren't party to the agreement.
• Workflows can be made more complex. A system that sends a create and then sends an update presuming that it has seen the most "current" version, could accidentally overwrite information set by the server as part of the create process. (This can be mitigated by not returning an up-to-date ETag.)
• Audit becomes more complicated. The SecurityEvent resource points to a specific resource version when tracking what data was returned by a query. If the record is modified when it is returned, then the audit record will likely need to be supplemented with information about what elements were filtered.
• Multiple views of the same information by different people (or even by the same people in different contexts) may cause confusion, particularly when attempting to coordinate care across a team. Providing OperationOutcome instances containing warnings if information has been suppressed may be helpful, though doing this may not be possible, depending on security policy rules.
• If data is lost as part of the transmission process, then multiple stages of transmission (or even round-tripping of data) could result in significant degradation as information passes through multiple systems.