Versions Compared

Old Version 36

changes.mady.by.user Jamie Thomas

Saved on

compared with

New Version 37

changes.mady.by.user Jennifer E Shivers

Saved on

Key

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

...

IndividualRepresents (OpenHIE Community and/or Organization)
Shaun GrannisRegenstrief, Client Registry Community (OpenHIE Chief Architect)
Jack BowieApelon, Terminology Services Community
Bob JolliffeOpenHIE Health Management Information System Community
Luke DuncanIntraHealth, InterLinked Registries Community, Health Worker Registry Community
Carl LeitnerPATH, Health Financing towards UHC Community
Ryan CrichtonInteroperability Layer Community, Shared Health Record Community
Bryn RhodesDatabase Consulting Group, FHIR
Derek RitzecGroup
Carl FourieOpenHIE Implementers 
Josh ZamorVillageReach, Supply Chain Community
Unknown User (rgparker57)Shared Services Canada
Unknown User (danfuterman)Jembi Health Systems
James KariukiCDC

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.

...