201704 C-CDA on FHIR

Return to April 2017 Value-Based Care FHIR Mini-Connectathon

C-CDA on FHIR

This track will test the exchange of Clinical Documents (using document Bundle resources containing a Composition and other supporting resources) that conform to the profiles of the in-progress C-CDA on FHIR Implementation Guide.

Submitting WG/Project/Implementer Group

• Structured Documents Work Group

Justification

The Structured Documents Work Group is creating an Implementation Guide with a set of profiles (using the StructureDefinition resource) that represent Consolidated CDA documents using FHIR, and the work needs the kind of active testing and review that only a Connectathon can provide. Also, it has been a long time since a FHIR Connectathon has had a document track, and the Composition resource has changed significantly during that time so even the base resource could stand some more live testing.

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)
• Oliver Lawless
• Lisa Nelson (Janie Appleseed powered by MaxMD)
• Gay Dolin
• Lenel James (+ at least one payer and one payer-stakeholder vendor)
• Dynamic Health IT (several participants)
• Brett Marquard
• Corey Spears & Ron Archambault from Infor
• Howard Edidin
• ZeOmega
• A|D Vault

Roles

Document Creator

Creates a C-CDA on 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.

Document Consumer

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

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 C-CDA on 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 (example: http://fhirtest.uhn.ca/baseDstu3/Composition/140064)
• 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.
• Step 6: Call $validate on the Composition to see if it is valid against the C-CDA on FHIR profile.

2. Create a narrative document with supporting DAF resources

Action: User creates a narrative C-CDA on FHIR document consisting of a Composition resource with narrative sections, bundled with Patient and Author resources. User then adds additional Data Access Framework resources (e.g. DAF-AllergyIntolerance) with data supporting the narrative. User then POSTs the document to a FHIR server.

Precondition: none, but existing Patient,Practitioner, and DAF 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 DAF resources.

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

3. Create a document from DAF resources and generate corresponding narrative

Action: User creates C-CDA on FHIR document consisting of a Composition resource bundled with Patient and Author resources. User then adds additional Data Access Framework resources (e.g. DAF-AllergyIntolerance). Finally, user generates appropriate Composition.text and Composition.section.text content from the referenced resources. User then POSTs the document to a FHIR server.

Precondition: none, but existing Patient,Practitioner, and DAF 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. Consumer in Scenario 5 can extract and parse the DAF resources.

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

4. Display a narrative 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.

5. Extract DAF resources from document

Action: User retrieves a document submitted under Scenario 2 or 3 from the FHIR server, then extracts one or more DAF resources from the bundle.

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

Success Criteria: DAF resource is extracted.

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

Hint: try posting to the transaction endpoint of a FHIR server to do this automatically

6. Extract DAF resources from document, updates content and replaces document with new version or creates an entirely new document.

Action: User retrieves a document submitted under Scenario 2 or 3 from the FHIR server, then posts a new version of the document on the FHIR server.

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

Success Criteria: Composition resource for the retrieved document is updated to a new version on the FHIR server.

Bonus Points: User extracts DAF resource data from the original document and reconciles it with the new information before posting the reconciled version of the document.

7. Digitally signed C-CDA on 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

8. Patient Voice - Basic Scenario

Action: Perform Scenarios 1,2,3 and 4 (above) using a standard HL7 Personal Advance Care Plan Document

Scenario Story: Consumer creates a Personal Advance Care Plan (PACP) Document and registers it with an AD Registry. A clinical system retrieves the person's advance directives information by getting the PACP Document from the registry. The Clinical System attaches the PACP Document to the patient's record in their system and renders it for a Care Manager to support care planning for the patient.

Precondition: None

Success Criteria: Patient Generated Document is created and made available to be retrieved and rendered for clinician review

8. Patient Voice - Bonus Scenario

Action: Perform Scenario 5 (above) using a standard HL7 Personal Advance Care Plan Document

Scenario Story: Consumer creates a Personal Advance Care Plan (PACP) Document and registers it with an AD Registry. A clinical system retrieves the person's advance directives information by getting the PACP Document from the registry. The Clinical System attaches the PACP Document to the patient's record in their system and renders it for a Care Manager to support care planning for the patient. The inclusion of Patient Goals is automated for the Care Manager. The Care Plan Management System enables Patient Goals to be selected from the PACP to populate information in the patient's Care Plan without the Care Manager having to manually enter the person's goals, preferences, and care priorities.

Precondition: None

Success Criteria: Patient Generated Document is created and made available to be retrieved and rendered for clinician review

TestScript(s)

TBD