As described in Key Specifications, Open protocol deals with the technology backbone for the Health Claims Data Exchange. Sections below define the key elements of the proposed Health Claims Data Exchange Protocol.

All communications between health claims exchange(s) and participating entities are expected to be done using Transport Layer Security. Therefore all APIs are expected to work only as HTTPS in the production environments.

In order to fulfil architectural principles listed in Health Claims Data Exchange - Open Specifications, the protocol needs to consider the following key design elements:

• The protocol must be designed to support the asynchronous exchange of information to support the scale and asynchronous nature of processes in the industry

• The protocol must support the federated deployment of multiple HCX instances.

• In order to ensure the security and privacy of sensitive data

  • The protocol must allow for separation of transport (and any other common information) from sensitive information in the respective flows

  • The protocol must provide for encryption, signing, and auditing of relevant information

• The protocol should allow creating unique identifiers for each message exchange

• The protocol should allow related multiple messages that are part of a single business flow

• The protocol should allow using existing registries for key entities - beneficiary, provider, and payor with a facility to extend them for the specific use case

• The protocol should be designed to allow for the inclusion of the new types of use cases

• The protocol should be designed to allow extending a use case as per the need of the use case/program (for example, a particular government scheme or innovative health financing solution may need different information about the beneficiary, provider, or intervention)

Based on these principles and design considerations, the next section lists key components of the HCX protocols.

Questions for Consultation

Question 1

Please review Key Design Considerations and suggest if there are other considerations that could help in the better design of Open Protocol.

This section focuses on digital specifications that are needed to realize the health claims network - open protocol and digital network management policies.

Details of domain data models and business policies are covered in the next section here.

Given the sensitive nature of the information involved during claims processing - personal details, health-related information, etc., it is imperative that the data is kept secure during the exchange process (security if data while stored at sender and receiver is expected to be as per the prevailing data security regulation of the data storage).

There are many language specific libraries available that can help you implement the required encryption/signing/verification that is described above.

In order to achieve this, various approaches are defined in the subsequent sections.

HCX instances are expected to log each API call received along with the non encrypted details (domain headers, sig/enc algorithm details, sender & recipient details) and status of signature verification.

Key Requirements:

• HCX instances should provide reports against the audit logs for different actors - payors, providers, beneficiaries, regulators, observers. Each HCX instance shall publish the list of reports supported by that instance and also define the level/details of information in each report.

• The audit information stored should be made available through an API, so that the participating systems can query the audit log related to them.

• Each HCX instance shall define an archival policy for retention & deletion of audit logs. The policy shall also define the process for accessing the logs after archival, if the HCX instance has support for it.

• It is recommended for HCX instances to have a configuration to control the amount of information that gets stored in the audit logs.

Questions for Consultation

Question 1

Apart from the list mentioned here, what other audit and reporting requirements would you expect HCX to fulfil?

TO ensure that sensitive information in the actual domain objects is not accessible even to the HCX, protocol requires the payload defined by the domain data specifications to be encrypted using a separate asymmetric encryption key of the final recipient established at the time of participant onboarding into the registry. API then carries the encrypted value of the payload. The payload encryption is expected to be performed using JSON web encryption RFC7516 as per algorithm and enclosed values fixed in the protected headers section above. At this point in time, no unprotected headers are envisioned in the HCX protocol. We also do not envision multiple recipient delivery in the current version of the HCX protocol.

Message Encryption

The high-level steps to encrypt the payload using the public key of the final recipient are:

1. Find out the public key of the recipient through registry lookup on HCX.

2. Let JWE protected header be = BASE64URL(UTF8((Registered JOSE headers) U (HCX Protocol Headers) U (HCX Domain Headers)). Please note that initial version of HCX protocol requires following JOSE headers: {"alg":"RSA-OAEP","enc":"A256GCM"}

3. Generate a random Content Encryption Key (CEK) as per the encryption algorithm.

4. Encrypt the CEK with the recipient's public key using the RSAES-OAEP algorithm to produce the JWE Encrypted Key.

5. Base64url-encode the JWE Encrypted Key.

6. Generate a random JWE Initialization Vector.

7. Base64url-encode the JWE Initialization Vector.

8. Let the Additional Authenticated Data encryption parameter be

ASCII(BASE64URL(UTF8(JWE Protected Header))).

1. Perform authenticated encryption on the plaintext with the AES GCM algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value, requesting a 128-bit Authentication Tag output.

2. Base64url-encode the ciphertext.

3. Base64url-encode the Authentication Tag

4. Assemble the final representation in flattened JSON serialization (Section 7.2.2 of RFC7516):

{
  "protected":"<integrity-protected header contents from step 2 above>",
  "encrypted_key":"<encrypted key contents from step 5 above>",
  "aad":"<additional authenticated data contents from step 8 above>",
  "iv":"<initialization vector contents from step 7 above>",
  "ciphertext":"<ciphertext contents from step 10 above>",
  "tag":"<authentication tag contents from step 11 above>"
}

Message Decryption

The high-level steps to decrypt and verify the integrity of the payload using the private key of the final recipient are:

1. From the received JSON serialized JWE token, Base64url decode the encoded representations of the JWE Protected Header (protected), the JWE Encrypted Key (encrypted_key), the JWE Initialization Vector (iv), the JWE Ciphertext (ciphertext), the JWE Authentication Tag (tag), and the JWE AAD (aad), following the restriction that no line breaks, whitespace, or other additional characters have been used.

2. Verify that the octet sequence resulting from decoding the encoded JWE Protected Header is a UTF-8-encoded representation of a completely valid JSON object conforming to RFC 7159; let the JWE Protected Header be this JSON object.

3. Let the JOSE Header be the JWE Protected Header. Verify that the resulting JOSE Header does not contain duplicate Header Parameter names.

4. Determine the Key Management Mode employed by the algorithm specified by the "alg" (algorithm) Header Parameter.

5. Verify that the JWE uses a key known to the recipient.

6. Decrypt the JWE Encrypted Key to produce the CEK. The CEK MUST have a length equal to that required for the content-encryption algorithm.

7. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE Protected Header)). This protected header is (Registered JOSE headers) U (HCX Protocol Headers) U (HCX Domain Headers).

8. Let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header).

9. Decrypt the JWE Ciphertext using the CEK, the JWE Initialization Vector, the Additional Authenticated Data value, and the JWE Authentication Tag (which is the Authentication Tag input to the calculation) using the specified content-encryption algorithm, returning the decrypted plaintext and validating the JWE Authentication Tag in the manner specified for the algorithm, rejecting the input without emitting any decrypted output if the JWE Authentication Tag is incorrect.

Participating systems are expected to follow best practices guidelines as in RFC8725 to ensure the security of the payload.

It is recommended to rotate these encryption keys once every year and mechanisms implemented for the providers/payers/HCX to intimate the ecosystem about the potential compromise of the keys.

Here is a sample of the set of libraries that you can explore:

1. Bouncy castle

2. Openssl

3. NaCl

4. Libgcrypt

5. PyNaCl

6. TweetNaCl

Questions for Consultation

Question 1

This section suggests JSON Web Encryption as per RFC7516 as the mechanism for payload security and integrity. Which alternative mechanism for payload security and privacy would you explore for HCX? Kindly provide the pros and cons of the alternative mechanism.

Question 2

In addition to the best practices mentioned in RFC8725, which other best practices/guidelines would you suggest to HCX participants for data security and privacy?

The protocol defines an API key-based security for authentication and authorization of the API calls between the participating systems and the HCX gateway. HCX instances have to generate the API keys in the form of JWT tokens (RFC7519) and shall mandatorily set an expiry time for all the generated tokens.

In future versions, HCX instances may support JWTs issued by other system identity providers, e.g. Health Facility Registry’s IDP.

Securing HCX Gateway APIs

All participant systems (e.g.: providers, payers) should obtain an API key from the HCX gateway with which it identifies itself to the gateway. When calling any API on the HCX gateway, the participant system should pass the API key as part of the 'Authorization' http header.

Steps to obtain the API key:

After a successful verification and onboarding of a participant system onto the participant registry, the HCX instance managing the registry shall share the following details via email, SMS, or both with the participant system:

• client_id: this is the identifier of the participant in the participant registry.

• client_secret: a unique secret is generated for the participant by the HCX instance. The client_secret value shall be stored in the participant registry in an encrypted format and shall not be sent in the registry APIs.

The participant system can call ‘/token/generate’ API along with the client_id and client_secret they have received to obtain the API key.

POST /token/generate
Content-Type: application/json
Request-Body:
 {
   "client_id": "client_id received by the participant",
   "client_secret": "client_secret received by the participant"
 }

HCX instance would respond with the API token upon successful validation of the client_id and client_secret values:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store
Response-Body:
 {
   "access_token": "the API key, a JWT access token",
   "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
   "token_type": "Bearer",
   "expires_in": 300
 }

JWT Token Structure:

API keys are expected to be in JWT format and signed as per JSON web signature (RFC7515). The API key should have three elements separated by periods (.): BASE64URL(UTF8(JOSE Header)), BASE64URL(JWS Payload), and BASE64URL(JWS Signature).

• JOSE Header should be a JSON with the following values:

{
  "typ":"JWT",
  "alg":"HS256"
}

• JWS Payload should be a claim set containing the mandatory claims jti, iss, sub, iat and exp.

  • jti - unique identifier for the JWT

  • iss - HCX instance identifier

  • sub - client_id of the participant

  • iat - unix timestamp at which the JWT is issued

  • exp - the expiration time after which the JWT must not be accepted for processing

• JWS Signature must be computed in the manner defined for HS256 algorithm over the input ASCII(BASE64URL(UTF8(JOSE Header)) || '.' || BASE64URL(JWS Payload)) using the client_secret value of the participant.

Revoking API Keys

HCX instances can revoke the API key of a participant by generating a new client_secret and updating it in the participant registry. The participant system has to generate a new API key by calling the ‘/token/generate’ API with the new client_secret value.

Securing Participant System APIs

HCX instances while making the calls to the participant system will use a self-generated JWT token with the following elements:

• JOSE Header should be a JSON with the following values:

{
  "typ":"JWT",
  "alg":"RS256"
}

• JWS Payload should be a claim set containing the mandatory claims jti, iss, sub, iat and exp.

  • jti - unique identifier for the JWT

  • iss - HCX instance identifier

  • sub - same as iss claim, HCX instance identifier

  • iat - unix timestamp at which the JWT is issued

  • exp - the expiration time after which the JWT must not be accepted for processing

• JWS Signature must be computed in the manner defined for RS256 algorithm over the input ASCII(BASE64URL(UTF8(JOSE Header)) || '.' || BASE64URL(JWS Payload)) using the private key of the HCX instance.

Participant systems should validate the API key signature using the public key of the HCX instance.

Questions for Consultation

Question 1

This section suggests JSON Web Tokens as per RFC7519 as the mechanism for API security. Which alternative mechanism for API security would you explore for HCX? Kindly provide the pros and cons of the alternative mechanism.

As indicated in the overall message flow diagram, the exchange platform will be the routing engine that will be responsible for receiving the data from either participant (provider, payor, another HCX instance, ...), and performing necessary validations, and forwarding it to the intended recipients.

Terminology

1. Request - Initiation of the flow by the sender by passing relevant payload in the message structure defined by this protocol. Requests may travel from Sender to the Receiver through a relay of HCX instances.

2. Response - Response/reply by the recipient of the request by passing relevant response payload defined by this protocol. Responses may also travel from the “original request message” recipient to the “original request message” sender through a relay of HCX instances. The key difference here is that a response is always sent as an earlier event received from the HCX instance.

3. HCX instance - A runtime of the HCX platform that performs the role of message receiving and forwarding on behalf of senders and receivers. Based on the use case, any participating party may act as the sender (thereby a requester), or a receiver (thereby a recipient). E.g. for the cashless claims use cases defined so far - Providers will be the senders in case of CheckEligibility, PreAuth and ClaimSubmission use cases (and the payers will be recipients), while Payers will be the sanders in case of PaymentNotice (and the providers will be recipients).

4. Message - HCX protocol transfers a Message that contains a transport envelope and the content as per the use case.

   1. Transport envelop is a set attribute that carries the transport information for HCX to reliably forward the message to the destination

   2. Content would have two parts:

      1. Business headers - any domain or use case specific information which may not be necessary for the transportation but allows more information about the payload, e.g. type of the payload

      2. Payload - Domain object defined for the pertinent use case. Usually, this data will be encrypted using the recipient's key to ensure that HCX instances cannot view this data.

5. Senders and Receivers - Two systems participating in the information exchange. They may also be referred to as client/server as per current industry terminology. E.g. Provider(s) are senders in claims flow use case, and Payor(s) are senders in Payment Notice use case in the flow diagram above.

Overall Message Flow Diagram

HCX protocol is designed for the exchanges to work in an asynchronous manner (like SMTP), therefore each use case will be completed in a cycle of messages as shown below:

Exchange Protocol

Sender to HCX (Leg 1)

• The sender (originator of the communication) sends the initial message to its preferred HCX instance.

• HCX validates the status of the sender and the next intended recipient (maybe another HCX instance) on its registries.

• HCX then performs required signature verifications etc before responding with an acknowledgement to the sender.

• It then forwards it to either the end recipient (if registered with the same instance) or the next HCX in the chain.

Steps 1 and 7 in the above diagram as examples of this leg.

HCX to Receiver (Leg 2)

• Final HCX in the relay chain (could be the original HCX itself) checks the status of the recipient on its registries,

• performs needed verifications and forwards the message to the recipient.

• The recipient acknowledges the receipt of the message.

Steps 3 and 9 in the above diagram as examples of this leg.

Receiver to HCX (Leg 3)

• The recipient (receiver of the original request message) sends the response message to its preferred HCX instance.

• HCX validates the status of the recipient and original sender (maybe another HCX instance) on its registries.

• HCX then performs required signature verifications etc before responding with an acknowledgement to the recipient.

• It then forwards it to either the initial sender (if registered with the same instance) or the next HCX in the chain.

Steps 4 and 10 in the above diagram as examples of this leg.

HCX to Sender (Leg 4)

• Final HCX in the relay chain (could be the original HCX itself) checks the status of the original sender on its registries,

• Performs needed verifications and forwards the response message to the sender.

• The sender acknowledges the receipt of the response message.

Steps 6 and 12 in the above diagram as examples of this leg.

Relays

In case Sender and receiver are listed/registered on different HCX instances, there may be relays between the HCXs. Steps 2, 5, 8 and 11 in the above diagram may involve such relays. Appendix A provides an example of a provider-payor use case with a relay between two HCXs.

Message Structure

To facilitate safe, secure, and reliable message exchanges through HCX, its message payload needs to be designed in a manner that separates the actual use case-specific information (payload) from transport and generic domain-specific information (headers). To achieve this, HCX messages can be structured in line with JWE tokens as below (value in bracket are the corresponding JSON keys as per JWE):

1. Protected headers (protected) - A set of attributes that provide transport, security, message integrity and summary information about the message being exchanged.

2. Encrypted Payload (ciphertext) - Payload containing the relevant domain entity (eObject) as prescribed for the use case by the domain specifications. This needs to be encrypted so that HCX cannot read this.

3. Signature (tag) - Digital signature on the protected header and the payload of the message to ensure its integrity.

4. Other JWE elements like iv (Initialisation Vector for the algorithm), aad (additional authentication data), and encrypted_key (Content Encryption Key)

HCX expects the resulting JWE token to be JSON serialised. The following subsections detail each of these message elements:

Protected Headers

Protected headers contain information that helps exchanges to identify senders, receivers of the message, perform integrity checks, audits and routing functionality. Header values are posted in clear and never contain any Personally Identifiable Information (PII) about the patient. HCX protocol uses JWE protected headers for such information to ensure these are not tampered with by the intermediate gateways. Protected Headers for HCX will be the union of the following three header categories:

Registered JOSE Headers

JSON Web encryption header as per RFC7516. For HCX V1, this is proposed to be fixed to:

{"alg":"RSA-OAEP","enc":"A256GCM"}

HCX Protocol Headers

Used as private headers as per RFC7516 section 4.3. Please note that all the parameter names are appended with “x-hcx-” to avoid a collision.

The following table provides the protocol related header elements in the claims exchange:

HCX Domain Headers

JSON object containing a map of domain-specific header values as proposed in domain data specifications. E.g. For claims use cases, domain specs may decide to populate the total claimed amount, list of diagnostics/procedures. Please note that all such parameter names must follow the naming convention x-hcx-<use_case_name>-<parameter_name>, where

• use_case_name = short name (<16 chars) given to the use case by domain working group, it is advisable to keep it the same as the one in API’s URI path

• Parameter_name = short name (<32 chars) given to the parameter

Therefore the protected headers will be:

Protected Headers = (Registered JOSE headers) U (HCX Protocol Headers) U (HCX Domain Headers)

Payload

Use case-specific base64 encoded, encrypted payload as defined in Domain Data specifications. This can be thought of as a private claim in JWT terminology. JSON web encryption as defined in RFC7516 to be used for encrypting the payload with “alg” and “enc” as defined in the JOSE header above.

E.g. In the current cashless claims scenario, domain working groups have decided the payload to be an FHIR bundle of the appropriate type. Therefore the payload will be an encrypted FHIR bundle as defined in the domain data specs.

Signatures

As per RFC7516, cryptographic mechanisms used in JWE encrypts and provides integrity protection to encrypted payload and protected headers using Authenticated Encryption with Associated Data (AEAD), hence additional signatures are not needed for message integrity protection.

API Structure

Based on the above protocol definition and the message structure, each use case API in the HCP ecosystem is expected to follow the following pattern for the onward and return journey of the use case message:

<transport_protocol>://<server_address>/<protocol_version/><resource_name>/<action|on_action>, where

• transport_protocol - for HCX V1 purpose it will always be https

• server_address is the address of the server on which the API is called (an HCX for payor/provider or a payor/provider/HCX for an HCX)

• protocol_version - API version for the current protocol to help support protocol transitions

• resource_name is the name of the domain resource that the API is serving. E.g. for cashless claims, it may be “claims”, “coverage eligibility”, etc. based on the use case.

• action is the action sought within the context of that resource

• on_action represents the callback from the receiving system for responding to the original message

Keeping this pattern in mind, in the current cashless use case following APIs are expected to be supported.

Please note that search APIs are expected to support search parameters as detailed in the domain data specifications. For FHIR based entities this is expected to be clearly published in the corresponding implementation guides. Visibility and availability of the attributes in the search result payloads are also expected to be defined in domain data specifications.

CoverageEligibility

• Eligibility check

  • /coverageeligibility/check (provider->HCX, HCX->payor)

  • /coverageeligibility/on_check (payor->HCX, HCX->provider)

Claims

• PreAuth submission

  • /preauth/submit (provider->HCX, HCX->payor)

  • /preauth/on_submit (payor->HCX, HCX->provider)

• PreAuth Search

  • /preauth/search (provider->HCX, HCX->payor)

  • /preauth/on_search (payor->HCX, HCX->provider)

• Claim submission

  • /claim/submit (provider->HCX, HCX->payor)

  • /claim/on_submit (payor->HCX, HCX->provider)

• Claims Search (Also supports status search)

  • /claim/search (provider|regulator|auditor->HCX, HCX->payor)

  • /claim/on_search (payor->HCX, HCX->provider|regulator|auditor)

Payments

• Payment notice and acknowledgement

  • /paymentnotice/request (payor>HCX, HCX->provider-)

  • /paymentnotice/on_request (provider->HCX, HCX->payor)

• Payment Search (Also supports status search)

  • /paymentnotice/search (provider->HCX, HCX->payor)

  • /paymentnotice/on_search (payor->HCX, HCX->provider)

Following OpenAPI 3.0 specification details these APIs in detail.

Questions for Consultation

Question 1

Please review the Exchange Protocol and provide comments/suggestions on its comprehensiveness. Kindly provide aspects of the protocol would you find challenging and suggestions to overcome those challenges.

Question 2

While the consultation paper covers only interactions between the provider and payer, and the interactions with the beneficiary will be detailed post public consultation, what additional workflows do you think must be considered?

HCX registries will act as a source of truth for participant information on the platform. These may be extended from/link to already existing registries in the ecosystem, e.g. registry may extend from National Health Facility Registry provided by NHA. The benefit of extending from an existing registry would be:

• Easy maintenance of base data at the source registry

• The extended registry only needs to maintain additional/supplementary information pertaining to its use case

• Better interoperability

Keeping with the key design principles listed above, registries on HCX will strive to be minimalistic, self-maintainable, support non-repudiability, accessible through OpenAPIs, Extensible and evolvable, and designs for data privacy and security. All registries on the HCX platform will minimally provide the following APIs:

• Create

• Update

• Search

• Delete

• Cancel

Please note that onboarding of the actors in the registry will take place through workflows defined by domain groups and may change over time, therefore the access to the data modification APIs would be controlled by the HCX instance provider and used as part of the onboarding process.

Participating Organisations/Systems Registry

This registry stores key details about the participants on the exchange who can exchange data through it. It may link with data on the HFR registry and will have fields necessary to facilitate claims data exchange with providers. Proposed attributes of the registry are:

User Registry

While the exchange protocol by itself may not need to focus on the human user (as the exchange is between systems), operational management of the exchange infrastructure may require administrative infrastructure that may necessitate a registry for operational users from organizations running HCX as well as participating organizations. Following are the proposed attributes for the User registry:

Following OpenAPI 3.0 document describes these registries and the associated APIs.

Questions for Consultation

Question 1

Please review the proposed participant registry details and provide comments on whether the given attributes are a minimal sufficient list for the functioning of the HCX? What other attributes may be included? What should be the cardinality of those attributes?

Question 2

Please review the proposed participant registry details and any other attributes advised in Question 2 above. Please provide your comments on the data privacy or security aspect of these attributes?

Question 3

Please review the proposed user registry details and provide comments on whether the given attributes are a minimal sufficient list for the functioning of the HCX? What other attributes may be included? What should be the cardinality of those attributes?

Question 4

Please review the proposed user registry details and any other attributes advised in Question 3 above. Please provide your comments on the data privacy or security aspect of these attributes?

Scenarios for Cross gateway exchange

The cross gateway communication will be required in the following scenarios –

1. When a provider is onboarded in a gateway instance but the payer for that health policy scheme is registered in another gateway instance.

2. If a beneficiary enrolled in health policy took treatment in a network hospital in another state and that hospital is onboarded in a different gateway instance than the payer.

3. For top-up cases, the providers and payers are registered in different gateway instances and in such scenarios primary insurance is handled by one payer in one gateway instance but the secondary insurance is handled by another payer registered in a different gateway instance.