Members
The Architecture Review Board (ARB) is lead by the Chief Architect. ARB members are community representatives who are committed to the Architecture Governance and Principles.
Individual | Represents (OpenHIE Community and/or Organization) |
---|---|
Shaun Grannis | Regenstrief, Client Registry Community (OpenHIE Chief Architect) |
Jack Bowie | Apelon, Terminology Services Community |
Bob Jolliffe | OpenHIE Health Management Information System Community |
Luke Duncan | IntraHealth, InterLinked Registries Community, Health Worker Registry Community |
Carl Leitner | PATH |
Ryan Crichton | Jembi Health Systems, Interoperability Layer Community, Shared Health Record Community |
Eduardo Jezierski | InSTEDD, Facility Registry Community |
Derek Ritz | ecGroup |
Carl Fourie | OpenHIE Implementers |
Duane Bender | Mohawk College |
Denise Johnson | ICF |
Responsibilities
Champion the OHIE community's "Adaptable" / "implementable" principle.
HOW: Map the workflow priorities to real-world implementation needs. Make decisions based upon expressed needs. Implementation-Driven.
Champion the OHIE community's "Standards-based" principle.
HOW: Ensure the OHIE community is engaging in IHE and other interoperability specification development processes to meet implementer needs.
HOW: Develop workflows that appropriately leverage IHE and other standards and standards processes.
HOW: Where standards don’t exist, advocate for the development of future solutions.
HOW: Advocate for standards-based interfaces.
HOW: Track emerging standards development processes and evaluate their usefulness to the OpenHIE community.
Champion the OHIE community "Interchangeability" / "Swappable" principle
HOW: Enable plurality of architecture components.
Establish and curate the OHIE Architecture Diagram.
Routinely review the architecture diagram and evaluate and make decision on changes needed.
HOW - when changes or updates are requested, the ARB and the Community will discuss them and come to consensus.
HOW - solicit feedback from implementers and other OHIE community members
Facilitate the creation and curation of the OHIE Workflows and Approve the OHIE workflows.
HOW - Evaluate workflow additions or changes to assess the feasibility of incorporating into the OHIE framework; including determining whether the proposed workflow can be incorporated into an existing workflow with or without modification.
HOW - Ensure each workflow has a sponsor
HOW - Make architectural decisions based on implementer’s expressed needs
HOW - Choose standards that best support the HIE user's needs.
HOW - Have a process for developing workflows
Determine and curate and communicate Maturity Model updates
HOW - Have a regular release schedule and process for reviewing and updating maturity of OHIE workflows
HOW - Review sponsor assessments and work with the sponsor(s) to come to consensus on the assessment.
Determine OHIE IHE Connectathon and other standards testing plans
HOW - Evaluate profile and software changes and determine and prioritize testing needs.
Build OHIE community awareness and consensus around OHIE Architecture
- HOW - Use Architecture community meetings and mailing list to facilitate discussions, share information and gather input
- HOW: Mailing list and on the regular architecture calls are open and anyone can join
- HOW - ARB Members will cast a vote when majority consensus cannot be achieved by the architecture community
- HOW - Maintain awareness of OHIE architecture, community and implementer needs by regularly attending OHIE Architecture meetings.