201701 Unscheduled Care

Return to January 2017 Proposals

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:

1. 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?
2. Test the idea of a profile specific to Emergency Care

Proposed Track Lead

Sorin Voicu (svoicucomendant at tsystem dot com) See Connectathon_Track_Lead_Responsibilities

Expected participants

• T-System, Inc.
• Please email svoicucomendant at tsystem 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

1. Pre-arrival registration (EMS → EDIS)

   Cannot transmit Protected Health Information at this point

   Create minimal Patient and Encounter (Last Name=EMS Unit Name, Given Name=chief complaint, Gender, Age)

2. Registration (EMS → HIS)

   Protected Health Information can be shared at this point

3. Registration (HIS → EDIS)

   Update Patient and Encounter

4. Medical History retrieval on-demand

   Get allergies from HIS

   Get home medications from HIS

   Get problems from HIS

5. Vital sign monitoring (monitor → EDIS)
6. Order placement (EDIS → LIS or RIS)
7. Order result (LIS or RIS → EDIS)
8. Discharge information (EDIS → HIS)
9. CDA

   HIS consumes/integrates CDA information

Ambulatory Patient

1. Registration (EMS → HIS)

   Protected Health Information can be shared at this point

2. Registration (HIS → EDIS)

   Create Patient and Encounter

3. Medical History retrieval on-demand

   Get allergies from HIS

   Get medications from HIS

   Get problems from HIS

4. Vital sign monitoring (monitor → EDIS)
5. Order placement (EDIS → LIS or RIS)
6. Order result (LIS or RIS → EDIS)
7. Discharge information (EDIS → HIS)
8. 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