Difference between revisions of "201901 FHIR Documents"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template for FHIR Connectathon Track Proposals}}")
 
 
Line 1: Line 1:
 
 
[[Category:201901_FHIR_Connectathon_Track_Proposals|Jan2019 Proposals]]
 
[[Category:201901_FHIR_Connectathon_Track_Proposals|Jan2019 Proposals]]
 
__NOTOC__
 
__NOTOC__
=Track Name=
+
=FHIR Documents=
 +
 
 +
This track will test the exchange of FHIR Documents (using document Bundle resources containing a Composition and other supporting resources).
 +
 
 +
=FHIR Documents Introductory Slides=
 +
TODO
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
<!-- Who is asking for this track? -->
+
*[[Structured_Documents_Workgroup|Structured Documents Work Group]]
  
 
==Justification==
 
==Justification==
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
 
  
 +
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.
  
==Clinical input requested==
+
==Track Lead==
<!--Please indicate here if you would like input from the the Clinical community please indicate so here. The  connectathon organizers will contact you to follow up. -->
 
  
==Related tracks==
+
* TBD
<!--Other tracks in this event that share similar goals and could either be combined, or an attendee could reasonable do both -->
+
** Email:
 
 
==Proposed Track Lead==
 
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
 
See [[Connectathon_Track_Lead_Responsibilities]]
 
  
 
==Expected participants==
 
==Expected participants==
 
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
 
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
 +
 +
Users who are interested in representing the clinical content expected in Consolidated CDA (C-CDA) documents using native FHIR resources are encouraged to participate.
  
 
==Roles==
 
==Roles==
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
 
 
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
 
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
===Role 1 Name===
+
===Document Creator===
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 +
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===
 +
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 +
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==
 
==Scenarios==
<!-- What will be the actions performed by participants? -->
 
  
===Scenario Step 1 Name===
+
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.
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
+
 
:Precondition: <!-- What setup is required prior to executing this step? -->
+
While this track is about FHIR Documents in general, some may wish 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/
:Success Criteria: <!-- How will the participants know if the test was successful? -->
+
 
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
+
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 other tracks 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.)
  
<!-- Provide a description of each task -->
+
 
 +
 
 +
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. The signature may either be a detached signature (present in a Provenance resource pointing to the document) or an enveloped signature (present in the Bundle itself). An example of an enveloped resource can be found here: https://chat.fhir.org/user_uploads/2/c1/XEIrR_V_O-G6GzBg-kGi8hMW/signed.xml. In all cases the client is responsible for signing the document, not the FHIR server.
 +
:Precondition: A document from any scenario above exists to be signed
 +
:Success Criteria: Document is signed and signature is verified
  
 
==TestScript(s)==
 
==TestScript(s)==
Line 45: Line 84:
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
-->
 
-->
 
+
TBD
==Security and Privacy Considerations==
 
<!-- Optional (for initial proposal): Address the topic of Privacy and Security.
 
* What Authentication/Authorization will be used (e.g. SMART on FHIR (OAuth), HEART (UMA/OAuth), IHE IUA (OAuth), generic OAuth, generic SAML, mutual-Auth-TLS), or explicitly indicate that it is out of scope and left to implementations.
 
* What Privacy Consent management will be used? When the Consent Resource is used, define how.
 
* What Audit Logging will be used? When the AuditEvent Resource is used, define expectations of what events will be logged and what each AuditEvent will contain.
 
* How will Provenance be used? Provenance use should be mandated when data is imported from other systems, so as to track that source of that data. Provenance should be used when data is authored by unusual sources, such as the Patient themselves or devices.
 
* How will security-labels be used? Security-labels are meta tags used to classify the data into various confidentiality, sensitivity, and integrity classifications. These security-labels are then available for use and available for access control decisions.
 
I am happy to help: JohnMoehrke@gmail.com -- security co-chair
 
-->
 

Latest revision as of 23:16, 6 November 2018


FHIR Documents

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

FHIR Documents Introductory Slides

TODO

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.

Track Lead

  • TBD
    • Email:

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.

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 wish 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 other tracks 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. The signature may either be a detached signature (present in a Provenance resource pointing to the document) or an enveloped signature (present in the Bundle itself). An example of an enveloped resource can be found here: https://chat.fhir.org/user_uploads/2/c1/XEIrR_V_O-G6GzBg-kGi8hMW/signed.xml. In all cases the client is responsible for signing the document, not the FHIR server.
Precondition: A document from any scenario above exists to be signed
Success Criteria: Document is signed and signature is verified

TestScript(s)

TBD