201709 FHIR Documents

FHIR Documents

This track will test the exchange of FHIR Documents (using document Bundle resources containing a Composition and other supporting resources).

Submitting WG/Project/Implementer Group

• Structured Documents Work Group

Justification

FHIR documents have been maturing, but there are aspects of documents that need more testing, such as digital signatures, the $document operation, decomposing documents into their component resources via the transaction endpoint of a FHIR server, validating document profiles such as C-CDA on FHIR, etc.

Proposed Track Lead

• Rick Geimer
  • Email: rick dot geimer at lantanagroup dot com
  • Skype: rgeimer

• Sarah Gaunt
  • Email: sarah dot gaunt at lantanagroup dot com

Expected participants

Users who are interested in representing the clinical content expected in Consolidated CDA (C-CDA) documents using native FHIR resources are encouraged to participate. The following persons and organizations have already expressed their intent to participate.

• Lantana Consulting Group (several participants)
• TBD

Roles

Document Creator

Creates a FHIR document (Bundle containing a Composition and supporting resources) using whatever means are appropriate, including manual creation, assembling documents from other resources, transforming C-CDA R2.1 XML documents (CDA -> FHIR transform), etc. and submits that document to a FHIR server. Optionally a document creator may digitally sign the document.

Document Consumer

Retrieves a FHIR document created by the Document Creator from the FHIR server and does one or more of the following: a) validates the document against a profile such as C-CDA on FHIR, b) displays the document in a browser using a supplied display stylesheet, c) extracts discrete resources from the document for some other purpose, or d) verifies the digital signature on the document, if present.

Scenarios

For all scenarios below, participants are expected to provide their own content for the documents (obviously nothing with PHI should be used at a public Connectathon). If participants don't have readily available content, they are encouraged to create documents that mimic the content in Consolidated CDA sample files.

1. Create a narrative document

Action: User creates a narrative FHIR document consisting of a Composition resource with narrative sections, bundled with Patient (Composition.subject) and Practitioner (Composition.author) resources. User then POSTs the document to a FHIR server.

Precondition: none, but existing Patient and Practitioner resources may be used.

Success Criteria: Bundle is successful submitted to a FHIR server. Consumer in Scenario 4 can display the document and render all attested content.

Bonus Points: Bundle validates against C-CDA on FHIR profiles.

Basic script:

• Step 1: Create a Composition resource
• Step 2: Ensure the subject, author, and custodian references point to valid Patient, Practitioner, and Organization resources (can create yourself, get from DAF track, or query a FHIR server for them).
• Step 3: POST the Composition to a FHIR server
• Step 4: Check the operation outcome to ensure it was successful
• Step 5: Call $document on the Composition (if supported by the server) to get a full document Bundle back, or create the Bundle through other means (custom code, etc.)

2. Create a narrative document with supporting section entries

Action: User creates a narrative FHIR document consisting of a Composition resource with narrative sections, bundled with Patient and Author resources. User then adds additional resources to sections such as those from the US-Core implementation guide (e.g. US-Core-AllergyIntolerance) with data supporting the narrative. User then POSTs the document to a FHIR server.

Precondition: none, but existing Patient,Practitioner, and other resources may be used, as well as a document that passed Scenario 1.

Success Criteria: Bundle is successful submitted to a FHIR server. Consumer in Scenario 4 can display the document and render all attested content. Consumer in Scenario 5 can extract and parse the resources.

Bonus Points: Bundle validates against appropriate profiles such as US Core or C-CDA on FHIR.

3. Display a document

Action: User retrieves a document submitted under Scenario 1, 2, or 3 from the FHIR server and displays it in a web browser using the supplied stylesheet.

Precondition: A document from Scenario 1, 2, or 3 exists on the target FHIR server.

Success Criteria: Document is successfully displayed.

Bonus Points: User improves the supplied stylesheet.

4. Extract resources from document

Action: User retrieves a document submitted under Scenario 2 or 3 from the FHIR server, then extracts one or more resources from the bundle. This may be done with custom code, or by posting the document to the transaction endpoint of a FHIR server.

Precondition: A document from Scenario 2 or 3 exists on the target FHIR server.

Success Criteria: resources are extracted.

Bonus Points: User creates a new document based partially on data extracted from the original document.

5. Digitally sign FHIR documents

Action: User create a document using any scenario above and digitally signs it. Recipient verifies the signature.

Precondition: A document from any scenario above exists to be signed

Success Criteria: Document is signed and signature is verified

TestScript(s)

TBD