201709 FHIR Documents
Return to September 2017 Proposals
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
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.
While this track is about FHIR Documents in general, some may with to create documents compliant with the C-CDA on FHIR spec. The current build of that spec can be found here: http://build.fhir.org/ig/HL7/ccda-on-fhir/
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
