OpenHIE Architecture Specification
4.0
4.0
  • Specification Overview
  • How to use the Specification
  • Architecture Specification
    • Architecture
    • Architectural Principles
    • Standards and Profiles
  • OpenHIE Component Specifications
    • Non-Functional Requirements
    • Client Registry (CR)
    • OpenHIE Facility Registry (FR)
    • OpenHIE Finance and Insurance Service (FIS)
    • OpenHIE Health Management Information System (HMIS)
    • OpenHIE Health Worker Registry (HWR)
    • OpenHIE Interoperability Layer (IOL)
    • OpenHIE Logistics Management Information System (LMIS)
    • OpenHIE Product Catalogue (PC)
    • OpenHIE Shared Health Record (SHR)
    • OpenHIE Terminology Service (TS)
    • Point-Of-Care Systems
  • Workflow (Exchange) Specification
    • Aggregate Reporting Workflows
      • Export Aggregate Data
      • Validate and Save Aggregate Data
    • Alerting / Sending Reminders or Information
      • Send Client Alert Workflow
      • Send Health Worker Alert Workflow
    • Care Services Discovery
      • Query Health Worker and/or Facility Records Workflow
      • Query Care Services Records Workflow
      • Search Care Services Workflow
      • Request Care Services Updates Workflow
    • Laboratory Work Flows
      • Order Laboratory Test
      • Report Lab Results
    • Patient Identity Management Workflows
      • Create Patient Demographic Record Workflow
      • Update Patient Demographic Record Workflow
      • Query Patient Demographic Records by Identifier Workflow
      • Query Patient Demographic Records by Demographics Workflow
    • Shared Health Record
      • Save Patient-level Clinical Data Workflow
      • Query Patient-level Clinical Data Workflow
    • Terminology Service Workflows
      • Expand Value Set
      • Translate Code
      • Verify Code Existence
      • Verify Code Membership
      • Query Value Set
      • Query Code Systems
      • Query Concept Maps
      • Lookup Code
    • Vaccine Workflows
  • How to Provide Feedback and Input
  • Change Log and Versioning
Powered by GitBook
On this page
  • OpenHIE SHR Workflow Requirements
  • OpenHIE SHR Functional Requirements
  1. OpenHIE Component Specifications

OpenHIE Shared Health Record (SHR)

PreviousOpenHIE Product Catalogue (PC)NextOpenHIE Terminology Service (TS)

Last updated 3 years ago

The Shared Health Record (SHR) facilitates the sharing of clinical information between health information systems to enable better patient care, thus improving health outcomes. The Shared Health Record is a means of allowing different services to share health data stored in a centralized data repository. It contains a subset of normalized data for a patient from various systems such as an electronic medical record or the Laboratory Information Management System. This record is queried and updated between the different institutions and systems that are authorized to do so. The Shared Health Record is distinct from a data warehouse; it is an operational, real-time transactional data source.

A shared health record is normalised if all metadata items such as patient, provider, and facility identifiers are resolved to appropriate universal identifiers (as opposed to their local identifiers as used by a client system). In addition, all terminology codes in use need to be mapped to an appropriate reference terminology to ensure that the information is consistently understood.

See also .

OpenHIE SHR Workflow Requirements

A is to allow the various infrastructure services (such as the SHR) to be interchangeable. To support this, the used by the Shared Health Record are outlined in the workflows below.

To be an OHIE SHR component, the SHR application must be able to support the OHIE workflows listed below. Implementations may support only the workflows needed to support their use case:

#

SHR Workflows (Described in detail in the later part of this document)

Recommendation/ Requirement

Requirement

Requirement

OpenHIE SHR Functional Requirements

#

SHR Functional Requirement

Recommendation/ Requirement

SHRF-1

Stores patient level clinical data that forms a patient’s electronic health record

a. Stores unstructured clinical data such as PDFs and narrative text

b. Stores structured clinical data such as an encounter with several discrete observations, compatible with a standard exchange format

c. Relating clinical information to other clinical information, e.g., annotating/describing a document with discrete observations

Recommended

SHRF-2

Expose services that have the ability to receive and save patient clinical data in unstructured form, both text or binary (PDF/image), annotated with sufficient metadata to identify patient/provider.

Recommended

SHRF-3

Expose services that have the ability to receive and save patient clinical data in a structured form such as CDA documents or FHIR resources.

Recommended

SHRF-4

Expose services that have the ability to receive and save patient clinical data In a form that contains both structured and unstructured elements.

Recommended

SHRF-5

Exposes services that respond to queries for a patient’s EHR

a. Can return a specific known document or a list of documents for a patient (as it was submitted)

b. Can return a list of discrete observations for a patient that satisfy specific query parameters. This data can subsequently be used for trending or providing the previous encounters that a patient has had.

c. Can return a full set of clinical information stored about a patient

d. Return patient summary - everything the SHR knows about a patient with links to fetch the individual data items

Recommended

SHRF-6

The SHR shall maintain the context in which the data was submitted.

Recommended

SHRF-7

The SHR should keep detailed audit logs of all interactions with clinical data

a. Keep audit logs of any clinical and demographic data that is stored or changed. Logging who has accessed/viewed clinical information does NOT need to be stored, this is something that an interoperability layer could log.

b. Records and versions updates; records can never be deleted, only marked as such; any previous update should not rewrite old data; no information should ever be removed from the system.

Recommended

SHRF-8

The SHR should support the ability to export data for secondary use.

Recommended

SHRF-9

The SHR should provides interfaces/extension points at various stages of the data lifecycle to allow for semantic validation or simple decision support.

Recommended

SHRF-10

The SHR should allow for storage and retrieval of basic privacy/policy constraints (access control-restrict part of record and restrict entire record).

Recommended

SHRF-11

The SHR should be able to store identified and predefined observational data mapped to standard reference terminology.

Recommended

SHRF-12

The SHR should have a mechanism to resolve conflicts if records are submitted simultaneously.

Recommended

Non-Functional Requirements
core principle of the OpenHIE architecture
OpenHIE Standards and Profiles
SHRWF-1
Save patient-level clinical data workflow
SHRWF-2
Query patient-level clinical data workflow