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

Was this helpful?

Edit on GitHub
  1. Business Policy Specifications

Guidelines for Event audits

All events (claim request created, claim forwarded, data requested, authorisation, payment, etc) in the claims flow and corresponding system requests and responses between Provider TMS/Beneficiary apps, HCPs, and Payer TMS must be digitally signed and logged to ensure immutability, non-tamperability, and non-repudiability.

The HCX needs to persist the logs for a configurable (as prescribed by the law of the land) period of time so that they can be retrieved when necessary and this audit trail must be made transparently available to the customer. To ensure integrity, logs should be append-only and should not be allowed to be edited.

Next Steps

This section proposes a high-level approach that can be adopted for event audit policies for an HCX ecosystem. More deliberation is needed to arrive at model policies that can then be readily extended to be adopted by the ecosystem. Domain working groups will continue to work on developing a detailed approach for event audit policy formulation as well as a model policy for easy adoption.

PreviousGuidelines for Beneficiary Authentication by Providers/PayorsNextReference Templates

Last updated 2 years ago

Was this helpful?