The Evolution of a Problem and its Solution

One of the well received pieces of feedback on the IHE Reconciliation profile this week was about the maintenance of identifiers for information items produced as a result of a reconciliation process.  Essentially, if you incorporate a fact about a patient into your EHR that was externally sourced, you have to retain and reproduce the identifier you originally recieved with it.  We had made that a strong recommendation, but due to feedback, changed that to a requirement.

As a result, we needed to address another issue, which is how information evolves over time, and how its identity changes over time as well.

There are a number of interesting cases:

1. Status Updates
2. Changes in Treatment 
3. Additions of new Information and relationships 
4. Correction of Erroneous Information
5. Disease Progression 
6. Changes in Diagnosis

Status Updates

Status updates do NOT change the identity of an act that has been recorded.  Over time, order #### has been placed, shipped, canceled, received, paid et cetera.  Over time, diseases are active and resolved, treatments (e.g., medications) are active, completed, canceled or discontinued.  Et cetera.  If during the reconciliation process, you make a status change, it does not change the original identity of the item.   

Changes in Treatment

Medication X is discontinued, replaced by medication Y, or is used in a different dose and/or frequency are examples of this case.  In this case, the Status of the old medication is changed (to completed or , and a new medication information item is created with a new identity.  The status of the old item is changed to reflect the reason kind of change made.

If a medication was discontinued without replacement before it was expected to be finished normally, it would be marked as "aborted".  Marking an act as "aborted" is a cue that the act was terminated abnormally without any replacement.

If it was discontinued without replacement before it was expected to be finished normally, and a new medication replaces it, it should be marked as "obsolete".  The new information item can be marked as the previous acts replacement.  If dose or frequency are changed, it should be treated the same way.  Marking an act as obsolete is a cue that that you should look for a replacement.

If the medication completed normally (e.g., a three month prescription), and its replacement is different (in medication or dose), then it should be marked as completed, and the new information item with a new identity can be linked as its successor. 

Corrections

This old piece of data was incorrectly recorded, and a new piece of data replaces it.  Again, pretty easy.  In this case, the old information item has its status changed to "nullified", indicating that it was incorrect, and the new information item has a new identity, and can be marked as the replacement for the old one.  This kind of correction only applies when there have been mistakes in entry or reporting of the information, NOT when there have been mistakes in judgement (see changes in diagnosis below).

Additions

Let's say that you have an allergy with a known manifestation of hives.  Subsequently, it is determined that a new manifestation exists that is anaphylaxis.  The new manifestation has a new identity, but is attached to the old allergy and the identity of the old allergy does not change.  Similarly, you can have an assessment of the severity of a particular disease.  The assessment may change over time.  Each time it changes, it takes on a new identity, but the original observation to which it applies does not change its identity.

The addition of descriptive attributes previously unknown (e.g., a stop date), also would not change the identity of an information item.

Progression of Disease

Influenza can eventually result if not treated into pneumonia.  This is a natural progression of disease along a particular pathway.  In this particular case, the progression to pneumonia is a new observation on the patient with a new identity, and the previous observation can be retained as well with its existing identity, because both are true. Note, in this case, the "concern" act from which the influenza observation originated would have a new observation associated with it for the pneumonia.  The identity of the original concern does not change. There are cases where the diagnostic categories form a progression that excludes the previous category (e.g., Stage I Cancer vs. Stage 2 Cancer).  In these cases, the original observation

Changes in Diagnosis

This is the stickiest one to deal with.  A change in diagnosis is a new judgement, clearly, and that has a new identity.  However, I'm not sure what to do with the old one.  If the previously recorded diagnosis of X was made as the result of a clinical judgement, and it is incorrect, the following things are true statements:

• A previous diagnosis was made that the patient had X.
• That diagnosis was incorrect.

I think the right way to handle this one is that same as if you decide to change the treatment for a patient.  The old diagnosis is marked as "aborted" (NOT nullified).  

My reasoning is this:  The old diagnosis (or assessment) did exist.  Marking it as "aborted" indicates that the line of reasoning was prematurely terminated (e.g., in light of new information).  If instead, it had been marked as nullified, it would have indicated that the diagnosis was reported or entered incorrectly, which is in fact, NOT the case.  It may very well have been reported and entered correctly, but was made based on incomplete or incorrect information.  When a diagnosis is changed in this way, it indicates that the providers judgement has changed, and follows the recording pattern whether that judgement is about the condition the patient is suffering from, or the treatment they are given.

This doesn't solve every issue.  One thing I'm still struggling with is how to deal with "holds" or temporary suspensions of medications.  I believe the right way to handle this is to report every suspension event along side the medication event.  I think of suspensions to be a new event (an override of a previous decision based on temporary factors).  Reporting both allows the receiving provider to be aware that a patient is NOT currently taking their medications (e.g., due to a pending surgery).  However, I think what we need to do with this particular issue is call it out as being something that needs a profile without addressing it in the reconciliation profile.

IHE PCC Reconciliation

IHE PCC just finished a week full of meetings in Oak Brook to complete development of its profiles and white papers for public comment. One of the profiles we are working on this year is Reconciliation of Diagnoses, Allergies and Medications, or RECON for short.

The RECON profile has one actor, the reconciiation agent. Usually this would be implemented by an EHR system. The actor has functional and technical requirements.

Functionally the actor is required to access clinical information about problems, medications and allergies. That information must be able to come from clinical documents, and may also come from queries using the IHE QED profile, or using data from other unprofiled sources.

The actor must then determine which of the various diagnoses, allergies and medications reported from the various information sources are in agreement, and which are different. It must then suggest changes to make to a final list. IHE doesn't say how those changes are suggested, but does offer some guidance in this profile on what information might be used to help make those decisions.

The healthcare provider using the system that supports this actor will then be able to make any corrections, additions, or updates to the lists.

Finally, the system must be able to report the reconciled results. The results reported include what was accepted by the healthcare provider during the reconciliation process, of course. But they also identify the healthcare provider(s) who reconciled the data, and the information sources that were used during reconciliation.

This profile will enable systems to take advantage of information communicated in, for example multiple CCD documents, and to coordinate it with information stored within an EHR. One benefit of this profile that because it also records the sources of information which have already been reconciled, a receiving system can also avoid work by taking advantage of that fact. Thus, if a system receives information in document C which contained information reconciled from document A and B, then it could avoid reconciling against document A and B again.

It will soon be published for public comment and I look forward to your feedback.

Update on the IHE Reconciliation

The IHE Patient Care Coordination met in Canada about a month ago to review work items we are delivering this year.  I'm focusing on the Reconciliation profile in that committee.

So far, we have completed a big chunk of the Volume I work (overview, scope, use cases, actors and transactions), and are just getting started on Volume II (technical details).  Because of the many simplifications that we implemented a month ago, this is mostly a content profile.  Accessing the data used for reconciliation is supported by IHE IT Infrastructure profiles (e.g., XDS, XDR, XDM), and the structure of problems, medications, and allergies is specified in IHE PCC Content profiles.

The major additions to content include the following:

A reconciliation act which collects:

• The identity of the person performing the reconciliation.  Open question:  Other than name, address, telephone and ID, should we gather other data (specialty, licensure, et cetera).
• The sources of information, either as
• Documents, in which case we need to know the Document used, and the system (e.g., HIE home community identifier) from which it came (perhaps captured as an informant).
• Query Results (using QED), in which case we need to know the query used to retrieve the data (captured as observation media), the performer of the query (to address issues of acess  ontrol), and the system from which it came (an identifier similar to the home community ID).
• The clinical statements that were produced as a result of the reconciliation process. 
• Relevant links between the resulting clinical statements produced from reconciliation, and any previous clinical statements showing the progression of information.  For example, if a different medication regiment is intended to replace an existing regimen, this link should be present.  A similar case might occur where "back pain" is subsequently diagnosed as a "compressed disk", in which case the latter diagnosis might "replace" the former.

The final piece that is needed is a discussion of the "Concern model" which HL7 used to keep track of problems and allergies as they progress through the care and treatment process.  This will likely be added to Volume I at a high level, and then be reflected in some clarifications in Volume II on the Concern, Problem Concern and Allergy Concern entries.

One issue that needs  further attention is how to deal with updates to documents or content used in reconciliation.  The IHE IT Infrastructure DSUB (pdf) profile allows a system to subscribe to documents for a patient, but in this particular case, we'd actually want to subscribe for updates (replacements) of the specific documents used in the reconciliation act.  That's not presently supported by DSUB, but I think we'd want to see that option.  It's dealing with an edge case that we'd hope would be infrequent (replacing a document reported in error), but still important to the process.

I don't think there are good answers to this same challenge for QED yet, although the CM profile effectively acts as a subscription using very similar transactions to QED.  I'll have to think about that one.  

 

Reconciliation of Problems

Today IHE PCC members met to discuss issues around reconciling problems in our first call on the Reconciliation profile approved by the PCC Technical Committee for the 2011-2012 season.  This is probably the second in a series of posts on the Reconciliation profile.

What follows are some not quite stream of conciousness (but nearly so), thoughts on that meeting.  It was, by the way, very productive, thanks very much to Wendy (who I've now embarrased), who lent her expertise from dealing with this problem in Cancer Registries to this topic.

Here is a short summary of what I think were some of the important conclusions that we reached:

Assumptions:
There are two stages to reconciliation, the "automation" stage where software analyzes the information and proposes reconciled results, and the "human decision" stage where a healthcare provider selects the appropriate outputs.

One question this raises which we did address at all was whether the patient could select appropriate outputs.  There is no reason why this profile could not be used by a PHR, but it broadens the use case.  I think that becomes an open question in the profile.

We focused on the first stage, and particularly on problems.  The first step that we identified was that there might be a filter that selects the items from the problem list that need to be reconciled.  In CCD, and therefore in IHE profiles, a problem can be classified as a complaint, symptom, finding, problem, condition, diagnoses or functional limitation.  We pretty much agreed that reconciliation should focus on problems, conditions, and diagnoses.  I don't know that we came to a conclusion on functional limitations.  On complaints, symptoms and findings, we generally agreed that these were typically point in time events that did not need to be reconciled.  So, a patient report of runny nose on 11/1 is different from a report of runny nose on 11/2 even though they might be related to the same diagnosis.

I asserted that all of these items have an identity and that if you encounter two problems with the same identity, then they must, according to the semantics of the information model, refer to the same problem.  If they don't, this is a bug.  This is the only case where we identified that two items are the same with absolute certainty.

The next step is to find items that refer to the same kind of problem. There is a clear case where if the codes identifying the problem are the same for two items, then the items on the list could refer to the same problem.  So, if the code represents "ankle sprain" in both cases, then you have a candidate pair.  Coding systems have built in hierarchies (ICD-9-CM) and is-a relationships (SNOMED-CT) which means that two different codes could also represent the same problem at different levels of specificity.  Identifying these requires clinical knowledge that is outside of the scope of the profile, but we need the profile to be aware that this knowledge can be applied.  But code is not enough, you also need time span.  If the time spans are identical, then the candidate match is very strong.  If they overlap, it is strong, but not quite as strong.  If they are separated by some time, depending upon the problem, they could be the same problem.  For example, if the problem is "lung cancer" an the two time spans are separated by five years, then this might be considered two separate problems, but not if less than that.  But for other diseases, like flu, the time span might be shorter, and for chronic conditions like diabetes, time may not be relevant.  Again, this is clinical knowledge that would need to be applied.

Deciding which code to apply in the reconciled result when hierarchy or is-a relationships exist led to a discussion about which one was preferred, the authoritativeness of the source, and the originality of the information.  Diagnostic tests, for example, tend to produce more definitive and finely specified results than an initial diagnosis (this is a gross generalization).  There seemed to be preference for more fine grained results, but then there is also the desire to be able to access the original diagnosis when available (I think for quality and other metrics).  I think the jury is still out on this, but I personally lean towards the refined result.

One thing we did not address is body site.  Some problems (like ankle sprain) would clearly be different if they applied to a different target site (left vs. right).  So that may also need to be considered.

There are basically three kinds of things to identify: Sets of problems that are identitical (see above), sets which are nearly so (same code and clinically overlapping times), sets which contain refinements (slight variations in code and clinically overlapping times), and sets of these where two or more contain conflicting information (document A says flu resolved at time X, and B says flu still active at time Y where Y > X)



For problems, there is secondary information, like problem status, comments, and severity, which don't seem to be all that useful for determining whether two problems are the same, but which may be information that needs to be reconciled.

We agreed that comments should not be carried forward to a "new" problem that is the result of the reconciliation process, because as data changes, the comment may lose relevance.  For example, a diagnosis of flu that morphs subsequently into pneumonia as more information becomes available, could have a comment to the effect that "watch out for pneumonia" in the flu stage because the patient might be particularly susceptible.  If that comment was retained when the problem transitioned into "pneumonia", it would no longer make sense.

On a similar note, but not widely discussed was "severity".  Severity of a problem can change over time, going up or down.  It's really an "annotation" on the problem, that should have its own effective time, and could appear in multiple instances, but we didn't model it that way in IHE.  As modeled in IHE the Severity observation is not separable from the original diagnosis.  So, I think if we want to deal with severity tracking over time we need to create a new template which includes the effective time of the severity observation.  That won't break anything, and the original IHE severity template is optional on problems, so we can fix it without breaking existing implementations.

Now for some thoughts we didn't address on the call:
Going back to HL7 semantics for problem, and using the example of flu observed on 11/1 in an active problem.  On 11/12 it's still an active problem.  If on 11/14 the problem (flu) is now resolved, then this is simply part of the state diagram for act, going from new on 11/1 to active to completed finally on 11/14.   But, if on 11/14 it instead becomes pneumonia, what you really have is a new act (the observation of pneumonia) that replaces or succeeds the previous act (the observation of flu).  Following the HL7 Concern Tracking model, pneumonia is a new concern that either replaces the previous concern about flu, or could have the concern of flu now as one of its sub-components.  I think though, that in this case, we can safely say that while these are related, they are not the same concern.  But for ankle sprain, where the observation was originally just "ankle sprain" but gets refined to "ankle sprain of deltoid ligament", then the concern is the same, BUT, the observation which is its subject is refined to the new code.

That raises another issue, which is whose concern is this.  If the concern "belongs" to the author, then changing identity of the author changes the identity of the concern.  But according to the HL7 Concern tracking model, the concerns are "of the patient", rather than owned by any single provider:

Thus the concern class can function as a grouper for all activities associated with a specific patient-related problem. The problem can, due to different observations, evolve over time and can be tracked or managed by one or more care professionals. Different professionals may have different opinions of the nature of the problem, but all their observations are grouped under the same concern. So essentially, the concern class is used to track what affects the patient. It is independent of the assigned profession, and can have different personal diagnoses attached. It is what ties all underlying activities (Acts) together.

So, no problem here.  The concern act is a collaboration between healthcare providers, not owned by any single one of them.

That introduces a new problem.  Who is the author of a concern that has been reconciled?  Is it authored by the original provider or by the reconciling provider, or both.  I think here the choice is pretty simple, but again, we didn't address it on today's call.  Realistically, as concerns are updated through reconciliation, the latest reconciler becomes an author at the time of the reconciliation, and the concern can retain previous authors.  The next question I have is what should be necessary to be recorded in a reconciled problem list.  I think that at the bare minimum, the most recent author needs to be retained in the transmission of the information, but prior authors may be retained.

Some other things that came up:
1.  We need a way to indicate that a list of items was reconciled, by who, on what date, and using what sources of information. 

My analysis for this is that this is an act (reconciliation), with a performer (the reconciler), that occured (in event mood) on a specific date and time.  The act references information sources, which can be external documents (a CDA document) or information sources (a clinical data repository returning results via QED).  Describing the former is easy, just use document ID.  Describing the latter is more difficult, as you would at the very least need to describe the query, information source, and date/time of the query, and identity of the querier.  We could potential address that problem by requiring the results of any query to be stored in a document so it could be later referenced if need be.

This act can be contained within an the organizer for the type of list being produced (MEDLIST, PROBLIST, et cetera), which could simplify some data recording for each of the contained content.

2.  Interim results from automation need to include all data that needs or was reconciled, but final results need to include only references to what was reconciled.  That is because the reconciliation agent needs to be able to show the differences between the sources, but the final reconciled list need not, so long as all information can be traced back.

3.  There needs to be some way to represent the clustering of information.

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.