Guidelines for attachments/documents in claim.supportingInfo

[gopi-g-dev]

From the HCX Workshop Parking Lot items - Feb 2023: https://docs.google.com/spreadsheets/d/1orSLpwn90HXCgGe-RsMJj7LLVyxXa-VW2dczAtut6mg/edit?usp=sharing

This has been a pending item for long. It is quite clear now that the integrators are looking for some guidelines on sending claim attachments as part of the FHIR Claim resource. FHIR has deliberately not gotten in to the depths of file sharing and access control, as it is outside its scope, it is expected that the industry come up with different ways of solving the problem according to their needs and it may be difficult to come up with a single approach that is satisfying for every participant.

So, the working group would come up with some guidelines and suggestions on the attachments could be sent in a secure and reasonably convenient way. Please participate and add your ideas.

[abhimail]

Dear All,

Kindly find below the proposal on attachment handling/document sharing as indicated in @gopi-hcx’s post above:

Context

To establish a successful long-term document exchange strategy, one should employ sophisticated mechanisms such as PHR, HIE-CM, and advanced FHIR capabilities while providing guidelines on document handling within participant systems. However, the immediate priority is to enable the use of current document management processes and encourage the adoption of better ones. This proposal provides phase 1 recommendations for exchanging claim-related supporting documents.

The HCX protocol can meet the immediate requirement for document handling in the "Handling Attachment" section, but it needs further elaboration to assist integrators in implementing various scenarios such as Document Management Systems (DMS) managed by senders (primarily providers) versus receivers (primarily payers) and sharing DMS credentials with counterparties. The following sections detail the key scenarios and proposed mechanisms for each.

Sender (Requester) managed DMS

Pre-signed URLs can be used to exchange documents between senders and receivers in a secure and efficient manner. Here's how it is envisioned to work:

1. The sender generates pre-signed URLs for the documents they want to share. These URLs include a signed authorization token that specifies the permissions and expiration time for accessing the document.
2. The sender shares pre-signed URLs via HCX request resources ({reqeust_resource}.supportingInfo or Communication.payload) to the receiver as detailed in the “Handling Attachment” section of the protocol.
3. The receiver accesses the documents using the pre-signed URLs. The authorization token embedded in the URLs verifies that the receiver has permission to access the document and that the URL has not expired.
4. Once the receiver has accessed the document, they can view it, download it, or save it to their own system.

Pre-signed URLs are a secure and tamper-proof method for exchanging documents between senders and receivers. The use of an authorization token ensures that only authorized individuals can access the document, and the sender can further enhance security by strategies like - limiting the number of times the document can be accessed, adding unique identifiers from the request, etc. This method is easily accessible and does not require any special software or infrastructure, as the documents can be stored in cloud-based storage services like Amazon S3 or Microsoft Azure. Additionally, pre-signed URLs can be set to expire after a specified time period, protecting the document's confidentiality and preventing access after it is no longer required. Given these benefits, pre-signed URLs are highly recommended for document sharing in HCX flows.

Receiver managed DMS

When the receiver manages the Document Management System (DMS), one of the key challenges is to share the DMS details, such as the type of DMS (http, ftp), endpoint URL, and access credentials, with the sender in a manner that allows the receiver to change the DMS details as needed. There are two ways to achieve this:

Out of band DMS details sharing:

This leverages existing ways of sharing Payer’s DMS details with others (Providers, TPAs, etc.) and HCX protocol doesn’t have a role to play in such sharing of DMS details.

Inline DMS details sharing through HCX

This method enables the sharing of DMS details between the sender and receiver via HCX response resources in an inline manner. The organization.endpoint profiles available in various response resources such as CoverageEligibilityResponse and ClaimResponse are utilized for this purpose.

Here is an overview of how the inline DMS details sharing is intended to work:

1. Receiver receives one of the cycle request from sender
2. If the sender doesn't have its own DMS or can't create pre-signed URLs for some reason, the receiver decides to send its DMS details to the sender to use it as DMS. This can be done for various cycles in the protocol:
   1. CoverageEligibility cycle: Payer sends the DMS details as part of CoverageEligibilityResponse.insurer.endpoint.
   2. Claim cycles (predetermination, pre-auth, claim): Payer can send the DMS details as part of ClaimResponse.insurer.endpoint. This would mainly be used if the CoverageEligibility cycle wasn;t used for the episode.
   3. CommunicationRequest cycle: Receiver could also raise explicit (solicited) CommunicationRequest and send the DMS details in CommunicationRequest.requester(organisation).endpoint. The sender is expected to respond as described in 3c below.
3. The sender can then use the received DMS information to access the receiver's DMS, upload necessary documents, and provide the url reference to the document in subsequent requests/cycles as follows:
   1. As part of supportingInfo in predetermination, pre-auth, claim cycles.
   2. As part of proactive CommunicationRequest payload to send the information beyond the Claim request cycle, e.g. when DMS details were themselves received as part of a previous/current claim cycle (predetermination, pre-auth, claim cycles).
   3. Respond to a CommunicationRequest raised by the receiver using Communication.payload[].
4. Receivers are expected to communicate following DMS details using Organisation.endpoint attribute of resources listed in point 2 above:
   1. organisation.endpoint.connectionType should be one of “http” or “ftp” (HCX will publish the needed value set for this).
   2. Organisation.endpoint.address should be the respective url for the system
   3. Organisation.endpoint.header (array) should contain the protocol specific headers to access the DMS
      1. In the case of HTTP, the headers required would depend on the authentication scheme chosen by the DMS. You can refer to the list of authentication schemes and their respective RFCs here.
      2. In the case of FTP, the headers could be used to carry needed FTP credentials.

The proposed document exchange mechanism is a significant stride in enhancing the document exchange process among ecosystem participants. Although there's always room for improvement, we're confident that this mechanism will simplify the document exchange process and foster greater collaboration between stakeholders.

We kindly request everyone to review the proposed mechanism and share their valuable feedback as comments in this discussion. We intend to deliberate on these suggestions in our next working group meeting.