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.
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.
"Adaptable" / "implementable"
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.)
"Interchangeability" / "Swappable"
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.
The architecture review board is designed to include members representing OpenHIE stakeholders including; OpenHIE Architecture Component communities, OpenHIE organizations and implementers.
Each OpenHIE component community will nominate 2 voting members for the architecture review board to act as delegates representing the views of their respective sub-community. It is expected that the voting representatives will reflect the views of their sub-community in a manner determined by their respective sub-community. For example, one sub-community may grant their representatives the authority to vote as they see fit, while another sub-community may further specify their representatives actions. This shall be determined by individual sub-communities. In addition to the sub-community-specific representatives, at-large members will be identified.
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.
These discussion vehicles are open and anyone can join.When discussion consensus cannot be achieved or when making formal decisions on the OHIE architecture necessary,the architecture review board will thenvote for consensus.
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.
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.)
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.
- If a topic does not receive 70% of the vote, it is not approved and concerns must be identified for further discussion.