Governance

Governance principles

Openness and Inclusivity

The governance framework promotes open participation, welcoming diverse perspectives and contributions from all community members.

Transparency

The decision-making processes, rules, and activities of the governance body are transparent and accessible to the community. Important information, discussions, and updates are shared openly.

Consensus Building

The community strives to reach a consensus through open dialogue and respectful discussions. Major decisions are made collectively, considering the viewpoints and expertise of community members.

Accountability

The governance body is accountable to the community. It ensures that decisions and actions are aligned with the community’s best interests and the core principles of the HCX Protocol.

Adaptability

The governance framework is designed to evolve and adapt as the community grows and the protocol develops. It allows for the incorporation of new ideas, emerging technologies, and changing needs.

Protocol design principles

Open

Specifications must be designed to be open to support technology and promote vendor neutrality. They must be published under the most unrestricted license (Creative Commons or MIT license) as applicable to enable wider ecosystem participation and foster innovation through extensibility. Being open also helps leverage wider ecosystem expertise at the time of designing and evolving the specifications.

Evolvable and Extendable

They must be designed to be evolvable over a period of time thereby helping adapt to changing needs. By being extendable they provide ecosystems with the capability to leverage these specifications for their context while maintaining interoperability.

Interoperability

Given that the key role of HCX specifications is to create and enhance interoperability between diverse ecosystem participants, any feature added to the specification must ensure that it increases interoperability between implementations.

Minimalistic and Inclusive

Minimalism is crucial to ensuring that specifications enable and do not restrict innovation or inclusion. In order to be inclusive while maintaining minimalism, before including any new feature/enhancements in the specification, proposers and reviewers should ask the following questions: 1. Do we need it? and, 2. Do we need it now? If the answer to both these questions is “Yes” then that feature may be included in the specification.

Unification over standardisation

There would be situations when not all the features or requirements of the specifications may be standardised (at least in the near term), and may vary with context and ground realities. In such cases, the goal of the specification should be to prioritise and harmonize those requirements/features such that there is an integrated set of requirements/features all stakeholders can agree with or at least accept. For example, insurance product-and-services value-set may be defined differently for different contexts (social vs private), then the specification should allow for the ecosystem to use any of these definitions based on context, and allow for the standardisation to happen as a natural consequence of ecosystem adoption rather than a forced adoption.

Balance data privacy and security with data empowerment

They must provide the mechanisms to keep the data secure (e.g. mandating SSL for data in transit, requiring relevant data to be encrypted) and private (e.g. consent-based data access) while still allowing for mechanisms to exchange needed information between trusted parties.

Provide for non-repudiability

They must provide mechanisms to view and verify attribute trails - who accessed or updated what and when - through mechanisms like digital signatures and tamper-proof audit trails.

Unbundled

They should strive to break down the complexity of the domain into multiple simple pieces thereby resulting in multiple simple specifications which can be bundled in a modular manner to suit the needed context and help solve dynamic challenges.

Governance Approach

Governance Body

The governance body comprises elected representatives from within the community and the anchor organisation (Swasth). These representatives serve as stewards of the protocol and work collaboratively to make decisions on behalf of the community. They are responsible for coordinating efforts, overseeing technical developments, establishing standards, and resolving governance-related matters.

Community Engagement:

The community is encouraged to actively engage in the governance process. Community members can contribute through discussions, proposing ideas, submitting feedback, participating in working groups, and taking part in the decision-making process. Regular updates, community meetings, and open forums provide opportunities for community members to voice their opinions and shape the direction of the protocol.

Continuous Improvement:

The governance structure is designed to continuously improve and refine its processes. The community regularly assesses the effectiveness of governance mechanisms, incorporating feedback and implementing improvements as necessary. This ensures that the governance framework remains robust, responsive, and aligned with the evolving needs of the community.

Goevrnance Process

The broad outline of the process would be:

1. Swasth will form a core governance council for specifications with representation from across the insurance ecosystem (insurance, TPA, policyholder groups, service provider representatives, small provider associations, academic institutions/experts in the area, the regulator, and relevant public bodies).
2. The governance council will facilitate the formation of domain-specific working groups, which will create clear criteria for the evaluation of a proposal.
3. Ideas for changes/enhancement is proposed by one of the group members.
4. The working group evaluates the idea.
5. If approved, development/enhancement begins.
6. Resultant specifications will be reviewed by a peer group for implementability.
7. Specifications will be maintained in open repositories GitHub, Confluent (or similar), Terminology servers etc. based on the nature of the specification.
8. The resulting specifications/enhancement will be put out for open consultation.
9. The working group reviews public consultation feedback and incorporates the necessary changes. (Any inputs not included will receive responses too).
10. Specifications shall be published for wider adoption.
11. Specifications are made available through most permissible licenses like MIT or Creative Commons.
12. In the due course of time, a fully independent ethics and conflicts committee to act as an appellate authority for all protocol-related work, including oversight of the governance body.
13. All deliberations, minutes, and documents produced by the ethics and conflicts committee, specifications governance council, and working groups will be made publicly available.