This is about an IHE Profile proposal that I presented (doc) to the PCC Technical Committee today on Reconciliation of data elements found from multiple sources of information. The problem is that too much data can be overwhelming. According to a more than fifty year old paper by George Miller, the human working memory capacity is seven plus or minus two. Later research shows this to be somewhat different depending upon how the information can be chunked, but the limitation is still present. And yet, numerous studies show that the average number of medications taken by high risk populations (elders, patients with chronic conditions, et cetera) exceeds seven. So, for complex cases, the data that needs to be reconciled could exceed human working memory, which is a recipe for error. And you cannot just go out and buy and upgrade either.
Or, can you? We use applications which syncronize data all of the time, and notify us of changes. Every time you sync your smart phone, a reconciliation process is executed. So, how can we make the EHR technology support this better?
That's the idea behind the Reconciliation profile. The point is that you have a service, call it the Reconciliation Service, that
- Knows how to get information from other information systems, including EHRs, PHRs, Immunization Registries, disease registries, ePrescribing hubs, or HIEs.
- Understands the semantics by which problems, meds, allergies, et al, are exchanged (via CCD/C32).
- Can automatically identify duplicated, updated, or new information based on those semantics,
- And can interact with a User Agent to display to the provider, and get updates back from the provider on these changes,
- And can report the reconcilled results.
Those systems can do this veryt well because they have some common rules about how they exchange calendar and contact information. We can take advantage of some of those same rules. If two problems have the exact same universal ID (a data element on clinical statements required by all IHE profiles), then they must, according to the semantics, represent the same problem. So we can find some of this easily if we agree not to lose identifiers in exchanges. But also, we can take advantage of other rules to identify possible duplicates where IDs aren't synced. In those cases, the system might look at the code used to describe the problem, and whether the dates overlapped. Two instances of flu with overlapping dates can be identified as likely being the same "problem". There are other heuristics that could also come into play, especially in vocabularies where there is a hierarchy or "isa" relationship. If document A indicates a problem on 11/18/2010 of ICD-9-CM code 845 (ankle sprain), and document B indicates a problem using ICD-9-CM code 845.01 (ankle sprain of deltoid ligament) on the same date, then this is also a case where automation can identify a potential duplicate, with richer results.
The output of this process would be a list of duplicates, updates, and new information in a structured format that could be presented in a user interface, to be accepted, rejected or modified by a healthcare provider.
So, instead of looking at 2 or 3 lists of 8-10 items, he or she can look at one consolidated list showing a composite view of information, that can be highlighted with respect to variances over time.
The output of the interaction with the provider would be the reconciled list, plus the following pieces of data: Who performed the reconciliation, when, and against what data sources. That information would flow into the next system that needed to perform reconciliation, which would further benefit the process.
So, if you have document A, B and C containing information to reconcile, and C indicates that it contained a reconciliation of A and B already, then C already contains one provider's reconciled list.
The profile doesn't specify how to do the reconciliation, but it does identify certain cases where some kind of reconciliation can be done, and how to record the results to indicate what was done. So there are some functional requirements that the reconciliation service needs to meet to generate the output. It also creates opportunities for some systems to be really smart about how they identify duplications and changes, which can greatly add value.
Reconciliation is something that is done on just about every visit or transfer of care for a patient. Because of the volume of data that might be dealt with, it's a process that is ripe for some interoperable automation. We vote on whether this proposal goes forward tomorrow morning. I expect that it will go forward, as it has quite a bit of support.
That's some cool technology. I want to implement it.
So moved... seconded ... passes unanimously.
ReplyDeleteGreat concept, Keith.
ReplyDeleteAs I have time, I'd like to be involved.
One concern that I would have is to make sure that the scope and use cases for this are clearly defined because the definition of 'duplicate' will vary depending on the use case (think of the LISP eq vs eql vs equal vs equalp type issues), and some of the examples of "is this the same" can get very complicated. But, if this is held to specific use cases such as human clinical reconcile of medications/allergies/problems as they occur with discrete data import (including from CDA documents, or real time queries of multiple external systems) between different systems, this will help to hold it to be a very pragmatic and serve a very needed purpose.
In the reconcile process, I would also float the concept of building "evidence" lists. For example if a medication "Atenolol" was ordered on 1/2/2009, then that provides evidence that the patient is currently on atenolol, but it does not imply that with certainty (2009 is a while ago, and there might or might not be evidence that says that it was stopped in the meantime). Similarly, the fact that a medication was ordered does not imply that it was taken, but does provide evidence that it is more likely to be taken. If the order was refilled at a pharmacy last month, that could be more evidence on the same concept "patient is taking atenolol" (which needs to be matched through your identification of sameness above). If the patient subsequently stated in an interview done yesterday that they were taking it, then is pretty strong evidence. Within the evidence "patient is taking atenolol", there may be evidence of details such as the specific brand as filled "Tenormin", ordered and filled dose of "100mg" (vs contradictory evidence from the patient interview that might indicate "50mg") and frequency "daily".
I agree - great concept. I too would welcome the opportunity to participate.
ReplyDeleteI agree that this is a timely and valuable concept. In most previous discussions I've been involved in on this subject (which have been frequent, but sporadic over the last 2-3 years), it has seemed important to capture the original source information in its original context (standardized or not, codified or not), as that represents the "beliefs" or observations made by various people over time. Getting to the "source of truth" which is the desired output of reconciliation needs traceability back to the original sources, since the "novel decision support" that John Halamka mentioned in his "Smart Medication Reconciliation" blog post, and the more general approach in your IHE proposal, are all aids to get the user close to the goal, but aren't likely to get them 100% of the way there with 100% certainty. Thanks for the proposal, and I look forward to its progress.
ReplyDeleteDavid Tao
Keith, great post. In the medication space, NCPDP SCRIPT based Medication History transactions from either Prescription Benifit Manager (claims) or Pharmacy sources via the Surescripts network are a great method to confirm that ordered medications are being taken. Secondly, I see a role in PHRs providing similar confirmatory information.
ReplyDeleteGeorge Robinson, Sr Pharmacy Informaticist Partners
Hi Keith. Just to add to this thread, it's a very challenging and interesting problem. I've been working on this for medications, allegies and problems for the past 2 years and have learned many lessons. Some of the challenges especially when we start talking about problems are (a) the level of aggregation/subsumption that would need to be done without loss of important details and (b) the differentiation between essentially inferred and verified active meds/problems/allergies. It's very tricky. Glad to share more if there's interest.
ReplyDeleteKeith,
ReplyDeleteI just noticed that there's an existing IHE PIR (Patient Information Reconciliation) profile http://wiki.ihe.net/index.php?title=Patient_Information_Reconciliatiwithin the Radiology Technical Framework, which is about images on unidentified or misidentified patients. Since that's already in an approved final version, I guess its name is taken and difficult to change now. Perhaps your new proposed profile should have a more descriptive name such as "Clinical Data Reconciliation" or "CDA Reconciliation" so it doesn't sound too much like PIR.
Yes, I agree, it probably needs a better name, but I leave that up to the planning committee, because at least we understand the concept. I should check in with the cochairs -- oh heck, that would be me.
ReplyDelete