Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Thursday, November 18, 2010

Reconciliation

No, this isn't about me making nice with someone after teeing them off ...

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
  1. Knows how to get information from other information systems, including EHRs, PHRs, Immunization Registries, disease registries, ePrescribing hubs, or HIEs.
  2. Understands the semantics by which problems, meds, allergies, et al, are exchanged (via CCD/C32).
  3. Can automatically identify duplicated, updated, or new information based on those semantics,
  4. And can interact with a User Agent to display to the provider, and get updates back from the provider on these changes,
  5. And can report the reconcilled results.
Now, like I said, we do this every time we sync our smart phones with our calendars and contact lists.

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.