OpenHIE is a collaborative community focused on the sharing and use of health data, rather than a downloadable technical solution. OpenHIE offers best practice recommendations identified by a community that shares experiences and insights, and an architecture that serves the needs of resource emerging environments.
The OpenHIE architecture is a conceptual architecture that builds upon patterns for data exchange. Each part of this architecture can be utilized to solve data sharing challenges in a health context.
OpenHIE is a collaborative community focused on the sharing and use of health data, rather than a downloadable technical solution.
So how do you implement health data sharing?
Each country has their own specific needs when it comes to setting up or making their own health information system more effective. We typically see countries start with a component, an exchange project, sharing between components, or an architectural blueprint project as outlined in the Getting Started Guide. The architecture diagram pictured showcases a conceptual health information exchange system.
These components of the architecture can be implemented while working alongside OpenHIE community members and using best practices identified in the community, including sub-communities that focus on different areas of the architecture. There is also a pathway where implementers can make use of technical global goods solutions within the OpenHIE Architecture.
Making Connections to Technical Solutions
Technological solutions from open-source global goods can target specific OpenHIE architectural components within a health information exchange and can be leveraged to support individual components and aid interoperability.
For example, Open Concept Lab (OCL) is an open-source terminology management system and community who works closely with OpenHIE Terminology Services efforts. Teams looking to implement or bolster their terminology management within an environment, could work alongside OCL to utilize their tools in order to gain real-time electronic access to terminological resources and integrate it within their own software platforms.
In doing this work, they are building the terminology services piece of the conceptual OpenHIE architecture. Terminology Implementers could also consider participating in the OpenHIE Terminology Service sub-community, or reviewing the OpenHIE Getting Started Guide or Specification to gain more details on beginning to set up pathways for data exchange or read more on the reusable architecture of the OpenHIE community.
Defining the Process to Implement OpenHIE
For implementation teams, working with global goods like OCL, utilizing OpenHIE resources, or participating in the community process – these are all pathways in implementing the OpenHIE Architecture.
These implementation teams can then share with OpenHIE how they implemented the data exchange differently and share what worked and what didn’t.
OpenHIE isn’t a solution you can download or use, but rather a community of individuals who come together to solve issues in surrounding health care systems. If you are looking for a way to get started with OpenHIE and finding ways the architecture and community process can support your needs in health information exchange, we recommend beginning with the Getting Started Guide: Paths to Data Exchange where you can learn more about OpenHIE and how you can get started!
Would you like to read this blog in Spanish? Check out a translated version of this blog post on one of our partner organizations, RECAINSA's website: DE LA ARQUITECTURA CONCEPTUAL DE OPENHIE A LA PUESTA EN MARCHA DE SU PROYECTO DE INTERCAMBIO DE DATOS