|
|
| Line 1: |
Line 1: |
| − | [[Category:201709_FHIR_Connectathon_Track_Proposals|September 2017 Proposals]]
| |
| − | __NOTOC__
| |
| − | =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==
| |
| − | *[[Structured_Documents_Workgroup|Structured Documents Work 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==
| |
| − | <!-- 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 are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
| |
| − | ===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 -->
| |
| − | 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)==
| |
| − | <!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested.
| |
| − | These should be committed to SVN under trunk/connectathons/[connectathon]
| |
| − | -->
| |
| − | TBD
| |
