Documents
Space shortcuts

OpenHIE Community Wiki

Documents
Communities
Projects
Resources

Documents

Child pages
  • OpenHIE Architecture
9 more child pages
Skip to end of metadata
Go to start of metadata

Purpose of the Diagram

The following diagram is a high-level conceptual diagram or logical overview of the OpenHIE architecture that is intended to be notional.  This diagram represents the consensus of the OpenHIE Architecture Review Board as determined through the Architecture Governance and Principles.   It is expected that implementations based upon OpenHIE may have more precise lower-level conceptual diagrams and /or physical diagrams.  

High Level Overview

A Health Information Exchange (HIE) makes the sharing of health data across information systems possible. Like a universal translator, an HIE normalizes data and secures the transmission of health information throughout databases, between facilities, and across regions or countries.

OpenHIE’s architecture is made up of six open-source software components, all interacting/interoperating to ensure that health information from various external systems is gathered into a unified person-centric medical record.  To accomplish this, the exchange normalizes the context in which health information is created across four dimensions: 1) who received health services, 2) who provided those services, 3) where did they receive the services, 4) and what specific care did they receive.  By focusing on the “For Whom”,”By Whom”, “Where”, and “What” of a patient's health visit we help to bring relevant information directly to the point of care. This supports enhanced decision-making, improves the quality, safety and continuity of care, and facilitates the appropriate use of information to improve population health.

Note: Registries maintain authoritative reference  information required to support health information exchange. They provide query and resolution services so that participating systems can validate or obtain the formal and normalized observations, identifiers, names and codes to reference an entity (such as a health worker, client, facility, etc.)

 

Quick Links

 

 

 

 

  1. 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?” See also:What constitutes an OpenHIE Terminology Service?

  2. An enterprise master patient index (EMPI), or Client Registry manages the unique identity of citizens receiving health services with the country – “For whom".  See also: What constitutes an OpenHIE CR?

  3. 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. See also: What constitutes an OpenHIE SHR?

  4. 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. See also: What constitutes an OpenHIE HMIS?

  5. A Health Facility Registry serves as a central authority to uniquely identify all places where health services are administered within the country – “Where?” See also: What constitutes an OpenHIE Facility Registry?


  6. A Health Worker Registry is the central authority for maintaining the unique identities of health providers within the country – “By whom." See also:  What constitutes a HWR?


  7.  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. See also: What constitutes an OpenHIE IOL?

     

  8. 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.

 

9 Comments

  1. Carl Fourie

     It is expected that implementations based upon OpenHIE may have more precise lower-level conceptual diagrams and /or physical diagrams.  

    I like the new text here. This languages raises the question: "What if I only have some of the components? Is it still an OpenHIE architecture project?" I think we have a great chance to highlight that having an OpenHIE architecture doesn't mean needing all the components. .

  2. pardha

    Could you provide real epic for  usage of TS component in in the above architecture?Whar are the spcicifications, protocols, where do we get the complete universal codes?

  3. Jack Bowie

    Terminology services are used in a number of the standard workflows, usually for validating codes. We do not as yet have a standard "starter set" of terminologies/codes available. The particular code systems that are required in an OHIE implementation are usually specified by the implementing organization, e.g., a country's Ministry of Health, so providing a "typical" set has proven difficult. Members of the Terminology Services community can assist you in locating any specific code systems you require. You can find further details on the considerations for code system selection and the recommended FHIR transactions for a Terminology Service in the Terminology Services Planning and Implementation Guide and associated documents, available on the Terminology Services page of this Wiki.

    1. Jamie Thomas

      Resource can be found here - https://wiki.ohie.org/display/SUB/Terminology+Service+Community

  4. Vikas

    What is the similarity/difference between HMIS within "external systems" and HMIS within "openHIE component layer"

    1. Carl Fourie

      HI Vikas

      I'm not quite sure I understand your question fully?

      1. Vikas

        Hi Carl,

        Sorry for not being clear. it was more of a thought when i wrote the message.

        So the architecture shows HMIS under External system (below the interoperability layer) and OpenHIE component layer (above the IL). These two uses of the same term is confusing to me. We can still keep the same term if we have a clear definition of what is included in HMIS below the IL and above the IL. Does it make sense?

        Thanks!

        1. Carl Fourie

          Hi Vikas

          The way I've come to read this is that the HMIS can play both roles depending on the implmentation and architectural needs. For example: the HMIS can be a contributor/consumer of data from the HIE (this may be where the implementation of the HMIS is not within the mandate and control of the project), or it may be when data needs to flow between HMIS solutions (Such as the PEPFAR DATIM work where we see country to PEPFAR aggreatdate data exchanges as well as national to global etc).

          The other is where the implementation of the HMIS is considered part of the broader HIE (under the same governance and focused on serving the business vision of the HIE).

          That is more a personal view of how I'd read that and others from the HMIS community may describe it differently. Hope that helps

          1. Jennifer E Shivers

            The architecture pattern has been abstracted to meet multiple scenarios.

            Here an example where there can be multiple HIMS systems involved in a single country's implementation:

            A region in a country may have it's own HMIS that is required to collect data from various facilities in it's purview. That HMIS may then be required to send data to the national HMIS that is in the national HIE.

            Carl also provided you with an example where the is a PEPFAR HMIS and a Country HMIS. In this case, it is likely that both HMIS systems could reside in different HIEs.

            .

This work is licensed under a Creative Commons Attribution 4.0 International License.