Stream: implementers
Topic: ADT IN1 deactivated insurance records
AJ (Jun 07 2017 at 04:39):
This post relates to ADT interfaces (patient demographics) where medical practices wish to integrate two different internal systems. There are two major gaps that I see in the ADT standard relating to active status. One has to do with the patient's account status under the PID segment not being defined in the standard, and the other has to with deactivated insurances not being included under the IN1 segment. Has anybody been part of discussions in your own projects or with the standards committee to help address these two gaps?
Below I'm going into more background on the insurance deactivation dilemma...
As background, the business use case scenario has to do with patient demographics info being passed between an EHR that's used by the front desk (this is the system where the initial patient registration takes place) and an entirely seperate downstream billing system where the registration is updated and corrected for billing purposes. The main problem for this kind of ADT interface right now is that not all vendors are on board with sending messages that include information on an insurance plan ABC that was deactivated / terminated in the patient's registration in the source system. The messaging under the IN1 segment only sends active insurances, so any insurances that are deactivated in the demographics file are not included whatsoever. This gap ends up causing obsolete insurances to remain "active" in the downstream billing system, because no message was received saying ABC should be deactivated in the downstream system.
For reference, here’s a diagram that helps illustrate the technical design at hand for this challenge: http://www.mbsselect.com/hl7-interfaces.html#eCW
Of note, we’ve been able to successfully convince one of the vendors to include deactivated insurances in their ADT messages as part of customization work. But, there are still all the other vendors that don’t support this yet. Of course, it doesn’t really matter if only one of the vendors agrees to get creative with us here since it takes two to tango. The business case and requirements for insurance active status to be included are obvious -- I hope everyone can agree -- but, the standards gap continues to exist with years just flying by. So, again, I’m hoping to learn more if the standards committee will be soon focusing on this particular challenge/gap with ADT messages so the various vendors can be encouraged to finally get on board in helping to solve this data reconciliation issue.
Really looking forward to hearing back on other people's thoughts and experiences. Thanks in advance for the insight.adt
Lloyd McKenzie (Jun 07 2017 at 05:04):
You may not necessarily get feedback here as the primary focus is FHIR rather than v2, but lots of people have their hands in both worlds, so who knows. At the moment v2 support is primariliy through the HL7 list servers. This would be something that could be raised on either the Patient Administration or Financial Management lists.
Paul Knapp (Jun 07 2017 at 18:31):
Hi @AJ I am a co-chair of Financial Management which is responsible for the IN1 segment so I am happy to take this issue back to the committee.
For clarification, is it your desire that when a party discovers that an insurance (INx) segment is no longer valid that it updates all parties to which it has previously sent that INx with a new one or an indication that the INx is no longer in force or valid? or That expired insurances of which the sender is aware should be included with the inactive status along with any currently active insurances? or something else entirely?
AJ (Jun 07 2017 at 22:46):
Hi @Paul Knapp thanks so much for the reply back!! Glad I was able to connect with the right person!!!
Yes, the last item is the correct one. Both inactive and active should be sent. The expired insurances (per operator's manual deactivation in the registration/demographics record at the UI level) should be included in the next ADT as an IN1 set that indicates the inactive or deactivated status of that one IN1 record. Of course, any new insurances that are added to replace the inactive insurance should also be included as another IN1 set in the message, as is the case now. To clarify, right now, vendors are sending multiple IN1 sets for all active insurances on file for the patient regardless of whether or not these insurances are even new or updated. If you update the patient's cell phone, then all active insurances will also be sent once more under IN1. Heck, it'd be better if they didn't do that and only sent IN1 if something has changed in IN1, but that may be a bigger fish to fry.
So, ideally, the IN1 sets with inactive status would go last in sequence, but the seq order is lesser in importance than just having it in the message (i.e. anywhere, somewhere) for starters. The other "nice-to-have" behavior that would be ideal would be to just have the inactive/deactivated insurances included in the ADT messages just ONE TIME at the onset of the operator deactivating the record -- meaning that this operator deactivation action would be the sole trigger for including the inactive IN1 sets in the message on a one-time basis. This would help with ongoing reconciliation so "like" records are not confused for one another resulting in the wrong records deactivated downstream due to faulty matching logic. But, if vendors are not able to include this conditionally so that it's only included after that first trigger event, then we can deal with it another way if it continues to be included again in again in future ADT messages (i.e. when other unrelated aspects of the patient's demographic file is updated).
Again, just having these inactive records in the message somewhere is better than not at all as is the case now -- beggars can't be choosers! Since the standard doesn't indicate a place for the insurance active status right now, vendors are skipping over this important data maintenance item when they're coming up with their own interface solutions based on the ANSI specs. So, hopefully, having a place for it in the standard spec will help solve this industry-wide problem I keep running into.
The same goes for the active status for the patient account itself at the PID level. Do you know who works on PID that could help there, as well?
Thanks again!!
Simone Heckmann (Jun 08 2017 at 09:26):
Hi AJ,
I think you have stumbled over the generic V2-> FHIR mapping issue when the V2 message sends "snapshot style" data.
We have had the very same discussions with the Allergies, where a deleted Allergy wouldn't trigger a message saying "this is the deleted allergy" but instead a message saying "these are the active allergies, delete all previously stored data and replace with the current set".
We even had a connectathon, trying to find solutions to this.
Bottom line is: Your V2-> FHIR integration engine will have to do just that: Tag the coverage resources it sends (or better: use Provenance resources to keep track), so it can recognize them and then, whenever a new set of coverages arrives in a V2 message, it will have to delete all previously sent coverages in the target system and replace them with the current ones.
That however becomes problematic, when the target system has already added data to the resources (they would be lost) or referenced the resources (the IDs of the newly created resources would be different).
See:
http://wiki.hl7.org/index.php?title=Version_2_-_FHIR_Mapping_Scenarios#2._ADT_.28single_source_system.29
https://www.slideshare.net/DevDays/gf-v2-mappingdevdays2016hl7
https://vimeo.com/191935494
Paul Knapp (Jun 13 2017 at 17:25):
Thanks @Simone Heckmann you have captured this well. Also, I think there can be the follow on issue of determining who you then need to update given the update you have just received.
Paul Knapp (Jun 13 2017 at 17:31):
@AJ Patient Admin is responsible for PID I think. You would think that senders of the IN1 segment when knowing that the insurance is no longer valid would have set the expiry date of the insurance to a date in the past so that receivers would know not to submit claims, and other transactions, against coverages which are no longer applicable.
AJ (Jun 13 2017 at 22:27):
@Simone Heckmann and @Paul Knapp Thanks to both of you for your input and resource links. In our scenario, our middleware solution we've designed (and we're a third party) is sitting in between two source systems where one system is only sending one way while the other sends two ways. And, the system that handles two way can neither process inactive records sent to them nor do they provide the inactive "status" value in the outbound messages they generate. To give they some credit on missing the boat here, if you look at the ADT specs for IN1, there is nothing about insurance status represented. So, you can understand why developers, who are far removed from the business process, would have overlooked the importance here. That said, my main request/wish is for the standards committee to better represent this in the ANSI spec document so vendors across the industry can account for this better. On a side note, we're definitely seeing the rise of "two sources of truth" interface solutions starting to rise as practices are finally coming to terms with their EMR system not being the best at revenue cycle management (aka "medical billing"). I should also mention that the coverage dates are not often populated by the practice staff nor are they required in the practice management systems. So, that's not a reliable data element to base things off of since it's inconsistently (or I should say infrequently) provided when insurances are deactivated. In other words, you can deactivate and insurance record in the PM or EMR system without ever touching the elig coverage start or end date fields. Because we're dealing with scenarios where one system is just one-way whereas the other system can send messages two ways (and both systems are the source of "truth" so to speak), we've developed a proprietary database solution in the middleware layer where we've effectively cloned the data sets from both systems into different tables where we track their various updates, apply reconciliation algorithms, and then cherry pick which values "win" that we decide should be sent vs. dropped in the HL7 messages that are relayed. This has worked beautifully in the case of every data element except the insurance multi-value records... and we'll continue to face challenges here until the vendor that's the receiving system agrees to process inactive status, which isn't even in the standard specs. But, that's just the struggle with one vendor... we keep hitting it again and again with the next vendor and the one after and so on. So, again, it's a standards issue in that not everyone is on board with even including this data and being able to process it. Representing it in the standard spec file is the least help that the HL7 committee can assist with so I can fight this painful, recurring battle vendor to vendor with an official field designation in the ANSI specs. Thanks again for all your help, insight, and understanding of the tough challenges. Cheers!
Paul Knapp (Jun 14 2017 at 01:11):
@AJ I just check V2.8 and noted the following for IN1:
IN1-2 Health Plan ID (CWE) 00368
Definition: This field contains a unique identifier for the insurance plan. Refer to User-defined Table 0072
- Insurance Plan ID in Chapter 2C, Code Tables, for suggested values. To eliminate a plan, the plan could
be sent with null values in each subsequent element. If the respective systems can support it, a null value
can be sent in the plan field.
Last updated: Apr 12 2022 at 19:14 UTC
