This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201709 FHIR Documents"

From HL7Wiki
Jump to navigation Jump to search
(Replaced content with "{{subst::Template for FHIR Connectathon Track Proposals}}")
Line 1: Line 1:
 +
[[Category:201709_FHIR_Connectathon_Track_Proposals|September 2017 Proposals]]
 +
__NOTOC__
 +
=FHIR Documents=
  
−
[[Category:201709_FHIR_Connectathon_Track_Proposals|Sept 2017 Proposals]]
+
This track will test the exchange of FHIR Documents (using document Bundle resources containing a Composition and other supporting resources).
−
__NOTOC__
 
−
=Track Name=
 
  
 
==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.  
  
 
==Proposed Track Lead==
 
==Proposed Track Lead==
−
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
+
 
−
See [[Connectathon_Track_Lead_Responsibilities]]
+
* Rick Geimer
 +
** Email: rick dot geimer at lantanagroup dot com
 +
** Skype: rgeimer
 +
 
 +
* Sarah Gaunt
 +
** Email: sarah dot gaunt at lantanagroup dot com
  
 
==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. The following persons and organizations have already expressed their intent to participate.
 +
 +
* Lantana Consulting Group (several participants)
 +
* TBD
  
 
==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 -->
 +
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 -->
 
<!-- 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? -->
+
1. Create a narrative document
−
:Success Criteria: <!-- How will the participants know if the test was successful? -->
+
: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.
−
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
+
: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, 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 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. 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: 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
 +
 
 +
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
  
−
<!-- Provide a description of each task -->
 
  
 
==TestScript(s)==
 
==TestScript(s)==
Line 38: Line 87:
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
-->
 
-->
 +
TBD

Revision as of 18:49, 7 June 2017


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.

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 (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, 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 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. 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: 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

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

Retrieved from "https://wiki.hl7.org/w/index.php?title=201709_FHIR_Documents&oldid=140547"