Shared Health Record

Owned by Piotr Mankowski
Last updated: Jun 02, 2020
3 min read

Overview

According to OpenHIE standards a Shared Health Record (SHR) should fulfill the following four functions for client EMRs (like OpenMRS):

  1. Store a useful subset of clinical data

  2. Retrieve relevant clinical data as needed

  3. Update the SHR with relevant clinical data as needed

  4. Feed into reporting/analytics pipelines

Use Cases

Primary

  • A point-of-care system (i.e., LIS, EMR, etc.) should be able to store a normalized subset of clinical information items (that which is deemed appropriate to share) from a patient’s clinical record on that system.

    • We should be able to store Observations, Allergies, Care Summaries, Care Plans etc.

    • Store unstructured data along with associated metadata, e.g. a PDF document or digital image with attached patient demographic information

  • A point-of-care system should be able to retrieve relevant portions (up to the full set) of this clinical record as needed.

    • Retrieve a longitudinal list of patient clinical information by type, date or other query parameters

  • A point-of-care system should be able to update existing clinical records on the SHR while keeping the version history

  • The SHR should acknowledge requests from a client system and provide appropriate information in the event of errors

Secondary

  • Data should be available for extraction for secondary use.

Workflows

The Shared Health Record consists of a subset of workflows within the OpenHIE Framework, specifically:

  • Save patient-level clinical data workflow – V2.0

  • Query patient-level data workflow – v2.0

  • Query for Aggregate data from the SHR

  • Aggregate data exchange from patient level system to HMIS

Required FHIR Module Resources

US Core Profile:

(Resources are currently Implemented in FHIR, not necessarily the entire profile)

--------------------------------------------

(Resources not currently implemented)

OpenHIE SHR recommended dataset:

  • Items related to a patient daily care, such as:

    • Clinical Observations

    • Care summaries

    • Allergies

    • Medications that have been prescribed to the patient

    • Clinical Notes (Referral/provider) (not coordination of referrals)

    • Medical histories (we are implementing an SHR to store the history)

    • Quality of life indicators (these are observations)

    • Textual Care/Action Plans (for Asthma, Diabetes, PMTCT etc.)

    • Nutritional / mental health assessments (these are observations)

    • Problem Lists / Diagnosis / Health conditions

    • Radiology impression / report (not entire image, may be a pointer to the image)

    • Reportable items - make sure we collect enough for the next level up

    • Record a clinically relevant event to allow us to record details that something has happened 

  • Lab report (without full lab sample details)

  • Immunizations

Required FHIR Module Functionality

Store a useful subset of clinical data
Send a bundled response with the requested/required resources

Retrieve relevant data as needed
Create/Update functionality 

Maintaining Resource Identity 
Support for Unstructured Document Transfer (XDS.b? CDA?)
US Core DocumentReference Profile

Update the SHR with relevant data as needed
Subscriptions?
Custom OpenMRS Scheduled Task ?

updatedSince

elements parameter support (to keep bundle size down)

Feed into reporting/analytics pipelines
Async FHIR Support
Pipeline support? 

Coding conversions (terminology) 

Version support 

Deliverables

  1. Specifications for an SHR in Haiti

    1. IG and profiles

    2. Technical specs

  2. Selection of SHR tools (HAPI JPA server)

  3. Contextualization to SEDISH architecture (OpenHIM etc., likely OpenCR, mediator)

    1. Semantic decisions

    2. architecture decisions

    3. tool selection decisions

  4. MVP demo 

    1. Security

    2. Showcase a usecase in Continueum of care

      1. Create patient in one instance (local → centralized)

      2. Search for and get SHR of patient in another instance (centralized –> Local)

        1. FHIR bundle stored in a complex obs and rendered, possibly using https://www.hl7.org/fhir/domainresource-definitions.html#DomainResource.text

  5. Security Strategy 

Evaluation Strategies

https://wiki.ohie.org/display/documents/Workflow+Collection+Maturity



  • The system should be validated against the health needs of low resource settings, e.g. HIV, TB, Maternal Care.

Relevant FHIR Docs

Relevant Talk Posts

Relevant Github Links

Open Questions

  1. Where does the responsibility for determining patient identify / de-duplication lie? Is it with the client system, or with the SHR? 

  2. Is the second target usecase the MPI?