EHR MU - Interoperability, but of what?

In preparing for my presentation on Stage 2 Meaningful Use (MU) requirements for the November, 2012 Fourth Annual Medical Connectivity Conference I had the opportunity to delve further into the question of what had to be connected to what, and interoperable with what, in order for providers seeking EHR incentive payments to satisfy their MU obligations.  (I ended up making this presentation by phone from New York to Boston because of the lack of transportation out of New York post hurricane Sandy.)

Stage 2 of the federally defined Meaningful Use (MU) is now upon us (details here), and a recurring theme is clearly interoperability. But what this means, and to whom, has not always been clearly presented. In this regard there has been occasional talk from the medical device engineering side of the room that MU requires that a variety of "traditional" medical devices must be able to send data to the EHR. (I introduce the term traditional here to distinguish common bedside medical devices from new players such as Clinical Decision Support systems (CDS) and perhaps EHRs themselves.) However, with a few exceptions, these traditional devices are not part of the MU requirements, and an actual reading of the Stage 2 regulations, and the means to test EHRs for certification, shows that there is no required call for such direct communication. This does preclude that some elements of the Stage 2 requirements might be enabled by connectivity of traditional medical devices, but might is clearly not the same as must. In this regard the official definition of MU must be separated from the general notion of in some way using an EHR for some meaningful end. It might also be noted that some parts of required MU might in fact not be very meaningful.

What medical devices do require connectivity for MU? The answer is imaging and lab, from which diagnostic results must both be accessible from or within the EHR. And the lab results  must be "structured data" which presumably precludes sending a fax and then scanning it in. Another medical device arena is the requirement for multiple CDS functionality within the EHR, where each CDS application must operate automatically on information already in the EHR, i.e. the CDS must automatically do its assessment and notification alert without further intervention by the user. Of course the user will then have to determine what to do with the information provided. To the degree that a CDS is a medical device (and the FDA has certainly acted in a way that shows that at least some of them are), then a CDS that is part of MU of a EHR is a connected medical device, albeit not a traditional one.

The vital signs component of Stage 2 MU is a good example of an element that might use connectivity, but which doesn't have to. On a recent medical encounter of my own, various vital sign data was observed by the technician and then typed into the nearby desktop without first writing it down (on cuff, palm or scrap of paper). MU does not require that the vital sign data arrive in the EHR automatically via a connected solution. It only requires that the data be entered and available, and manual entry is fully acceptable. So while an automatic data delivery vital signs solution might be attractive, there is no requirement that this be the approach taken.  In this regard the MU certification test method for vital signs appears to be written for manual entry, and an auto-only implementation would require some talking around the test method.

We might recall why auto-vital signs is thought by some to be desirable (other than the medical device vendors). The usual reasons are it is faster (more timely and efficient), correspondingly frees the care giver from the task, and there would be an elimination of transcription errors. More-or-less continuous (or regularly sampled) vital signs data might also be enabled, addressing the problem of the only data that is available being old data. However there are few positive things in life without a potential downside. Here the possible downsides are incorrect association of data and patient, unreliable success of transmission, and the loss of an active human filter on whether the data seems correct or not. Note that here the human does not determine if the data is actually correct because they typically don't have an alternative measurement. Instead they can only determine if the data seems reasonable. In this regard unreasonable data, assuming it can be well defined, is a fine candidate for automatic detection.

There are no current MU requirements for other patient specific medical devices (e.g. infusion pumps, monitors, ventilators, etc.) to communicate with the EHR, and little place in the MU elements for the use of such data, even if it were available. While there may be uses for such data other than MU, and these uses might be meaningful in a more general sense, I have seen more articulation of how it was being done than why it was being done. At a minimum it does create a historical  record, but one that is likely never to be looked at unless there is an untoward outcome. MU has much more of an emphasis  on immediate/point-of-care value.

So that covers medical devices. Yet there is much talk of interoperability in the context of EHRs, but in general it means the exchange of data from one EHR to another, to a Health Information Exchange (HIE), to public health data bases, or to and from the patient. This type of on line data exchange is an important part of the promise of EHRs to actually have a positive impact on individual care and public health, and these exchanges  are required (although how it is going to happen is an ongoing struggle). But these exchanges  do not involve traditional medical devices. However if an EHR is a medical device (which is yet to be fully vetted), then the interoperability requirements become applicable to them as medical devices, and then one could say that there is an MU requirement for interoperability of medical devices. But this line of semantic, if not circular reasoning, still doesn't mean that other devices need connectivity for MU purposes. There are also other connectivity functions that are required such as Computerized Physician Order Entry (CPOE), but again this does not involve a traditional medical device.

Another MU term that caught my engineering ear was the discussion of  feedback in medication delivery. Further reading showed that this did not mean that the drug delivery mechanism was being automatically controlled after a drug was ordered and made available, e,g, a closed loop infusion pump. Instead it meant only that a human was providing feedback that the final stage of the drug delivery process had been  executed.

The bottom line is that MU for the most part does not require the connectivity of medical devices and the associated direct receipt of medical device data by an EHR. If someone tells you there is such a requirement, ask them to show you the specific associated MU data element and its explanation. While I am not from Missouri, "show me" is always a good request when there is an assertion that something is required. And the answer has to be specific (e.g. by CFR cite), not generic (e.g. its in the MU requirements).

A word about Stage 3. In general Stage 3 is a discussion at this point so that there are no requirements that have been agreed to. However there is a draft requirement (SGRP 204B) that some home medical device data be made available by patients to an EHR. An early draft of this element alluded to this happening automatically through a device connectivity solution. However the current draft does not suggest this. Instead patient entered data would suffice without a requirement that the device be the direct communicator. But automatic is certainly not precluded. Another general lesson here is that early discussions and drafts are not requirements, and might not ever be requirements. Pay attention--yes. Say, you have to--premature.