HCX Protocol
v0.8
v0.8
  • Summary
  • Context
  • Introduction to HCX
  • Approach
    • Design Principles
    • Key Specifications
    • Governance
  • Technical Specifications
    • Open Protocol
      • Registries
      • Claims Data Exchange (HCX) Protocol
        • Exchange Protocol
        • Message Structure
        • API Structure
        • Error Handling
      • Data Security and Privacy
        • Transport Security
        • Message Security and Integrity
        • API Security
      • Audit and Reporting
      • Notifications
        • Terminology
        • Categories
        • API specifications
        • List of key topics
        • Future considerations
      • Third party Information sharing
    • Digital Network Policies
  • Domain Specifications
    • Domain Data Models
      • Handling Attachments
      • Handling Processing Errors
    • Terminologies (Code sets or Metadata standards)
    • Domain Specific Languages (DSLs)
    • Implementation Guide
  • Business Policy Specifications
    • Access Control (Roles)
    • Guidelines for Participant Onboarding
    • Guidelines for Grievance Redressal
      • Scope of disputes
      • Involved participants
      • Guideline process for dispute resolution
      • Guidelines for leveraging FTA
      • Next steps
    • Guidelines for SLAs and ecosystem satisfaction
    • Guidelines for Operating charges
    • Guidelines for Beneficiary Authentication by Providers/Payors
    • Guidelines for Event audits
    • Reference Templates
      • HCX - Terms of use
      • Payer-Provider addendum
      • Payer-Policyholder addendum
    • Next steps
  • Contributing to the specifications
  • Future Roadmap
Powered by GitBook
On this page
  • Objective
  • Proposed Governance Approach and Process for Specifications at Swasth during the pilot period

Was this helpful?

Edit on GitHub
  1. Approach

Governance

A proposed approach for the governance of HCX specifications

PreviousKey SpecificationsNextTechnical Specifications

Last updated 2 years ago

Was this helpful?

Objective

Specifications are fundamental to the success of the envisioned claims network. Specifications need to create consensus amongst a broad base of health system stakeholders to ensure that they can act as this common foundation. This document proposes a governance approach for the open specifications in line with outlined in the and further contextualized for HCX specifications.

Proposed Governance Approach and Process for Specifications at Swasth during the pilot period

As evident, creating functional specifications will require a robust process and deep collaboration between multiple stakeholders. The process must:

  1. Enable the delivery of universal health coverage (UHC) in India

  2. Drive healthcare outcomes and inclusion as well as patient safety and privacy

  3. *

  4. Ensure content is*

  5. Ensure content is*

  6. Establish an appropriate*

  7. Ensure ongoings*

(* Points 3 to 7 have been adopted from the must-have criteria followed by HL7)

Hence, the development and maintenance of standards must follow an open and consultative process with widely inclusive, committed groups that can bring together necessary skills, viewpoints, and networks.

​The HCX community proposes to maintain and improve specifications through an inclusive, open, and consultative process. The broad outline of the process would be:

  1. ​ would establish a governance council with representation from across the healthcare ecosystem (insurance, TPA, patient groups, 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 topic-specific working groups

  3. Working groups will create clear criteria for the evaluation of a proposal

  4. Ideas for new specifications/enhancement is proposed by one of the group members

  5. The working group evaluates the idea

  6. If approved, development/enhancement begins

  7. Resultant specifications/enhancement will be reviewed by peer group for implementability

  8. The resulting specifications/enhancement will be put out for public consultation

  9. The working group reviews public consultation feedback and incorporates the necessary changes. (Any inputs not included will receive responses too)

  10. Specifications will be published for wider adoption

  11. Specifications will be maintained in open repositories like GitHub, Confluent (or similar) based on the nature of the output

  12. Specifications are made available through most permissible licenses like MIT or Creative Commons

  13. Swasth will also create a fully independent ethics and conflicts committee to act as an appellate authority for all our work, including stewardship of specifications

  14. All deliberations, minutes, and documents produced by the ethics and conflicts committee, specifications governance council, and working groups will be made publicly available

key design principles
National Digital Health Blueprint
Foster consensus
fit for purpose
implementable
implementer community
maintenance of the standard
Swasth