201701 Unscheduled Care
Unscheduled Care
Submitting WG/Project/Implementer Group
- Emergency Care Working Group
- T-System, Inc.
Justification
The domain of unscheduled care – Emergency Department or Urgent Care visits – presents challenges that are unique in comparison with primary care or hospital inpatient care:
- Medical history is often limited and out-of-date
- Information about the patient or the present illness can be very scarce or even non-existent
- Multiple providers are involved by definition (EMTs, Emergency Department nurses and physicians, lab and radiology technicians, pathologists, radiologists, hospital ICU providers, etc.)
- There is no single system that is the owner/master of the patient data so data reconciliation is needed in many cases
- Time is usually a much more important factor than in other care settings
The intent of this track is twofold:
- Validate FHIR resources in the scenarios below:
- Are there missing fields that are required in the space of unscheduled care?
- Are there elements that are required by the specification that do not apply/do not exist in the space of unscheduled care?
- Are there any additional resources that, if there, would greatly simplify system interoperability in the space of unscheduled care?
- Test the idea of a profile specific to Emergency Care
Proposed Track Lead
Sorin Voicu (sorinvc at gmail dot com) See Connectathon_Track_Lead_Responsibilities
Expected participants
- T-System, Inc.
- Please email sorinvc at gmail dot com if you are interested in participating. We would like to have this track added to the January 2017 Connectathon.
Roles
EDIS
FHIR-compliant Emergency Department or Urgent Care Information System that is used to document elements directly related to the episode of care (procedures, administered medications, lab/radiology orders, lab/radiology results, diagnoses, codes (CPT, ICD, etc.)).
EHR/HIS
FHIR-compliant Hospital or Practice Management Information System that manages administrative data (e.g., patient demographics, insurance information, etc.) and historical patient information (i.e., medical history based on previous encounters).
Vital Sign Monitor Device
FHIR-compliant Vital Sign monitor device that sends vital sign readings to the EDIS.
ePCR
FHIR-compliant electronic Patient Care Reporting or Emergency Medical Services Information System that manages pre-arrival patient data and communicates the data to EDIS and HIS.
LIS
FHIR-compliant Lab Information System that receives diagnostic orders and sends back diagnostic order results.
RIS
FHIR-compliant Radiology Information System that receives diagnostic imaging orders and sends back diagnostic imaging order results.
There are multiple additional roles that can participate in these interactions – Data Analytics engines querying any of the systems above, HIE repositories, registries (e.g., Syndromic Surveillance, Trauma, etc.), post-discharge follow-up systems, devices (e.g., Medication Cabinets) – but we chose to keep the scenarios fairly simple to allow some the fundamental aspects of the interactions to be worked out.
Scenarios
EMS Patient
- Pre-arrival registration (EMS → EDIS)
- Cannot transmit Protected Health Information at this point
- Registration (EMS → HIS)
- Protected Health Information can be shared at this point
- Registration (HIS → EDIS)
- Medical History retrieval on-demand
- Get allergies from HIS
- Get medications from HIS
- Get problems from HIS
- Vital sign monitoring (monitor → EDIS)
- Order placement (EDIS → LIS or RIS)
- Order result (LIS or RIS → EDIS)
- Discharge information (EDIS → HIS)
- CDA
- HIS consumes/integrates CDA information
Ambulatory Patient
- Registration (EMS → HIS)
- Protected Health Information can be shared at this point
- Registration (HIS → EDIS)
- Medical History retrieval on-demand
- Get allergies from HIS
- Get medications from HIS
- Get problems from HIS
- Vital sign monitoring (monitor → EDIS)
- Order placement (EDIS → LIS or RIS)
- Order result (LIS or RIS → EDIS)
- Discharge information (EDIS → HIS)
- CDA
- HIS consumes/integrates CDA information
We foresee the following aspects that would require discussion and resolution during the Connectathon:
- User identity: Is there one entity that manages this across systems for the flow or do users have multiple identities?
- Is data pushed by data owner to data user (i.e., Add patient, Add allergy intolerance, Add condition, etc.) or requested by the data user based on a trigger/hook (i.e., Get patient, Get allergy intolerance, Get condition, etc.)?
- Is a REST-ful approach best in these interactions or would documents or messages be more appropriate?
- Is reconciliation by the data user needed or does the data user modify resources directly in the data owner system?
Resources Involved
- Patient
- Encounter
- AllergyIntolerance
- Condition
- MedicationStatement
- MedicationOrder
- DiagnosticRequest
- DiagnosticReport
- Observation
- Composition
