The following table represents the OHIE reference technologies. It is a list that is expanded as new workflows and use cases are added. See the Architecture Maturity model that describes the business processes that these tools support.
OpenHIE Architecture
OpenHIE Component Descriptions
- A Terminology Service serves as a central authority to uniquely identify the clinical activities that occur within the care delivery process by maintaining a terminology set mapped to international standards such as ICO10, LOINC, SNOMED, and others – “What?”
- An enterprise master patient index (EMPI), or Client Registry manages the unique identity of citizens receiving health services with the country – “For whom"
- A Shared Health Record (SHR) is a repository containing the normalized version of content created within the community, after being validated against each of the previous registries. It is a collection of person-centric records for patients with information in the exchange.
- A Health Management Information System (HMIS) stores routinely-collected aggregate health care data, and facilitates their analysis with the goal of improving the quality of health services.
A Health Facility Registry serves as a central authority to uniquely identify all places where health services are administered within the country – “Where?”
A Health Worker Registry is the central authority for maintaining the unique identities of health providers within the country – “By whom"
A Health Interoperability Layer receives all communications from external services within a health geography, and orchestrates message processing among the external systems and the OpenHIE component layer.
External systems, such as the OpenMRS electronic medical records (EMR) system and the RapidSMS mHealth application, are used by clinicians and by community health workers to access and update a patient’s person-centric shared health information and to record healthcare transactions.