Members
The Architecture Review Board (ARB) is lead by the Chief Architect. ARB members are community representatives who
...
Deliverables
Advanced Tables - Table Plus |
---|
Deliverable | Description | Deliverable Type | Review Cycle | Last Review Date |
---|
OpenHIE Specification | Documentation of the OpenHIE Architecture, components and workflows. | OHIE Website | Annual or Semi-Annual | July 2022 | OpenHIE Diagram Movable Options | Version of OHIE diagram with movable components for use by project teams and implementers. | Movable Diagram Wiki Page | Annually (needs to stay in sync with diagram) | June 2020 | OpenHIE Testing Strategy |
| Coming Soon | TBD |
| OpenHIE IHE Integration Statements | IHE Integration testing statements for OpenHIE reference software. | Wiki Page | Historic | May 2016 | Privacy and Security | OpenHIE Architecture Topic Page that makes a statement on Privacy and Security. | Wiki Page | Review in an ARB Meeting | June 2016 | FHIR Statement |
|
| Review in an ARB Meeting |
|
|
Members of the ARB
Individual | Represents (OpenHIE Sub-Community and/or Organization) |
---|
| Regenstrief, |
...
...
...
...
...
...
...
...
Responsibilities
...
Responsibilities of the ARB
Expand |
---|
title | Expand for Responsibilities |
---|
|
Based upon real-world needs, the Architecture Review Board has the following responsibilities:Champion the OHIE Community’s principles of |
---|
|
...
...
Make decisions based upon expressed needs. |
|
...
Champion the OHIE community's "Standards-based" principle.
...
the OHIE community is engaging in IHE and other interoperability specification development processes to meet implementer needs. |
|
...
Develop workflows that appropriately leverage IHE and other standards and standards processes. |
|
...
...
Where standards don’t exist, advocate for the development of future standards solutions. |
|
...
Advocate for standards-based interfaces. |
|
...
Track emerging standards development processes and evaluate their usefulness to the OpenHIE community. |
|
...
Champion the OHIE community "Interchangeability" / "Swappable" principle
Enable plurality of architecture components. | Develop and maintain an architecture roadmap on a yearly basis. |
|
...
Establish and curate the OHIE Architecture Diagram.
Support creating, curating, and publishing the OHIE Specification, including the architecture diagram, components specifications, and workflows that support patterns for data exchange. |
---|
Routinely review and publish the specification. | When changes or updates are requested, the ARB and the Community will discuss and establish consensus. | Routinely review and publish the specification. | When |
|
...
Routinely review the architecture diagram and evaluate and make decision on changes needed.
...
changes or updates are requested, the ARB and the Community will discuss |
|
...
...
...
...
Solicit feedback from implementers and other OHIE community members |
|
...
...
...
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. |
|
...
Ensure each workflow has a sponsor. |
|
...
Make architectural decisions based on the implementer’s expressed needs. |
|
...
Identify standards that best support the HIE user's needs. |
|
...
...
...
...
process for reviewing and updating the maturity of OHIE workflows |
|
...
Review sponsor assessments and work with the sponsor(s) to |
|
...
establish consensus on the assessment. |
|
...
...
, curate, and communicate OHIE testing strategy. |
---|
|
Evaluate profile and software changes and determine and prioritize testing needs. | Work with sub-communities to identify testing scenarios and cases to meet the architectural specification. | Routinely review and publish the OpenHIE Conformance Testing Specification. | Curate the OpenHIE Conformance and Compliance testing approach. | Ensure each component, workflow scenario, and test sets have a sponsor. | Build OHIE community awareness and consensus around OHIE |
|
...
Conformance testing and possible country-level use. | Use Architecture and DevOps community meetings and mailing |
|
...
lists to facilitate discussions, share information |
|
...
, gather input, and establish consensus. |
Curate Reference Software lists. |
---|
Engage each of the OpenHIE sub-communities to nominate the proposed reference software(s) of the community. | Validate the community’s evaluation of the software against the Specification and Conformance Testing Framework. | 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 |
---|
Support emerging and existing OHIE community groups with onboarding on the fundamentals of the OHIE specification and architecture | Engage in other community calls as needed/appropriate to support the introduction to the architecture. | Represent the OpenHIE architecture in LMIC and digital health community meetings and conferences as appropriate. |
|