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.