Thoughts following last month's OHIE Leadership Call

Community Growth Governance / Administration
1

Hi everyone!

I wanted to thank everyone for the rich conversation last month around how to evolve our community’s governance and organizational structure. While we started off focusing specifically on the “leadership team”, we quickly all realized that the conversation is more difficult to have unless we take a broader step back and look at our growing community needs as a whole.

So, I share with you a straw man, based upon a lot of the feedback received from you all. We can talk further about this over the months to come, and hopefully put some of this into effect before next year’s annual meeting. :slight_smile:

Steering Committee:

  • Purpose(s): Provide fundamental guidance around community priorities, and areas of emphasis. The “strategic” leadership of the community.

  • Membership: Chaired by MOH representative, and constituted of over 50% MOH/MOH-delegated participants. Other participants are direct beneficiaries of community proceeds.

  • Responsibilities: Approve yearly community operating plan, review/guide quarterly community progress reports

  • Authority: More strategic than operational authority… also responsible for it’s own membership and group process

Advisory Committee:

  • Purpose(s): Provide routine recommendations to both the Steering Committee and the Leadership Team, bring organizational and resource-raising SME to the OpenHIE community.

  • Membership: Varied, but typical membership might consist of philanthropy/aid representatives, SDO representatives, academics, and other SMEs as the time necessitates.

  • Responsibilities: Convene regularly to provide advice and counsel to OpenHIE community strategic and operational leadership

  • Authority: Mostly advisory, can influence but not direct.

Leadership Team:

  • Purpose(s): Oversee the overall daily operations and direction of the OpenHIE community. The “operational leadership” of the community.

  • Membership: Community members, and representatives of partnering organizations that have made substantive contributions to the community. Fixed representation by: Project Lead, Chief Architect, Community Manager, and other key community roles.

  • Responsibilities: create and refine yearly operational plans, create/modify community structure, determine leadership roles, oversee community financial resources

  • Authority: makes most all routine structural, resourcing, and financial decisions (ie, approve new workflows, meeting locations, partner organization approval, etc)

Architectural Review Board:

  • Purpose(s): Oversees all technical and standards-based products of the community. The “technical leadership” of the community.

  • Membership: Chaired by Chief Architect. Fixed membership consists of representatives from each of the component sub-communities. Also consists of SME membership per the needs of the fixed membership.

  • Responsibilities: produce/manage OpenHIE Architecture Specification, Workflow Specification Releases, Functional Requirement Specifications, and guides overall technical endorsement activities.

  • Authority: makes most technical decisions on behalf of the community

Sub-community Leadership Team:

  • Purpose(s): Provide direction, oversight, project management for component sub-communities

  • Membership: At least two leaders with historical domain expertise around subcomponent, and ideally formally related to partner organizations.

  • Responsibilities: Respond to implementer and ARB needs.

  • Authority: Group process, meeting timing, functional requirements for corresponding component.

Interest Group Leadership Team:

  • Purpose(s): Drive community process around HIE use cases and/or other areas of emerging interest to the community.

  • Membership: Members self-select based on their level of interest in defining, quantifying or qualifying new subjects of interest for OHIE to consider as part of the platform-based approach.

  • Responsibilities: Identify subjects of interest, qualify the value of the subject area and the relevance to existing or new OHIE initiatives, and refine understanding of the subject area to a point where OHIE can incorporate that understanding in an actionable way.

  • Authority: Group process, meeting timing, work-plan for subjects of interest and actionable deliverables.

2

Hello Paul:

This is a very sound straw man. Two comments, one very general, and the other just positing some details for the last category “Interest Group Leadership Team:”

First comment: while perhaps naturally apparent to veterans of the group, I think it would help if OHIE declared the scope of its work and it’s intended or aspirational “reach” in terms of regions and countries. For example, while I think the composition of the Steering Committee is great, and initially would be MoH representatives from countries where OHIE members are active, but what is the ambition mid and long term for the org. I know that the participating membership is global in scope, however even if you can provide the characteristics of countries this open approach can be most beneficial to it would be helpful to the various levels of the governance structure as well as be inviting to new participating ministries and country initiatives.

Second just some additional wording for the last category (this is first thoughts):

Interest Group Leadership Team:

** Purpose(s): Drive community process around HIE use cases and/or other areas of emerging interest to the community.*

** Membership:* Members self-select based on their level of interest in defining, quantifying or qualifying new subjects of interest for OHIE to consider as part of the platform-based approach.

** Responsibilities:* Identify subjects of interest, qualify the value of the subject area and the relevance to existing or new OHIE initiatives, and refine understanding of the subject area to a point where OHIE can incorporate that understanding in an actionable way.

** Authority:* Group process, meeting timing, work-plan for subjects of interest and actionable deliverables.

Ron P.

3

Thanks Ron! :slight_smile: I will work on the first comment and get back to you. This has been written and agreed to a few different times, but it’s due a refresh.

On the second, I’m just going to lift what you’ve done for us and add it as an edit! :slight_smile:

Thanks!

4

Here are the current Architecture roles and responsibilities:

  1. Champion the OHIE Community’s principles of “Adaptable” / “implementable”, “Standards-based” and “Interchangeable” / “Swappable”.
  • 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.
  1. 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: when changes or updates are requested, the ARB and the Community will discuss and establish consensus.
  • HOW: 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: Maintain a process for developing workflows
  1. Determine, 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.
  1. 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.
  1. 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.
  1. 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.