EDI transactions have ISA segment with Sender ID and Receiver ID identifying who and where sends the transaction. The transaction carries multiple entities such as Eligitbility requests (HIPAA 270), responses (HIPAA 271), claims (HIPAA 837), claim payments (HIPAA 835), enrollments (HIPAA 834), etc.
In FHIR these entities are atomic resources which do not contain Sender and Receiver information, which is quite logical since it is transaction level information not related to entities directly. However, this information is required to organise proper interaction between two parties.
I see MessageHeader resource that carries Sender and Receiver info. Moreover, the type of the fields sender and receiver is just right, it can be either Practitioner or Organization (I assume that for cases when data goes trough clearing house it is organization as well. Basically we can say an exact person or somebody who works at certain company)
The problem is that Claims, EligibilityRequest, Responses, etc. do not refer MessageHeader and when you have some claim in your FHIR server it is impossible to say who sent it for whom it was sent.
I am not sure that MessageHeader is a proper resource here that is intended to carry an analogue of ISA/GS (envelope) segments from EDI. However, I did not find anything that can carry this information. Also, MessageHeader does not have identifier field.
So, the question is how to provide Sender and Receiver information for claims, eligibility requests, etc?
It depends on how you’re sharing the information. If you’re communicating claims inside of a message, then you’ll be transmitting a Bundle which includes a MessageHeader as well as the Claim, EligibilityRequest or whatever is relevant to that message. And the message will indicate the sender and receiver. That’s necessary because the message may go through multiple transmission hops.
On the other hand, if you’re using REST, the sender and receiver will typically mutually authenticate using TLS, so the exchange will be conducted in a context where both systems will know who the sender and receiver are. If this information needs to be persisted, the Provenance resource would be used. (The Provenance resource would track all involved systems and would point to the data shared.)
If you’re communicating using services, the way sender and receiver is managed can vary. If done using HTTP, TLS will apply. If you’re using SOAP or SMTP or some other transport, the transport will manage that information.
The MessageHeader would point to the Claim(s) using the “focus” element. Everything in a FHIR message bundle has to be tied together by relationships pointing one way or another. That said, all of the business semantics should be present in the Claim itself. The Claim itself indicates the Organization (and individual) submitting the Claim and the insurer being asked for payment. So most of the time, the specific applications that were involved in transmitting and receiving the instance probably aren’t relevant (and if relevant, will be exposed using Provenance). The MessageHeader will typically be thrown away once the message is processed unless it’s retained for audit purposes.
Yes, indeed the focus field could refer claims (or other resources). Though, if “focus” (or similar) was in Claim and referred Envelope (MessageHeader) it would be better. Now if I have 1000 claims in one transaction I can put 1000 focus links to MessageHeader and if I need to delete one claim I will also need to update MessageHeader and delete “focus” referencing that deleted claim. Thus, instead of one DELETE operation I will have DELETE plus UPDATE (and additional processing of that MessageHeader resource prior to update).
One more problem with MessageHeader that it does not have identifier which could be very useful. The use case is when submitter sends bundle (MessageHeader + Claims) and there is a technical glitch (connection problems, etc) when he needs to resubmit the whole previously prepared bundle without creating it from scratch. The receiver system checks if it is resubmission or not by checking the transmission unique id. Moreover, it could help tracking the submissions sent by sender, already stored in fhir server and submitter to someone else.
The Group resource could be used for the case I am talking about but it refers limited set of resources in its Group.member.entity.
Has MessageHeader resource been deprived of identifier field intentionally? Most resources do have this field as optional one.
A given claim could be conveyed in numerous messages and other instances for different purposes. However, a given message is tied to only one particular set of payloads. As noted, MessageHeader is generally throw-away. Its purpose is to ensure delivery. The semantics of the Claim are found on the Claim itself, not the MessageHeader.
MessageHeader does have an id - as every resource does. This is used when replying to a message. (And the message Bundle has an id as well.) Neither have business identifiers as neither are stored by different systems where each assigns its own id (unlike lab results, orders, patients, etc.)
Can you explain your use-case for linking Claim to MessageHeader again? Why do you care about sender and receiver of the message a claim was delivered with once delivery is complete?
My use case is front-end system that can submit fhir data (let’s say bundle with MessageHeader and many Claims) to fhir server. The fhir server is used as a storage for clinical data, has some UI that connects and portrays claims, etc.
However, there is a back-end system that does not support FHIR data and works with HIPAA EDI. I need to assemble HIPAA 837 transaction for them.
Overall I have enough data to create loop 2000C(Patient) or 2000B(Subscriber) including loops 2300 (Claims) and other stuff in service lines , etc.
However, I do not have data on FHIR Server about loops 1000A - Submitter Name and 1000B Receiver Name. Also I do not have ISA segment information like Information Source and Information Receiver.
Submitter is not always BillingProvider that is referenced from Claim , it can be anybody else (Practitioner or Organization).
Back-end system needs this information about original submitter and receiver since they respond with claim payment still in HIPAA format (835 transaction) and I want to convert this format to FHIR format and submit back to original submitter of the initial FHIR Bundle with claims.
Also I would like to simplify tracking on UI and want to see who is the original Submitter of this claim even though Billing Provider is different. For that I would prefer to store on FHIR Server claims (which I can render on UI) and submitter and receiver info. Also I could do search based on these values. That is why I do not want to loose MessageHeader after the bundle is delivered. Though, It seems like MessageHeader is not the best resource for my use case.
The flow diagram is
Front-end Submitter(FHIR compliant)[1] <–> Me and My FHIR Server (FHIR Compliant)[2] < – > back-end system (non FHIR Compliant)[3]
There can be multiple [1] and multiple [3]. When 1 sends something I need to know who is [3] to deliver the claim. As well as when I get some non-real-time response from [3] I need to understand which [1] I need to send it to.
In EDI there are loops 1000A - Submitter Name and 1000B Receiver Name for that. I am trying to find an analogue in FHIR.
The Claim.provider/Claim.organization are typically the ‘sender’ and Claim.insurer the receiver. And typically the claim may not travel from the source to the destination directly, including when using FHIR Rest as discussed above. The transmission often involves several hops where the number of hops is not directly known to the participants.
If you have situations where for example a ‘billing manager/TPA (BILLER)’ is performing the billing on behalf of the provider organization and submitting the claims to a TPA (Third Party Administrator) who is know (often not the case) AND you are required to reflect these other parties rather than have them be silent parts of the respective sender/receiver infrastructure, then either you need to use a message framework where each Claim would be sent in a bundle with a MessageHeader (per claim or per bundle where each Claim would need to have a reference to the MessageHeader in an extension) or you would need to add sender and receiver extensions to the Claim.
In Financial Management we haven’t yet begun to create US profiles which will reflect the US specific information and terminology requirements. I expect we will begin to consider that effort in May in Spain or shortly thereafter if we don’t have sufficient US participation in Madrid.
Thank you, Paul. I have exactly situation as you described. Using some workarounds is fine for me now. I just did not want to miss existing functionality or misuse the resources.