OpenHIE
OpenHIE 101
OpenHIE Architecture
February 2019
Purpose
To guide an overview discussion on the OpenHIE Architecture:
Objectives
Community
Process
Specifications
Specifications
OpenHIE is NOT Software
OpenHIE Architecture IS Patterns
Note: OpenHIE also has Exemplar Software demonstrating the workflows, but OHIE is not software
Community
Process
SPECIFICATIONS
Architecture Diagram
Example Workflow
Example Workflow
Workflows
(Information Exchanges)
Approved
In-Progress
Coming Soon?
Maturity Model
Community
Role
Principles
Calls (twice a month)
Process
Specifications
COMMUNITY
Architecture Community Engagement
OpenHIE Community Leads
OpenHIE Architecture Community
Client Registry
Facility Registry
Terminology
HMIS
Interoperability and SHR
Health Worker and Interlinked Registry
Insurance
Supply Chain
Real-Life Experience / Needs
OpenHIE Community Call
Real-life Needs, Technology, Standards, Specifications
Other Project Teams, Countries and Projects, Standards Bodies
Real-Life Experience / Needs, standards
Real-Life Experience / Needs, Direction, Scope
How to Participate
OpenHIE Architecture Calls
2nd Monday and Last Friday
@ 10am EST
COMING SOON
*Designed by Freepik from www.flaticon.com
Process
Specifications
Community
PROCESS
OpenHIE: Mythbusters!
Debunking some common “myths” around OpenHIE!
OpenHIE.exe?
Q: Is OpenHIE a downloadable and single click install software package?
A: No. OpenHIE is an architecture and an approach.
There are reference tools and technologies that are able to prove the architecture but these are not packaged as a “downloadable and installable” solution
Open Source Only
Q: Does OpenHIE only work with Open Source software?
Can I use commercial or non open software with OpenHIE?
A: OpenHIE supports an open architectural approach; meaning non open applications are welcome to engage and leverage the architecture as well as play the role of the key components.
OpenHIE provides open source reference technologies to support the architecture but welcomes commercial solutions too.
All or Nothing!
Q: Do you have to use all of OpenHIE at once?
Can I use bits and pieces?
Will you still like me if I don’t use it all?
A: OpenHIE promotes an evolutionary architecture; use what is needed but be lead by architectural design. By thinking broader we are able to meet our current needs and create space for future expansions.
In short: use what is needed, don’t need to use it all at once.
Our way or the highway!
Q: Do I have to use your workflows exactly?
What if there isn’t a workflow for what I want to do?
What about new standards?
A: OpenHIE encourages implementations to challenge and bring new use-cases to the communities. Each implementation has unique needs and they may drive different decisions when it comes to standards. OpenHIE provides a base to “step off” from and customize your implementation design.
Additional Details
OpenHIE Components
OpenHIE Components
The external applications and tools that communicate with the HIE: �
OpenHIE Components
Interoperability layer: manages communications from the external systems and orchestrates how the rest of the HIE will do its work to satisfy them.
How does OpenHIE work?
Terminology Service: Provides answer to the question: What vocabulary do we agree on? Allows the different databases to map to each other, even when they use different terms.
OpenHIE Components
Client Registry: Lets HIE know who received the health services.�
Creates and curates a unique identity for every patient.
OpenHIE Components
Shared Health Record: What is the client’s health history? �
OpenHIE Components
Health Management Information System: Holds information on the population’s health history.
Supports big data analytics, public health planning, decision making
OpenHIE Components
Facility Registry: Answers question: What location provides health services?
Manages the master facility list.
OpenHIE Components
Health Worker Registry: Answers Question: Who provides health services?