...
| Individual | Represents (OpenHIE Sub-Community and/or Organization) |
|---|---|
| Regenstrief, Client Registry Community (Architecture Community Lead) | |
| Apelon, Terminology Services Community | |
| OpenHIE Health Management Information System Community | |
| IntraHealth, InterLinked Registries Community, Health Worker Registry Community | |
| PATH, Health Financing towards UHC Community | |
| Interoperability Layer Community, Shared Health Record Community | |
| Database Consulting Group, FHIR | |
| ecGroup | |
| OpenHIE Implementers | |
| VillageReach, Supply Chain Community | |
| Parker Digital Health Consulting Inc. | |
| Jembi Health Systems | |
| CDC |
...
Based upon real-world needs, the architecture community has the following responsibilities:
- Champion the OHIE community's
- Community’s principles of "Adaptable" / "implementable" principle.
- , "Standards-based" and "Interchangeable" / "Swappable".
- HOW:
Map - Map the workflow priorities to real-world implementation needs.
Make - Make decisions based upon expressed needs.
Implementation-Driven.Champion the OHIE community's "Standards-based" principle.- HOW:
Ensure - Ensure the OHIE community is engaging in IHE and other interoperability specification development processes to meet implementer needs.
- HOW:
Develop - Develop workflows that appropriately leverage IHE and other standards and standards processes.
- HOW: Where standards don’t exist, advocate for the development of future standards solutions.
- HOW:
Advocate - 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 - 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: Develop and maintain an architecture roadmap on a yearly basis.
- Support creating, curating, and publishing the OHIE Specification, including the architecture diagram, components specifications, and workflows that support patterns for data exchange.
- HOW: Routinely review and publish the specification.
- HOW: when changes or updates are requested, the ARB and the Community will discuss and establish consensus.
- HOW: Routinely review and publish the specification.
- HOW:
HOW - - when changes or updates are requested, the ARB and the Community will discuss
them - and
come to - establish 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 the implementer’s expressed needs.
- HOW
- Choose - : Identify standards that best support the HIE user's needs.
- HOW
- Have - : Maintain a process for developing workflows
- Determine and
- , curate, and communicate Maturity Model updates.
- HOW
- : Maintain a regular
- process for reviewing and updating the maturity of OHIE workflows
- HOW
- : Review sponsor assessments and work with the sponsor(s) to
- establish consensus on the assessment.
- Determine OHIE IHE Connectathon and other standards testing plans
- , curate, and communicate OHIE testing strategy.
- HOW:
- Evaluate profile and software changes and determine and prioritize testing needs.
- HOW: Work with sub-communities to identify testing scenarios and cases to meet the architectural specification.
- HOW: Routinely review and publish the OpenHIE Conformance Testing Specification.
- HOW: Curate the OpenHIE Conformance and Compliance testing approach
- HOW: Ensure each component, workflow scenario, and test sets have a sponsor.
- HOW: Build OHIE community awareness and consensus around OHIE
- Conformance testing and possible country-level use.
- HOW
- : Use Architecture and DevOps community meetings and mailing
- lists to facilitate discussions, share information
- , 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
- , and establish consensus.
- Curate Reference Software lists.
- HOW: Engage each of the OpenHIE sub-communities to nominate the proposed reference software(s) of the community.
- HOW: Validate the community’s evaluation of the software against the Specification and Conformance Testing Framework.
- HOW: Publish and curate the list of software on the OpenHIE wiki and correlate artifacts with the specification.
- NOTE: It is not this board’s responsibility for identifying software (that lies with the sub-communities), however, it is the responsibility to validate the nominees and evaluate their submission based on the specification.
- Support the community at large in understanding the OHIE architecture framework
- HOW: Support emerging and existing OHIE community groups with onboarding on the fundamentals of the OHIE specification and architecture
- HOW: Engage in other community calls as needed/appropriate to support the introduction to the architecture.
- HOW: Represent the OpenHIE architecture in LMIC and digital health community meetings and conferences as appropriate.
Deliverables
| Advanced Tables - Table Plus | |||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...