Just the facts Ma'am

We like to think we store facts in our EHR systems. It’s just not that simple. Sometimes even the experts disagree.  The following is derived from a recent response I made on the HL7 Patient Care list on allergies.

An Allergy Observation A that states “no known allergies” at a particular point in time can certainly coexist with an Allergy Observation B that indicates an allergy to nuts that occurred at a later point in time.

The Allergy Observation of B is NOT necessarily a refutation of Allergy Observation A. B may be an allergy developed later in life that did not exist at the time A was evaluated.  Those two facts are completely consistent.

The Allergy List at time A may include an observation for no known allergies.
The Allergy List at time B should include any allergies observations listed and not subsequently refuted, and so should not include “no known allergies”.

That is to say, within an Allergy List, the positive and negative assertions, and assertions of “no known allergies” found in the list should be internally consistent, but it may not be for perfectly understandable reasons.  The process of reconciliation can help here.

Some systems promote internal consistency (a best practice), while others may not, or simply cannot (see below). We all live in a world of both, and there are cases where conflicting information is useful to be aware of.

Nearly a true story...
Somewhere in some EHR, someone has recorded Allergic to Penicillin in my daughter’s allergy list. In some other EHR that have Allergic to Amoxicillin. In a third, she has Allergic to Beta Lactam Antibiotics. In a fourth it records: Allergic to Amoxicillin and NOT Allergic to Penicillin. A healthcare provider looking at an aggregated view of this data would correctly conclude that my daughter has an allergy to some antibiotic, and that further questioning is needed to understand the true case, and to Reconcile the differences. That cannot be automated, and in fact, if the provider with “Allergic to Penicillin” and the other one with “Allergic to Amoxicillin” and “NOT Allergic to Penicillin” merged, how should they reconcile the conflicts in their combined data?

So, if we want to make rules or promote best practices, I’d say finally:

Allergy Observations are independent assessments of allergies to a specific substance, class of substances, or an indication that no allergies are known.
An Allergy List is an aggregation of allergy observations.
A Reconciled Allergy List is usually an internally consistent (according to some provider’s judgment) list of allergy observations describing the patient’s current allergy status, but may include conflicting data when that information may not be able to be interpreted without more investigation.

To be or not to be

Allergic ... that is the real question.  The answer, one would expect, to show up in an AllergyIntolerance resource.  Except that resource is described as:

A record of a clinical assessment of an allergy or intolerance; a propensity, or a potential risk to an individual, to have an adverse reaction on future exposure to the specified substance, or class of substance.

Where a propensity is identified, to record information or evidence about a reaction event that is characterized by any harmful or undesirable physiological response that is specific to the individual and triggered by exposure of an individual to the identified substance or class of substance.

And yet to reason about allergies is also to reason about their absence, and a reasoner could be (reasonably) expect to discover all that is known about allergies in the AllergyIntolerance resource. Because, in a clinical assessment, there is the outcome of "not allergic to X", where X can represent a specific substance (latex), a class of substances (beta-lactam antibiotics), or the universal set of everything (medications).  And yet we have no SIMPLE way to represent this, except as the reason for a LIST of such allergy resources being empty.

If we do not get this right, everyone will certainly remember our sins.

   -- Keith

It Shouldn't Require a 500-lb Gorilla to Get Good Care

Those of you who follow me on Facebook already know my wife was thrown from her horse on Monday.  The short of it is that other than a cracked rib and a possible crack in her sacroiliac, and some serious muscle edema and soft tissue damage, she is otherwise OK, but will need some rehabilitative therapy before she can come home.  Mostly, you'd describe it as a level 10 pain in the ass, literally (reduced to level 5/6 today).

In talking to her case working regarding transfer to Rehab, she said she was waiting on the insurance company to respond (Aetna).  Figuring I could at least rattle a cage, I called the customer service number on the card.  I asked when Aetna might be able to complete the prior authorization for her transfer.  He looked it up and told me "we just got that in today at 12:05", and later told me "since it is not marked urgent it could take 7-10 days to process" (these are quotes as best as I recall them). And I also learned that if it was marked urgent it could take 48-72 hours.

So I called my employer's benefits center, and with their help, was able to get someone else on the line who gave me better, but still not awesome information.  "It normally takes a few hours, at most two days" she said.  Based on this situation, she and I determined that it was a) unlikely that she would be transferred today, but likely that it would happen tomorrow. I had our representative, a virtual 500-lb gorilla with a great British accent stay on the line with us while we had this conversation, just so she would know that she was being monitored by someone other than just the patient or their representative.

It shouldn't take this kind of effort to get an answer to the simple question: When will this get done.  I don't care about service level guarantees that are so long as to be completely f*****g useless. There's a 24-hour delay in this service that is completely unnecessary. That's a hospital bed being used wastefully, a patient not being cared for at the best level of service, a bed gone waiting somewhere else where she could have care, and all because why?

I don't care really.  I can put a number on the increased costs of care in this kind of situation that is directly addressable within the payer's nearly complete control, and as it so happens, there's something I personally can do about this as well.  It shouldn't require a 500-lb gorilla to get good answers, and it shouldn't require a day and a half to approve good care.

I went into this situation with low expectations on the administrative side, and unfortunately, they were pretty much met as expected.  Look out folks, I may be setting my sights on a new target.

-- Keith

P.S. In further news, I must have rattled the right cage.  She was transferred today.

Hackers on FHIR

One recent concern about FHIR that has crossed several different list servers recently is that of making patient health data more readily hackable.  In one scenario, the concern goes: If we make patient data more accessible via FHIR, that will also make it more likely to be hacked.  Another scenario goes: We need to ensure that all data accesses include notification to the patient to ensure that hacking doesn't occur.

A couple of comments on these and similar concerns:

Making it easier to use APIs to access health data, and using standards that everyone else is using ALSO makes it easier to secure data using off the shelf technologies.  Secondly, we can apply all of the learning that goes into securing non-Health APIs to secure Health APIs.  Thirdly, we will have to learn.  Not rolling out modern APIs to make patient data more accessible is NOT the right answer.

However, at the same time, we don't want to mandate a one-size-fits-all solution for security.  When you are using FHIR on the back-end to coordinate between disparate systems in the inpatient setting, that could involve thousands of transactions.  These should be secured, but notifying the patient of each transaction isn't the answer either.  That kind of information flood may indeed show evidence of a hack, but if only one in a hundred messages contains the signal, sending all of them means it will likely be lost.  Google sends me a message every time a new computer is used to access my account. That's a great example of filtering the content.

We need to learn from others, we need to take care with patient information, but the last thing we need to do is PANIC.  FHIR already includes much that supports securing information.  Unlike anything I've seen go before it in HL7, it integrates audit and provenance and partitioning in the core of the specification, and provides support for authorization, authentication and access control, and not just as an afterthought.

Hackers will try, and in some places, we already know they will succeed.  Standards cannot ensure good design, they can only make it easier to do so.  It will be up to us, the implementers, to take advantage of those features in a smart way, to protect the most vital and sensitive data of patients.

   Keith

IHE PCC Bed Management Profile

The IHE PCC Bed Management profile represents a departure from business as usual in the IHE PCC Technical Committee.  It is neither a modern CDA based profile, nor a post-modern FHIR based profile.  Instead, it returns us to working with the twentieth century HL7 Version 2 family of standards.  Why? In this particular case they are widely implemented in the systems where Bed Management is important, they aren't broken, and they are quite sufficient to the use case.  I just uploaded the draft version of the profile for our Volume 1 review next week, where most of the committee will be in Portugal meeting to go over the materials.  I, alas will not be, as I have to be in Orlando suffering (#sarcasm) through a vacation with my family.

The problem this profile attempts to address is to reduce patient wait times for beds when being transferred from the ED to the inpatient setting.  While this profile may use ancient messaging technology, it does provide some support for modern 21st century analytics.  By communicating early in the ED visit, the bed manager can make predictions about resource needs (both beds and staffing), an support appropriate measures in order to provide better care.

In this profile the ADT Patient Registration system communicates patient demographics to the EDIS. The EDIS communicates patient status (potential need for a bed, patient acuity, movement, et cetera) to the bed manager so that it can apply predictive analytics to support resource allocation.  The Order Placer is assumed to be a CPOE component by which the ED physician enters an admission order to the bed manager.  The Bed Manager communicates bed status to the EDIS and ADT Patient Registration system.  Finally, the ADT Tracker support tracking of activity so that facilities can create dashboards, digital bed boards, and capture measures of quality (e.g., time between order to admit and patient transfer from the ED) to support better management of facility resources.

I'll be working in the pre-park (Universal) morning with the IHE PCC Technical Committee whilst on vacation in order to keep up with reviews of this profile.  While I'll miss most of the fun, I'll at least be able to keep up with my work on this particular item.  Unfortunately, I cannot be in two places at once, and as beckoning as a trip to Portugal sounds, a week playing with my family will still win every time.

   Keith

The five rights of interoperability

You can find many different versions of five rights in healthcare:

• Medication Administration: Right Patient, Right Drug, Right Dose, Right Route, Right Time
• Clinical Decision Support: Right Information, Right Person, Right Channel, Right Format, Right Time
• Imaging: Right Study, Right Order, Right Way, Right Report, Right Action.
• Staffing: Right Number, Right Skills, Right Location, Right Time, Right Assignment

What are the five rights for interoperability?

I would argue for these five:

1. Right Information
2. Right Interpretation
3. Right Time
4. Right Workflow
5. Right Value

Right Information

This defines what information is needed.  The patient lab results, their problem list, preferred pharmacy, et cetera.  I need not say right patient in this case, because right information implies right patient.

Right Interpretation

It's not enough that the information accurately reflect what I need to know, but also that it be in a format that my system can use.  Don't send me information in imperial units when I operate in metric, or bad things can happen (and not just to satellites).  Don't send me just text when so much more could be done with coded data (nor fail to send me your text when you cannot code it).

Right Time

I need it when I need it.  Don't make me get it before I need it or can pay attention to it, nor make me wait for it when I need it, nor give it to me after it might have been useful.

Right Workflow

Don't make me work any harder than necessary to get it.   You'd think right time would cover this, but it doesn't.  Think about how many times users have to jump to another system to get to the data,or are seven clicks away from it when it should just be right there at their fingertips.

Right Value

This is the kicker for me, and a point of failure that most often occurs in so many programs fostering interoperability.  It needs to provide the right value for the user to warrant the investment and effort in taking advantage of it.

Whose rights are these? These rights belong to everyone: from the patient to the doctors office to the the front office to the back office to the payer, to public health and anywhere else.

I'm neither the first person or the last to riff on five rights for interoperability. These are simply my five. Which would you include? 

There is still good in me!

The tag line to this comes from a joke where a long-time friend of mine upon being transferred from Engineering to Product Management claimed that he was going over to the dark side.  I have a weird dual role in that I'm reporting up through the engineering line, but matrixed into product management.  So, I haven't gone over to the dark side completely!

In some ways, I feel like one of the very rare gray Wizards of Recluce, who must carefully walk between two worlds. The challenge for the main character in that story was to learn how to look at things differently from either perspective did normally so as to manage much more than could be done from either perspective alone.

I'm still getting settled in, and until I do, I expect to be spending a good deal more time on the dark than the light.  I hope you'll bear with me until I discover that middle way.