201605 C-CDA on FHIR Connectathon Proposal

Return to May 2016 Proposals

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)

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

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.

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.

6. Extract DAF resources from document, updates content and replaces document with new version

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