Welcome
We believe in the collective knowledge of the masses and that as a network we are our own experts in both posing our questions and finding answers to them. As this is a new space within OpenHIE we would like you to add, edit and suggest changes on what you would like to see on the OpenHIE Implementers Network section. What answers do you want, what isn't really that clear (it may just be a reformatting or bringing together of content from the broader OpenHIE site but it is still important to know). WE have done a short poll internally and as a start have highlighted the following as areas that would be valuable, please contribute or call out what would fit in these areas and suggest others:
Basic OpenHIE Overview
The implementers page should have a basic OpenHIE overview to ensure that implementers actually understand what OHIE is and what it isn’t. The layman’s guide is a good start but would want a bit more
Architecture overview
Getting OpenHIE setup
The page should have a space where implementers can find “Quick Start” information in getting OpenHIE setup and or stood up. It should also unpack its design ideas (implementable and not just installable - in that it should be implemented after design of solution and not to design the solution)
FAQ
A list of FAQs that are and will arise out of the mailing lists
Implementations Descriptions
A space where existing and or planned implementations are listed AND Described. We would want to provide a very very basic easy to use implementation description template that would allow implementers to share what they are doing, basic designs and set the tone for conversations.
Is OpenHIE for Me
A high level overview of OpenHIE from what it does and what it doesn’t do. Looking to try and answer is OpenHIE for “me”; reference where it is and what is being done with it. How it has been applied in different ways.
Considerations of content for a high-level overview:
- Not a Database But a Conduit of Standardized, Accessible and Contextual Data
- Not an Electronic Health Record In and Of Itself
- Business, Subject Matter Expertise, and Technical knowledge of health information and its usage
- Software Development Expertise
- What components of HIE are able to be implemented within stakeholder groups and sustained?
- Overarching concerns:
- Governance
- Finance
- Analysis Services
- Software and Programme Development
- Support
- Long-term sustainability
- Gov't, Partner, and Vendor products and services required to support HIE components
- Overarching concerns:
Portal Views for 3 groups
Country Implementers View
Governance
In order to effectively provide governance oversight for the HIE architecture and its constituent business and technical components, it is recommended to establish a Governance Framework for sponsorship thus ensuring policies, standards and processes are established for health information exchange among "a set of participants.
"HIE governance refers to the establishment and oversight of a common set of behaviors, policies,
and standards that enable trusted electronic health information exchange among a set of participants."
-- U.S. Gov't Office of the National Coordinator for Health Information Technology (ONC)
- Organizational Principles: Identify generally applicable approaches for good self-governance;
- Trust Principles: Guide HIE governance entities on patient privacy, meaningful choice, and data management in HIE;
- Business Principles: Focus on responsible financial and operational policies for governance entities, with emphasis on transparency and HIE with the patients best interests in mind;
- Technical Principles: Express priorities for the use of standards in order to support the Trust and Business Principles as well as furthering the execution of interoperability.
It is thought that Principles and 'actions' above could be adapted and combined with the OpenHIE Governance and Principles as a starting place for determining the appropriate governance model or models needed within the context of low-resource settings, or the needs of a particular country or Domain setting. Bearing in mind that varying degrees of design and implementation may need to be considered due to the potential needs of less or more complex scenarios. Not all countries are equal in their need to implement all the features of an HIE and connected systems strategy.
This type of Governance may not be suitable for all regions within which an HIE is instituted, but nonetheless provides overarching concepts and principles which are comprehensive enough to handle diverse strategy, planning and governance concerns.
Budgeting
Data Standards
Privacy Framework
Policies
Regulatory Framework
eHealth Framework
Domain Experts View
Figure: OpenHIE Architecture
In the diagram above are depicted the building blocks of a Health Information Exchange based upon the the OpenHIE Architecture, namely: Client Registry, Facilities Registry, Health Management Information System, Health Worker Registry, Shared Health Record, and Terminology Services, and the Interoperability Services Layer that interconnects them all and provides Authentication, Interlinked Registries, and Entity Matching services.
The framework of components of HIE provides for integration with various standards compliant systems and tools, such as (but not limited to):
Country and Partner EHRs
Laboratory Information Management Systems (LIMS)
Logistics Management Information Systems (LMIS)
Pharmacy Information Systems
etc.
Developer's View
- Interface development
OpenHIM Mediators
- Working with standards
- Core Workflows (fit for purpose, standards compliant)
OpenHIE Assumptions
There are a few key assumptions that are made when considering OpenHIE. (( Help us build these out and write them out to why they are impactful and how to mitigate them ))
- Connectivity between Point of Care (PoC) and HIE:
- To leverage the full functionality of the OpenHIE a constant connection is preferable. Store and forward and asynchronous options are implementable and need to be discussed as to how to best leverage these
- The PoC system must adopt the appropriate standards to function with the HIE or must go through a mediator system that translates their programming interfaces to standardized requests. These standards are identified in the OpenHIE workflows.
- Infrastructure Ownership
- (( Someone needs to own the OpenHIE infrastructure. We assume maximum benefit for all parties working in a given context would be a single HIE with multiple contributors. Is this a valid assumption? Do we have field implementations out there that have a single owner of the HIE and different organizations contributing data. ))
- Data Access
- OpenHIE assumes that all data is accessed through the Interoperability Layer. Direct access to an infrastructure component defeats the purpose of the HIE. As we build out a particular component, PoC and Infrastructure systems must ensure that the IL is the only route of access. This comes up when a point-to-point feature is developed between a PoC and Infrastructure system outside of the OpenHIE context. We hope development teams keep the applicability of standards in the OpenHIE context as they build out features.
- We assume that data in the HIE is a public good, available to any PoC team wishing to participate in the HIE. With that said, patients should be able to opt-out of sharing their information with other providers who access the HIE. (There's a good discussion on this topic in the IL mailing list see attachments)
- (( Should we assume that accessing the HIE also requires posting data to the HIE? i.e. two way interaction ))
- (( Should we assume that accessing the HIE is an opt-in from the PoC provider? If it's mandated by a government, what burden does that place on the provider? What incentives are there to contribute? ))
- Record Modification
- (( Should we assume that anyone who has access to POST data to openHIE has the capability to modify the records? Are there standard checks and balances when putting data into the HIE? What should we assume from the PoC perspective ))
- Error Management SOPs and workflows