Versions Compared

Key

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

This document was created to clarify the definitions of different OpenHIE stakeholder needs pointed out by the OpenHIE Implementers Network (OHIN). This document is identifying the various stakeholder roles that the OpenHIE community has identified. Stakeholders (organizations / individuals / MoHs) are not limited to a single role and can, and often do, play multiple roles. The focus here is to look at the particular needs different stakeholder roles may have. These roles and definitions are meant to be adaptable to a variety of different environments. 

Ministry of Health (MoH) / Government / National bodies

Individuals employed by or seconded to MoH or Government departments with varying level of ICT knowledge. Primary focus is in understanding how to address real world needs faced by departments; how leveraging OpenHIE architectures and shared components could address aspects of their current health sector strategy; how leveraging a unified shared architecture could see synergies emerge from shared donor investment and shared technical expertise.

They look at a whole picture approach that includes impact, services, change management, costs, maintenance and roll-out. 


OpenHIE note: Should try to meet them more on the “this is how that intervention towards health outcome X can be supported by OpenHIE” as well as “consider factors XYZ when looking at data exchange/system operation/policy etc.” These organizations should share practices that allow for evolution of the practices in the OpenHIE Architecture.  

Implementers

These are groups often tasked with bringing into reality the envisaged interventions. This group includes those who work with, for, or in collaboration, of the MoH (or are members of the MoH itself) within a particular context. They carry the responsibility to operationalize the vision as well as, often, create policies and governance structures, design the architecture and plan for successful implementation of the end goal. 

Can contain distinct groups that focus on:

  • How to create a successful health systems intervention 
  • Identifying and planning to roll out identified solution and create impact 
  • Standing up technical solutions
  • Creating a framework for ongoing sustainability of the intervention.

These groups have interest topics that vary from architectural design, standard selection, software solutions through to the operationalization of the designs (installation, configuration, integrations and trainings).


OpenHIE note: Should aim to meet these groups with more guidance on how to action an implementation, what factors to consider outside of just installing the software (such as policy about data exchange, stakeholders to engage with etc). This group wants to know how to actually operationalize the “features / functionality” of OpenHIE. These organizations should share practices that allow for evolution of the documentation in the OpenHIE Architecture.  

Funders

Organizations and representatives who are charged with providing resources to support impacts in the areas of health care/aid/etc. Often with experience across the board from technology to domain expertise to program management. Looking to be aware of viable patterns and tools that would best position supporting programs to achieve success. These groups may be aware of the value of investing in common open source infrastructure as a pathway for sustainability for ongoing impact but are looking for a viable approach and banner to do this under/with.


OpenHIE note: Should be looking to showcase the community of support, the existing knowledge, where we’ve had success before, how common architecture and design can bridge between vertical programs, how this is a pattern for information systems that supports sustainability, how OpenHIE has been used/implemented to impact health objectives and outcomes as well as how OpenHIE can contribute to improved health outcomes etc.

Domain Experts / Technical Experts

These are groups/individuals that are well versed in best practices and positioned to create broader health system interventions. These include new and or refined ways to address burdens of disease/care, new interventions and treatment plans / strategies. The group is more health focused and less focused on the detail of the software.


OpenHIE note: Should aim to meet these groups with the “health voice” of how OpenHIE supports the health impact. Talking to points such as reducing lost to follow up, supporting identifying a person across the “enterprise”, improve continuity of care, use of aggregated data and creating accessible health data as well as Civil Registration and Vital Statistics etc.

Developers wanting to adopt and implement OpenHIE standards

Various types: 

  1. Developers who will customize and install OpenHIE components
  2. Developers of point of care/service tools which will connect with OpenHIE.
  3. Developers who manage software that may wish to have their tool become a backend component in addition to the current reference tools. 


OpenHIE note:These are the nuts and bolts teams. They are concerned about how to implement the standards we propose. They ask how leveraging OpenHIE may provide access to scalability and providing impact on a larger scale. They ask: “How do I make system y do abc, etc”. We also rely on these teams to help refine the workflows and drive new/refinements of workflows based on real-world implementation/interoperability needs.

Consumers of Information Exchange

These are individuals/ teams that include providers of direct health care as well as a public and population health (e.g. surveillance officers) focus.  They may overlap with the domain experts but represent the end user needs. 


OpenHIE note: Members of this domain should be included in the development cycle as they will be aware of potential uses of the data. While domain experts are involved in representing the ‘health voice’, the end user represents the community that uses the data. OpenHIE needs to be aware of the impact on End Users / Health Care Teams but primarily OpenHIE ‘speaks’ to the other mentioned stakeholder groups. 

Standards Development Orgs

These are groups is an organization whose primary function is developing, coordinating, publize, revising, amending, reissuing, interpreting, or otherwise producing technical standards  to address the needs of a group of affected adopters.


OpenHIE note: This includes both health terminology and syntactic data exchange standards required to support health information exchange.  OpenHIE partners with health standards organizations to create, refine and utilize standards.

Content Creators / Capacity Strengthening Organizations

Stakeholders creating and sharing health information exchange and related training materials (such as FHIR, HIE components, and standards).  


OpenHIE note: These organizations should be focused on creating and sharing content strengthening local capacity in countries to build knowledge and sustainability around health information exchange that can then be shared back through resources like the OpenHIE Academy

Universities / Academic Institutions

Academic stakeholders involved in leading or supporting country or regional health information exchange efforts.  


OpenHIE note: These professionals and institutions should be engaged to ensure collaboration across multiple regions and institutions in support of countries.  These individuals and organizations should share practices that allow for evolution of the documentation in the OpenHIE Architecture.  

Regional Partners

These groups include geographic regional partners that are convening over topics with regard to digital health and health information exchange. These organizations have a defined geographic region that they service and are their own separate organizations, not housed within any particular country.


OpenHIE note: These organizations should be focused on creating opportunities tailored to the needs of their region and would serve as the primary relationship builder for OpenHIE in their specific regions

Tool Creators

These organizations create and support applications aligned with the various components in the OpenHIE Architecture Diagram.  


OpenHIE note: These organizations should be focused on ensuring alignment with the OpenHIE specification as well as contributing to the Specification evolution as practices for sharing data evolve and mature.  

Related Initiatives

These organizations act in a similar capacity as OpenHIE but in their own perspective concentration in the digital health ecosystem. They can serve as a community of practice within one of the sub components of the OpenHIE standard, or for a community that falls outside of the OpenHIE standard, but it still closely tied in the broader scope of digital health


OpenHIE note: These initiatives tend to be communities of practice or a group of organizations coming together to enhance global digital health. OpenHIE strives to ensure initiatives work to enhance each others efforts and not create duplication.


Table of Contents

inistry of Health (MoH) / Government / National bodies

Individuals employed by or seconded to MoH or Government departments with varying level of ICT knowledge. Primary focus is in understanding how to address real world needs faced by departments; how leveraging OpenHIE architectures and shared components could address aspects of their current health sector strategy; how leveraging a unified shared architecture could see synergies emerge from shared donor investment and shared technical expertise.

They look at a whole picture approach that includes impact, services, change management, costs, maintenance and roll-out. 

OpenHIE note: Should try to meet them more on the “this is how that intervention towards health outcome X can be supported by OpenHIE” as well as “consider factors XYZ when looking at data exchange/system operation/policy etc.” These organizations should share practices that allow for evolution of the practices in the OpenHIE Architecture.  

Implementers

These are groups often tasked with bringing into reality the envisaged interventions. This group includes those who work with, for, or in collaboration, of the MoH (or are members of the MoH itself) within a particular context. They carry the responsibility to operationalize the vision as well as, often, create policies and governance structures, design the architecture and plan for successful implementation of the end goal. 

Can contain distinct groups that focus on:

  • How to create a successful health systems intervention 
  • Identifying and planning to roll out identified solution and create impact 
  • Standing up technical solutions
  • Creating a framework for ongoing sustainability of the intervention.

These groups have interest topics that vary from architectural design, standard selection, software solutions through to the operationalization of the designs (installation, configuration, integrations and trainings).

OpenHIE note: Should aim to meet these groups with more guidance on how to action an implementation, what factors to consider outside of just installing the software (such as policy about data exchange, stakeholders to engage with etc). This group wants to know how to actually operationalize the “features / functionality” of OpenHIE. These organizations should share practices that allow for evolution of the documentation in the OpenHIE Architecture.  

Funders

Organizations and representatives who are charged with providing resources to support impacts in the areas of health care/aid/etc. Often with experience across the board from technology to domain expertise to program management. Looking to be aware of viable patterns and tools that would best position supporting programs to achieve success. These groups may be aware of the value of investing in common open source infrastructure as a pathway for sustainability for ongoing impact but are looking for a viable approach and banner to do this under/with.

OpenHIE note: Should be looking to showcase the community of support, the existing knowledge, where we’ve had success before, how common architecture and design can bridge between vertical programs, how this is a pattern for information systems that supports sustainability, how OpenHIE has been used/implemented to impact health objectives and outcomes as well as how OpenHIE can contribute to improved health outcomes etc.

Domain Experts / Technical Experts

These are groups/individuals that are well versed in best practices and positioned to create broader health system interventions. These include new and or refined ways to address burdens of disease/care, new interventions and treatment plans / strategies. The group is more health focused and less focused on the detail of the software.

OpenHIE note: Should aim to meet these groups with the “health voice” of how OpenHIE supports the health impact. Talking to points such as reducing lost to follow up, supporting identifying a person across the “enterprise”, improve continuity of care, use of aggregated data and creating accessible health data as well as Civil Registration and Vital Statistics etc.

Developers wanting to adopt and implement OpenHIE standards

Various types: 

  1. Developers who will customize and install OpenHIE components
  2. Developers of point of care/service tools which will connect with OpenHIE.
  3. Developers who manage software that may wish to have their tool become a backend component in addition to the current reference tools. 
OpenHIE note:These are the nuts and bolts teams. They are concerned about how to implement the standards we propose. They ask how leveraging OpenHIE may provide access to scalability and providing impact on a larger scale. They ask: “How do I make system y do abc, etc”. We also rely on these teams to help refine the workflows and drive new/refinements of workflows based on real-world implementation/interoperability needs.

Consumers of Information Exchange

These are individuals/ teams that include providers of direct health care as well as a public and population health (e.g. surveillance officers) focus.  They may overlap with the domain experts but represent the end user needs. 

OpenHIE note: Members of this domain should be included in the development cycle as they will be aware of potential uses of the data. While domain experts are involved in representing the ‘health voice’, the end user represents the community that uses the data. OpenHIE needs to be aware of the impact on End Users / Health Care Teams but primarily OpenHIE ‘speaks’ to the other mentioned stakeholder groups. 

Standards Development Orgs

These are groups is an organization whose primary function is developing, coordinating, publize, revising, amending, reissuing, interpreting, or otherwise producing technical standards  to address the needs of a group of affected adopters.

OpenHIE note: This includes both health terminology and syntactic data exchange standards required to support health information exchange.  OpenHIE partners with health standards organizations to create, refine and utilize standards.

Content Creators / Capacity Strengthening Organizations

Stakeholders creating and sharing health information exchange and related training materials (such as FHIR, HIE components, and standards).  

OpenHIE note: These organizations should be focused on creating and sharing content strengthening local capacity in countries to build knowledge and sustainability around health information exchange that can then be shared back through resources like the OpenHIE Academy

Universities / Academic Institutions

Academic stakeholders involved in leading or supporting country or regional health information exchange efforts.  

OpenHIE note: These professionals and institutions should be engaged to ensure collaboration across multiple regions and institutions in support of countries.  These individuals and organizations should share practices that allow for evolution of the documentation in the OpenHIE Architecture.  

Regional Partners

These groups include geographic regional partners that are convening over topics with regard to digital health and health information exchange. These organizations have a defined geographic region that they service and are their own separate organizations, not housed within any particular country.

OpenHIE note: These organizations should be focused on creating opportunities tailored to the needs of their region and would serve as the primary relationship builder for OpenHIE in their specific regions

Tool Creators

These organizations create and support applications aligned with the various components in the OpenHIE Architecture Diagram.  

OpenHIE note: These organizations should be focused on ensuring alignment with the OpenHIE specification as well as contributing to the Specification evolution as practices for sharing data evolve and mature.  

Related Initiatives

These organizations act in a similar capacity as OpenHIE but in their own perspective concentration in the digital health ecosystem. They can serve as a community of practice within one of the sub components of the OpenHIE standard, or for a community that falls outside of the OpenHIE standard, but it still closely tied in the broader scope of digital health

OpenHIE note: These initiatives tend to be communities of practice or a group of organizations coming together to enhance global digital health. OpenHIE strives to ensure initiatives work to enhance each others efforts and not create duplication.