Shared Health Record
Overview
According to OpenHIE standards a Shared Health Record (SHR) should fulfill the following four functions for client EMRs (like OpenMRS):
- Store a useful subset of clinical data
- Retrieve relevant clinical data as needed
- Update the SHR with relevant clinical data as needed
- 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)
- US Core AllergyIntolerance Profile
- US Core Condition Profile
- US Core DiagnosticReport Profile for Laboratory Results Reporting
- US Core DiagnosticReport Profile for Report and Note exchange
- US Core Encounter Profile
- US Core Laboratory Result Observation Profile
- US Core Location Profile
- US Core Medication Profile
- US Core MedicationRequest Profile
- US Core Patient Profile
- US Core Pediatric BMI for Age Observation Profile
- US Core Pediatric Weight for Height Observation Profile
- US Core Practitioner Profile
- US Core Provenance Profile
--------------------------------------------
(Resources not currently implemented)
- US Core CarePlan Profile
- US Core CareTeam Profile
- US Core DocumentReference Profile
- US Core Immunization Profile
- US Core Implantable Device Profile
- US Core Organization Profile
- US Core Procedure Profile
- US Core Smoking Status Observation Profile
- US Core Pulse Oximetry Profile
- US Core PractitionerRole Profile
- US Core Goal Profile
- In addition US Core uses the Vital Signs Profile from the FHIR Specification.
--------------------------
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
- Specifications for an SHR in Haiti
- IG and profiles
- Technical specs
- Selection of SHR tools (HAPI JPA server)
- Contextualization to SEDISH architecture (OpenHIM etc., likely OpenCR, mediator)
- Semantic decisions
- architecture decisions
- tool selection decisions
- MVP demo
- Security
- Showcase a usecase in Continueum of care
- Create patient in one instance (local → centralized)
- Search for and get SHR of patient in another instance (centralized –> Local)
- FHIR bundle stored in a complex obs and rendered, possibly using https://www.hl7.org/fhir/domainresource-definitions.html#DomainResource.text
- 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
- Where does the responsibility for determining patient identify / de-duplication lie? Is it with the client system, or with the SHR?
- Is the second target usecase the MPI?