HCX Protocol
v0.9
v0.9
  • Summary*
  • Glossary*
  • Context
  • Introduction to HCX*
  • Technical Specifications
    • Open Protocol
      • Registries*
        • QR Code Specifications*
      • Claims Data Exchange (HCX) Protocol
        • Message Flows*
          • Primary Message Flow
          • Additional Message Flows
            • Redirect
            • Forward
            • Intra Cycle Communication*
              • Seeking Supporting Information
              • Seeking Beneficiary Consent
              • Seeking Account Information
            • Relay
            • Third party Information sharing
          • Notifications
            • Categories
            • List of key topics
        • Message Structure
        • API Specifications*
          • Registry APIs
          • Primary Flow APIs
          • Supporting APIs
          • Notification APIs
        • Error Handling
      • Data Security and Privacy
        • Transport Security
        • Message Security and Integrity
        • API Security*
      • Audit and Reporting
    • Digital Network Policies
  • Domain Specifications
    • Domain Data Models
      • Handling Attachments
      • Handling Processing Errors
    • Terminologies
    • Domain Specific Languages (DSLs)
    • FHIR Implementation Guide*
  • Business Policy Specifications
    • Access Control (Roles)*
    • Guidelines for Participant Onboarding*
      • Sandbox process
      • Production onboarding (Go live)*
      • Potential De-boarding scenarios
    • 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
  • Use cases*
    • OPD
      • Typical Workflows
        • Cashless
        • Reimbursement
      • Mapping to the HCX protocol
        • Cashless
        • Reimbursement
    • IPD
      • Typical Workflows
        • Cashless
        • Reimbursement
      • Mapping to the HCX protocol
        • Cashless
        • Reimbursement
    • Implementation Considerations
  • Contributing to the protocol
  • Future Focus Areas*
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. Technical Specifications
  2. Open Protocol
  3. Claims Data Exchange (HCX) Protocol
  4. API Specifications*

Notification APIs

Details of APIs that facilitate notifications through HCX.

PreviousSupporting APIsNextError Handling

Last updated 1 year ago

Was this helpful?

Key Design Considerations

In order to make notifications secure, lightweight and easily deliverable and actionable, following constraints are proposed:

  • Reuse existing protocol features wherever possible

  • Limit the Maximum size of notification payload

  • Templatized messages based on notification topic to encourage semantic interoperability

Following key APIs are envisioned to enable notifications in HCX. Full API specifications in OpenAPI 3.0 format are available .

List of Supported Notifications

Get the list of notification types supported by the network along with their classification and access control parameters. Key attributes of notification type master data are:

Attribute/Property

DataType

Description

title

String

Title of the notification

description

String

Details about the notification

sender

List<String>

List of roles who can send this notification.

recipient

List<String>

List of roles who can subscribe to this notification.

topic_code

String

Unique code for the notification topic

category

String

Category of the notification as detailed above - network (broadcast & target), participant, use_case

priority

int

Default priority assigned to the topic. 0 means highest, positive integer would carry the respective relative priority. Negative would be that the topic is disabled. Relative order of category for different message categories is recommended to be use_case > participant > network

API details

/notification/list

As evident sanctity of the master list of notification is important for effective notification service on the network, hence it is recommended that master list of the notification is given the same treatment as an operator would give to its code for the switch.

Subscription to notifications

APIs to subscribe or unsubscribe to a notification type based on its subscribability. For Use case type notifications, this API is also expected to be implemented by the participating systems supporting such notifications. Key attributes of the subscription model are:

Column

DataType

Description

subscription_id

UUID

Unique identifier for the subscription.

participant_code

String

Identifier of the subscriber.

topic_code

String

Identifier of the notification topic.

status

Integer

Status of the notification. Values: 1 - active, 0 - inactive, -1 - pending for approval.

subscription_data

Object

Encrypted details subject of subscription for the use_case category

subscribed_on

timestamp

expires_on

timestamp

Timestamp when the notification expires. Can use a reasonably long period to indicate forever valid notifications, however it is recommended that subscriptions are periodically renewed.

API details

Input would be the topic_code and payloads containing use case related details wherever applicable. The final response would be returned asynchronously.

/notification/subscribe

/notification/unsubscribe

/notification/subscription/list

Trigger notifications

APIs to trigger the actual notification that would be used by the participants (including HCX switch) to notify the intended participants. This API would be used in two modes:

  1. by HCX switch on participants to deliver the final notification (of all categories)

  2. By participants on HCX to trigger delivery notifications of participants and use case categories on the intended recipients.

Proposed attributes of notification header and payload:

Column

DataType

Description

notificationId

String (UUID)

Unique id assigned by the initiator to the notification

sender

String

Participant code of the notification initiator

category

String

Category of the notification as defined by the specs - network, participant or use_case

topic

String

Topic of notification as defined in the master list of notifications

recipientCodes

String[]

Participant code of the recipient(s) of the notification. Could be one or more based on the need.

recipientRoles

String[]

Participant role of the recipient(s) of the notification. Could be one or more based on the need.

recipientCodes and/or recipientRoles can be used to send a notification (network or participant category) to a subset of participants defined in the notification master data for the corresponding topic.

subscriptions

String[]

Conditional mandatory: list of subscription_ids (at least one) is mandatory for use_case category notifications.

Locale

String

Placeholder if localisation needs to be supported in future

reference

String

Optional reference to the context for which the notification is meant. E.g. could be correlation_id or workflow_id for a use_case notification.

Maybe another notification that was sent earlier.

initiationTime

Timestamp

Protocol suggested format timestamp of when the notification was initiated by the sender

expiry

Timestamp

Expiry of the notification - should be later than initiationTime and currentTime.

message

String

Detailed message - usually picked from the template associated with the topic.

messageData

Key: Value dictionary

Key value pairs containing data for the replaceable attributes in the message template

API details

/notification/notify: return a synchronous acknowledgement of notification being received. Please note that no callback pair is defined for notify API.

Updating the notification subscriptions

APIs to track and expire the notification subscription that will be used by the notification initiating participants to stop sending notifications to the subscribed participants after the expiry trigger condition is satisfied.

There can be two type of subscription expiry conditions:

  1. Event based triggers

  2. Time based triggers

This API will be used by the initiating participants to revoke the subscription access of the receiving participants.

Subscription update alerts

Any change in the subscription from the sending participant would be notified to all the affected receiving participants using the proposed targeted network notification capability. This is proposed to ensure that receiving participants are not inadvertently affected by change in subscription and may trigger renewal workflows for cases when subscriptions are revoked by sending participants.

API Details

/notification/subscription/update

here
  • Key Design Considerations
  • List of Supported Notifications
  • API details
  • POST/notification/list
  • Subscription to notifications
  • API details
  • POST/notification/subscribe
  • POST/notification/unsubscribe
  • POST/notification/subscription/list
  • Trigger notifications
  • API details
  • POST/notification/notify
  • Updating the notification subscriptions
  • Subscription update alerts
  • API Details
  • POST/notification/subscription/update
post

This API is for the participants in the network to check the master list of notifications available to them.

Authorizations
Body
one ofOptional
Responses
200
OK
application/json
400
Request Validation failed
application/json
404
Requested resource was not found
application/json
500
Downstream systems down/unhandled exceptions.
application/json
post
POST /notification/list HTTP/1.1
Host: 
Authorization: Bearer JWT
Content-Type: application/json
Accept: */*
Content-Length: 36

{
  "filters": {},
  "limit": 10,
  "offset": 1
}
{
  "timestamp": "1629057611000",
  "notifications": [
    {
      "title": "Payer Downtime",
      "description": "A notification about the Payer System Downtime. This information will be useful for all participants.",
      "sender": [
        "payor"
      ],
      "recipient": [
        "provider"
      ],
      "topic_code": "NOTIFICATION@HCX01",
      "category": "network",
      "priority": 1,
      "template": "text"
    }
  ],
  "count": 1
}
post

This API is for the participants in the network to check the master list of notifications available and subscribe to them.

The participant should send the below details in the request body while making a call for notification subscription.

  • The notification topic_code (as topic_code) to understand the notification to which the participant want to subscribe.
  • The sender_list from whom the notification will be expected by the subscriber.

The response to this API could be one of the following:

  1. A successful accepted (202) response from the HCX gateway if the strucuture of the request is valid and the validation of open attributes (protocol headers) is successful. Upon successful validation, HCX gateway forwards the same request to the intended recipient asynchronously.
  2. A successful OK (200) response from the HCX gateway if the strucuture of the request is valid and the validation of open attributes (protocol headers) is successful and the recipient is HCX gateway. There is no callback expected in this case.
  3. An error response if any of the validations fail.

If the request is validated and accepted by HCX gateway, based on recipient it will be processed. If it recipient is not HCX gateway, the request will be forwarded to recipient and the participant should expect a response via callback API from recipient.

Authorizations
Body
one ofOptional
Responses
200
OK
application/json
400
Request Validation failed
application/json
404
Requested resource was not found
application/json
500
Downstream systems down/unhandled exceptions.
application/json
post
POST /notification/subscribe HTTP/1.1
Host: 
Authorization: Bearer JWT
Content-Type: application/json
Accept: */*
Content-Length: 67

{
  "topic_code": "NOTIFICATION@HCX01",
  "sender_list": [
    "PAYOR01@HCX01"
  ]
}
{
  "timestamp": "1629057611000",
  "subscription_id": "SUBSCRIPTION01@HCX01",
  "status": 1
}
post

This API is for the participants in the network to check the subscription list and unsubscribe to them. The participant should send the below details in the request body while making a call for notification unsubscription.

  1. The protocol headers defined and used by all the other APIs to understand the sender, recipient, status etc,.
  2. The notification topic_code (as x-hcx-notification_subscription.topic_code) to understand the notification to which the participant want to unsubscribe.

The response to this API could be one of the following:

  1. A successful accepted (202) response from the HCX gateway if the strucuture of the request is valid and the validation of open attributes (protocol headers) is successful. Upon successful validation, HCX gateway forwards the same request to the intended recipient asynchronously.
  2. A successful OK (200) response from the HCX gateway if the strucuture of the request is valid and the validation of open attributes (protocol headers) is successful and the recipient is HCX gateway. There is no callback API call expected in this case.
  3. An error response if any of the validations fail.

If the request is validated and accepted by HCX gateway, based on recipient it will be processed. If it recipient is not HCX gateway, the request will be forwarded to recipient and the participant should expect a response via callback API from recipient.

Authorizations
Body
one ofOptional
Responses
200
OK
application/json
400
Request Validation failed
application/json
404
Requested resource was not found
application/json
500
Downstream systems down/unhandled exceptions.
application/json
post
POST /notification/unsubscribe HTTP/1.1
Host: 
Authorization: Bearer JWT
Content-Type: application/json
Accept: */*
Content-Length: 67

{
  "topic_code": "NOTIFICATION@HCX01",
  "sender_list": [
    "PAYOR01@HCX01"
  ]
}
{
  "timestamp": "1629057611000",
  "subscription_id": "SUBSCRIPTION01@HCX01",
  "status": 1
}
post

This API is for the participants to get the notification subscription list.

The participant should send the below details in the request body.

Authorizations
Body
one ofOptional
Responses
200
OK
application/json
400
Request Validation failed
application/json
404
Requested resource was not found
application/json
500
Downstream systems down/unhandled exceptions.
application/json
post
POST /notification/subscription/list HTTP/1.1
Host: 
Authorization: Bearer JWT
Content-Type: application/json
Accept: */*
Content-Length: 36

{
  "filters": {},
  "limit": 10,
  "offset": 1
}
{
  "timestamp": "1629057611000",
  "subscriptions": [],
  "count": 1
}
post

This API is for the participants to explicitly send the notification to recipients via HCX gateway. The participant should send the below details in the request body while making a call to send notification.

The notification protected headers defined and used by all the other APIs to understand the sender, recipient_type, recipients etc,.

description - work in progress.

The response to this API could be one of the following:

  1. A successful ok (200) response from the HCX gateway if the strucuture of the request is valid and the validation of open attributes (protocol headers) is successful. Upon successful validation, HCX gateway forwards the same request to the intended recipient asynchronously.
  2. An error response if any of the validations fail.

The HCX gateway will send the notification to all the recipients of the notification if the x-hcx-recipient_id is HCX gateway identifier.

Authorizations
Body
one ofOptional
all ofOptional

JSON object

Responses
200
OK
application/json
400
Request Validation failed
application/json
404
Requested resource was not found
application/json
500
Downstream systems down/unhandled exceptions.
application/json
post
POST /notification/notify HTTP/1.1
Host: 
Authorization: Bearer JWT
Content-Type: application/json
Accept: */*
Content-Length: 1231

{
  "payload": "eyJlbmMiOiJBMjU2R0NNIiwKImFsZyI6IlJTQS1PQUVQIiwKIngtaGN4LXNlbmRlcl9jb2RlIjoiMS00ZGMzZTA4OC1hMzEzLTQ0YWItYWZhMS0wMjIyOTU5Y2I3NWIiLAoieC1oY3gtcmVjaXBpZW50X2NvZGUiOiIxLTkzZjkwOGJhLWI1NzktNDUzZS04YjJhLTU2MDIyYWZhZDI3NSIsCiJ4LWhjeC1yZXF1ZXN0X2lkIjoiMjZiMTA2MGMtMWU4My00NjAwLTk2MTItZWEzMWUwY2E1MDkxIiwKIngtaGN4LWNvcnJlbGF0aW9uX2lkIjoiNWU5MzRmOTAtMTExZC00ZjBiLWIwMTYtYzIyZDgyMDY3NGUxIiwKIngtaGN4LXRpbWVzdGFtcCI6IjIwMjEtMTAtMjdUMjA6MzU6NTIuNjM2KzA1MzAiLAoieC1oY3gtc3RhdHVzIjoicmVxdWVzdC5pbml0aWF0ZSIsCiJ4LWhjeC13b3JrZmxvd19pZCI6IjVlOTM0ZjkwLTExMWQtNGYwYi1iMDE2LWMyMmQ4MjA2NzRlMiIsCiJ4LWhjeC1kZWJ1Z19mbGFnIjoiSW5mbyIsCiJ4LWhjeC1lcnJvcl9kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCAidHJhY2UiOiAiIn0sCiJ4LWhjeC1kZWJ1Z19kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCJ0cmFjZSI6IiJ9LAoiandzX2hlYWRlciI6eyJ0eXAiOiJKV1QiLCAiYWxnIjoiUlMyNTYifSwKImp3ZV9oZWFkZXIiOnsiYWxnIjoiUlNBLU9BRVAiLCJlbmMiOiJBMjU2R0NNIn0KfQ==.6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.Mz-VPPyU4RlcuYv1IwIvzw"
}
{
  "timestamp": "1629057611000",
  "api_call_id": "123e4567-e89b-12d3-a456-426614174000",
  "correlation_id": "123e4567-e89b-12d3-a456-426614174000"
}
post

This API is for the participants to explicitly send the notification to recipients via HCX gateway. The participant should send the below details in the request body.

  • The notification topic_code (as topic_code) to understand the notification to which the participant want to subscribe.
  • The sender_list from whom the notification will be expected by the subscriber.
  • The status of the subscription.

The response to this API could be one of the following:

  1. A successful OK (200) response from the HCX gateway if the strucuture of the request is valid. There is no callback expected in this case.
  2. An error response if any of the validations fail.

If the request is validated and accepted by HCX gateway, based on recipient it will be processed. The changes to the subscription should be notified to the subscriber(s).

Authorizations
Body
topic_codestringRequired

Unique notification identifier from HCX gateway using the master list.

Example: NOTIFICATION@HCX01
subscriber_liststring[]Required

The list of subscribers to which the the subscription data will be updated.

Example: PROVIDER@HCX01
statusnumberRequiredExample: 1
Responses
200
OK
application/json
400
Request Validation failed
application/json
404
Requested resource was not found
application/json
500
Downstream systems down/unhandled exceptions.
application/json
post
POST /notification/subscription/update HTTP/1.1
Host: 
Authorization: Bearer JWT
Content-Type: application/json
Accept: */*
Content-Length: 83

{
  "topic_code": "NOTIFICATION@HCX01",
  "subscriber_list": [
    "PROVIDER@HCX01"
  ],
  "status": 1
}
{
  "timestamp": "1629057611000",
  "api_call_id": "123e4567-e89b-12d3-a456-426614174000",
  "correlation_id": "123e4567-e89b-12d3-a456-426614174000"
}