Submitting WG/Project/Implementer Group
Justification and Objectives
The US Core Implementation Guide version 3.1.0 which is based on FHIR R4 is the basis for further testing and guidance by the Argonaut Project Team. The guide will retain the US Core artifacts and names and provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing of the servers for conformance to the profiles and be capable of responding to all of the “supported searches” specified in the US Core Implementation Guide Server CapabilityStatement.
Eric Haas email@example.com
Brett Marquard firstname.lastname@example.org
Link to informal poll for your intent to participate:
For this Connectathon we are using the official Conman tool to signup if you are participating
(See the Sprint Tracker! spreadsheet for participants in the 2019 September Connectathon.)
We will use the Argonaut stream in Zulip for communication before, during, and after the connectathon: https://chat.fhir.org/#narrow/stream/179175-argonaut
The following actors are part of the US Core IG:
- US Core Requestor: An application that initiates a data access request to retrieve patient data. This can be thought of as the client in a client-server interaction.
- US Core Responder: A product that responds to the data access request providing patient data. This can be thought of as the server in a client-server interaction.
Please review the US Core Implementation Guide for the supported ArgoR4/US Core profiles, and searches as well as the extensive guidance surrounding each set of queries and profile usage.
See the Conman for signup information and participant details and endpoint access instructions
Test the servers for conformance to the ArgoR4/US Core profiles response to all of the “supported searches” documented in the "Quick Start" sections and specified in the Argonaut Data Query Implementation Guide Server CapabilityStatement for these profiles:
For Example in US Core AllergyIntolerance Quick Start:
... and the corresponding CapabilityStatement:
- Demonstrate Conformance to the latest US Core profiles
- Successfully retrieve clinical data for a single patient using the US Core profiles with the “SHALL support” searches specified in the US Core IG Quick Start Section.
- Including retrieval of clinical notes as described in the Clinical Notes Guidance Page
- Including retrieval of Medication List as described in the Medication List Guidance Page
- Successfully retrieve data provenance in addition to the clinical data for a single patient using the included US Core Provenance artifacts with the “SHALL support” searches specified in the Argo R4 IG Provenance Quick Start section.
- Successfully retrieve a "on demand" CCD document for a single patient using the $docref operation specified in the US Core IG.
- Successfully retrieve US Core artifacts using the defined as “SHOULD support” searches specified in the US Core IG for a single patient.
- Additional pilot Testing of UDI elements - Sincethe January ballot of 2019 in cooperations with the FDA, US Core include all the component parts of UDI in US Core Implantable Device profile.
- Very little guidance is provided on writing and updating data in the context of US Core profiles. There are multiple issues that will need to be considered when defining expected behavior by the various actors to support updates and writes to the data including: Currently the IG defines write for only Clinical notes as described in the Clinical Notes Guidance Page and the CapabiltyStatement.
( here is the link: https://inferno.healthit.gov/inferno/ )
( here is the link: https://www.getpostman.com/collections/26da0121ec41d5c98d98 or check out this Postman Published Collection on public server: https://documenter.getpostman.com/view/1447203/SVmsTzP4)
- Every Query
- Set up environment and patient Id and you are good to go ( Note that this collection is a Work in Progress since the last Connectathon and not be fully functional )
- sample synthetic data that is conformant to US Core R4
- See the Synthea documentation for details!
Security and Privacy Considerations
Refer to individual Server implementation details in the Sprint Tracker! Spreadsheet.
2020-01 US Core
Postman Collection connected with Cerner Sandbox.
- planning to maintain the Collection and share.
- add Visualizer
- Tested with Epic - update for easier connecting
- Still requiring status
- number of validation issues that tracking down
- Identified issue using HL7 terminology validator (didn’t have IDC9 loaded)
- Reported problem with it flagging unrecognized extensions
- Do we need to have tests to see dataAbsentReason (DAR) used at least once?
- Considering At least the must supports
- Discuss whether should limit MR profile: with intent = 'order' to be computable.
- Follow up for trackers to Hl7 to add "unknown" concept to the following Base FHIR resources.
- - AllergyIntolerance.clinicalStatus
- - Condition.clinicalStatus
- - DocumentReference.status
- - Immunization.status
- - Goal.lifecycleStatus
- Technical Corrections to US Core
- On CapabilityStatement Server page remove Provenance requirement from Medication, Location, Practitioner, PractitionerRole, and Organization
- In USCDI Table = change 'MedicationStatement' change to 'MedicationRequest'Remove MedicationStatement on guidance page.
- Clarify that Location/PractitionerRole are not being referenced by other resources intentionally as part of a tracker item.
- Fix bullet 2 in medication list guidance to clarify in intent = 'order' (should be sub-bulleted)
- Add Write to DocRef QuickStart (removed from 3.1.0 in editing error)
- Add explicit SHALL support search with status if status required to the guidance on the For Servers Requiring Status
- Clarify text in clinical notes guidance on 'minimum required' to reference only the DocRef. and that the DiagnosticReport codes are strongly suggested but not required as id defined in the profile's bindings.
- Discuss strategy and timing of a technical correction timeline vis a vis the rule announcements. road map TBD
- Strategy on expansion of US Core