This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201701 Unscheduled Care"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template for FHIR Connectathon Track Proposals}}")
 
Line 2: Line 2:
 
[[Category:201701_FHIR_Connectathon_Track_Proposals|Jan 2017 Proposals]]
 
[[Category:201701_FHIR_Connectathon_Track_Proposals|Jan 2017 Proposals]]
 
__NOTOC__
 
__NOTOC__
−
=Track Name=
+
=Unscheduled Care=
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
−
<!-- Who is asking for this track? -->
+
* Emergency Care Working Group
 +
* T-System, Inc.
  
 
==Justification==
 
==Justification==
−
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
+
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==
 
==Proposed Track Lead==
−
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
+
Sorin Voicu (sorinvc at gmail dot com)
 
See [[Connectathon_Track_Lead_Responsibilities]]
 
See [[Connectathon_Track_Lead_Responsibilities]]
  
 
==Expected participants==
 
==Expected participants==
−
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
+
* 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==
 
==Roles==
−
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
+
===EDIS===
−
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
+
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.)).
−
===Role 1 Name===
+
===EHR/HIS===
−
<!-- Provide a description of the capabilities this role will have within the connectathon -->
+
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==
 
==Scenarios==
−
<!-- What will be the actions performed by participants? -->
 
  
−
===Scenario Step 1 Name===
 
−
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
−
:Precondition: <!-- What setup is required prior to executing this step? -->
 
−
:Success Criteria: <!-- How will the participants know if the test was successful? -->
 
−
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
 
  
−
<!-- Provide a description of each task -->
+
===EMS Patient===
 +
# Pre-arrival registration (EMS &rarr; EDIS)
 +
#: Cannot transmit Protected Health Information at this point
 +
# Registration (EMS &rarr; HIS)
 +
#: Protected Health Information can be shared at this point
 +
# Registration (HIS &rarr; EDIS)
 +
# Medical History retrieval on-demand
 +
#: Get allergies from HIS
 +
#: Get medications from HIS
 +
#: Get problems from HIS
 +
# Vital sign monitoring (monitor &rarr; EDIS)
 +
# Order placement (EDIS &rarr; LIS or RIS)
 +
# Order result (LIS or RIS &rarr; EDIS)
 +
# Discharge information (EDIS &rarr; HIS)
 +
# CDA
 +
#: HIS consumes/integrates CDA information
 +
 
 +
 
 +
===Ambulatory Patient===
 +
# Registration (EMS &rarr; HIS)
 +
#: Protected Health Information can be shared at this point
 +
# Registration (HIS &rarr; EDIS)
 +
# Medical History retrieval on-demand
 +
#: Get allergies from HIS
 +
#: Get medications from HIS
 +
#: Get problems from HIS
 +
# Vital sign monitoring (monitor &rarr; EDIS)
 +
# Order placement (EDIS &rarr; LIS or RIS)
 +
# Order result (LIS or RIS &rarr; EDIS)
 +
# Discharge information (EDIS &rarr; 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 ==
 +
* Resources Involved
 +
* Patient
 +
* Encounter
 +
* AllergyIntolerance
 +
* Condition
 +
* MedicationStatement
 +
* MedicationOrder
 +
* DiagnosticRequest
 +
* DiagnosticReport
 +
* Observation
 +
* Composition
 +
 
  
 
==TestScript(s)==
 
==TestScript(s)==

Revision as of 14:34, 4 November 2016


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 (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

  1. Pre-arrival registration (EMS → EDIS)
    Cannot transmit Protected Health Information at this point
  2. Registration (EMS → HIS)
    Protected Health Information can be shared at this point
  3. Registration (HIS → EDIS)
  4. Medical History retrieval on-demand
    Get allergies from HIS
    Get 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)
  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

  • Resources Involved
  • Patient
  • Encounter
  • AllergyIntolerance
  • Condition
  • MedicationStatement
  • MedicationOrder
  • DiagnosticRequest
  • DiagnosticReport
  • Observation
  • Composition


TestScript(s)

Retrieved from "https://wiki.hl7.org/w/index.php?title=201701_Unscheduled_Care&oldid=128572"