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
 
(One intermediate revision by the same user not shown)
Line 127: Line 127:
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
-->
 
-->
 +
 +
 +
==Testing Summary==
 +
 +
===Scenario used: The Ambulatory Scenario===
 +
# Register patient in EMR
 +
# Create encounter in EMR
 +
# Document home medications, allergies, and conditions in EMR
 +
# Create patient in EDIS
 +
# Create encounter in EDIS
 +
# Trigger retrieval of home medications, allergies, and conditions from EMR
 +
# Integrate home medications, allergies, and conditions in EDIS
 +
 +
===Approach===
 +
* Use Postman scripts to drive the ambulatory scenario
 +
* Use all servers available as EMRs and our system as the EDIS
 +
:* Servers needed to be STU3 and support the resources involved which excluded a few of the available servers
 +
* Focus on the exchange of demographic information, home medications, allergies, and conditions
 +
 +
===Results===
 +
* We were able to test all steps above with
 +
:* Grahame’s Server
 +
:* The Aegis WildFHIR server
 +
:* HSPC server
 +
* We tested with the others available but we were not successful due mainly to the DSTU version (our implementation is DSTU3 only)
 +
 +
===Lessons Learned===
 +
* The notion of recorder or information source for these entities across systems introduces the need for mapping of users or keeping of remote references
 +
:* Medical Record Number – a key element in our workflow – is not always available
 +
* Systems use different types of ID (patient ID, Medicare ID, military ID)

Latest revision as of 15:09, 25 January 2017

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 in EDIS (Last Name=EMS Unit Name, Given Name=chief complaint, Gender, Age)
    POST /Patient
    POST /Encounter
  2. Registration (EMS → HIS)
    Protected Health Information can be shared at this point
    Create Patient and Encounter in HIS
    POST /Patient
    POST /Encounter
  3. Registration (HIS → EDIS)
    Find encounter in EDIS
    GET /Encounter?identifer=[identifier]
    Update Patient and Encounter in EDIS
    PUT /Patient/[id]
    PUT /Encounter/[id]
  4. Medical History retrieval on-demand
    Find patient in HIS
    GET /Patient?identifier=[identifier]
    Get allergies from HIS
    GET /AllergyIntolerance?patient=[id]
    Get home medications from HIS
    GET /MedicationStatement?patient=[id]
    Get problems from HIS
    GET /Condition?patient=[id]
  5. Vital sign monitoring (monitor → EDIS)
    POST /Observation
  6. Order placement (EDIS → LIS or RIS)
  7. Order result (LIS or RIS → EDIS)
  8. Discharge information (EDIS → HIS)
    Update encounter in HIS
    PUT /Encounter/[id]
  9. CDA
    HIS consumes/integrates CDA information

Ambulatory Patient

  1. Registration (HIS → EDIS)
    Create Patient and Encounter
  2. Medical History retrieval on-demand
    Get allergies from HIS
    Get medications from HIS
    Get problems from HIS
  3. Vital sign monitoring (monitor → EDIS)
  4. Order placement (EDIS → LIS or RIS)
  5. Order result (LIS or RIS → EDIS)
  6. Discharge information (EDIS → HIS)
  7. 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


TestScript(s)

Testing Summary

Scenario used: The Ambulatory Scenario

  1. Register patient in EMR
  2. Create encounter in EMR
  3. Document home medications, allergies, and conditions in EMR
  4. Create patient in EDIS
  5. Create encounter in EDIS
  6. Trigger retrieval of home medications, allergies, and conditions from EMR
  7. Integrate home medications, allergies, and conditions in EDIS

Approach

  • Use Postman scripts to drive the ambulatory scenario
  • Use all servers available as EMRs and our system as the EDIS
  • Servers needed to be STU3 and support the resources involved which excluded a few of the available servers
  • Focus on the exchange of demographic information, home medications, allergies, and conditions

Results

  • We were able to test all steps above with
  • Grahame’s Server
  • The Aegis WildFHIR server
  • HSPC server
  • We tested with the others available but we were not successful due mainly to the DSTU version (our implementation is DSTU3 only)

Lessons Learned

  • The notion of recorder or information source for these entities across systems introduces the need for mapping of users or keeping of remote references
  • Medical Record Number – a key element in our workflow – is not always available
  • Systems use different types of ID (patient ID, Medicare ID, military ID)
Retrieved from "https://wiki.hl7.org/w/index.php?title=201701_Unscheduled_Care&oldid=132177"