This new report (download page) is focused on the factors that contribute to effective home health care: integrated and easy to use medical devices and information systems, and the physical characteristics of a home that is supportive (or at least does not present barriers) to home health care delivery. There is quite a mix of recommendations in this report, from the insane (numbers 6 and 7) to the most excellent (numbers 4 and 9).

I came across this via a Modern Healthcare blog post by Joseph Conn. Like me, Conn was drawn to the first recommendation (from the NRC report):

Recommendation 1. The U.S. Food and Drug Administration and the Office of the National Coordinator for Health Information Technology should collaborate to regulate, certify, and monitor health care applications and systems that integrate medical devices and health information technologies. As part of the certification process, the agencies should require evidence that manufacturers have followed existing accessibility and usability guidelines and have applied user-centered design and validation methods during development of the product.

In his blog post, Conn quoted David Wegman, the chairman of the NRC's Committee on the Role of Human Factors in Home Health Care, which produced the report, on the roles of the ONC and FDA as it relates to medical devices and HIT:

“As it is now, the ONC has the responsibility for the credentialing and oversight for health information technology and the FDA over devices,” Wegman said. “The gap is when those devices are interconnected.”

It seems to me that Wegman's wrong about the FDA and the purported gap between medical devices and HIT. First, depending on the intended use claimed by the manufacturer, software applications can (and do) meet the legal definition of a medical device, and are regulated as such by FDA. Also, the FDA neither certifies products (like the FAA does airplanes), or compels manufacturers to adopt specific standards for their products (although this is encouraged). The principal mission of FDA is to ensure the safety and effectiveness of medical devices. Wegman's right about the ONC, although they don't directly certify HIT products. The ONC is focused on driving interoperability, standards adoption, usability, and the actual use of HIT products in a meaningful way.

Who Will Regulate EMRs?

The gap between ONC and FDA is not so much the types of products they regulate; I suspect that they will increasingly claim oversight of many of the same products in the near future. The gap lies between the different missions of the two organizations. For example, the ONC gives little attention to patient safety. There are no certification tests that ensure patient safety, instead they are focused on providing a base line set of functionality (including support of certain standards), and end-user usability. The ONC has no reporting mechanism or legal requirement that HIT vendors and providers report incidents that could have or did result in a patient's injury or death.

Another important difference lies in how they're legislatively empowered. These two different operating approaches, combined with different legal and bureaucratic authorities, could easily result in gaps that will impact products that pass through both organization's purview.

As an aside, FDA has undertaken a big initiative focused on the use of medical devices by lay-people. The option to take an infusion pump designed and intended for use in the hospital, and labeling it for home use is pretty much over. And a key lever for ensuring the safety of the home based devices is usability - if the patient or caregiver can't effectively use the device, how could it be safe?

I expect ONC to continue to squabble with FDA, in an effort to protect their clients (EMR vendors) from an additional regulatory burden. It is doubtful that FDA will roll over for ONC. Rather, they will likely continue their planned approach and ONC - along with HIT vendors - will just have to deal with it. In fact the expectation that FDA will eventually regulate EMRs, or at least parts of EMRs, has been around for some time.

Medical Device Interoperability

One remaining problem that was explored in Conn's blog post is how to incentivize medical device manufacturers (and EMR vendors to a lesser degree) to adopt industry standards and pursue the certification efforts necessary to realize actual cross-vendor interoperability. As noted above, FDA lacks the authority to make that mandate. The ONC can mandate standards on the HIT side - which is an important first step, but lacks any authority over medical device manufacturers.

Fortunately, there are two ongoing industry efforts working to drive medical device interoperability. The one most closely related to the home health market is that undertaken by the Continua Health Alliance. This organization, mostly driven by manufacturers, is working at break neck speed (at least for the medical device industry) to create cross vendor interoperability for the ambulatory remote monitoring market that they target.

Another interesting initiative are the efforts behind the Integrate Clinical Environment standards effort. The implementation of ICE is being driven by a number of government grants from places like the NIH and DoD. Another facet of the ICE effort is work with FDA, Continua, AAMI and the Medical Device Plug and Play Interoperability Program at CIMIT.

A third effort, and one that's farther down the road in many ways, is the IHE PCD domain. The IHE was created as a test and certification consortium for HIT applications and the integration of HIT with medical devices.

Two very successful areas for IHE are the radiology and clinical lab domains. In both cases there were industry standards adopted by both HIT and medical device vendors, and the IHE facilitated the agreement on use cases, and provided certification tests to prove conformity. The PCD (patient care device) domain is hobbled with a major weakness, there is no industry standard that's been adopted by industry that can be used to integrate medical devices and HIT.

Consequently the PCD domain has had to select industry standards to support the use cases they wanted to implement, and wait for manufacturers to build those standards into their products. Rather than select one broad standard, like DICOM, the PCD domain has taken a piecemeal approach, using bits and pieces of standards, and when necessary creating their own "standards" such as rosetta terminology mapping.

Started in 2005, there are finally a goodly number of vendors with commercial products that support the basic profiles (use cases). The more recent profiles shown at the Interoperability Showcase at HIMSS are mostly works in progress and not yet available as commercial products. It is the slow progress of the participants in the IHE PCD that gave rise to more recent efforts like the ICE standard.

Once characterized as a "market expense" by industry participants, the IHE PCD has become a more serious forum for cross vendor interoperability. This was probably inevitable as the number of defined uses cases or profiles grew to encompass more complete and meaningful workflows like alarm notification. The IHE's biggest strength is the adoption of its profiles as selection criteria in providers Requests For Proposals. Support for IHE PCD profiles will be increasingly important to connectivity solution vendors targeting applications like clinical documentation, alarm notification/messaging middleware, remote surveillance and data aggregation.

One final effort that should have an important role to play is the MD FIRE project. This effort, called the Medical Device "Free Interoperability Requirements for the Enterprise," is the result of collaboration by legal council at Partners Healthcare, Johns Hopkins and Kaiser. These institutions came together and created legal language that can be inserted into Requests for Proposals and purchase agreements that places legal burdens on medical device manufacturers to provide connectivity and interoperability capabilities.

It is well known that providers want open systems with cross vendor interoperability. Sadly, it is also well known that most providers will simply buy whatever their currently favored vendor wants to sell them. It is only by including requirements like those in MD FIRE that manufacturers will be incented to actually make those features available - some day, hopefully before I retire.