# Getting Started Guide: Paths to Data Exchange ## **What is OpenHIE?** OpenHIE is a self-organizing, mission-driven community of stakeholders assisting the strengthening of national Health Information Exchanges (HIEs) to support access to data by a Health Information System (HIS). The initiative emerged from the Health Informatics Public Private Partnership initiative funded by the US President’s Emergency Plan for AIDS Relief (PEPFAR). OpenHIE is more than a set of technical specifications. It is also a collaborative community of practice. This community includes ministry of health personnel, funders, enterprise architects, solution designers, software engineers, implementers and health system managers. OpenHIE was created on the belief that integrated and interoperable health information systems are critical to improve the quality and continuity of healthcare. {% hint style="success" %} **Resources and Examples:** * [OpenHIE Academy](https://academy.ohie.org/) * [OpenHIE Website](https://ohie.org/) * [OpenHIE Architecture Specification](https://ohie.org/framework/) {% endhint %} **This work is licensed under a Creative Commons Attribution 4.0 International License.** # Select a Pathway Use this page to pick which pathway(s) to follow. ## How to Use this Guide This guide is designed to help ministries of health, implementers and others involved in establishing eHealth architecture and health system project teams get started with health information exchange. Over the past few years we have observed that some implementers choose to start their journey by working in a specific OpenHIE component like a facility registry. Other implementers may choose to start with a health exchange project that allows for sharing of health data. While a third group started at a more foundational level like doing an eHealth Architecture or blueprint project. Each of these starting points has benefits and challenges. Ultimately, the components, the data exchange projects and the architecture are needed to benefit fully from health information exchange and none of these pathways is mutually exclusive. The path toward data exchange is a multi-faceted journey that will take time. Use this guide to make progress on one or more pathways toward information exchange. ## **Pathways** Identify the type of project(s) that you are working on and click on the appropriate pathway.
| **Type of Project** | **Description / Implications** | Start Here | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | [**Component Project**](/getting-started/dev/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope) | |

Pathway 1

| |

Exchange Project

| |

Pathway 1

| | [**Architecture Project**](/getting-started/dev/pathway-2-architecture/untitled) | |

Pathway 2

| # PATHWAY 1: Component and Data Exchange Projects Select the appropriate phase of the project to get started. * [Phase 1: Governance, Value, and Scope](/getting-started/dev/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope) * [Phase 2: Requirements and Design](/getting-started/dev/pathway-1-component-and-data-exchange/phase-2-requirements-and-design) * [Phase 3: Implement, Support, and Scale](/getting-started/dev/pathway-1-component-and-data-exchange/phase-3-implement-support-and-scale) # Pathway 1.1 - Governance, Value, and Scope Component Level Project and Exchange Level Project ## People * [ ] [Identify Stakeholders](/getting-started/dev/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope/identify-stakeholders) * [ ] [Determine and Document Roles and Responsibilities](/getting-started/dev/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope/determine-and-document-roles-and-responsibilities) ## Process * [ ] [Establish or Define Governance Structures](/getting-started/dev/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope/establish-or-define-governance-structures) * [ ] [Determine Project Scope](/getting-started/dev/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope/determine-project-scope) * [ ] [Document the Expected Value of the Project](/getting-started/dev/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope/document-the-expected-value-of-the-project) * [ ] [Establish a Project Plan ](/getting-started/dev/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope/establish-a-project-plan) {% content-ref url="/pages/-MbkzPuyvLJCNJvoul1Y" %} [Pathway 1.2 - Requirements and Design](/getting-started/dev/pathway-1-component-and-data-exchange/phase-2-requirements-and-design) {% endcontent-ref %} {% content-ref url="/pages/-MbkzdubiTD6syhAgqD3" %} [Pathway 1.3 - Implement, Support, and Scale](/getting-started/dev/pathway-1-component-and-data-exchange/phase-3-implement-support-and-scale) {% endcontent-ref %} # Identify Stakeholders Phase 1: Component and Exchange Path ## **Identify Stakeholders** To help ascertain the requirements and provide input into architecture components and OHIE data exchange implementations, stakeholders and system users should be identified. Interest in a specific component or a project that uses one or more OHIE components has the potential to span a diverse network of stakeholders. By identifying who is engaged in providing or using the information and who will provide support to the new system or service, implementers can begin to form a stakeholder engagement plan to inform the design and implementation of the project. To identify stakeholders, ask questions such as: * *Who are the interested and impacted parties?* * *Is the national health ministry and/or other levels of the health system like one or more regional levels interested or impacted?* * *Are there advocacy groups that can help?* Stakeholders that may be considered include: * Organizations or people that create data that will be captured (e.g. patient data, facility data, terminology.) * People providing data or entering data into the component(s) needed for the project (e.g. Patients or Clients, Healthcare professionals, community workers, facility managers.) * People and organizations using the data collected for metrics reporting or decision making * Organizations driving the project * Ministry of Health representatives * Technical and infrastructure support teams (e.g. help desk personnel, system hosting and connectivity providers) that may end up supporting the component(s), the bandwidth or other technology needed for the project to be successful. ### Identifying Stakeholder Motivations Once potential stakeholders are identified, it is helpful to understand high-level stakeholder motivations and challenges. Understanding these motivations will help teams engage and recruit the individuals that will represent the organizational stakeholders in: * Defining project scope * Vetting and prioritizing key use cases and user stories * Ensure agreement on the data specifications and requirements Stakeholders and the appropriate governance structures should be involved throughout the project lifecycle including; defining project scope and objectives, design, development and implementation of the components, and not just at the beginning. As new business cases arise, the group should strategically plan to scale-up and implement in line with national and international standards. The composition of the stakeholder groups may be dynamic with new members joining the group as new requirements emerge and are prioritized through established governance structures. {% hint style="success" %} **Resources and Examples:**[ ](https://docs.google.com/a/instedd.org/document/d/1jQUZ1n1Oh2d_VTeXlFj-Y2IPkqQXvoGDV6v98Y5n4DI/edit) * [**Actor and Stakeholders Guide**](https://docs.google.com/a/instedd.org/document/d/1jQUZ1n1Oh2d_VTeXlFj-Y2IPkqQXvoGDV6v98Y5n4DI/edit) * [ **Stakeholder List Template**](https://docs.google.com/a/instedd.org/spreadsheet/ccc?key=0AvRUEKy5Lc7BdDVIM2toWHZYQno0MFlZUVJ0d0ltRWc#gid=0) {% endhint %} # Determine and Document Roles and Responsibilities Phase 1: Component and Exchange Path ## **Determine and Document Roles and Responsibilities** Once stakeholders are identified, it is important to confirm the roles and responsibilities among the various stakeholders supporting the selected component(s) and any data entry or exchanges. There may be existing and new responsibilities for users ranging from data collection, data entry, curation, governance, management and support roles. {% hint style="success" %} **Reference:** [Digital Implementation Investment Guide (DIIG)](https://www.who.int/publications/i/item/9789240010567): Integrating Digital Interventions into Health Programmes (Chapter 2) {% endhint %} # Establish or Define Governance Structures Phase 1: Component and Exchange Path ## **Establish or Define Governance Structures** There is often a tendency to consult stakeholders and establish governance structures at the beginning of a project and end discussions there. Be careful to manage this pitfall as success of the project is often due to communication and buy-in from stakeholders and governance structures. If governance structures are already defined, clearly establish how the project team and stakeholders align and report to governance groups. If governance structures are not already in place, the team will need to begin to establish some governance structure that will work for the scope of the project. Consider options for forming a structure that can be used to support the current project with an eye toward establishing structures that can be used to govern health ICT projects as they arise. Make sure to consider the different stakeholder groups that may have to contribute the data captured, utilize the data or support the tooling or infrastructure as stakeholders are considered. As new business cases arise, the group should strategically plan scale up and implementation in-line with national and international data exchange and terminology standards. The composition of the stakeholder groups may be dynamic with new members joining the group as new requirements emerge and are prioritized through established governance structures. {% hint style="success" %} **Reference:** [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567) (Chapter 5.3: Leadership and Governance Considerations) {% endhint %} # Determine Project Scope Component Level Project and Exchange Level Project ## **Determine Project Scope** We strongly recommend an iterative project implementation process. When using an iterative process, implementation teams should designate an initial scope for a project and consider phases. For example, the vision may be to have all patients in the country or region listed in the client registry, this may not be practical or necessary for the first implementation of the registry. You will want to clearly state the vision and the goals for each phase of the project. For example, the first phase of a project might simply be to prove that data can be electronically shared between two systems. One of the main objectives for a governance structure is to determine the scope of use cases and user stories that will be supported by each iteration of the component or data exchange project and to determine how each subsequent iteration moves the team toward the larger goal for that project. For example, If you have selected to implement a Client Registry, then you may need to determine which point-of service providers or national ID systems will interact with the client registry in the initial implementation. Or, you may determine that only the women of childbearing age will be included. Each project team will need to work with the governance structure to set the scope based upon the HIE strategy, goals and priorities for the project. An ideal initial scope is large enough to prove that some part of the project technically works and small enough to do that in the specified context and still add value to the health providers, health system and / or patients. In an initial implementation, many teams limit scope by one or more factors such as: * Patient population * Region * Number of facilities * Number of indicators or data points * Number of features included # Document the Expected Value of the Project Component Level Project and Exchange Level Project ## **Document the Expected Value of the Project** It is important to document the value that one expects from component, health exchange and architecture projects. To help document the value, you may want to engage stakeholders in answering the following questions: * How can we benefit from the selected component(s), project or architecture? * Why are we interested in implementing it? * What problems are we trying to solve or what opportunities does this project open up? {% hint style="success" %} **Reference:** [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567) (Ch. 9 Value Proposition and Next Steps) {% endhint %} When possible, setting up measurable expectations are best. The following are examples of the qualitative value and descriptions of potential measures that might help guide you in thinkinging about the value of your project. In a pilot project, it may be appropriate to document that some of the value may be learning or proving how technology might work in your particular context. However, it is best to make sure that there is some health system value to the project as well. The value can be articulated in costs, but many health projects will provide more qualitative value. ### Examples of potential learning from projects: * Learn how an information exchange works * Learn about what is needed to support an information exchange * Learn about transaction frequency and bandwidth needs * Learn about process needed to support intermittent connectivity data sharing * Learn about FHIR ### **Examples of eHealth Architecture Value:** * Government leaders can better align their ongoing investments and coordinate disparate, technology-based systems to optimize the accessibility of data for use, systems-maintenance, and long-term sustainability. * Managers of country-health and public-health institutions can leverage the increased quality and availability of health data for greater visibility into programmatic impact, including on patient care, and the relative efficacy of different interventions, which will enable better decision-making and allocations of resources. ### **eHealth Architecture Measures might include:** * The number of transactions supported by a component or the different types of transactions supported by a component. * Documented different use cases that are aligned with the architecture * Number of point-to-point integrations eliminated or avoided * The number of data [exchange standards](https://ohie.org/framework/) identified and implemented ### **Examples of Component or Data Exchange Projects** * Knowing the real-time demand for various medicines and health commodities, or the level of training and availability of health professionals, is critical. * Health managers at all levels can better analyze the performance of institutions and identify gaps with a combination of Clients, previously seen as passive beneficiaries, can obtain better health care through a continuum of delivery in which they play an active role. ### **Measures might include** * Ability to provide near real-time statistics on commodities or resource availability in a region * Ability to plan for resource constraints or mobilizations during an outbreak # Establish a Project Plan Component Level Project and Exchange Level Project ## **Establish a Project Plan** A good project plan should address resources (technical and human), cost constraints and estimated timing. The resource plan and project plans should address the following types of activities that are considered to be in scope for the project: * Necessary governance check points required by the governance process. * Defining requirements. * System design and alignment with architecture and data exchange and terminology standards. * Establishing hosting environments and hardware and software upgrade processes. * Selecting, procuring, installing and configuring software and hardware components needed to support the project. * If this is a data sharing project, point-of-care systems or other systems that are sharing data may need to be enhanced to support data sharing. * Documentation of the technical solution and information required to support the solution. * Testing to prove that the system operates as desired, including data exchanges, business processes and load testing. * Development of policies and procedures required to support the system(s) and business processes. * Training for users and support staff. * Communications regarding roll out. * Support for end users and support for system patches and upgrades * For data exchange projects, also consider * Point-of-Care systems, insurance systems and / or national registry systems that will interact with the component you are implementing may need to be enhanced to communicate with the appropriate architecture components through the Interoperability Layer of the architecture. * Configuration and testing with interfacing point-of-care systems, insurance systems and / or national registry systems that are within the scope of the project.
{% hint style="success" %} **Reference:** [Infrastructure & Procedures Checklist](https://docs.google.com/spreadsheets/d/1xTvwUJUEN62yFr8TK4mOynk333Iv8kRbpu4ihjh_WOM/edit#gid=0) {% endhint %} # Pathway 1.2 - Requirements and Design Component Level Project and Exchange Level Project INPUT SOME GRAPHIC HERE FOR PHASE 2 / PATHWAY 1 ## People * [ ] [Establish Training Programs](/getting-started/dev/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/establish-training-programs) ## Process * [ ] [Determine Resources and Identify Constraints and Environmental Factors](/getting-started/dev/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/determine-resources-and-identify-constraints-and-environmental-factors) * [ ] [Analyze the Environment and Context](/getting-started/dev/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/analyze-the-environment-and-context) * [ ] [Identify System Constraints](/getting-started/dev/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/identify-system-constraints) * [ ] [Document Requirements](/getting-started/dev/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/document-requirements) * [ ] [Select Software/Component(s)](/getting-started/dev/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/select-software-component-s) * [ ] [Testing](/getting-started/dev/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/testing) {% content-ref url="/pages/-MbkzdubiTD6syhAgqD3" %} [Pathway 1.3 - Implement, Support, and Scale](/getting-started/dev/pathway-1-component-and-data-exchange/phase-3-implement-support-and-scale) {% endcontent-ref %} # Establish Training Programs Component Level Project and Exchange Level Project ## **Establish Training Programs** We recommend identifying training needs and establishing a training plan. When considering training needs, look at data creation and use activities as well as systems support. Consider the following: * Training system users on the business processes and systems features required to enter, and update information * Training of the system support staff/help desk personnel in key operational aspects of the systems and data exchanges being implemented * Training on installation / upgrade / backup processes * Training on any data privacy / data security policies and procedures applicable to data capture, storage, use and transfer # Determine Resources and Identify Constraints and Environmental Factors Component Level Project and Exchange Level Project ## **Determine Resources and Identify** **Explore Opportunities and Challenges** The motivations driving an implementation can be detailed by the perceived opportunities or challenges that stakeholders face. For example, implementing a Facility Registry might include the desire to share data across systems related to health facilities for supply chain management, monitoring and evaluation, health service delivery and many other systems. {% hint style="success" %} **Resources and Examples:** * **Job aid:**[ Opportunity Brainstorming Methods](https://docs.google.com/a/instedd.org/document/d/1aBxu3GysAyGtpPG3s1LFpTZimO8lyO4p6yhV3e2BHlA/edit) - Example for a facility registry. This can be modified for use with other project types. * **Job aid:**[ Risk Identification and Management](https://docs.google.com/a/instedd.org/document/d/17Gu76gShQhPz6axQzirT7c8LL8Ckwk8qnekC-SSKLL0/edit#heading=h.ydr5ktvto6o0);[ Risk Matrix Template](https://docs.google.com/a/instedd.org/spreadsheet/ccc?key=0AvRUEKy5Lc7BdGlvRm5yNk1PbmtXRUYzU1R3elNrZ3c#gid=0) * **Tanzania Example:**[ Tanzania Facility Registry Goals and Challenges](https://docs.google.com/document/d/1jSyiytftmCGM_-d5hfKS_mVhDkh0Ol1ZdSsPc-wN7gU/edit?usp=sharing) {% endhint %} **Identify Applicable Standards** While researching the data needed in your context, list any applicable terminology and data standards used. The source of these standardized data lists can either be from international sources or defined by appropriate national bodies. In some cases, there may be local standards that are used across health systems. If local terminology standards are used, you may want to consider linking those to international standards or codes. Each standardized list should include a code that components of the health information system can use to refer to the element as well as a textual representation of that element in one or more languages. {% hint style="success" %} **Examples:** * [Philippines National Health Data Dictionary](http://uhmis1.doh.gov.ph/UnifiedHMIS/images/downloads/Forms_and_Manuals/NHDD_v2_Jan_17_2011.pdf) * [The FHIR Patient Resource identifies options for gender](https://www.hl7.org/fhir/patient.html) * [FHIR Implementation Guides Registry](http://www.fhir.org/guides/registry/) - Each FHIR IG may contain applicable value sets. * [ISO/TS 22220:2011 Identification of Subjects of Healthcare](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=59755) * [ISO 21091:2013](http://www.iso.org/iso/catalogue_detail.htm?csnumber=51432): Health informatics -- Directory services for healthcare providers, subjects of care and other entities. * Laboratory Tests -- [LOINC](http://www.loinc.org/) {% endhint %} **Critical Integrations** In addition to collecting and standardizing facility lists, it is important to identify and achieve critical integrations with priority systems. Multiple APIs are available to facilitate the automated transmission of data; however, it will be required that some code be incorporated into the partner system to consume the API. For example, common high priority systems to consider integration with the facility registry include: DHIS2, CommCare, PROMIS, and OpenLMIS. You’ll need to determine what the critical integrations are for your project. \
# Analyze the Environment and Context Component Level Project and Exchange Level Project ## **Analyze the Environment and Context** To begin the requirements and design process, start by analyzing the current environment. Seek to answer the following: * *What are the current processes in this context?* * *Are there existing policies and procedures that might be impacted or provide guidance for the project?* * *Are there technical solutions and infrastructures already in place?* * *What is known about the system users and their ability to interact with the system?* * *Are there specific language needs to support system users?* * *How will you know if you have succeeded?* * *What are the challenges or barriers to successful implementation?* {% hint style="success" %} **Reference:** [Infrastructure & Procedures Checklist](https://docs.google.com/spreadsheets/d/1xTvwUJUEN62yFr8TK4mOynk333Iv8kRbpu4ihjh_WOM/edit#gid=0) {% endhint %} # Identify System Constraints Component Level Project and Exchange Level Project ## **Identify System Constraints** **Identify System Constraints** Identifying the high-level system constraints will help implementers understand the factors that need to be addressed in order to design a system that fits the unique context. Identify known constraints such as: * Data Capacity - For example, the following types of questions might be asked about a client registry or a shared health record; What is the country’s population? How many of those people will the registry need to support? How many patients are already stored in point-of-care applications? For other projects, the questions may be about how many facilities or products need to be supported. * Data Quality - How complete and accurate is the patient demographic data captured in the existing point-of-care and/or national identifier systems? Which existing records are paper and which are electronic? * Network Capacity and Reliability - Are there constraints on the network reliability or capacity? Are secure network connections between organizations already established? * Power Constraints- Are there any constraints on electricity or power? If so, what are they? * Data Privacy Laws and Regulations– Are there any local or regional data privacy laws that apply to the client’s demographic data? * Other healthcare software laws or regulations – Are there applicable guidelines for managing healthcare records or for validating healthcare software? Based upon the country’s unique context, there may be additional constraints that need to be documented. \
# Document Requirements Component Level Project and Exchange Level Project ## **Document Requirements** **Document Data Specifications** A data specification document is a technical tool describing the data elements or the information to be managed in one or more registries. This is a similar concept to a data dictionary where the representations, meaning, and format of data elements in the system are documented. It is recommended one consider the appropriate [FHIR Resources](https://www.hl7.org/fhir/resourcelist.html) and [FHIR Implementation Guides](https://www.fhir.org/guides/registry/) for registries such as the Facility Registry, Client Registry, Health Worker Registry and Product Catalogue. In addition, you will want to consider inclusions of any key local attributes. Other considerations include alternate representations, i.e., “mappings”, that may be required for reporting to external authorities, sharing data with other eHealth systems, or alternate stakeholder needs. {% hint style="success" %} **Resources and Examples:** * **Job aids:**[ Facility Registry Data Specification Guide](https://docs.google.com/document/d/1V1nw2aLUUdDHJk_C36GRpiPAcRW1n89WaYZtFTWp4mE/edit?usp=sharing);[ Draft WHO MFL Guide](https://docs.google.com/a/instedd.org/file/d/0B_RUEKy5Lc7BS2swR3ZDTjZZeTQ/edit?usp=sharing) * **Tanzania Example:**[ TZ Facility Registry Data Specification](https://docs.google.com/document/d/1X_3unJ6v3ZOgmXHQ4W98zKXzy7uifi9h_ZLUyULX88M/edit?usp=sharing) * **Rwanda Example:**[ RW Registry Specifications (See Page 17)](https://drive.google.com/file/d/0B_RUEKy5Lc7Bd0tuYzVmcFdiY1E/edit?usp=sharing) {% endhint %} **Document Component Functional Requirements** Each OpenHIE component will have both data exchange needs including the ability to support specific standards and APIs and needs for functional requirements. You should start your journey by looking at the [OpenHIE Architecture Specification](https://ohie.org/framework/). This will outline some of the key requirements for each type of component. For functional requirements, you may want to additionally document them using user stories. User Stories are a mechanism to gather user requirements and/or core requirements describing the desired registry functionality. They are a short and simple description of how a particular user needs to interact with the system. They tell who, what and why the person is interacting with the system. The following are two short examples of user stories from different projects. * **Example User Story – Other Clinic Visits:** * A pregnant woman enters the clinic for her first appointment. The healthcare worker collects the patient’s name and demographic information. The worker wants to see if the woman has had visits at other clinics so the worker enters in the demographic information and asks for data from other institutions. The system will determine if the patient has visited other point-of-care facilities and return the references to those visits. * **Example User Story – Insurance Verification:** * A man walks into a clinic he has not visited before. The health worker needs to verify the man’s insurance. The health worker asks for his name and geographic information. The man provides the information. The health worker enters in his information and asks for insurance verification. The system will use the information entered to check with insurance providers and verifies that the man has insurance. **Document Data Exchange Requirements** The data exchanges are the processes for sharing data between OHIE components. We recommend drawing out the data exchange required using interactions diagrams. The [OpenHIE Specification](https://ohie.org/architecture-specification/) can provide a foundation for recommending the standards and processes for data exchange. Along with the typical technical expertise required to develop and implement a technology solution, the registry requires technical knowledge of healthcare transactions standards such as IHE PIX/[PDQ](https://wiki.ohie.org/display/documents/Patient+Demographics+Query+IHE+ITI-21+Transaction). The [OpenHIE Architecture Specification](https://ohie.org/architecture-specification/) outlines the recommended standards for each transaction. If you need to implement a data exchange that is not already outlined in the [OpenHIE Architecture Specification](https://ohie.org/architecture-specification/), please contact the [OpenHIE Architecture Community](https://wiki.ohie.org/display/resources/Architecture+Subcommunity+Call) to gain alignment, ensure that any work your team is doing can be used by others and get any help needed for creating FHIR IGs and/or IHE profiles if they do not already exist. {% hint style="success" %} **References:** * [OpenHIE Standards and Profiles](https://wiki.ohie.org/display/documents/OpenHIE+Standards+and+Profiles) * [OpenHIE Architecture Specification](https://ohie.org/architecture-specification/) {% endhint %} **Document Data Privacy Impact and Requirements** If the project component(s) or information exchanges contain patient demographic data that is used to identify a person, it is important to understand any national and/or local data privacy laws that apply to this data. The role of the governance structure and content owner is to understand privacy laws and ensure policies, procedures and processes are in place to protect patient privacy. Based upon applicable privacy and electronic records regulations for your context, an implementation team may need to address privacy and the appropriate management of electronic healthcare records through measures such as: * Guidelines for granting access to the component 1. *(Who approves access? Who can access the registry and when is access allowed?)* The guidelines may need to consider: * Physical access to servers and data * Database access via DBA (Database Administrator) or technical resource and perhaps a client registry application * Exchange access *(What systems can provide data to or receive data from the registry?)* * Documented annual or regular privacy training for those with access to the component * Process for annually reviewing data access * Privacy and security incident management processes. *(How are potential breaches of security or privacy to be handled?)* {% hint style="success" %} **Resource:** [Guidelines on Protecting the Confidentiality and Security of HIV Information](http://data.unaids.org/pub/manual/2007/confidentiality_security_interim_guidelines_15may2007_en.pdf) - While aimed at HIV patient data, this resource can be used to help understand privacy, confidentiality and security concerns for patient information. **Reference:** [OpenHIE Privacy and Security](https://wiki.ohie.org/display/SUB/OpenHIE+Privacy+and+Security) {% endhint %} **Agile and Iterative Development** After the identification and prioritization of requirements and user stories is complete, agile and iterative development takes the prioritized lists and applies the project team to resolve the prioritized requirements and user stories. Additional requirements and user stories will continue to be generated throughout the lifetime of the implementation and should be prioritized and similarly addressed by the team. Initially, the goal of this activity will be to address the user stories that will result in a viable and operational OpenHIE component(s) or data exchanges. Additional, development will continue to occur and will also be informed through routine testing and re-prioritization among the team. A GitHub or similar repository to track this process can help to keep both technical and non-technical stakeholders engaged and accountable. # Select Software/Component(s) Component Level Project and Exchange Level Project ## **Select Software/Component(s)** Based upon the requirements documented, your team will need to evaluate and select software solutions. When selecting software, it is important to understand the current state of your eHealth architecture. If there is an architecture in place, you will want to select a solution that aligns with the architecture or the future direction of the architecture. We recommend documenting a high-level process to follow. The following steps may be helpful: ### 1. Landscape assessment of tools This can be done through a landscape assessment to determine the tools that are out in the field and how they align with your strategy. You may want to categorize in a meaningful way that helps you think about the field. One example is to use a two-by-two grid to help categorize the tools in some way. | General Use, High Initial Investment | Health Specific Use, High Initial Investment | | ------------------------------------ | -------------------------------------------- | | General Use, Low Initial Investment | Health Specific Use, Low Initial Investment | ### 2. Narrow the list Narrow the list of possible tools to ones that align with your strategy and architecture. Look at factors such as your ability to support the underlying technology, the maturity of the tool / references from other projects / deployment strategies, ability to support your security needs, ability to support data exchanges and standards and your contextual needs to narrow the list to tools you will evaluate more closely. Document the criteria you used to narrow the field as this may be needed to support your decision or if suitable tools are not found in further review stages. Methods for helping narrow might be looking at their websites, sending some email questions and / or having a quick phone conversation. ### 3. Assess business requirements Once you have chosen a few tools to look at more closely, you will need to have a list of high -level business requirements and needs for the tool assessment. We recommend having the tool creator to demonstrate and / or sketch out how they would tackle one of your business challenges (use cases) to allow your team to make an effective evaluation. The [OpenHIE Architecture Specification](https://ohie.org/framework/) contains a list of based component requirements as well as data exchange requirements for each of the architecture components. You may want to use this as a base for documenting the requirements for the components that you’ll need. You’ll want to think about the following when looking at the available tools: 1. Ability to support the platforms that the tool runs on 2. Ability to support and deploy the tool ### 4. Document your process We recommend documenting your selection process and the results of the process so that you can communicate the reasoning for the decision. You will want to complete some type of an evaluation process for each of the components you need to select. {% hint style="success" %} **References:** * [Example Tool Evaluation Sheet for Demonstration / Interview Discussion ](https://docs.google.com/document/d/19XlZHaOrixnOVO2UqvL1TkIzgK1MpNTOvkfnBWgzqxw/edit) * [Outline for Tool Demonstration](https://docs.google.com/document/d/1szBCgu8QO4lwVFiDorhHez_iKC1kYObnLJfUzR5TpZk/edit#heading=h.pmbpp94xcyj1); [OpenHIE Reference Technologies ](https://wiki.ohie.org/display/documents/Reference+Technologies) * [OpenHIE Architecture Specification](https://ohie.org/framework/) {% endhint %} # Testing Component Level Project and Exchange Level Project ## **Software Validation and Testing** There are many components required to validate and test software that is used to manage healthcare records. Some ministries of health like the United States FDA have specific guidance documents that need to be followed to ensure that healthcare software has been appropriately validated and tested and that electronic records requirements are being met. The purpose of this section is not to detail good software validation practices, but to highlight specific testing considerations for health software. ### **Workflow Testing (Integration Testing)** You will need to test to ensure that any components sharing data with other components appropriately integrate with the Interoperability Layer and each of the point-of-care systems or other systems that will provide or receive data. One approach for this testing could be to test various iterations of each workflow(data exchange) that will be used between each of the various components involved. This testing would then be repeated for each system that is in scope. This approach paired with an approach that goes through the whole health care process is recommended. ### **Performance and Load Testing** There are at least two aspects of performance testing that will need to be addressed. First is transaction through-put. This can be tested by estimating the number of transactions (data exchanges) that will be expected during peak business times and ensuring that the network and hardware can support this volume of transactions. \ \ The second aspect of testing that needs to be considered is ensuring that the registry/OpenHIE component(s) is configured to support the number of records required to be stored in the component at its peak usage for the given scope. For component systems such as the client registry, facility registry and other OHIE components, hardware, databases, matching algorithms and key system functions will need to be tested to ensure that they are appropriately configured and tuned to handle the estimated number of records expected in the next two or three years. ### **User Testing** A key component of the agile process initiated will be to conduct routine field testing of the system that should be completed to gain feedback from a subset of system users. The goal of this activity is to obtain user feedback on the use of the component. The testing should be a separate activity from augmented or decentralized processes to collect and standardize data that may also be desired as part of the governance and management of a facility registry system. It is also likely that the formality of the testing may vary based on the availability of resources and at the request of the central stakeholders. {% hint style="success" %} **Examples and References:** * **Example:** [**User Testing Guide**](https://docs.google.com/document/d/1ZGqn_0XJYdzZLTE25sUjQEkeosM5lSV5xJ0GsmAjGzU/edit?usp=sharing) * **Reference:**[ **INVEST in Good Stories, and SMART Tasks**](http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/) * **Reference:**[ **Examples of Rwanda User Stories for RHIE**](https://wiki.ohie.org/download/attachments/10486056/RHEA%20storyboard%20%284%29.pptx?version=1\&modificationDate=1386949763329\&api=v2) {% endhint %} # Pathway 1.3 - Implement, Support, and Scale Component Level Project and Exchange Level Project ## People * [ ] [Establish a Support Plan](/getting-started/dev/pathway-1-component-and-data-exchange/phase-3-implement-support-and-scale/establish-a-support-plan) * [ ] [Implement a Scalability Plan](/getting-started/dev/pathway-1-component-and-data-exchange/phase-3-implement-support-and-scale/implement-a-scalability-plan) ## Process * [ ] [Communication and Roll out](/getting-started/dev/pathway-1-component-and-data-exchange/phase-3-implement-support-and-scale/communication-and-roll-out) # Establish a Support Plan Component Level Project and Exchange Level Project ## **Establish a Support Plan** ### **Create Support Plan** It should be expected that requirements and requests for OHIE components and data exchanges between them will evolve over time. For this reason support strategies should be developed and should remain in place to triage requests for data, system enhancements, integrations, operations support or general troubleshooting among users. Common types of ongoing support are described below. ### **Operations Support** Operations support is intended to maintain the logistics and infrastructure required for each of the components. The content owner, infrastructure owner and software owners will need to support the system. This support includes: monitoring error logs, maintaining a server, ensuring security protocols, carry out backups, and software and hardware updates as needed. ### **Developer Support** Developer support is important to facilitate any future adaptations of the OHIE components and data exchanges. For instance it may be desirable to create a specialized data curation function, additional workflows (data exchanges), or other applications that would work in coordination with the registry or components in a service oriented fashion. Developer support will also include the identification, documentation and resolution of any enhancement requests or software bugs. ### **Integration Support** Ongoing support will be required to triage requests for integration, issues, and API enhancements to support other systems interested in consuming your selected components’ data. New systems that want to consume an API may also require some technical assistance to create an end node in their application to facilitate integration. ### **Data Support** Ongoing support will also require assistance for issues related to data collection, curation, analysis and utilization. There will be ongoing requirements to provide training, troubleshoot issues and respond to data access requests by users. Other aspects of data support include: data collection, entry, permissions, bulk imports, data flows, curation, and data quality. ### **Help Desk Support** Help desk support may not be required initially, but as more users and organizations start using the registry or relying on the data exchanges it may become important to identify, document, triage and direct response to types of requests from the varied types of users. ### **Capacity development and Training** To appropriately provide the support mentioned above, there will need to be training to build the capacity of support personnel to enable them to perform basic administration of OpenHIE components and data exchanges. In addition, there may be changes regarding scope, data and quality improvements as outlined in the support plan. ### **Post-Production Evaluation** Post production, it is important to capture lessons learned. One helpful exercise is to have the team make two lists. In the first list, the team should document the aspects of the project that worked well. This will provide insight into processes that can contribute to the success of additional project iterations. In the second list, the team should note the items that could be done differently next time. This exercise is important as the implementation process is meant to be iterative. Once the system is running and stabilized, the iterative development process can begin again with an expanded scope. New interfaces, user stories or workflows may need to be added.\ \
# Implement a Scalability Plan Component Level Project and Exchange Level Project ## **Implement a Scalability Plan** **Scale-Up** The goal of this step is to engage appropriately with stakeholders to ensure the management and institutional processes are in place for ongoing curation, governance, and data utilization. The governance structure and / or stakeholders will need to create a scalable support plan in order to support an agile environment. Don’t forget to test the system’s capabilities to handle additional transaction and data loads as additional use cases or regions are added to scope. # Communication and Roll Out Component Level Project and Exchange Level Project ## **Establish Communications Plan** The roll out of a new system, process or procedure often requires a communication plan. Review your stakeholder list to ensure that those who are a part of the governance process, using the software, impacted by new processes being established, additional or upgraded systems or technology are appropriately informed and updated about changes in process and policies.\
# PATHWAY 2: Architecture Select the appropriate phase of the project to get started. * [Phase 1: Governance, Value, and Scope](/getting-started/dev/pathway-2-architecture/untitled) * [Phase 2: Requirements and Design](/getting-started/dev/pathway-2-architecture/phase-2-requirements-and-design) * [Phase 3: Implement, Support, and Scale](/getting-started/dev/pathway-2-architecture/phase-3-implement-support-and-scale) # Pathway 2.1 - Governance, Value, and Scope Architecture Level Project ## People * [ ] [Identify Stakeholders](/getting-started/dev/pathway-2-architecture/untitled/identify-stakeholders) * [ ] [Determine and Document Roles and Responsibilities](/getting-started/dev/pathway-2-architecture/untitled/determine-and-document-roles-and-responsibilities) ## Process * [ ] [Establish or Define Governance Structures](/getting-started/dev/pathway-2-architecture/untitled/establish-or-define-governance-structures) * [ ] [Scope](/getting-started/dev/pathway-2-architecture/untitled/scope) * [ ] [Define Value of Health System Architecture](/getting-started/dev/pathway-2-architecture/untitled/define-value-of-health-system-architecture) * [ ] [Establish a Project Plan](/getting-started/dev/pathway-2-architecture/untitled/establish-a-project-plan) {% content-ref url="/pages/-MblKNJUM--K6n\_rv2Nf" %} [Pathway 2.2 - Requirements and Design](/getting-started/dev/pathway-2-architecture/phase-2-requirements-and-design) {% endcontent-ref %} {% content-ref url="/pages/-MblKV2wOQQ19aZOc1uz" %} [Pathway 2.3 - Implement, Support, and Scale](/getting-started/dev/pathway-2-architecture/phase-3-implement-support-and-scale) {% endcontent-ref %} # Identify Stakeholders Architecture Level Project ## **Identify Stakeholders** To establish the architecture, the stakeholders may be a bit broader than they are for a typical data exchange or component project. \ \ To identify stakeholders, ask questions such as: * *Who is impacted by these architectural standards and who are the other interested parties?* * *Is there a larger governmental architecture, standards body or ICT infrastructure that the health architecture needs to align with?* * *Are there advocacy groups that can help?* ### Stakeholders to Consider * Organizations or people that support software solutions * Key architects or developers * Key or influential project leads * Other government of MOH architects that the health architecture may need to align with * Government ICT organizations that support health projects or infrastructure * Organizations driving the project * Ministry of Health representatives * Technical and infrastructure support teams (e.g. help desk personnel, system hosting and connectivity providers) that may end up supporting the component(s), the bandwidth or other technology needed for the project to be successful. ### **Identifying Stakeholder Motivations** Once potential stakeholders are identified, it is helpful to understand high-level stakeholder motivations and challenges. Understanding these motivations will help teams engage and recruit the individuals that will represent the organizational stakeholders in: * Defining the architecture project scope * Vetting and prioritizing key use cases and user stories that the architecture needs to support * Moving toward alignment on architecture standards Ask questions such as: * *Are there different/varying motivations among interested and impacted parties?* * *What might be the success criteria for different stakeholders?* # Determine and Document Roles and Responsibilities Architecture Level Project ## **Determine and Document Roles and Responsibilities** Once stakeholders are identified, it is important to confirm the roles and responsibilities among the various stakeholders. It is recommended that there is a clear governance structure and mechanisms are in place to align projects with the architecture. Recommended Roles: * Enterprise Architect - this role may or may not be a full-time role, but will be needed to ensure that the architecture is documented and that there are processes in place to help projects align with the architecture. {% hint style="success" %} **Reference:** [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567): (Chapter 2: Form the Team and Establish Goals) {% endhint %} # Establish or Define Governance Structures Architecture Level Project ## **Establish or Define Governance Structures** There is often a tendency to consult stakeholders and governance structures at the beginning and end discussions there. Be careful to manage this pitfall as success of the project is often due to communication and buy-in from stakeholders and governance structures. If governance structures are already defined, clearly establish how the project team and stakeholders align and report to established governance groups. \ \ If governance structures are not already in place, the team will need to begin to establish some governance structure that will support definitions and maintain the health architecture. Depending upon the scope of the architecture and the goals for getting started, the governance structure may need to consider engaging the following types of groups or groups that support these services: * Government and / or Ministry of health ICT * Government and / or Ministry of health internet and technical infrastructure * Country standards groups boards or bodies * Government and / or Ministry of health cloud services or hosting services teams. * Private healthcare stakeholders or research organizations that may need to interact with MOH services and data * Privacy and security officers or advisers * Country or regional identity managers * Civil registries * Health supply chains {% hint style="success" %} **References:** * [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567) (Chapter 6: Digital Health Architecture) * Nsaghurwe, A., Dwivedi, V., Ndesanjo, W. et al. [One country's journey to interoperability: Tanzania's experience developing and implementing a national health information exchange. BMC Med Inform Decis Mak 21, 139 (2021).](https://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-021-01499-6) {% endhint %} # Determine Project Scope Architecture Level Project ## **Determine Project Scope** The scope of the architecture can be a bit challenging. One perspective is to think about the systems and data sharing transactions that are in the purview of the ministry of health. However, there may be other health data and health transactions that are in the jurisdiction of other ministries. Examples of this may include the health supply chain and / or health medications and insurance coverage practices may be important even if these are not directly in the purview of the MOH. To help move forward, you can begin with the architecture under a specific jurisdiction. However, you may want to include other branches as appropriate in the stakeholders. You may want to use any existing health strategy documentation, examples from other countries and / or the OpenHIE Architecture Specification and Diagram to help think about scope of the architecture. Ultimately, you will need to understand the systems that are needed to support the data sharing goals of the country. To begin to identify these needs, use the DIIG (Chapter 3). {% hint style="success" %} **References:** * [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567): (Chapter 3: Identify Health System Challenges and Needs) * OpenHIE Architecture Specification
{% endhint %} # Define Value of Health System Architecture Architecture Level Project ## **Define Value of Health System Architecture** National digital-health architectures are blueprints that establish the health and information needs and the software and hardware requirements that governments must consider to deliver digitally-supported health programs in a coordinated manner. These blueprints can provide critical guidance to governments, the private sector, non-governmental providers, and donors about how to invest in digital technologies and services in an aligned way that supports capture of patient-level data that can be aggregated and used throughout the health system. It is important to discuss and articulate the value of this investment with stakeholders and the appropriate governance structures.
{% hint style="success" %} **Reference:** [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567) (Chapter 6: Digital Health Architecture) {% endhint %} # Establish a Project Plan Architecture Level Project ## **Establish a Project Plan** A good project plan should address resources (technical and human), cost constraints and estimated timing. The resource plan and project plans might address the following types of activities that are considered to be in scope for the project: * Identification of architecture stakeholders. * If an eHealth Governance structure is not already in place, you will most likely need to outline time and activities to establish the governance structure. * Necessary governance checkpoints for the Architecture creation. * You may want to consider doing an inventory of existing health software / software projects. This will help with understanding of tools in the field. * Defining requirements or specific scope of the information and data exchanges that the architecture needs to support. [See DIGG (Chapter 3 Identify System Challenges and Needs)](https://www.who.int/publications/i/item/9789240010567) * Establishing [architecture principles](https://docs.google.com/document/d/1kXL3ZaCdyaqk1gpgaT_XaUVYZe-okImr-VAK_l_CHjo/edit). * Defining and documenting the principles and architecture components. * Defining standards. For example, are there specific data exchange standards such as those mentioned in the [OpenHIE Architecture Specification](https://ohie.org/framework/). You may also want to consider aspects such as noting that new software should support standard APIs. * Defining processes, procedures and expectations for new project teams. For example, there may be specific times that a project team needs to present to a governance or architecture team to provide a plan for alignment with the architecture principles and standards. * Defining roles and governance structures to establish and support curation of the architecture and support project teams in aligning with the architecture. {% hint style="success" %} **References:** * [Architecture Principles](https://docs.google.com/document/d/1kXL3ZaCdyaqk1gpgaT_XaUVYZe-okImr-VAK_l_CHjo/edit); [OpenHIE Architecture Specification](https://ohie.org/framework/) * [Digital Implementation Investment Guide:](https://www.who.int/publications/i/item/9789240010567) (Chapter 3: Identify System Challenges and Needs) {% endhint %} # Pathway 2.2 - Requirements and Design Architecture Level Project ## Process * [ ] [Inventory Existing Tools](/getting-started/dev/pathway-2-architecture/phase-2-requirements-and-design/inventory-existing-tools) * [ ] [Document Use Cases](/getting-started/dev/pathway-2-architecture/phase-2-requirements-and-design/document-use-cases) * [ ] [Establish Architecture Principles](/getting-started/dev/pathway-2-architecture/phase-2-requirements-and-design/establish-architecture-principles) * [ ] [Document the Architecture](/getting-started/dev/pathway-2-architecture/phase-2-requirements-and-design/document-the-architecture) * [ ] [Establish Architecture Processes](/getting-started/dev/pathway-2-architecture/phase-2-requirements-and-design/establish-architecture-processes) * [ ] [Establish Standards](/getting-started/dev/pathway-2-architecture/phase-2-requirements-and-design/establish-processes) {% content-ref url="/pages/-MblKV2wOQQ19aZOc1uz" %} [Pathway 2.3 - Implement, Support, and Scale](/getting-started/dev/pathway-2-architecture/phase-3-implement-support-and-scale) {% endcontent-ref %} # Inventory Existing Tools Architecture Level Project ## **Inventory Existing Tools** When determining your strategy or road map, it may be useful to determine if there are existing tools that can support the desired information exchange use cases. When conducting the inventory, it may be useful to determine some of the following factors that will help in determining if use of the tool can be expanded to support the desired health information exchange use cases: * Implementation scope ( for example, the number of cases, patients or geographical scope of the implementation) * Ability to support data sharing through standards-based APIs / creation of standard message specifications (IHE profiles - See [OpenHIE Architecture Specification](https://ohie.org/framework/)) * Ability to support the tooling * Documentation is present and easy to understand * Source code is accessible and programming languages are understood by developers * Ability to support applicable terminology data standards {% hint style="success" %} **Tools:** [Digital Health Atlas](https://digitalhealthatlas.org/en/-/) **Reference:** [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567): (Chapter 4.2) {% endhint %} # Document Use Cases Architecture Level Project ## Document Use Cases Project teams can use different language to refer to the health business processes or practices for data exchange. We will use the term "use cases". As outlined in the digram below, OpenHIE is designed to support broad areas of use cases that cover individual patient care, population and public health and healthcare administration. Documenting your desired use cases is a step toward establishing the high-level requirements for your health information exchange. For examples of how countries and project teams are using health information exchange architecture, see the [OpenHIE Impact Stories](https://ohie.org/impact-stories/). ![](https://3308277642-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MaFTi2cXYF3MOUIP8lR%2F-Me5zeJ8tkgwdWzDi5vi%2F-Me61_lfpWR_bNfZP3uS%2FOpenHIE%20Architecture%20.jpg?alt=media\&token=b0473846-29b6-4d67-ac6f-b8df830a46d0) {% hint style="success" %} **Reference:** [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567): (Chapter 3.1.1) {% endhint %} # Establish Architecture Principles Architecture Level Project ## **Establish Architecture Principles** Just as a city’s infrastructure is designed to support the needs and uses of a city, the eHealth Architecture exists to support the needs for a country’s or region’s health goals and objectives. eHealth Architecture Principles are the underlying guidelines that ensure that eHealth technologies and technology projects support the eHealth strategies and objectives in a way that maximizes the investment. Because architecture principles are foundational, disparate organizations may share similar architecture principles. In summary, the eHealth principles provide a foundation for making conscious decisions about technology. ### What are Architecture Principles and why have them? Just as a city’s infrastructure is designed to support the needs and uses of a city, the eHealth Architecture exists to support the needs for a country’s or region’s health goals and objectives. eHealth Architecture Principles are the underlying guidelines that ensure that eHealth technologies and technology projects support the eHealth strategies and objectives in a way that maximizes the investment. Because architecture principles are foundational, disparate organizations may share similar architecture principles. In summary, the eHealth principles provide a foundation for making conscious decisions about technology. ### **What areas do architecture principles typically address?** TOGAF, The Open Group Architecture Framework, and other architecture processes or frameworks identify different types of architecture principles. To be effective, architecture principles do not need to be organized into categories. However, the following categories serve to help guide thinking about the content areas that architecture principles typically address. While these categories may have some overlapping scope, it may be helpful to ensure that the following types of principles are considered. #### Business Principles For an eHealth Architecture, these principles define how the architecture will support the Health and/or eHealth goals and objectives of the Ministry of Health. These principles typically address topics such as: * Scope of the principles or the business areas that are expected to be aligned with the principles. * Alignment with strategic Health and/or eHealth goals. * Need for consideration of the full life-cycle of technology. * Support for applicable laws and regulations. #### Data Principles For an eHealth Architecture, these principles define how the eHealth data will be managed and governed. These principles typically address topics like: * Expectations regarding data security, data privacy, and transparency. * High-level expectations relating to data governance and management. #### Technology and Application Principles To provide the best service possible, some organizations may have principles about their technology and application development approaches. The principles should be above any specific technology. These principles may address topics such as: * A preference for service oriented or agile architecture. * A preference for a specific application hosting strategy. * If technologies need to be supported and maintained internally, there may be a preference to limit technology diversity or restrict to certain types of licensing. * Process Principles - These are principles that guide the processes for how technology projects are approached. These principles may address topics such as: * A systems approach to ensure the solution aligns with the eco system and is focused on user needs. * The desire to participate in open standards and processes. ### **What does an architecture principle include?** The following is a general structure for architecture principles. Some organizations may use a different format or have additional categories of information that is captured. ### **Example Principles Structure** * Principle name - this is succinct and represents the essence of the principle. * Description or definition - A two or three sentence definition or description of the principle. It is important to not use vague words like “consider”. * Business rationale - A statement on the value or benefit of using this principle. ### Examples of Architecture Principles The following are illustrative examples of Architecture Principles. The list is intended to help generate thought around the types of principles that may be applicable to a specific environment. This is not intended to be an exhaustive list and it is expected that principles and descriptions will be modified extensively to fit the needs of the environment. The reference column provided in the table below points to resources where the principle is referenced. #### Business Principle Examples | **Example Principle Name** | **Example Description** | **References to the principle or a similar principle** | | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | 1. Adherence to the Principles | These principles apply to all eHealth projects in the country. |

TOGAF

Scotland Health Directorate

| | 2. Maximize Benefit to the Health Ministry and the eHealth Strategy | Information management decisions are made to provide maximum benefit to the country’s Ministry of Health and eHealth strategy as a whole. |

TOGAF

Scotland Health Directorate

| | 3. Inclusiveness | All organizations in the Ministry of Health and all stakeholders participate in information management decisions needed to accomplish health objectives. | TOGAF | | 4. Legal Compliance | eHealth information management processes comply with all relevant laws, policies, and regulations. | TOGAF | | 5. Standards Based | The architecture and solutions use relevant open eHealth standards where standards are available. |

Scotland Health Directorate

USG

OpenHIE

Digital Principles

| | 6. Build for Sustainability | Plan for sustainability from the start, including planning for long-term financial health e.g., assessing total cost of ownership. |

Digital Principles

BID

| | 7. Solutions are based upon the eHealth business needs and reference architecture | Solutions will be based upon eHealth business needs and the eHealth Architecture guides the design and delivery of solutions. | Scotland Health Directorate | | 8. Leverage existing investments | The Country’s eHealth solutions will leverage maximum benefit from existing eHealth investments that can be aligned with the eHealth reference architecture. | Scotland Health Directorate | | 9. Reuse, Buy, Build | Where possible, software solutions are reused. If reuse is not possible and solutions are externally available either via open source or from software vendors, they will be selected. Only where ministry requirements are substantially unique, or where specific constraints arise, will development be considered. | Scotland Health Directorate | | 10. Accountability | Making roles and responsibilities clear | | | 11. Transparency | Making it clear on the where, when and how decisions are reached | | #### Example Data Principles | **Example Principle** | **Description** | **References** | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | 1. Information is an asset and is governed | Data and Information are assets and are managed and governed accordingly. Each data element has a data steward responsible for the definition of the data and ensuring that there are processes to ensure accuracy, and reliability. There are defined rules on who can create, modify, view and delete data. |

Scotland Health Directorate

TOGAF

| | 2. Privacy and Security of data | All information is secured against unauthorized access, modification or loss. Consider the context and needs for privacy of personally identifiable information when designing solutions and mitigate accordingly. |

Scotland Health Directorate

Principles for Digital development

| | 3. Common Vocabulary and Definitions | Data is defined consistently throughout the enterprise, and the definitions are understandable and available to all users and systems. |

TOGAF

Scotland Health Directorate

| | 4. Data is Shared and Accessible (open data) | Users have access to the data necessary to perform their duties; therefore, data is shared across enterprise functions and organizations. Data is accessible to users as necessary to complete their jobs and in compliance with privacy and security designs. | **TOGAF** | #### Example Technology and Application Principles | **Example Principle** | **Description** | **References** | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------- | | 1. Service Oriented Architecture | Where possible, architecture and solutions are composed of reusable modular components and services, based on Service Oriented Architecture. |

TOGAF

Scotland Health Directorate

| | 2. Technology diversity | Technology diversity is controlled to minimize the cost of maintaining expertise in, and connectivity between, multiple platforms. | Scotland Health Directorate | | 3. Ease of use | Applications are easy to use. The underlying technology is transparent to users, so they can concentrate on tasks at hand. | TOGAF | | 4. Common Use | Development of applications used across the enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization | TOGAF | | 5. Responsiveness | Applications are available and responsive to needs | | #### Example Process Principles | **Example Principle** | **Description** | **References** | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | 1. Understand the existing ecosystem | Ensure projects and programs are built, managed, and owned with consideration given to the local ecosystem. | Principles for Digital Development | | 2. Design with the user in mind |

Include representatives of stakeholders in planning, design, development and assessment of solutions. Develop context appropriate solutions informed by user needs.

| | | 3. Data Driven |

Design projects so that impact can be measured at discrete milestones with a focus on outcomes rather than outputs.

| Principles for Digital Development | | 4. Project Governance | eHealth projects will be managed under the eHealth governance process. | | | 5. Open | Use open standards, open source and open innovation. |

BID

OpenHIE

Principles for Digital Development

| {% hint style="success" %} **References:** * [Principles for Digital Development](https://digitalprinciples.org/) * [TOGAF ( The Open Group Architecture Framework) - Architecture Principles](http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html#tagtcjh_2) * [National Health Service Scotland - Architecture Principles](http://www.ehealth.nhs.scot/wp-content/uploads/sites/7/documents/standard-architecture-principles1.pdf) * [BID ( Better Immunization Data) project principles](http://bidinitiative.org/the-principles/) * [OpenHIE Principles ](https://app.gitbook.com/@openhie/s/arch-spec/architecture-specification/architectural-principles) {% endhint %} # Document the Architecture Architecture Level Project ## Document the Architecture ### Content to Consider When developing your health architecture, you may want to consider including the following content: * Information about the health system context * You may want to include linkages to key health system documents or priorities * [Architecture principles](/getting-started/dev/pathway-2-architecture/phase-2-requirements-and-design/establish-architecture-principles) * Architecture diagram / components * you may want to reference the OpenHIE Architecture here. * [Standards](/getting-started/dev/pathway-2-architecture/phase-2-requirements-and-design/establish-processes) or a reference to standards * Consider of the data exchange standards and / or terminology standards are stored in the Architecture document, an appendix or a separate standards document. * Guidelines for application may be included in the architecture or other documentation for health information teams to follow. These may include expectations such as: 1. Project teams must create documentation of system assets (for example, requirements, design, installation process) 2. Applications that share data must/should have APIs 3. Application purchases or selection must be done via an evaluation process where the criteria and decision are documented 4. Applications should be designed in a way that support data standards 5. Any source code developed specifically for MOH should be stored in the MOH source code repository 6. Interoperability layer should be used for data exchange (No new point-to-Point) 7. Project teams must complete an HIS project Alignment (processes outlined in this document) 8. Additional guidelines... The following are some examples of how the architecture has been documented. {% hint style="success" %} **References:** * [Kenya Health Architecture ](https://www.data4sdgs.org/sites/default/files/services_files/Kenya%20Health%20Information%20Systems%20Interoperability%20Framework.pdf) * [Tanzania 2012-2018 Strategy](https://www.who.int/goe/policies/countries/tza_ehealth.pdf) * [Uganda](https://health.go.ug/sites/default/files/National%20e_Health%20Strategy_0.pdf) {% endhint %} # Establish Architecture Processes Architecture Level Project ## Establish Architecture Processes and Governance ### Why have Architecture Processes? Unless there are processes in place to support the application and maintenance of the architecture, the designated architecture will be documentation that is placed on a shelf or used in presentations. To support the use and maintenance of the architecture, there are some processes or governance structures that need to be put in place. ### Processes to consider #### 1. A process to support HIS project alignment with the architecture Process to have HIS teams present or discuss their health information project with an architect, governance committee or architecture review board at project initiation and perhaps other important stages can help HIS teams align with the architecture. This process or project governance step should be structured to: * Ensure health project project alignment with the documented architecture principles, component and standards * Promote appropriate re-use existing of existing software (justification for introducing duplicative components) Process triggers or actions that might activate this process need to be documented. These might include: * There is an HIS project or software project that is not yet aligned with the architecture governance process * A new HIS project is initiated by a funder, partner organization or any level of the health system. * An existing HIS project or system is expanding the scope of their project to include additional use cases and / or software. #### 2. HIS Asset Inventory Update Processes This process would ensure that the HIS project or software inventory is created and kept up to date. It may require that there are specific times when project teams or funders add items to the inventory and/or update them on a regular basis. You may want to have a process or policy on selection of software that ensures that software aligns with the architecture and where appropriate re-uses software component investments that have already been made. Process triggers or actions that might activate this process need to be documented. These might include: * There is an HIS project or software project that is not yet in the software inventory. * A new HIS project is initiated by a funder, partner organization or any level of the health system. * An existing HIS project or system is expanding the scope of their project to include additional use cases and / or software. * Annual or biannual inventory update / review #### 3. Software Selection Process This process would ensure that software is selected based upon a process that documents high-level business needs as well as needs for data sharing and compliance with the architecture. This process might also be designed to evaluate existing software in the inventory to see if it meets the desired needs. Process triggers or actions that might activate this process need to be documented. These might include: * There is an HIS project that needs a new software component * A new HIS project is initiated by a funder, partner organization or any level of the health system and requires software. * An existing HIS project or system is expanding the scope of their project to include additional use cases and / or software. #### 4. A process to review standards / update standards To keep the standards up to date and provide a relevant and living document for project teams, it is suggested that there is some process to curate (add to / update / retire) standards and / or the architecture diagram. ### **Audience for Architecture Processes** When creating the architecture processes, consider the audience for the processes. The following are some key stakeholders to consider: * All HIS project teams creating or managing HIS software for use in capturing, processing, reporting or sharing health information in any level of the health system. * FMOH HITD Personnel * Health Architecture Governance / working group members * Sponsors and key stakeholders for HIS projects # Establish Standards Architecture Level Project ## Establish Standards ### **Message Standards** Message standards provide the syntax for exchanging information between different computer systems. OpenHIE provides the OpenHIE Architecture Specification that can serve as a foundation for these syntactic standards. {% hint style="success" %} **References:** * [OpenHIE Architecture Specification ](https://app.gitbook.com/@openhie/s/arch-spec/) * [Standards and Profiles](https://app.gitbook.com/@openhie/s/arch-spec/architecture-specification/standards-and-profiles) {% endhint %} ### **Terminology Standards** The following documents may provide a reference for getting started with terminology standards. {% hint style="success" %} **References:** * Alunyu, A. E., & Nabukenya, J. (2018). [A Conceptual Model for Adaptation of eHealth Standards by Low and Middle-Income Countries. Journal of Health Informatics in Africa, 5(2).](https://doi.org/10.12856/JHIA-2018-v5-i2-199) * Alunyu, A. E., Wamema, J., Kiwanuka, A., & Bagyendera, M. (2020). [Factors that Influence Potential Success of eHealth Standards Adoption in a Low- and Middle-Income Country: a review. Journal of Health Informatics in Africa, 7(1), 24 - 37.](https://doi.org/10.12856/JHIA-2020-v7-i1-274) * [WHO eHealth Strategy Toolkit](https://apps.who.int/iris/handle/10665/75211) * [Terminology Maturity Model ](https://docs.google.com/presentation/d/1rqRTzzSRKVujdt0NPFp75kgiK00r-PkR2DIezsXPfLU/edit#slide=id.g2502884cb7_0_18) {% endhint %} \
# Pathway 2.3 - Implement, Support, and Scale Architecture Level Project ## Process * [ ] [Communication and Roll Out](/getting-started/dev/pathway-2-architecture/phase-3-implement-support-and-scale/communication-and-roll-out) # Communication and Roll Out Architecture Level Project ## **Establish Communications Plan** The roll out of a new system, process or procedure often requires a communication plan. Review your stakeholder list to ensure that those who are a part of the governance process, expected to comply with the architecture or are impacted by new processes being established are appropriately informed and updated about changes in process and policies.\
# How to Provide Feedback / Input ## We Want Your Input Help others in the OpenHIE community by: * Iterating on the content that is here and making it more clear, more refined and better! * Suggesting new content that you are working or or that you would like us to work on! ## How to Suggest Additions and Revisions: 1. Go to [Discourse ](https://discourse.ohie.org/c/openhie-feedback/3) 2. Select "new topic" button 3. Specify the artifact that needs revision. In this case, it is the "OpenHIE Getting Started Guide" and follow the directions to make your suggestion. Be as specific as possible. Thank you. # Change Log ## August-2021 ### New Guide * Combined materials from the former guides that were focused on an individual component and added material to focus on data exchange projects and getting started with an architecture project. **This work is licensed under a Creative Commons Attribution 4.0 International License.** # Getting Started Guide: Paths to Data Exchange ## **What is OpenHIE?** OpenHIE is a self-organizing, mission-driven community of stakeholders assisting the strengthening of national Health Information Exchanges (HIEs) to support access to data by a Health Information System (HIS). The initiative emerged from the Health Informatics Public Private Partnership initiative funded by the US President’s Emergency Plan for AIDS Relief (PEPFAR). OpenHIE is more than a set of technical specifications. It is also a collaborative community of practice. This community includes ministry of health personnel, funders, enterprise architects, solution designers, software engineers, implementers and health system managers. OpenHIE was created on the belief that integrated and interoperable health information systems are critical to improve the quality and continuity of healthcare. {% hint style="success" %} **Resources and Examples:** * [OpenHIE Academy](https://academy.ohie.org/) * [OpenHIE Website](https://ohie.org/) * [OpenHIE Architecture Specification](https://ohie.org/framework/) {% endhint %} **This work is licensed under a Creative Commons Attribution 4.0 International License.** # Select a Pathway Use this page to pick which pathway(s) to follow. ## How to Use this Guide This guide is designed to help ministries of health, implementers and others involved in establishing eHealth architecture and health system project teams get started with health information exchange. Over the past few years we have observed that some implementers choose to start their journey by working in a specific OpenHIE component like a facility registry. Other implementers may choose to start with a health exchange project that allows for sharing of health data. While a third group started at a more foundational level like doing an eHealth Architecture or blueprint project. Each of these starting points has benefits and challenges. Ultimately, the components, the data exchange projects and the architecture are needed to benefit fully from health information exchange and none of these pathways is mutually exclusive. The path toward data exchange is a multi-faceted journey that will take time. #### Use this guide to make progress on one or more pathways toward information exchange. ## **Pathways** Identify the type of project(s) that you are working on and click on the appropriate pathway.
| **Type of Project** | **Description / Implications** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [**Component Project**](/getting-started/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope) |

To work on a component project, follow PATHWAY 1: Component and Data Exchange Projects

| |

Exchange Project

|

To work on a data exchange project, follow PATHWAY 1: Component and Data Exchange Projects

| | [**Architecture Project**](/getting-started/pathway-2-architecture/untitled) |

To work on an architecture project, follow PATHWAY 2: Architecture

| # PATHWAY 1: Component and Data Exchange Projects Select the appropriate phase of the project to get started. * [Phase 1: Governance, Value, and Scope](/getting-started/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope) * [Phase 2: Requirements and Design](/getting-started/pathway-1-component-and-data-exchange/phase-2-requirements-and-design) * [Phase 3: Implement, Support, and Scale](/getting-started/pathway-1-component-and-data-exchange/phase-3-implement-support-and-scale) # Pathway 1.1 - Governance, Value, and Scope Component Level Project and Exchange Level Project ## People * [ ] [Identify Stakeholders](/getting-started/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope/identify-stakeholders) * [ ] [Determine and Document Roles and Responsibilities](/getting-started/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope/determine-and-document-roles-and-responsibilities) ## Process * [ ] [Establish or Define Governance Structures](/getting-started/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope/establish-or-define-governance-structures) * [ ] [Determine Project Scope](/getting-started/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope/determine-project-scope) * [ ] [Document the Expected Value of the Project](/getting-started/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope/document-the-expected-value-of-the-project) * [ ] [Establish a Project Plan ](/getting-started/pathway-1-component-and-data-exchange/phase-1-governance-value-and-scope/establish-a-project-plan) {% content-ref url="/pages/-MbkzPuyvLJCNJvoul1Y" %} [Pathway 1.2 - Requirements and Design](/getting-started/pathway-1-component-and-data-exchange/phase-2-requirements-and-design) {% endcontent-ref %} {% content-ref url="/pages/-MbkzdubiTD6syhAgqD3" %} [Pathway 1.3 - Implement, Support, and Scale](/getting-started/pathway-1-component-and-data-exchange/phase-3-implement-support-and-scale) {% endcontent-ref %} # Identify Stakeholders Phase 1: Component and Exchange Path ## **Identify Stakeholders** To help ascertain the requirements and provide input into architecture components and OHIE data exchange implementations, stakeholders and system users should be identified. Interest in a specific component or a project that uses one or more OHIE components has the potential to span a diverse network of stakeholders. By identifying who is engaged in providing or using the information and who will provide support to the new system or service, implementers can begin to form a stakeholder engagement plan to inform the design and implementation of the project. To identify stakeholders, ask questions such as: * *Who are the interested and impacted parties?* * *Is the national health ministry and/or other levels of the health system like one or more regional levels interested or impacted?* * *Are there advocacy groups that can help?* Stakeholders that may be considered include: * Organizations or people that create data that will be captured (e.g. patient data, facility data, terminology.) * People providing data or entering data into the component(s) needed for the project (e.g. Patients or Clients, Healthcare professionals, community workers, facility managers.) * People and organizations using the data collected for metrics reporting or decision making * Organizations driving the project * Ministry of Health representatives * Technical and infrastructure support teams (e.g. help desk personnel, system hosting and connectivity providers) that may end up supporting the component(s), the bandwidth or other technology needed for the project to be successful. ### Identifying Stakeholder Motivations Once potential stakeholders are identified, it is helpful to understand high-level stakeholder motivations and challenges. Understanding these motivations will help teams engage and recruit the individuals that will represent the organizational stakeholders in: * Defining project scope * Vetting and prioritizing key use cases and user stories * Ensure agreement on the data specifications and requirements Stakeholders and the appropriate governance structures should be involved throughout the project lifecycle including; defining project scope and objectives, design, development and implementation of the components, and not just at the beginning. As new business cases arise, the group should strategically plan to scale-up and implement in line with national and international standards. The composition of the stakeholder groups may be dynamic with new members joining the group as new requirements emerge and are prioritized through established governance structures. {% hint style="success" %} **Resources and Examples:**[ ](https://docs.google.com/a/instedd.org/document/d/1jQUZ1n1Oh2d_VTeXlFj-Y2IPkqQXvoGDV6v98Y5n4DI/edit) * [**Actor and Stakeholders Guide**](https://docs.google.com/a/instedd.org/document/d/1jQUZ1n1Oh2d_VTeXlFj-Y2IPkqQXvoGDV6v98Y5n4DI/edit) * [ **Stakeholder List Template**](https://docs.google.com/a/instedd.org/spreadsheet/ccc?key=0AvRUEKy5Lc7BdDVIM2toWHZYQno0MFlZUVJ0d0ltRWc#gid=0) {% endhint %} # Determine and Document Roles and Responsibilities Phase 1: Component and Exchange Path ## **Determine and Document Roles and Responsibilities** Once stakeholders are identified, it is important to confirm the roles and responsibilities among the various stakeholders supporting the selected component(s) and any data entry or exchanges. There may be existing and new responsibilities for users ranging from data collection, data entry, curation, governance, management and support roles. {% hint style="success" %} **Reference:** [Digital Implementation Investment Guide (DIIG)](https://www.who.int/publications/i/item/9789240010567): Integrating Digital Interventions into Health Programmes (Chapter 2) {% endhint %} # Establish or Define Governance Structures Phase 1: Component and Exchange Path ## **Establish or Define Governance Structures** There is often a tendency to consult stakeholders and establish governance structures at the beginning of a project and end discussions there. Be careful to manage this pitfall as success of the project is often due to communication and buy-in from stakeholders and governance structures. If governance structures are already defined, clearly establish how the project team and stakeholders align and report to governance groups. If governance structures are not already in place, the team will need to begin to establish some governance structure that will work for the scope of the project. Consider options for forming a structure that can be used to support the current project with an eye toward establishing structures that can be used to govern health ICT projects as they arise. Make sure to consider the different stakeholder groups that may have to contribute the data captured, utilize the data or support the tooling or infrastructure as stakeholders are considered. As new business cases arise, the group should strategically plan scale up and implementation in-line with national and international data exchange and terminology standards. The composition of the stakeholder groups may be dynamic with new members joining the group as new requirements emerge and are prioritized through established governance structures. {% hint style="success" %} **Reference:** [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567) (Chapter 5.3: Leadership and Governance Considerations) {% endhint %} # Determine Project Scope Component Level Project and Exchange Level Project ## **Determine Project Scope** We strongly recommend an iterative project implementation process. When using an iterative process, implementation teams should designate an initial scope for a project and consider phases. For example, the vision may be to have all patients in the country or region listed in the client registry, this may not be practical or necessary for the first implementation of the registry. You will want to clearly state the vision and the goals for each phase of the project. For example, the first phase of a project might simply be to prove that data can be electronically shared between two systems. One of the main objectives for a governance structure is to determine the scope of use cases and user stories that will be supported by each iteration of the component or data exchange project and to determine how each subsequent iteration moves the team toward the larger goal for that project. For example, If you have selected to implement a Client Registry, then you may need to determine which point-of service providers or national ID systems will interact with the client registry in the initial implementation. Or, you may determine that only the women of childbearing age will be included. Each project team will need to work with the governance structure to set the scope based upon the HIE strategy, goals and priorities for the project. An ideal initial scope is large enough to prove that some part of the project technically works and small enough to do that in the specified context and still add value to the health providers, health system and / or patients. In an initial implementation, many teams limit scope by one or more factors such as: * Patient population * Region * Number of facilities * Number of indicators or data points * Number of features included # Document the Expected Value of the Project Component Level Project and Exchange Level Project ## **Document the Expected Value of the Project** It is important to document the value that one expects from component, health exchange and architecture projects. To help document the value, you may want to engage stakeholders in answering the following questions: * How can we benefit from the selected component(s), project or architecture? * Why are we interested in implementing it? * What problems are we trying to solve or what opportunities does this project open up? {% hint style="success" %} **Reference:** [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567) (Ch. 9 Value Proposition and Next Steps) {% endhint %} When possible, setting up measurable expectations are best. The following are examples of the qualitative value and descriptions of potential measures that might help guide you in thinkinging about the value of your project. In a pilot project, it may be appropriate to document that some of the value may be learning or proving how technology might work in your particular context. However, it is best to make sure that there is some health system value to the project as well. The value can be articulated in costs, but many health projects will provide more qualitative value. ### Examples of potential learning from projects: * Learn how an information exchange works * Learn about what is needed to support an information exchange * Learn about transaction frequency and bandwidth needs * Learn about process needed to support intermittent connectivity data sharing * Learn about FHIR ### **Examples of eHealth Architecture Value:** * Government leaders can better align their ongoing investments and coordinate disparate, technology-based systems to optimize the accessibility of data for use, systems-maintenance, and long-term sustainability. * Managers of country-health and public-health institutions can leverage the increased quality and availability of health data for greater visibility into programmatic impact, including on patient care, and the relative efficacy of different interventions, which will enable better decision-making and allocations of resources. ### **eHealth Architecture Measures might include:** * The number of transactions supported by a component or the different types of transactions supported by a component. * Documented different use cases that are aligned with the architecture * Number of point-to-point integrations eliminated or avoided * The number of data [exchange standards](https://ohie.org/framework/) identified and implemented ### **Examples of Component or Data Exchange Projects** * Knowing the real-time demand for various medicines and health commodities, or the level of training and availability of health professionals, is critical. * Health managers at all levels can better analyze the performance of institutions and identify gaps with a combination of Clients, previously seen as passive beneficiaries, can obtain better health care through a continuum of delivery in which they play an active role. ### **Measures might include** * Ability to provide near real-time statistics on commodities or resource availability in a region * Ability to plan for resource constraints or mobilizations during an outbreak # Establish a Project Plan Component Level Project and Exchange Level Project ## **Establish a Project Plan** A good project plan should address resources (technical and human), cost constraints and estimated timing. The resource plan and project plans should address the following types of activities that are considered to be in scope for the project: * Necessary governance check points required by the governance process. * Defining requirements. * System design and alignment with architecture and data exchange and terminology standards. * Establishing hosting environments and hardware and software upgrade processes. * Selecting, procuring, installing and configuring software and hardware components needed to support the project. * If this is a data sharing project, point-of-care systems or other systems that are sharing data may need to be enhanced to support data sharing. * Documentation of the technical solution and information required to support the solution. * Testing to prove that the system operates as desired, including data exchanges, business processes and load testing. * Development of policies and procedures required to support the system(s) and business processes. * Training for users and support staff. * Communications regarding roll out. * Support for end users and support for system patches and upgrades * For data exchange projects, also consider * Point-of-Care systems, insurance systems and / or national registry systems that will interact with the component you are implementing may need to be enhanced to communicate with the appropriate architecture components through the Interoperability Layer of the architecture. * Configuration and testing with interfacing point-of-care systems, insurance systems and / or national registry systems that are within the scope of the project.
{% hint style="success" %} **Reference:** [Infrastructure & Procedures Checklist](https://docs.google.com/spreadsheets/d/1xTvwUJUEN62yFr8TK4mOynk333Iv8kRbpu4ihjh_WOM/edit#gid=0) {% endhint %} # Pathway 1.2 - Requirements and Design Component Level Project and Exchange Level Project INPUT SOME GRAPHIC HERE FOR PHASE 2 / PATHWAY 1 ## People * [ ] [Establish Training Programs](/getting-started/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/establish-training-programs) ## Process * [ ] [Determine Resources and Identify Constraints and Environmental Factors](/getting-started/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/determine-resources-and-identify-constraints-and-environmental-factors) * [ ] [Analyze the Environment and Context](/getting-started/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/analyze-the-environment-and-context) * [ ] [Identify System Constraints](/getting-started/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/identify-system-constraints) * [ ] [Document Requirements](/getting-started/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/document-requirements) * [ ] [Select Software/Component(s)](/getting-started/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/select-software-component-s) * [ ] [Testing](/getting-started/pathway-1-component-and-data-exchange/phase-2-requirements-and-design/testing) {% content-ref url="/pages/-MbkzdubiTD6syhAgqD3" %} [Pathway 1.3 - Implement, Support, and Scale](/getting-started/pathway-1-component-and-data-exchange/phase-3-implement-support-and-scale) {% endcontent-ref %} # Establish Training Programs Component Level Project and Exchange Level Project ## **Establish Training Programs** We recommend identifying training needs and establishing a training plan. When considering training needs, look at data creation and use activities as well as systems support. Consider the following: * Training system users on the business processes and systems features required to enter, and update information * Training of the system support staff/help desk personnel in key operational aspects of the systems and data exchanges being implemented * Training on installation / upgrade / backup processes * Training on any data privacy / data security policies and procedures applicable to data capture, storage, use and transfer # Determine Resources and Identify Constraints and Environmental Factors Component Level Project and Exchange Level Project ## **Determine Resources and Identify** **Explore Opportunities and Challenges** The motivations driving an implementation can be detailed by the perceived opportunities or challenges that stakeholders face. For example, implementing a Facility Registry might include the desire to share data across systems related to health facilities for supply chain management, monitoring and evaluation, health service delivery and many other systems. {% hint style="success" %} **Resources and Examples:** * **Job aid:**[ Opportunity Brainstorming Methods](https://docs.google.com/a/instedd.org/document/d/1aBxu3GysAyGtpPG3s1LFpTZimO8lyO4p6yhV3e2BHlA/edit) - Example for a facility registry. This can be modified for use with other project types. * **Job aid:**[ Risk Identification and Management](https://docs.google.com/a/instedd.org/document/d/17Gu76gShQhPz6axQzirT7c8LL8Ckwk8qnekC-SSKLL0/edit#heading=h.ydr5ktvto6o0);[ Risk Matrix Template](https://docs.google.com/a/instedd.org/spreadsheet/ccc?key=0AvRUEKy5Lc7BdGlvRm5yNk1PbmtXRUYzU1R3elNrZ3c#gid=0) * **Tanzania Example:**[ Tanzania Facility Registry Goals and Challenges](https://docs.google.com/document/d/1jSyiytftmCGM_-d5hfKS_mVhDkh0Ol1ZdSsPc-wN7gU/edit?usp=sharing) {% endhint %} **Identify Applicable Standards** While researching the data needed in your context, list any applicable terminology and data standards used. The source of these standardized data lists can either be from international sources or defined by appropriate national bodies. In some cases, there may be local standards that are used across health systems. If local terminology standards are used, you may want to consider linking those to international standards or codes. Each standardized list should include a code that components of the health information system can use to refer to the element as well as a textual representation of that element in one or more languages. {% hint style="success" %} **Examples:** * [Philippines National Health Data Dictionary](http://uhmis1.doh.gov.ph/UnifiedHMIS/images/downloads/Forms_and_Manuals/NHDD_v2_Jan_17_2011.pdf) * [The FHIR Patient Resource identifies options for gender](https://www.hl7.org/fhir/patient.html) * [FHIR Implementation Guides Registry](http://www.fhir.org/guides/registry/) - Each FHIR IG may contain applicable value sets. * [ISO/TS 22220:2011 Identification of Subjects of Healthcare](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=59755) * [ISO 21091:2013](http://www.iso.org/iso/catalogue_detail.htm?csnumber=51432): Health informatics -- Directory services for healthcare providers, subjects of care and other entities. * Laboratory Tests -- [LOINC](http://www.loinc.org/) {% endhint %} **Critical Integrations** In addition to collecting and standardizing facility lists, it is important to identify and achieve critical integrations with priority systems. Multiple APIs are available to facilitate the automated transmission of data; however, it will be required that some code be incorporated into the partner system to consume the API. For example, common high priority systems to consider integration with the facility registry include: DHIS2, CommCare, PROMIS, and OpenLMIS. You’ll need to determine what the critical integrations are for your project. \
# Analyze the Environment and Context Component Level Project and Exchange Level Project ## **Analyze the Environment and Context** To begin the requirements and design process, start by analyzing the current environment. Seek to answer the following: * *What are the current processes in this context?* * *Are there existing policies and procedures that might be impacted or provide guidance for the project?* * *Are there technical solutions and infrastructures already in place?* * *What is known about the system users and their ability to interact with the system?* * *Are there specific language needs to support system users?* * *How will you know if you have succeeded?* * *What are the challenges or barriers to successful implementation?* {% hint style="success" %} **Reference:** [Infrastructure & Procedures Checklist](https://docs.google.com/spreadsheets/d/1xTvwUJUEN62yFr8TK4mOynk333Iv8kRbpu4ihjh_WOM/edit#gid=0) {% endhint %} # Identify System Constraints Component Level Project and Exchange Level Project ## **Identify System Constraints** **Identify System Constraints** Identifying the high-level system constraints will help implementers understand the factors that need to be addressed in order to design a system that fits the unique context. Identify known constraints such as: * Data Capacity - For example, the following types of questions might be asked about a client registry or a shared health record; What is the country’s population? How many of those people will the registry need to support? How many patients are already stored in point-of-care applications? For other projects, the questions may be about how many facilities or products need to be supported. * Data Quality - How complete and accurate is the patient demographic data captured in the existing point-of-care and/or national identifier systems? Which existing records are paper and which are electronic? * Network Capacity and Reliability - Are there constraints on the network reliability or capacity? Are secure network connections between organizations already established? * Power Constraints- Are there any constraints on electricity or power? If so, what are they? * Data Privacy Laws and Regulations– Are there any local or regional data privacy laws that apply to the client’s demographic data? * Other healthcare software laws or regulations – Are there applicable guidelines for managing healthcare records or for validating healthcare software? Based upon the country’s unique context, there may be additional constraints that need to be documented. \
# Document Requirements Component Level Project and Exchange Level Project ## **Document Requirements** **Document Data Specifications** A data specification document is a technical tool describing the data elements or the information to be managed in one or more registries. This is a similar concept to a data dictionary where the representations, meaning, and format of data elements in the system are documented. It is recommended one consider the appropriate [FHIR Resources](https://www.hl7.org/fhir/resourcelist.html) and [FHIR Implementation Guides](https://www.fhir.org/guides/registry/) for registries such as the Facility Registry, Client Registry, Health Worker Registry and Product Catalogue. In addition, you will want to consider inclusions of any key local attributes. Other considerations include alternate representations, i.e., “mappings”, that may be required for reporting to external authorities, sharing data with other eHealth systems, or alternate stakeholder needs. {% hint style="success" %} **Resources and Examples:** * **Job aids:**[ Facility Registry Data Specification Guide](https://docs.google.com/document/d/1V1nw2aLUUdDHJk_C36GRpiPAcRW1n89WaYZtFTWp4mE/edit?usp=sharing);[ Draft WHO MFL Guide](https://docs.google.com/a/instedd.org/file/d/0B_RUEKy5Lc7BS2swR3ZDTjZZeTQ/edit?usp=sharing) * **Tanzania Example:**[ TZ Facility Registry Data Specification](https://docs.google.com/document/d/1X_3unJ6v3ZOgmXHQ4W98zKXzy7uifi9h_ZLUyULX88M/edit?usp=sharing) * **Rwanda Example:**[ RW Registry Specifications (See Page 17)](https://drive.google.com/file/d/0B_RUEKy5Lc7Bd0tuYzVmcFdiY1E/edit?usp=sharing) {% endhint %} **Document Component Functional Requirements** Each OpenHIE component will have both data exchange needs including the ability to support specific standards and APIs and needs for functional requirements. You should start your journey by looking at the [OpenHIE Architecture Specification](https://ohie.org/framework/). This will outline some of the key requirements for each type of component. For functional requirements, you may want to additionally document them using user stories. User Stories are a mechanism to gather user requirements and/or core requirements describing the desired registry functionality. They are a short and simple description of how a particular user needs to interact with the system. They tell who, what and why the person is interacting with the system. The following are two short examples of user stories from different projects. * **Example User Story – Other Clinic Visits:** * A pregnant woman enters the clinic for her first appointment. The healthcare worker collects the patient’s name and demographic information. The worker wants to see if the woman has had visits at other clinics so the worker enters in the demographic information and asks for data from other institutions. The system will determine if the patient has visited other point-of-care facilities and return the references to those visits. * **Example User Story – Insurance Verification:** * A man walks into a clinic he has not visited before. The health worker needs to verify the man’s insurance. The health worker asks for his name and geographic information. The man provides the information. The health worker enters in his information and asks for insurance verification. The system will use the information entered to check with insurance providers and verifies that the man has insurance. **Document Data Exchange Requirements** The data exchanges are the processes for sharing data between OHIE components. We recommend drawing out the data exchange required using interactions diagrams. The [OpenHIE Specification](https://ohie.org/architecture-specification/) can provide a foundation for recommending the standards and processes for data exchange. Along with the typical technical expertise required to develop and implement a technology solution, the registry requires technical knowledge of healthcare transactions standards such as IHE PIX/[PDQ](https://wiki.ohie.org/display/documents/Patient+Demographics+Query+IHE+ITI-21+Transaction). The [OpenHIE Architecture Specification](https://ohie.org/architecture-specification/) outlines the recommended standards for each transaction. If you need to implement a data exchange that is not already outlined in the [OpenHIE Architecture Specification](https://ohie.org/architecture-specification/), please contact the [OpenHIE Architecture Community](https://wiki.ohie.org/display/resources/Architecture+Subcommunity+Call) to gain alignment, ensure that any work your team is doing can be used by others and get any help needed for creating FHIR IGs and/or IHE profiles if they do not already exist. {% hint style="success" %} **References:** * [OpenHIE Standards and Profiles](https://wiki.ohie.org/display/documents/OpenHIE+Standards+and+Profiles) * [OpenHIE Architecture Specification](https://ohie.org/architecture-specification/) {% endhint %} **Document Data Privacy Impact and Requirements** If the project component(s) or information exchanges contain patient demographic data that is used to identify a person, it is important to understand any national and/or local data privacy laws that apply to this data. The role of the governance structure and content owner is to understand privacy laws and ensure policies, procedures and processes are in place to protect patient privacy. Based upon applicable privacy and electronic records regulations for your context, an implementation team may need to address privacy and the appropriate management of electronic healthcare records through measures such as: * Guidelines for granting access to the component 1. *(Who approves access? Who can access the registry and when is access allowed?)* The guidelines may need to consider: * Physical access to servers and data * Database access via DBA (Database Administrator) or technical resource and perhaps a client registry application * Exchange access *(What systems can provide data to or receive data from the registry?)* * Documented annual or regular privacy training for those with access to the component * Process for annually reviewing data access * Privacy and security incident management processes. *(How are potential breaches of security or privacy to be handled?)* {% hint style="success" %} **Resource:** [Guidelines on Protecting the Confidentiality and Security of HIV Information](http://data.unaids.org/pub/manual/2007/confidentiality_security_interim_guidelines_15may2007_en.pdf) - While aimed at HIV patient data, this resource can be used to help understand privacy, confidentiality and security concerns for patient information. **Reference:** [OpenHIE Privacy and Security](https://wiki.ohie.org/display/SUB/OpenHIE+Privacy+and+Security) {% endhint %} **Agile and Iterative Development** After the identification and prioritization of requirements and user stories is complete, agile and iterative development takes the prioritized lists and applies the project team to resolve the prioritized requirements and user stories. Additional requirements and user stories will continue to be generated throughout the lifetime of the implementation and should be prioritized and similarly addressed by the team. Initially, the goal of this activity will be to address the user stories that will result in a viable and operational OpenHIE component(s) or data exchanges. Additional, development will continue to occur and will also be informed through routine testing and re-prioritization among the team. A GitHub or similar repository to track this process can help to keep both technical and non-technical stakeholders engaged and accountable. # Select Software/Component(s) Component Level Project and Exchange Level Project ## **Select Software/Component(s)** Based upon the requirements documented, your team will need to evaluate and select software solutions. When selecting software, it is important to understand the current state of your eHealth architecture. If there is an architecture in place, you will want to select a solution that aligns with the architecture or the future direction of the architecture. We recommend documenting a high-level process to follow. The following steps may be helpful: ### 1. Landscape assessment of tools This can be done through a landscape assessment to determine the tools that are out in the field and how they align with your strategy. You may want to categorize in a meaningful way that helps you think about the field. One example is to use a two-by-two grid to help categorize the tools in some way. | General Use, High Initial Investment | Health Specific Use, High Initial Investment | | ------------------------------------ | -------------------------------------------- | | General Use, Low Initial Investment | Health Specific Use, Low Initial Investment | ### 2. Narrow the list Narrow the list of possible tools to ones that align with your strategy and architecture. Look at factors such as your ability to support the underlying technology, the maturity of the tool / references from other projects / deployment strategies, ability to support your security needs, ability to support data exchanges and standards and your contextual needs to narrow the list to tools you will evaluate more closely. Document the criteria you used to narrow the field as this may be needed to support your decision or if suitable tools are not found in further review stages. Methods for helping narrow might be looking at their websites, sending some email questions and / or having a quick phone conversation. ### 3. Assess business requirements Once you have chosen a few tools to look at more closely, you will need to have a list of high -level business requirements and needs for the tool assessment. We recommend having the tool creator to demonstrate and / or sketch out how they would tackle one of your business challenges (use cases) to allow your team to make an effective evaluation. The [OpenHIE Architecture Specification](https://ohie.org/framework/) contains a list of based component requirements as well as data exchange requirements for each of the architecture components. You may want to use this as a base for documenting the requirements for the components that you’ll need. You’ll want to think about the following when looking at the available tools: 1. Ability to support the platforms that the tool runs on 2. Ability to support and deploy the tool ### 4. Document your process We recommend documenting your selection process and the results of the process so that you can communicate the reasoning for the decision. You will want to complete some type of an evaluation process for each of the components you need to select. {% hint style="success" %} **References:** * [Example Tool Evaluation Sheet for Demonstration / Interview Discussion ](https://docs.google.com/document/d/19XlZHaOrixnOVO2UqvL1TkIzgK1MpNTOvkfnBWgzqxw/edit) * [Outline for Tool Demonstration](https://docs.google.com/document/d/1szBCgu8QO4lwVFiDorhHez_iKC1kYObnLJfUzR5TpZk/edit#heading=h.pmbpp94xcyj1); [OpenHIE Reference Technologies ](https://wiki.ohie.org/display/documents/Reference+Technologies) * [OpenHIE Architecture Specification](https://ohie.org/framework/) {% endhint %} # Testing Component Level Project and Exchange Level Project ## **Software Validation and Testing** There are many components required to validate and test software that is used to manage healthcare records. Some ministries of health like the United States FDA have specific guidance documents that need to be followed to ensure that healthcare software has been appropriately validated and tested and that electronic records requirements are being met. The purpose of this section is not to detail good software validation practices, but to highlight specific testing considerations for health software. ### **Workflow Testing (Integration Testing)** You will need to test to ensure that any components sharing data with other components appropriately integrate with the Interoperability Layer and each of the point-of-care systems or other systems that will provide or receive data. One approach for this testing could be to test various iterations of each workflow(data exchange) that will be used between each of the various components involved. This testing would then be repeated for each system that is in scope. This approach paired with an approach that goes through the whole health care process is recommended. ### **Performance and Load Testing** There are at least two aspects of performance testing that will need to be addressed. First is transaction through-put. This can be tested by estimating the number of transactions (data exchanges) that will be expected during peak business times and ensuring that the network and hardware can support this volume of transactions. \ \ The second aspect of testing that needs to be considered is ensuring that the registry/OpenHIE component(s) is configured to support the number of records required to be stored in the component at its peak usage for the given scope. For component systems such as the client registry, facility registry and other OHIE components, hardware, databases, matching algorithms and key system functions will need to be tested to ensure that they are appropriately configured and tuned to handle the estimated number of records expected in the next two or three years. ### **User Testing** A key component of the agile process initiated will be to conduct routine field testing of the system that should be completed to gain feedback from a subset of system users. The goal of this activity is to obtain user feedback on the use of the component. The testing should be a separate activity from augmented or decentralized processes to collect and standardize data that may also be desired as part of the governance and management of a facility registry system. It is also likely that the formality of the testing may vary based on the availability of resources and at the request of the central stakeholders. {% hint style="success" %} **Examples and References:** * **Example:** [**User Testing Guide**](https://docs.google.com/document/d/1ZGqn_0XJYdzZLTE25sUjQEkeosM5lSV5xJ0GsmAjGzU/edit?usp=sharing) * **Reference:**[ **INVEST in Good Stories, and SMART Tasks**](http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/) * **Reference:**[ **Examples of Rwanda User Stories for RHIE**](https://wiki.ohie.org/download/attachments/10486056/RHEA%20storyboard%20%284%29.pptx?version=1\&modificationDate=1386949763329\&api=v2) {% endhint %} # Pathway 1.3 - Implement, Support, and Scale Component Level Project and Exchange Level Project ## People * [ ] [Establish a Support Plan](/getting-started/pathway-1-component-and-data-exchange/phase-3-implement-support-and-scale/establish-a-support-plan) * [ ] [Implement a Scalability Plan](/getting-started/pathway-1-component-and-data-exchange/phase-3-implement-support-and-scale/implement-a-scalability-plan) ## Process * [ ] [Communication and Roll out](/getting-started/pathway-1-component-and-data-exchange/phase-3-implement-support-and-scale/communication-and-roll-out) # Establish a Support Plan Component Level Project and Exchange Level Project ## **Establish a Support Plan** ### **Create Support Plan** It should be expected that requirements and requests for OHIE components and data exchanges between them will evolve over time. For this reason support strategies should be developed and should remain in place to triage requests for data, system enhancements, integrations, operations support or general troubleshooting among users. Common types of ongoing support are described below. ### **Operations Support** Operations support is intended to maintain the logistics and infrastructure required for each of the components. The content owner, infrastructure owner and software owners will need to support the system. This support includes: monitoring error logs, maintaining a server, ensuring security protocols, carry out backups, and software and hardware updates as needed. ### **Developer Support** Developer support is important to facilitate any future adaptations of the OHIE components and data exchanges. For instance it may be desirable to create a specialized data curation function, additional workflows (data exchanges), or other applications that would work in coordination with the registry or components in a service oriented fashion. Developer support will also include the identification, documentation and resolution of any enhancement requests or software bugs. ### **Integration Support** Ongoing support will be required to triage requests for integration, issues, and API enhancements to support other systems interested in consuming your selected components’ data. New systems that want to consume an API may also require some technical assistance to create an end node in their application to facilitate integration. ### **Data Support** Ongoing support will also require assistance for issues related to data collection, curation, analysis and utilization. There will be ongoing requirements to provide training, troubleshoot issues and respond to data access requests by users. Other aspects of data support include: data collection, entry, permissions, bulk imports, data flows, curation, and data quality. ### **Help Desk Support** Help desk support may not be required initially, but as more users and organizations start using the registry or relying on the data exchanges it may become important to identify, document, triage and direct response to types of requests from the varied types of users. ### **Capacity development and Training** To appropriately provide the support mentioned above, there will need to be training to build the capacity of support personnel to enable them to perform basic administration of OpenHIE components and data exchanges. In addition, there may be changes regarding scope, data and quality improvements as outlined in the support plan. ### **Post-Production Evaluation** Post production, it is important to capture lessons learned. One helpful exercise is to have the team make two lists. In the first list, the team should document the aspects of the project that worked well. This will provide insight into processes that can contribute to the success of additional project iterations. In the second list, the team should note the items that could be done differently next time. This exercise is important as the implementation process is meant to be iterative. Once the system is running and stabilized, the iterative development process can begin again with an expanded scope. New interfaces, user stories or workflows may need to be added.\ \
# Implement a Scalability Plan Component Level Project and Exchange Level Project ## **Implement a Scalability Plan** **Scale-Up** The goal of this step is to engage appropriately with stakeholders to ensure the management and institutional processes are in place for ongoing curation, governance, and data utilization. The governance structure and / or stakeholders will need to create a scalable support plan in order to support an agile environment. Don’t forget to test the system’s capabilities to handle additional transaction and data loads as additional use cases or regions are added to scope. # Communication and Roll Out Component Level Project and Exchange Level Project ## **Establish Communications Plan** The roll out of a new system, process or procedure often requires a communication plan. Review your stakeholder list to ensure that those who are a part of the governance process, using the software, impacted by new processes being established, additional or upgraded systems or technology are appropriately informed and updated about changes in process and policies.\
# PATHWAY 2: Architecture Select the appropriate phase of the project to get started. * [Phase 1: Governance, Value, and Scope](/getting-started/pathway-2-architecture/untitled) * [Phase 2: Requirements and Design](/getting-started/pathway-2-architecture/phase-2-requirements-and-design) * [Phase 3: Implement, Support, and Scale](/getting-started/pathway-2-architecture/phase-3-implement-support-and-scale) # Pathway 2.1 - Governance, Value, and Scope Architecture Level Project ## People * [ ] [Identify Stakeholders](/getting-started/pathway-2-architecture/untitled/identify-stakeholders) * [ ] [Determine and Document Roles and Responsibilities](/getting-started/pathway-2-architecture/untitled/determine-and-document-roles-and-responsibilities) ## Process * [ ] [Establish or Define Governance Structures](/getting-started/pathway-2-architecture/untitled/establish-or-define-governance-structures) * [ ] [Scope](/getting-started/pathway-2-architecture/untitled/scope) * [ ] [Define Value of Health System Architecture](/getting-started/pathway-2-architecture/untitled/define-value-of-health-system-architecture) * [ ] [Establish a Project Plan](/getting-started/pathway-2-architecture/untitled/establish-a-project-plan) {% content-ref url="/pages/-MblKNJUM--K6n\_rv2Nf" %} [Pathway 2.2 - Requirements and Design](/getting-started/pathway-2-architecture/phase-2-requirements-and-design) {% endcontent-ref %} {% content-ref url="/pages/-MblKV2wOQQ19aZOc1uz" %} [Pathway 2.3 - Implement, Support, and Scale](/getting-started/pathway-2-architecture/phase-3-implement-support-and-scale) {% endcontent-ref %} # Identify Stakeholders Architecture Level Project ## **Identify Stakeholders** To establish the architecture, the stakeholders may be a bit broader than they are for a typical data exchange or component project. \ \ To identify stakeholders, ask questions such as: * *Who is impacted by these architectural standards and who are the other interested parties?* * *Is there a larger governmental architecture, standards body or ICT infrastructure that the health architecture needs to align with?* * *Are there advocacy groups that can help?* ### Stakeholders to Consider * Organizations or people that support software solutions * Key architects or developers * Key or influential project leads * Other government of MOH architects that the health architecture may need to align with * Government ICT organizations that support health projects or infrastructure * Organizations driving the project * Ministry of Health representatives * Technical and infrastructure support teams (e.g. help desk personnel, system hosting and connectivity providers) that may end up supporting the component(s), the bandwidth or other technology needed for the project to be successful. ### **Identifying Stakeholder Motivations** Once potential stakeholders are identified, it is helpful to understand high-level stakeholder motivations and challenges. Understanding these motivations will help teams engage and recruit the individuals that will represent the organizational stakeholders in: * Defining the architecture project scope * Vetting and prioritizing key use cases and user stories that the architecture needs to support * Moving toward alignment on architecture standards Ask questions such as: * *Are there different/varying motivations among interested and impacted parties?* * *What might be the success criteria for different stakeholders?* # Determine and Document Roles and Responsibilities Architecture Level Project ## **Determine and Document Roles and Responsibilities** Once stakeholders are identified, it is important to confirm the roles and responsibilities among the various stakeholders. It is recommended that there is a clear governance structure and mechanisms are in place to align projects with the architecture. Recommended Roles: * Enterprise Architect - this role may or may not be a full-time role, but will be needed to ensure that the architecture is documented and that there are processes in place to help projects align with the architecture. {% hint style="success" %} **Reference:** [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567): (Chapter 2: Form the Team and Establish Goals) {% endhint %} # Establish or Define Governance Structures Architecture Level Project ## **Establish or Define Governance Structures** There is often a tendency to consult stakeholders and governance structures at the beginning and end discussions there. Be careful to manage this pitfall as success of the project is often due to communication and buy-in from stakeholders and governance structures. If governance structures are already defined, clearly establish how the project team and stakeholders align and report to established governance groups. \ \ If governance structures are not already in place, the team will need to begin to establish some governance structure that will support definitions and maintain the health architecture. Depending upon the scope of the architecture and the goals for getting started, the governance structure may need to consider engaging the following types of groups or groups that support these services: * Government and / or Ministry of health ICT * Government and / or Ministry of health internet and technical infrastructure * Country standards groups boards or bodies * Government and / or Ministry of health cloud services or hosting services teams. * Private healthcare stakeholders or research organizations that may need to interact with MOH services and data * Privacy and security officers or advisers * Country or regional identity managers * Civil registries * Health supply chains {% hint style="success" %} **References:** * [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567) (Chapter 6: Digital Health Architecture) * Nsaghurwe, A., Dwivedi, V., Ndesanjo, W. et al. [One country's journey to interoperability: Tanzania's experience developing and implementing a national health information exchange. BMC Med Inform Decis Mak 21, 139 (2021).](https://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-021-01499-6) {% endhint %} # Determine Project Scope Architecture Level Project ## **Determine Project Scope** The scope of the architecture can be a bit challenging. One perspective is to think about the systems and data sharing transactions that are in the purview of the ministry of health. However, there may be other health data and health transactions that are in the jurisdiction of other ministries. Examples of this may include the health supply chain and / or health medications and insurance coverage practices may be important even if these are not directly in the purview of the MOH. To help move forward, you can begin with the architecture under a specific jurisdiction. However, you may want to include other branches as appropriate in the stakeholders. You may want to use any existing health strategy documentation, examples from other countries and / or the OpenHIE Architecture Specification and Diagram to help think about scope of the architecture. Ultimately, you will need to understand the systems that are needed to support the data sharing goals of the country. To begin to identify these needs, use the DIIG (Chapter 3). {% hint style="success" %} **References:** * [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567): (Chapter 3: Identify Health System Challenges and Needs) * OpenHIE Architecture Specification
{% endhint %} # Define Value of Health System Architecture Architecture Level Project ## **Define Value of Health System Architecture** National digital-health architectures are blueprints that establish the health and information needs and the software and hardware requirements that governments must consider to deliver digitally-supported health programs in a coordinated manner. These blueprints can provide critical guidance to governments, the private sector, non-governmental providers, and donors about how to invest in digital technologies and services in an aligned way that supports capture of patient-level data that can be aggregated and used throughout the health system. It is important to discuss and articulate the value of this investment with stakeholders and the appropriate governance structures.
{% hint style="success" %} **Reference:** [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567) (Chapter 6: Digital Health Architecture) {% endhint %} # Establish a Project Plan Architecture Level Project ## **Establish a Project Plan** A good project plan should address resources (technical and human), cost constraints and estimated timing. The resource plan and project plans might address the following types of activities that are considered to be in scope for the project: * Identification of architecture stakeholders. * If an eHealth Governance structure is not already in place, you will most likely need to outline time and activities to establish the governance structure. * Necessary governance checkpoints for the Architecture creation. * You may want to consider doing an inventory of existing health software / software projects. This will help with understanding of tools in the field. * Defining requirements or specific scope of the information and data exchanges that the architecture needs to support. [See DIGG (Chapter 3 Identify System Challenges and Needs)](https://www.who.int/publications/i/item/9789240010567) * Establishing [architecture principles](https://docs.google.com/document/d/1kXL3ZaCdyaqk1gpgaT_XaUVYZe-okImr-VAK_l_CHjo/edit). * Defining and documenting the principles and architecture components. * Defining standards. For example, are there specific data exchange standards such as those mentioned in the [OpenHIE Architecture Specification](https://ohie.org/framework/). You may also want to consider aspects such as noting that new software should support standard APIs. * Defining processes, procedures and expectations for new project teams. For example, there may be specific times that a project team needs to present to a governance or architecture team to provide a plan for alignment with the architecture principles and standards. * Defining roles and governance structures to establish and support curation of the architecture and support project teams in aligning with the architecture. {% hint style="success" %} **References:** * [Architecture Principles](https://docs.google.com/document/d/1kXL3ZaCdyaqk1gpgaT_XaUVYZe-okImr-VAK_l_CHjo/edit); [OpenHIE Architecture Specification](https://ohie.org/framework/) * [Digital Implementation Investment Guide:](https://www.who.int/publications/i/item/9789240010567) (Chapter 3: Identify System Challenges and Needs) {% endhint %} # Pathway 2.2 - Requirements and Design Architecture Level Project ## Process * [ ] [Inventory Existing Tools](/getting-started/pathway-2-architecture/phase-2-requirements-and-design/inventory-existing-tools) * [ ] [Document Use Cases](/getting-started/pathway-2-architecture/phase-2-requirements-and-design/document-use-cases) * [ ] [Establish Architecture Principles](/getting-started/pathway-2-architecture/phase-2-requirements-and-design/establish-architecture-principles) * [ ] [Document the Architecture](/getting-started/pathway-2-architecture/phase-2-requirements-and-design/document-the-architecture) * [ ] [Establish Architecture Processes](/getting-started/pathway-2-architecture/phase-2-requirements-and-design/establish-architecture-processes) * [ ] [Establish Standards](/getting-started/pathway-2-architecture/phase-2-requirements-and-design/establish-processes) {% content-ref url="/pages/-MblKV2wOQQ19aZOc1uz" %} [Pathway 2.3 - Implement, Support, and Scale](/getting-started/pathway-2-architecture/phase-3-implement-support-and-scale) {% endcontent-ref %} # Inventory Existing Tools Architecture Level Project ## **Inventory Existing Tools** When determining your strategy or road map, it may be useful to determine if there are existing tools that can support the desired information exchange use cases. When conducting the inventory, it may be useful to determine some of the following factors that will help in determining if use of the tool can be expanded to support the desired health information exchange use cases: * Implementation scope ( for example, the number of cases, patients or geographical scope of the implementation) * Ability to support data sharing through standards-based APIs / creation of standard message specifications (IHE profiles - See [OpenHIE Architecture Specification](https://ohie.org/framework/)) * Ability to support the tooling * Documentation is present and easy to understand * Source code is accessible and programming languages are understood by developers * Ability to support applicable terminology data standards {% hint style="success" %} **Tools:** [Digital Health Atlas](https://digitalhealthatlas.org/en/-/) **Reference:** [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567): (Chapter 4.2) {% endhint %} # Document Use Cases Architecture Level Project ## Document Use Cases Project teams can use different language to refer to the health business processes or practices for data exchange. We will use the term "use cases". As outlined in the digram below, OpenHIE is designed to support broad areas of use cases that cover individual patient care, population and public health and healthcare administration. Documenting your desired use cases is a step toward establishing the high-level requirements for your health information exchange. For examples of how countries and project teams are using health information exchange architecture, see the [OpenHIE Impact Stories](https://ohie.org/impact-stories/). ![](https://3631092837-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MaFTi2cXYF3MOUIP8lR%2F-Me5zeJ8tkgwdWzDi5vi%2F-Me61_lfpWR_bNfZP3uS%2FOpenHIE%20Architecture%20.jpg?alt=media\&token=b0473846-29b6-4d67-ac6f-b8df830a46d0) {% hint style="success" %} **Reference:** [Digital Implementation Investment Guide](https://www.who.int/publications/i/item/9789240010567): (Chapter 3.1.1) {% endhint %} # Establish Architecture Principles Architecture Level Project ## **Establish Architecture Principles** Just as a city’s infrastructure is designed to support the needs and uses of a city, the eHealth Architecture exists to support the needs for a country’s or region’s health goals and objectives. eHealth Architecture Principles are the underlying guidelines that ensure that eHealth technologies and technology projects support the eHealth strategies and objectives in a way that maximizes the investment. Because architecture principles are foundational, disparate organizations may share similar architecture principles. In summary, the eHealth principles provide a foundation for making conscious decisions about technology. ### What are Architecture Principles and why have them? Just as a city’s infrastructure is designed to support the needs and uses of a city, the eHealth Architecture exists to support the needs for a country’s or region’s health goals and objectives. eHealth Architecture Principles are the underlying guidelines that ensure that eHealth technologies and technology projects support the eHealth strategies and objectives in a way that maximizes the investment. Because architecture principles are foundational, disparate organizations may share similar architecture principles. In summary, the eHealth principles provide a foundation for making conscious decisions about technology. ### **What areas do architecture principles typically address?** TOGAF, The Open Group Architecture Framework, and other architecture processes or frameworks identify different types of architecture principles. To be effective, architecture principles do not need to be organized into categories. However, the following categories serve to help guide thinking about the content areas that architecture principles typically address. While these categories may have some overlapping scope, it may be helpful to ensure that the following types of principles are considered. #### Business Principles For an eHealth Architecture, these principles define how the architecture will support the Health and/or eHealth goals and objectives of the Ministry of Health. These principles typically address topics such as: * Scope of the principles or the business areas that are expected to be aligned with the principles. * Alignment with strategic Health and/or eHealth goals. * Need for consideration of the full life-cycle of technology. * Support for applicable laws and regulations. #### Data Principles For an eHealth Architecture, these principles define how the eHealth data will be managed and governed. These principles typically address topics like: * Expectations regarding data security, data privacy, and transparency. * High-level expectations relating to data governance and management. #### Technology and Application Principles To provide the best service possible, some organizations may have principles about their technology and application development approaches. The principles should be above any specific technology. These principles may address topics such as: * A preference for service oriented or agile architecture. * A preference for a specific application hosting strategy. * If technologies need to be supported and maintained internally, there may be a preference to limit technology diversity or restrict to certain types of licensing. * Process Principles - These are principles that guide the processes for how technology projects are approached. These principles may address topics such as: * A systems approach to ensure the solution aligns with the eco system and is focused on user needs. * The desire to participate in open standards and processes. ### **What does an architecture principle include?** The following is a general structure for architecture principles. Some organizations may use a different format or have additional categories of information that is captured. ### **Example Principles Structure** * Principle name - this is succinct and represents the essence of the principle. * Description or definition - A two or three sentence definition or description of the principle. It is important to not use vague words like “consider”. * Business rationale - A statement on the value or benefit of using this principle. ### Examples of Architecture Principles The following are illustrative examples of Architecture Principles. The list is intended to help generate thought around the types of principles that may be applicable to a specific environment. This is not intended to be an exhaustive list and it is expected that principles and descriptions will be modified extensively to fit the needs of the environment. The reference column provided in the table below points to resources where the principle is referenced. #### Business Principle Examples | **Example Principle Name** | **Example Description** | **References to the principle or a similar principle** | | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | 1. Adherence to the Principles | These principles apply to all eHealth projects in the country. |

TOGAF

Scotland Health Directorate

| | 2. Maximize Benefit to the Health Ministry and the eHealth Strategy | Information management decisions are made to provide maximum benefit to the country’s Ministry of Health and eHealth strategy as a whole. |

TOGAF

Scotland Health Directorate

| | 3. Inclusiveness | All organizations in the Ministry of Health and all stakeholders participate in information management decisions needed to accomplish health objectives. | TOGAF | | 4. Legal Compliance | eHealth information management processes comply with all relevant laws, policies, and regulations. | TOGAF | | 5. Standards Based | The architecture and solutions use relevant open eHealth standards where standards are available. |

Scotland Health Directorate

USG

OpenHIE

Digital Principles

| | 6. Build for Sustainability | Plan for sustainability from the start, including planning for long-term financial health e.g., assessing total cost of ownership. |

Digital Principles

BID

| | 7. Solutions are based upon the eHealth business needs and reference architecture | Solutions will be based upon eHealth business needs and the eHealth Architecture guides the design and delivery of solutions. | Scotland Health Directorate | | 8. Leverage existing investments | The Country’s eHealth solutions will leverage maximum benefit from existing eHealth investments that can be aligned with the eHealth reference architecture. | Scotland Health Directorate | | 9. Reuse, Buy, Build | Where possible, software solutions are reused. If reuse is not possible and solutions are externally available either via open source or from software vendors, they will be selected. Only where ministry requirements are substantially unique, or where specific constraints arise, will development be considered. | Scotland Health Directorate | | 10. Accountability | Making roles and responsibilities clear | | | 11. Transparency | Making it clear on the where, when and how decisions are reached | | #### Example Data Principles | **Example Principle** | **Description** | **References** | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | 1. Information is an asset and is governed | Data and Information are assets and are managed and governed accordingly. Each data element has a data steward responsible for the definition of the data and ensuring that there are processes to ensure accuracy, and reliability. There are defined rules on who can create, modify, view and delete data. |

Scotland Health Directorate

TOGAF

| | 2. Privacy and Security of data | All information is secured against unauthorized access, modification or loss. Consider the context and needs for privacy of personally identifiable information when designing solutions and mitigate accordingly. |

Scotland Health Directorate

Principles for Digital development

| | 3. Common Vocabulary and Definitions | Data is defined consistently throughout the enterprise, and the definitions are understandable and available to all users and systems. |

TOGAF

Scotland Health Directorate

| | 4. Data is Shared and Accessible (open data) | Users have access to the data necessary to perform their duties; therefore, data is shared across enterprise functions and organizations. Data is accessible to users as necessary to complete their jobs and in compliance with privacy and security designs. | **TOGAF** | #### Example Technology and Application Principles | **Example Principle** | **Description** | **References** | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------- | | 1. Service Oriented Architecture | Where possible, architecture and solutions are composed of reusable modular components and services, based on Service Oriented Architecture. |

TOGAF

Scotland Health Directorate

| | 2. Technology diversity | Technology diversity is controlled to minimize the cost of maintaining expertise in, and connectivity between, multiple platforms. | Scotland Health Directorate | | 3. Ease of use | Applications are easy to use. The underlying technology is transparent to users, so they can concentrate on tasks at hand. | TOGAF | | 4. Common Use | Development of applications used across the enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization | TOGAF | | 5. Responsiveness | Applications are available and responsive to needs | | #### Example Process Principles | **Example Principle** | **Description** | **References** | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | 1. Understand the existing ecosystem | Ensure projects and programs are built, managed, and owned with consideration given to the local ecosystem. | Principles for Digital Development | | 2. Design with the user in mind |

Include representatives of stakeholders in planning, design, development and assessment of solutions. Develop context appropriate solutions informed by user needs.

| | | 3. Data Driven |

Design projects so that impact can be measured at discrete milestones with a focus on outcomes rather than outputs.

| Principles for Digital Development | | 4. Project Governance | eHealth projects will be managed under the eHealth governance process. | | | 5. Open | Use open standards, open source and open innovation. |

BID

OpenHIE

Principles for Digital Development

| {% hint style="success" %} **References:** * [Principles for Digital Development](https://digitalprinciples.org/) * [TOGAF ( The Open Group Architecture Framework) - Architecture Principles](http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html#tagtcjh_2) * [National Health Service Scotland - Architecture Principles](http://www.ehealth.nhs.scot/wp-content/uploads/sites/7/documents/standard-architecture-principles1.pdf) * [BID ( Better Immunization Data) project principles](http://bidinitiative.org/the-principles/) * [OpenHIE Principles ](https://app.gitbook.com/@openhie/s/arch-spec/architecture-specification/architectural-principles) {% endhint %} # Document the Architecture Architecture Level Project ## Document the Architecture ### Content to Consider When developing your health architecture, you may want to consider including the following content: * Information about the health system context * You may want to include linkages to key health system documents or priorities * [Architecture principles](/getting-started/pathway-2-architecture/phase-2-requirements-and-design/establish-architecture-principles) * Architecture diagram / components * you may want to reference the OpenHIE Architecture here. * [Standards](/getting-started/pathway-2-architecture/phase-2-requirements-and-design/establish-processes) or a reference to standards * Consider of the data exchange standards and / or terminology standards are stored in the Architecture document, an appendix or a separate standards document. * Guidelines for application may be included in the architecture or other documentation for health information teams to follow. These may include expectations such as: 1. Project teams must create documentation of system assets (for example, requirements, design, installation process) 2. Applications that share data must/should have APIs 3. Application purchases or selection must be done via an evaluation process where the criteria and decision are documented 4. Applications should be designed in a way that support data standards 5. Any source code developed specifically for MOH should be stored in the MOH source code repository 6. Interoperability layer should be used for data exchange (No new point-to-Point) 7. Project teams must complete an HIS project Alignment (processes outlined in this document) 8. Additional guidelines... The following are some examples of how the architecture has been documented. {% hint style="success" %} **References:** * [Kenya Health Architecture ](https://www.data4sdgs.org/sites/default/files/services_files/Kenya%20Health%20Information%20Systems%20Interoperability%20Framework.pdf) * [Tanzania 2012-2018 Strategy](https://www.who.int/goe/policies/countries/tza_ehealth.pdf) * [Uganda](https://health.go.ug/sites/default/files/National%20e_Health%20Strategy_0.pdf) {% endhint %} # Establish Architecture Processes Architecture Level Project ## Establish Architecture Processes and Governance ### Why have Architecture Processes? Unless there are processes in place to support the application and maintenance of the architecture, the designated architecture will be documentation that is placed on a shelf or used in presentations. To support the use and maintenance of the architecture, there are some processes or governance structures that need to be put in place. ### Processes to consider #### 1. A process to support HIS project alignment with the architecture Process to have HIS teams present or discuss their health information project with an architect, governance committee or architecture review board at project initiation and perhaps other important stages can help HIS teams align with the architecture. This process or project governance step should be structured to: * Ensure health project project alignment with the documented architecture principles, component and standards * Promote appropriate re-use existing of existing software (justification for introducing duplicative components) Process triggers or actions that might activate this process need to be documented. These might include: * There is an HIS project or software project that is not yet aligned with the architecture governance process * A new HIS project is initiated by a funder, partner organization or any level of the health system. * An existing HIS project or system is expanding the scope of their project to include additional use cases and / or software. #### 2. HIS Asset Inventory Update Processes This process would ensure that the HIS project or software inventory is created and kept up to date. It may require that there are specific times when project teams or funders add items to the inventory and/or update them on a regular basis. You may want to have a process or policy on selection of software that ensures that software aligns with the architecture and where appropriate re-uses software component investments that have already been made. Process triggers or actions that might activate this process need to be documented. These might include: * There is an HIS project or software project that is not yet in the software inventory. * A new HIS project is initiated by a funder, partner organization or any level of the health system. * An existing HIS project or system is expanding the scope of their project to include additional use cases and / or software. * Annual or biannual inventory update / review #### 3. Software Selection Process This process would ensure that software is selected based upon a process that documents high-level business needs as well as needs for data sharing and compliance with the architecture. This process might also be designed to evaluate existing software in the inventory to see if it meets the desired needs. Process triggers or actions that might activate this process need to be documented. These might include: * There is an HIS project that needs a new software component * A new HIS project is initiated by a funder, partner organization or any level of the health system and requires software. * An existing HIS project or system is expanding the scope of their project to include additional use cases and / or software. #### 4. A process to review standards / update standards To keep the standards up to date and provide a relevant and living document for project teams, it is suggested that there is some process to curate (add to / update / retire) standards and / or the architecture diagram. ### **Audience for Architecture Processes** When creating the architecture processes, consider the audience for the processes. The following are some key stakeholders to consider: * All HIS project teams creating or managing HIS software for use in capturing, processing, reporting or sharing health information in any level of the health system. * FMOH HITD Personnel * Health Architecture Governance / working group members * Sponsors and key stakeholders for HIS projects # Establish Standards Architecture Level Project ## Establish Standards ### **Message Standards** Message standards provide the syntax for exchanging information between different computer systems. OpenHIE provides the OpenHIE Architecture Specification that can serve as a foundation for these syntactic standards. {% hint style="success" %} **References:** * [OpenHIE Architecture Specification ](https://app.gitbook.com/@openhie/s/arch-spec/) * [Standards and Profiles](https://app.gitbook.com/@openhie/s/arch-spec/architecture-specification/standards-and-profiles) {% endhint %} ### **Terminology Standards** The following documents may provide a reference for getting started with terminology standards. {% hint style="success" %} **References:** * Alunyu, A. E., & Nabukenya, J. (2018). [A Conceptual Model for Adaptation of eHealth Standards by Low and Middle-Income Countries. Journal of Health Informatics in Africa, 5(2).](https://doi.org/10.12856/JHIA-2018-v5-i2-199) * Alunyu, A. E., Wamema, J., Kiwanuka, A., & Bagyendera, M. (2020). [Factors that Influence Potential Success of eHealth Standards Adoption in a Low- and Middle-Income Country: a review. Journal of Health Informatics in Africa, 7(1), 24 - 37.](https://doi.org/10.12856/JHIA-2020-v7-i1-274) * [WHO eHealth Strategy Toolkit](https://apps.who.int/iris/handle/10665/75211) * [Terminology Maturity Model ](https://docs.google.com/presentation/d/1rqRTzzSRKVujdt0NPFp75kgiK00r-PkR2DIezsXPfLU/edit#slide=id.g2502884cb7_0_18) {% endhint %} \
# Pathway 2.3 - Implement, Support, and Scale Architecture Level Project ## Process * [ ] [Communication and Roll Out](/getting-started/pathway-2-architecture/phase-3-implement-support-and-scale/communication-and-roll-out) # Communication and Roll Out Architecture Level Project ## **Establish Communications Plan** The roll out of a new system, process or procedure often requires a communication plan. Review your stakeholder list to ensure that those who are a part of the governance process, expected to comply with the architecture or are impacted by new processes being established are appropriately informed and updated about changes in process and policies.\
# How to Provide Feedback / Input ## We Want Your Input Help others in the OpenHIE community by: * Iterating on the content that is here and making it more clear, more refined and better! * Suggesting new content that you are working or or that you would like us to work on! ## How to Suggest Additions and Revisions: 1. Go to [Discourse ](https://discourse.ohie.org/c/openhie-feedback/3) 2. Select "new topic" button 3. Specify the artifact that needs revision. In this case, it is the "OpenHIE Getting Started Guide" and follow the directions to make your suggestion. Be as specific as possible. Thank you. # Change Log ## September-2021 ### New Guide * Combined materials from the former guides that were focused on an individual component and added material to focus on data exchange projects and getting started with an architecture project. **This work is licensed under a Creative Commons Attribution 4.0 International License.**