Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

titlePage under construction

The following information is under construction.  For full content see the OpenHIE Specification.  If you would like to contribute an outline or template for a tender or RFP, we can remove sensitive details and post examples here.  

Purpose of this Page

The purpose of this document is to provide resources for those in MOHs or implementer institutions who may be creating tenders or RFPs for HIE or HIE component requirements.  

Overview of Resources 

One of the key goals of the OpenHIE Architecture Specification is to articulate the requirements for the typical HIE components.  The following content can be used as a foundation for creating content for tender requests or requests for proposals. 

Content to Consider 

The following are examples of content that you may want to consider as you draft a tender or RFP.  Please feel free to take the content and reuse it as appropriate for your project.  

Use Cases  - What will the HIE or component be used for?  

Consider noting the key use cases or business use of the intended solution. 
Examples might be: 

  • Describing the creation of a shared patient-level repository that can inform a longitudinal view of a patient's care even if that care was received at multiple facilities.  
  • Describing the creation of a health exchange for better case reporting and analysis across facilities.  

Architecture - Which HIE components are desired? 

You may want to consider providing an overview of the HIE and the components needed to support your use case(s).  You may refer to the OpenHIE documentation or refer to country specific architecture documentation.  

Reference:  Overview of the OpenHIE Architecture as an example.  

Project Principles  - How do we intended to have the HIE or components work? 

You may want to consider outline key principles such as use of data exchange standards.  

Data Exchange Standards - What standards will the HIE need to follow?  

Consider documenting the standards that you would like to use.  These are the current standards that OpenHIE recommends.  

HIE Component Descriptions and Requirements - What is an overview of the component and base functionality needed to support our use cases? 

If you are creating a tender for a comprehensive HIE, consider these references as you describe each component and outline the high-level requirements.  For a tender for a specific component, consider the Non-functional Requirements and the description of the specific component that is being requested.  

Advanced Tables - Table Plus

Client or Patient Registry
Non-functional RequirementsThis page contains recommended non-functional requirements for any OpenHIE component software.  These requirements should be considered as people create requests for proposals and tenders.  
Client Registry This Each page contains a description of the architecture component and outlines high-level requirements that are expected of this component.  

Facility Registry 
Finance and Insurance Component
Health Management Information System
Health Worker Registry
Interoperability Layer
Logistics Management System
Product Catalog
Shared Health Record 
Terminology Service 
Point of Care SystemsThis page contains a description of the Facility Registry architecture component and outlines high-level requirements that are expected of this component. link to the data exchange patters that various point-of care systems should follow.  

Table of Contents