201609 C-CDA on FHIR

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

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
• 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

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.

TestScript(s)

TBD