Submitting WG/Project/Implementer Group
Justification and Objectives
The aim of this track is to evaluate the exchange of primary care records being exchanged from one primary care system to another, following the implementation guide developed through the Primary Care Data Quality project at http://build.fhir.org/ig/aehrc/primary-care-data-technical/index.html
Thus far, the IG includes sections and profiles for medical history (procedures, conditions), current medicines list, adverse reactions, immunisations, family history, social history and pregnancy.
This track will use the R4 version of FHIR.
Clinical input requested (if any)
Input from clinicians, particularly those involved in primary care, e.g. general practitioners/family medicine practitioners, practice managers or practice nurses, particularly in providing realistic (but not real) examples of the kinds and values for data that might be exchanged in this scenario, and the workflow that might apply to it.
Related tracks
2020-02 ePrescribing Track (Active Script List), Child Health Track
Proposed Track Lead
Jim Steel, Jim.Steel@csiro.au.
Expected participants
Australian Primary Care vendors, and others who share data with them. International vendors who might be interested in similar interoperability scenarios.
Participants from the Gravity Project who will be exploring early development on a use case to Gather SDOH Info in a Clinical Encounter (Contact Lisa Nelson, LNelson@max.md )
Track Orientation
A webinar will be hosted on date at time to share further participation information about this track. TBD
System Roles
Exporter
Scenario
Given a case description, produce a FHIR export of a patient record for transmission to another system.
Scenario Step 1 Name
Action: Export patient record as FHIR Bundle/Composition.
Precondition: Case entered into clinical system ready for export
Success Criteria: Patient record can be successfully validated and includes all necessary elements.
Bonus point: User interface for performing export
Importer
Scenario
Given a case description, produce a FHIR export of a patient record for transmission to another system.
Scenario Step 1 Name
Action: Import patient record as FHIR Bundle/Composition.
Precondition:
Success Criteria: Patient record can be successfully imported and viewed in importing system and includes all necessary elements.
Bonus point: User interface for performing import
Renderer
Scenario
Given a case description, render a human-readable representation of a FHIR export of a patient record for reading and/or validation by a clinician.
Scenario Step 1 Name
Action: Render a human-readable version of a patient record as FHIR Bundle/Composition.
Precondition: Provision of patient record as FHIR Bundle/Composition
Success Criteria: Patient record can be rendered and includes all necessary elements.
Bonus point: User interface for performing export or import, or appropriate control for clinician review/curation of content.
Gravity Scenario - Gather and Share Social Determinants of Health (SDOH) Information in a Clinical Encounter
Link to Social Determinants of Health (SDOH-CC) IG
System Roles
System Actor | Description of the Technical Role |
PMEHR (Practice Management/EHR) | The system that initiates the task to request patients to be screened using a certain screening questionnaire. |
Screening App | The system that receives the screening request and then initiates screening of patient through the Patient App. This system sends completed questionnaire responses to the intended recipient. |
Patient App | The system that enables a patient to complete a screening questionnaire. (May be grouped with the Screening App) |
Clinical Data Reg/Repo (Registry/Repository) | A system that requests clinical information which may include SDOH information also gathered during clinical care encounters. |
Actor Transaction Diagram
Use Case 1 - Sequence Diagram
Scenario
Gather and Share SDOH Information in a Clinical Encounter
Scenario Step 1 Initial Screen Patients Task
Action: PMEHR initiates a task for screening patients via the Screening App FHIR API. PMEHR supplies the Questionnaire and Patient List for the requested screening task.
Precondition: PMEHR has a developed Questionnaire screening tool that conforms to SDC Questionnaire and has a means to determine the right list of patients to be screened. Establish the endpoint to be used by Screening App for workflow requests.
Success Criteria: Screening App receives the Task request, Questionnaire, Patient List, and any other needed resources such as the Organization requesting the task to be performed and the Endpoint where Consent and QuestionnaireResponses information should be returned.
Bonus point: Develop more than one type of SDOH Questionnaire using Coded questions and Answers using the LHC Form Builder Tool.
Link to guidance from the Structured Data Capture IG.
Scenario Step 2 Perform Screen Patients Task
Action: Screening App interacts with Patient App to initiate consent to share SDOH questionnaire responses and, if agreed, administers the questionnaire and gathers the responses. Upon receiving a submitted questionnaire response, the Screening App returns the Consent and QuestionnaireResponse to the endpoint indicated in the Questionnaire.
Precondition: PMEHR endpoint for processing QuestionnaireResponses and Consent Resources was indicated in the Questionnaire using the SDC Questionnaire extension to support this element (sdc-questionnaire-endpoint)
Success Criteria: Patient's Consent and QuestionnaireResponse can be accepted, stored (associated with the correct patient), and viewed on the PMEHR.
Bonus point: Process more than one patient in a single task.
Scenario Step 3 Notify Task Initiator that Task is Completed
Action: Screening App sends message to PMEHR (task initiator) to indicate the requested task has been completed.
Precondition: Establish the endpoint to be used by PMEHR for workflow updates. Task has an expiration date/time set so task completion can be established when responses have been received from all requested patients on the list or when the task expiration date is reached.
Success Criteria: PMEHR App can display the status of the Task, and it shows as completed. (Dashboard previously showed "active")
Bonus point: At the point of receiving the Task completed message, and based on received QuestionnaireResponses, PMEHR computes what portion of the requested list of patients completed the screening task.
Scenario Bonus Step 4 & 5 Complete a Solicited Communication for a Progress Note Document Generated Following the Clinical Encounter
Action: Clinical Data Requestor/Recipient communicates a request to the PMEHR for a Progress Note for the Patient following the visit.
Precondition: PMEHR gathered documentation during the encounter and recorded SDOH information in the same system using consistent mechanisms to permit the SDOH information to be part of the visit "SOAP NOTE" documentation.
Success Criteria: PMEHR receives and processes the request then returns a solicitted Communication that includes the requested document.
Bonus point: Use the RESTful data processing mechanisms defined by CDex to query for the Patient's Food Insecurity Observation.
Link to Clinical Data Exchange (CDex) IG.
Link to Prior CDex Connectathon Track guidance.
TestScript(s)
Indicate any test scripts that will be used to help verify system behavior. TBD.
Security and Privacy Considerations
Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate