You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 40 Next »

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.

Responsibilities 

  1. Champion the OHIE community's "Adaptable" / "implementable" principle.

    1. HOW:  Map the workflow priorities to real-world implementation needs.  Make decisions based upon expressed needs.  Implementation-Driven.

  2. Champion the OHIE community's "Standards-based" principle.

    1. HOW:  Ensure the OHIE community is engaging in IHE and other interoperability specification development processes to meet implementer needs.

    2. HOW:  Develop workflows that appropriately leverage IHE and other standards and standards processes.  

    3. HOW: Where standards don’t exist, advocate for the development of future solutions.

    4. HOW:  Advocate for standards-based interfaces.

    5. HOW: Track emerging standards development processes and evaluate their usefulness to the OpenHIE community.

  3. Champion the OHIE community "Interchangeability" / "Swappable" principle  

    1. HOW:  Enable plurality of architecture components.  

  4. Establish and curate the OHIE Architecture Diagram.

    1. Routinely review the architecture diagram and evaluate and make decision on changes needed.  

    2. HOW - when changes or updates are requested, the ARB and the Community will discuss them and come to consensus.  

    3. HOW - solicit feedback from implementers and other OHIE community members

  5. Facilitate the creation and curation of the OHIE Workflows and Approve the OHIE workflows.  

    1. 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.

    2. HOW - Ensure each workflow has a sponsor

    3. HOW - Make architectural decisions based on implementer’s expressed needs

    4. HOW - Choose standards that best support the HIE user's needs.

    5. HOW - Have a process for developing workflows

  6. Determine and curate and communicate Maturity Model updates

    1. HOW - Have a regular release schedule and process for reviewing and updating maturity of OHIE workflows

    2. HOW - Review sponsor assessments and work with the sponsor(s) to come to consensus on the assessment.  

  7. Determine OHIE IHE Connectathon and other standards testing plans

    1. HOW - Evaluate profile and software changes and determine and prioritize testing needs.   

  8. Build OHIE community awareness and consensus around OHIE Architecture

    1. HOW - Use Architecture community meetings and mailing list to facilitate discussions, share information and gather input
    2. HOW:  Mailing list and on the regular architecture calls are open and anyone can join
    3. HOW - ARB Members will cast a vote when majority consensus cannot be achieved by the architecture community
    4. HOW - Maintain awareness of OHIE architecture, community and implementer needs by regularly attending OHIE Architecture meetings.

 

  • No labels