Giving a patient medications in the ER, having them pop positive on a test, and then withholding further medications because…
Readers Write: An Interoperability Data Challenge — Out and Back Demonstrating Reflection
An Interoperability Data Challenge — Out and Back Demonstrating Reflection
By Brody Brodock
Brody Brodock is a principal with AdaptTTest Consulting of Raleigh, NC.
I want to offer up a challenge that will express the current state of interoperability within regional systems. The challenge involves the top N most frequently used values within domains, exchanged via C-CDA within your community of practice, reconciled and incorporated, then returned to the sender, where the originating sender then reconciles and incorporates the returned items.
This should be a simple task that any certified EHR can accomplish with 100% accuracy. However, if you get better than 80% success in the first part of the exercise, I will be greatly surprised. If you can successfully exchange above 50% on the second round, I will be impressed. I would even argue that two systems from the same vendor will be challenged.
We should keep this to the required domains: medications, problems, and medication allergies. Other domains should be left out to reduce complexity. This gets messy really quickly.
You will need to gather from your system:
- Problems. Problem text, problem code, problem code set, status, date added, date updated, and onset date.
- Allergies. Allergy category, allergy severity, reaction, reaction severity, allergy dates with specificity, status, and the codes for allergy and allergy reaction.
- Medications. This might get trickier as some systems load meds into different table sets depending on the order type (prescription or order). But essentially you need the medication name, medication code, status, date of entry, order expiration date, dose, dose form, frequency, SIG, PRN, and DAW.
Once you gather these extracts, (you might need to limit the period), you should slice and dice the data to tell you what the most frequently used (MFU) items are. You don’t generally need to associate the metadata to other data elements. Knowing that the top medication allergy is penicillin is sufficient, the top reaction might be hives — they don’t need to be associated in this round.
HIPAA note: watch out for names in the SIG, and purge any “zzz” names you come across.
Now that you have your list, take the top 10 from each and add them to your new patient. Then another set of patients that reflect the metadata objects: status, dates, reactions, severity, PRN, DAW, etc. If you have the ability to add free text med allergies, then submit a patient safety defect report to your vendor, but send the free text allergy anyway. Try “pentillacillian” with “anti fylaktic” — yes, I have seen that.
Medications should be a mix of your top 10 prescriptions, plus your next 10 with your top SIG, plus the next top 10 with all of your statuses. Add a couple that are tapered dose, vaccines with multiple dosages, and multiple formulations (albuterol syrup, pill, and rescue inhaler) all active.
Your CDS/DUR systems are supposed to alert for for all of these domains. Once you reconcile and incorporate these items into your system, pick a couple of items like penicillin with anaphylaxis and attempt to prescribe that. You should get an alert. A significant battery of CDS/DUR tests should be done with this data.
Now that you have built up the patients, have your development team automate them so they can be duplicated on demand. If you don’t have an automation team, ask your vendor for their scripts. These tests should be part of your standard operational and production qualification tests — OQ/PQ.
Now send these patients via a summary of care or a transfer of care (try both — they should be different) to your geographic neighbors. Whichever systems from which you receive transfers, referrals, and notes. They will be ambulatory, acute, ED, SNF, and specialty facilities. But more importantly, they will be different systems, or at least different configurations of like systems.
Take these C-CDAs and send them through your Direct HISP, email, or sneaker net (HIPAA rules apply and these must be fake patients). You can name them “MedicationTest-xxx” where xxx is an alpha counting scheme: aaa is the first, aab the second, all the way to zzz being patient 676. If you can create patients with numbers in them, I would be surprised, but go ahead and try one of those patients too. “Patient 0” shouldn’t be possible, so it will probably blow up on the receiving end.
The receiving facility should then bring in the C-CDA and perform reconciliation of the listed domains. Problems, medication allergies, and medications should now be in this patient’s record.
The expected result is 100% accuracy in the exchange. No conversions, no substitutions, no increased or decreased specificity, no “go fish” in presenting the user with a series of options to reconcile. These are the most frequently used, so there should be no problem.
Your actual results will not be even close to 100%. You will have allergies that switch category, reactions that aren’t recognized, medication APIs that are switched to brands, problems that are either more specific or less specific than the incoming problem, dates that will increase specificity from year or null to DD/MM/YYY:Time, and multiple formulations that will be considered duplicates (three albuterol formulations).
Now without further modification, the receiving facility should create the same type of C-CDA and return it to the originating facility. A full round trip. The record that is returned will look like a completely different patient than the one that you sent out. Statuses and dates will be converted to something else and your medication intolerance will suddenly become a medication allergy. All sorts of fun here.
This is why healthcare interoperability singlehandedly enables the fax industry.
This is the first part of a long and complex set of tests, a simple out and back. Yet the exchange will demonstrate how badly the industry needs to get its data house in order. The results will not change just because you were using different technology. If you are using FHIR to write data back into your solution, you are going to have the same problems.
You obviously do not have any experience with Epic’s CareEverywhere. Bi-directional health information exchange between Epic organizations is seamless and nearly flawless. We do have the capability and have in fact received C-CDAs from non-Epic systems via CareEquality and Commonwell, however the quality and completeness of those C-CDAs has been highly variable.
Re: nearly flawless – I dare say that you aren’t looking close enough
Here is a sampling of additional complexities that I’ve encountered in Epic vs. Epic exchanges amongst just medication orders –
– Different medication interoperable mappings stemming from sites using different medication database vendor (e.g. one site uses FDB, the other Medi-Span)
– and even amongst sites using the same the same medication database vendor there can be differences if the sites are out sync on latest version loaded
– Medication frequencies are especially challenging for discretely mapping while not losing the specificity i.e. common to lose appendages like “after dinner”.
– Sites might interpret dose units differently for same medications, i.e. [20 mg of testosterone / 1 gram gel] order of at one site can transform into a [1 gram of testosterone / 50 grams of gel] order when received by a different site
– NDC codes can get re-used – which can sometimes result in medications discretely mapping to completely different concept
– Custom site-specific medication records …. (too much for me attempt to succinctly summarize all the potential challenges on this one)
Admittedly there has been much improvement overtime – so stuff like NDC codes being reused has become less severe. But still, I contend that the process has many persisting flaws/challenges that merit awareness.
Actually, I do
The problem I see with CareEverywhere is similar to the problems I see in other HIEs but in CareEverwhere I also see zombieism — the resurrection of previously ‘closed’ or reconciled items. And, bringing the C-CDA record into my Apple Health app is also rather comical.
I have four Epic records, three in RTP. When I had a recent motorcycle accident I was lying on the ED table and the ED doc was asking me about all of my medicines, allergies, and problems — when I gave him my succinct list he indicated that isn’t what the record was showing. In fact, every medication I had from the previous four years were listed as “Active”, my lisinopril “Intolerance” came through as an Allergy, and I had pharyngitis, was on antibiotics, had hypertension, and GERD — none of which were active in my main provider’s chart. So when I said, NKA and B+ he actually questioned it — I am glad I was able to correct his understanding of my med chart. I had “reconciled” my chart earlier that week — but it didn’t stick in CareEverywhere. In addition, the ED doc couldn’t access my images from my other records so had nothing to compare.
Also, yes I have seen records from other systems — I have not found Epics data to be any better than the rest — if we don’t admit we have a problem then we cannot solve the problem. If you would like to accept the challenge then lets prove that your data is great and everyone else’s needs to fall in line.
Thank you and Clarence for providing some of the only meaningful critiques of interoperability on this blog in years…this discussion is so much more useful than the strawman “Epic said interoperability is bad!”
I hope you don’t take this to be dismissive, I just want to address a few things you note.
All things being equal, if the source systems actually kept their documentation up to date, obsolete meds and problems wouldn’t be in the bucket for reconciliation at the destination system.
When it comes to an intolerance being transformed into an allergy, the last time I was in the loop that kind of distortion would result from bad analyst build (not a vendor bug).
If data was indeed corrected in the source systems but the destination hadn’t refreshed their stale data with a new pull, that’s on the destination. There are tons of hooks to retrieve updated data when a patient presents for care at a destination system. Maybe the external sites require the destination health system to collect update authorization forms before they’ll release additional info?
Last, asking for imaging to be exchanged by health systems is a tall order. Happy to say that the technology has been released by Epic though and is being implemented by the community, even if at a glacial pace.
To wrap up: in the (mythical) ideal world where the sources and the destination were all using the right workflows, analyst build, code versions, and available features… I think you’d be much happier with the conclusion.
I realized belatedly that Brody commented about something that didn’t ‘stick in Care Everywhere’.
On the off chance I’m reading that correctly I wanted to clear something up: Care Everywhere isn’t a centralized/hub HIE. It’s an adapter for an individual health system to do IHE & CCDA exchange with other entirely separate Epic installations & non-Epic entities. So, you weren’t changing a value in a central repository accessed by Epic clients, you were updating a record in a private database that could later use Care Everywhere to release that information to outside requests or internal triggers (‘with cause’).
Brody, you might have already known that, but I wanted to get it out there.
Onlooker,
You are pointing out that this is complicated, and there are plenty of actors and actions that can contribute to the problem. Completely valid point.
Not sure that “analyst build” is the problem as there are often competing needs that drive configurations, (I assume that is what you meant) but I agree with everything else you have said. If the medical record is not reconciled then the source system is part of the problem. However, I have yet to see a system that has “entanglement” of the data that has been exchanged. Meaning that if clinic A provides a referral for a preliminary diagnosis and the specialty adjusts the diagnosis and adds a new diagnosis is the provider notified? That is the goal of 360x but how many have implemented it — Cerner, Epic, ? I do want to stay agnostic to solutions because I believe it is a shared responsibility and in the end we are supposed to be supporting our customers: the patient, clinicians, researchers, public health administrators, and syndromic surveillance.
And while some HIEs may have entanglement, I haven’t seen it. If a clinician downloads, reconciles, and incorporates a clinical item, then resolves that item through treatment — will the HIE now notify the originator that the ‘condition’ has been resolved? The argument I have heard against that is that once the item is reconciled, the item becomes part of that clinicians ‘patient body of knowledge’ and is their responsibility.
Images are a tall order — FHIR may be able to help here, or some other restful call architecture — but we have been doing it for a while so my sympathy meter isn’t pegged to the right. But, glad it is a work in progress for some vendors.
Thanks for calling this out — it is an important part of the problem
Part of the problem that Brody is driving at here really isn’t a place that EMR vendors can meaningful contribute without frustrating their customer base. Once there are only a few EMR vendors left, then you can start telling your customers that they can’t do the thing in a way that prevents interoperability. The government could mandate that the EMR companies provide interoperability, but it either won’t work or will drive certain EMRs out of business. The situation is FUBAR in that respect.
The problem is that healthcare delivery and organizations just aren’t that standardized and process oriented. They’ve never been exposed to the sort of environment that produces that. What we need isnt a technology standard, it’s a process standard. As an example, accountants use GAAP so that they can calculate the revenues, losses, etc for their company. When someone tells me their GAAP deferred revenue, I know what they mean and how they calculated it. When someone tells me that a patient has an active medication in their chart, I don’t have a good idea about what that means.
I do question what the vendors can do as they appear to be only a segment of the problem. Those segments appear to be:
–Vendor: design, coding, schemas, UX, variance in their CCDA and FHIR usage, etc
–Organizational implementations: One group deciding to have Intolerance, another chooses adverse reaction – or differences in mission
–Clinicians themselves: documenting in the wrong domain, documenting discrete data in notes, training, etc
–External influencers: got to make those numbers, insurance requirements.
So if we only look at one segment of the problem then we can say that our side of the boat isn’t sinking.
If a clinician is selecting the first allergy in the drop down list (1-A drops) and then adding all the allergies to the notes in that “1-A” allergy (pennnicilin, sulfer, opiods) — is that the clinician’s training, the UX of the vendor solutions, or the organization for not monitoring their data quality? I believe that the solution must involve all parties, vendors assessing individual customers data, using that information to improve their solutions. Researchers feeding the data failures they are seeing to the organizations and vendors.
Data to information, information to knowledge, knowledge to wisdom — can we do that with pennnicilin, sulfer, opiods in an allergy to 1-A drops?
Ianal, thanks for helping me drive the message home
This was a really good discussion, very educational for a clinician. But it doesn’t make me feel good at all…