Members
The Architecture Review Board (ARB) is lead by the Chief Architect. ARB members are community representatives who
are committed 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 |
Deliverables
Advanced Tables - Table Plus |
---|
Deliverable | Description | Deliverable Type | Review Cycle | Last |
---|
|
review Review Date |
---|
OpenHIE Specification | Documentation of the OpenHIE Architecture, components and workflows. | OHIE Website |
|
OpenHIE Architecture | Description of the OHIE Architecture and the components. | Wiki Page | Annual or Semi-Annual | July 2022 | OpenHIE Diagram Movable Options | Version of OHIE diagram with movable components for use by project teams and implementers. |
|
Update Coming Soon | Reference Technologies | List of reference technologies with links to their repositories. | Wiki PageMultiple Wiki Pages | OpenHIE Testing Strategy |
| Coming Soon |
|
Workflow Collection Maturity | OpenHIE Workflows and the ARB's description of their known use and maturity. | OpenHIE Standards and Profiles | Message standards and profiles used in OpenHIE. | Wiki Page SecuirtySecurity. | Wiki Page | Review in an ARB Meeting | June 2016 | FHIR Statement |
|
| Review in an ARB Meeting |
|
|
and Deliverables | ARB Members, ARB / Architecture Community Responsibilities and Deliverables. | Wiki Page (This page) |
|
Archiecture
| Jan. 2021 | Architecture Processes |
| Update Coming Soon |
|
|
|
Members of the ARB
Individual | Represents (OpenHIE Sub-Community and/or Organization) |
---|
| Regenstrief, Patient Identity Management Community (Chief Architect) |
| Apelon, Terminology Services Community |
| OpenHIE Health Management Information System Community |
TBA | IntraHealth, InterLinked Registries Community, Health Worker Registry Community |
Jose Costa Teixeira | PATH |
| Interoperability Layer Community, Shared Health Record Community |
| Database Consulting Group, FHIR |
| ecGroup |
| Digital Square, Health Financing towards UHC Community |
| VillageReach, Supply Chain Community |
| Parker Digital Health Consulting Inc. |
| Jembi Health Systems, OpenHIE Implementers, Health Financing towards UHC Community |
| CDC |
| Facility Registry Community |
| Intellisoft |
Aisha Abdulahi | John Snow Incorporated |
| Clinton Health Access Initiative |
| ICF |
Haftamu Kebede Yigzaw | Mekelle University |
Responsibilities of the ARB
Expand |
---|
title | Expand for Responsibilities |
---|
|
Based upon real-world needs, the |
architecture community Architecture Review Board has the following responsibilities: |
HOW: Map the workflow priorities to real-world implementation needs. Make decisions based upon expressed needs. |
|
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 standards solutions. |
|
HOW: Advocate for standards-based interfaces. |
|
HOW: Track emerging standards development processes and evaluate their usefulness to the OpenHIE community. |
|
HOW: Enable plurality of architecture components. |
|
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 When changes or updates are requested, the ARB and the Community will discuss and establish consensus. |
|
HOW: Routinely review and publish the specification. |
|
HOW: when When changes or updates are requested, the ARB and the Community will discuss and establish consensus. |
|
HOW: solicit Solicit feedback from implementers and other OHIE community members. |
|
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: Identify standards that best support the HIE user's needs. |
|
HOW: 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, 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, 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. |
|