Description

This operation can be used to convert a FHIR Clinical Document into a FHIR transaction bundle.

This IG further expands on the Document End-Points discussion in FHIR Documents by providing a FHIR Operation that encapsulates the conversion of a FHIR bundle from type=document to type=transaction. The operation is generally used as a prelude to parsing the clinical document, extracting individual objects from the document for storage, querying, etc. General steps in the conversion might include: (1) Revise Bundle.type to "transaction"; (2) Ensure references within the bundle are not pointing to resource.id, but instead are pointing to a resource instance's full URL or other unique identifier; (3) Set Bundle.entry.request.method to "POST".

As described in Special Topic Immutable and parseable clinical documents, FHIR Clinical Documents are used in a number of different ways, where users may need to store a received document as an immutable object and/or parse a received document to extract observations and other entries. Parsing a received clinical document can entail not only processing all of the resources that it contains as individual resources, but may also entail identifying those objects that have already been received so as to avoid creation of duplicates, and assessing each object's revision status such that a server correctly supersedes previously obtained objects with newly received amended objects.

This operation performs step one of a parse and store objective, by converting a document bundle into a transaction bundle. From there, automated reconciliation of revised objects can be implemented in a number of ways. For instance, with Observation Resource, one might perform a conditional update on a previously stored object, where the update is applied to the stored Observation that has the same identifier and effectiveDateTime as the newly received amended Observation. Alternatively, one can simply store all objects, deferring to another system such as a document management system to collect objects and determine which are active. Yet another approach is to both store all new objects and update the status of previously stored objects to indicate that they have been superceded.

Different servers may generate different transaction bundles - e.g. one server's transaction bundle may only inlude POST requests while another server's transaction bundle may also include PUT requests (e.g. for conditional updates). This operation returns the transaction bundle to the client so that they can optionally inspect it before opting to load it.

Based on ballot feedback, the committee will consider modifying this operation to bypass the interim step of returning the intermediary transaction bundle and instead simply process the posted FHIR Clinical Document and return the results of an attempted parse and store.

Automated reconciliation is an experimental workflow. We are seeking reviewer input on the need for an operation that parses the resultant transaction bundle and stores the component objects, cognizant of revision semantics. In addition, we would like to know how the reviewer might anticipate implementing automated reconciliation.