SAVE THE DATE - #OHIE19 Nov 4-8, 2019 in Addis Ababa, Ethiopia - CLICK HERE
Skip to end of metadata
Go to start of metadata

Governance

To improve the effectiveness, efficiency, and transparency of the architecture design, deliberation, and decision-making processes, we seek to create an OpenHIE architecture governance process that will review design options and develop consensus-based (not necessarily unanimously approved) strategies through an architecture review board. Formal engagement/membership in the OpenHIE architecture review board is premised upon a commitment to guiding architecture principles.

Principles

  1. "Standards-based"
    1. OpenHIE preferentially seeks to leverage consensus-based, international interoperability specifications that support countries' health information exchange needs. We are committed to engaging in the IHE interoperability specification development process. To the extent possible we will leverage the IHE process to identify, evaluate and implement pre-existing IHE specifications and will also advocate for the development of future solutions.


  1. "Adaptable" / "implementable"

    1. Because health information exchange functional requirements vary among countries and evolve over time, we recognize that existing standards and interoperability specifications may not fully support a country's HIE needs. Consequently, OpenHIE seeks an architecture that supports -- does not unnecessarily constrain -- effective implementation of country-driven workflows that extend beyond current interoperability specifications. To the extent possible, we anticipate that such workflow extensions would be incorporated into future consensus-based standardized interoperability specifications. (It has alternatively been suggested we call this principle "user driven". We seek to make architectural decisions based on implementations expressed needs, and choose standards that best support the HIE user's needs.)


  2. "Interchangeability" / "Swappable"

    1. OpenHIE seeks to support a robust and diverse software component ecosystem where implementing and support organizations may leverage different software products for the OpenHIE components. To enable effective and efficient "swap-ability" of components, we seek an architecture that clearly defines and reinforces standardized interfaces for each of these components. We seek to ensure that the reference components of OpenHIE support standardized interfaces.

Process

  1. Primary discussion vehicle is for cross-cutting architectural concerns to be raised through the mailing list and on the regular architecture calls, which are open and anyone can join.

  2. The architecture review board is designed to include members representing OpenHIE stakeholders including; OpenHIE Architecture Component communities, OpenHIE organizations and implementers.  

  3. Ideas and opinions will be shared through primary discussion vehicles including the architecture calls  and the mailing list  to allowing multiple perspectives to be shared. When discussion consensus cannot be achieved or when making formal decisions on the OHIE architecture the architecture review board will vote for consensus.

  4. It is expected that all members must be given a reasonable opportunity to cast a vote. If a voting member is unable to attend a meeting when a vote is taken, reasonable efforts will be made to obtain their vote asynchronously.

  5. Decisions will be made through a consensus-based process. Consensus does not require that all participants agree although this is, of course, preferred.  In general, the dominant view of the working group shall prevail. (However, it must be noted that "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.)

  6. As most architecture group meetings are conducted via phone call, consensus will be determined by a roll-call vote using a “super majority decision rule” where decisions must meet a 70% threshold . If a voting member cannot attend a meeting where a vote is taken, alternate efforts for securing their vote will be used.

  7. If a topic does not receive 70% of the vote, it is not approved and concerns must be identified for further discussion.
  • No labels