Todd Cooper

When President George W. Bush declared in 2004 that most Americans would have an electronic medical record (EMR) by the end of 2014, there was an implicit mandate to have device interoperability before 2015. As we entered 2009, there was a cautious sense of anticipation regarding the assignment of a common device connectivity (CDC) use case1 to the Healthcare Information Technology Standards Panel (HITSP),2 marking the first time that in-patient acute care medical devices would be considered along with all the other health IT applications that were on its docket. It covered everything from basic integration with electronic health record (EHR) systems to full disclosure databases to wireless connectivity and first link interfaces on medical devices.

In February, literally days after a HITSP technical committee started formal discussions on the device connectivity requirements, our caution proved true: Passage of the American Recovery and Reinvestment Act of 2009/Health Information Technology for Economic and Clinical Health Act (ARRA/HITECH) legislation3 meant that for 90-plus days everyone would be refocused on reevaluating all of the work to date and reorganizing it to address the new mandates. That meant that all the device connectivity stuff was on the back burner … yet again.

By the time mid-August rolled around and HITSP started to pick up the pieces of work from earlier in the year, the question of what to do about devices was raised. Only now HITSP work products had been enhanced to include capabilities and service collaborations and there were new sources of device-related requirements, including the then recently published “meaningful use” matrix4 that identified an objective of medical device interoperability, targeting 2015. That’s good, right?

Pulling Together an Action Plan

The refined HITSP framework (courtesy of HITSP).

The problem was that with goals coming from the ARRA/HITECH legislation, objectives and milestones from the HIT policy committee5 in their “meaningful use” matrix, and requirements from use cases, including common device connectivity, remote monitoring, and emergency responder EHR, it became evident that device connectivity is easier said than done.

It was quickly determined that instead of wading into all the details and getting completely lost, a framework document should be rapidly developed that would review the relevant HITSP requirements and then propose a multiphased road map for how these goals might be met—and within the time frame specified. HITSP/TN905 device connectivity technical note represents the results of that activity, running from late August through to Thanksgiving, and is now out for public comment.

Now is your chance to review TN905, provide feedback, and potentially affect how device connectivity will be addressed over these next few years as part of the US health care reform effort.

The technical note looks at requirements from numerous sources, discusses general device connectivity issues and applications, and then establishes a road map that includes a “gap” analysis and suggestions for the development of open standards-based technical solutions. It includes the following major sections:

ARRA/HITECH and Device Informatics

This details those elements of the ARRA/HITECH legislation and meaningful use matrix that either directly mention devices or that benefit significantly from the availability of rich timely device data and services. Though the legislation does not use the “D” word, it does identify related deliverables such as patient monitoring, improved patient safety, and technologies that reduce medical errors, improve health care efficiency, and support telemedicine.

The Office of the National Coordinator (ONC) for Health Information Technology (HIT) health IT policy committee does directly reference devices in its “meaningful use” matrix and includes goals or objectives for the 2013 and 2015 years, including:

  • Medical device interoperability;
  • Closed loop medication management (The Five Rights of Medication Safety and electronic medication administration record—or eMAR—integration);
  • Clinical decision support—both for the enterprise and point of care; and
  • Access to comprehensive patient data— including full disclosure device data.

The message is clear that device interoperability and informatics are key components in its vision for health care in the United States.

Device Connectivity Landscape

This attempts to paint a picture of what device connectivity means, outside of narrowly focused use case documents and government legislation. This includes major sections on how devices at the point of care integrate with and support enterprise applications (EHR, flow sheets, and clinical decision support, or even medical equipment management), or clinical pathways and specific classes of workflow such as perioperative assessment. It includes a discussion of highly integrated, patient-centric point-of-care integration and integrated clinical environment (ICE)-based frameworks,6 supporting “smart” alarms, safety interlocks, real-time device-to-device synchronization, and even physiological closed-loop systems.

Additionally, this section calls out a number of design issues that should be factored into any technical specifications that include medical device communication, including:

  • Devices are … everywhere! And a given modality, such as an infusion pump or ventilator, may play differing clinical roles based on the care context in which they are deployed;
  • Semantic content—terminology and information models—must be coordinated across all care contexts;
  • Standard interfaces do not exist on most devices today, requiring the use of intermediary architectures such as gateways;
  • Security breaches can result in significant adverse events;
  • Clinical viewing of full-disclosure device data is typically filtered and summarized; and
  • Alarm communication can be life critical—life critical.

Though the list is not exhaustive, it provides a glimpse of some key issues for those who are not familiar with medical equipment integration and management.

Regulatory Considerations

A dimension that is unfamiliar to many in the HIT arena is what it means for a device or software application to be designated a regulated medical device. What are the implications? The technical note not only provides definitions for medical device, medical IT network, risk analysis, etc, but also considerations such as:

  • “Stand-alone software” applications as medical devices;
  • Creating medical IT networks via integration;
  • Alarm communication;
  • Risk management of medical IT networks—a full life cycle process; and
  • It concludes with a discussion on how these considerations may affect the manner in which HITSP addresses specific connectivity requirements.

Specific Requirements from Use Cases

Though the previous sections are either very high-level (ARRA/HITECH) or are general (landscape and regulatory), the requirements from HITSP use cases must be analyzed to a level of detail that allows the creation of a road map. Given the CDC use case’s summarization statement (“The ability to communicate high-acuity and inpatient multi and single parameter device information to and from an EHRS and other specialized clinical information systems via direct network connections and wireless networking within an organization”),7 this section addresses application and device types or modalities that are in scope for HITSP constructs (a broad list), data types and value sets that must be supported, transactions and document templates, full disclosure persistence, and even ICE supporting requirements.

Coupled with the requirements from the “meaningful use” matrix, as well as the remote monitoring and emergency responder use cases, this identifies the specific requirements that must be addressed by the development plan.

Road Map and Gaps

The most interesting and important element of the document is a road map proposal for how HITSP should address device connectivity over the next few years. It does so by identifying a set of target capabilities and a multiphased sequence of functional targets ranging from 2010 to 2013. These interoperability categories include:

  • Standardized device semantic content, or,in other words, parameters from onemanufacturer’s ventilator must be consistent with those from a different manufacturer;
  • Device-to-enterprise data reporting;
  • Point-of-care test device reporting;
  • Alarm communication and management;
  • Closed-loop medication administration;
  • Device point-of-care integration; and
  • Medical it-network management.

There is also a set of critical technical issues or “gaps” that need to be resolved in order to deliver on the road map, usually requiring coordination between HITSP and other external groups.

Capabilities, Service Collaborations, and Constructs

Based on the development road map, a framework is developed for which HITSP constructs, capabilities, and service collaborations will have to be created.

The graph on page 22 provides an overview of the HITSP process and work products that resulted from the 90-day effort to address the ARRA/HITECH legislation. All HITSP interoperability specifications are built on open standards, either base standards such as HL7 v2, or composite standards that profile a set of standards that are needed to solve a specific integration problem. The refined model added capabilities and service collaborations to the constructs that already existed—interoperability specifications, transactions, transaction packages, and components, such as a specific document template. These additions enabled the constructs to be more easily expressed in high-level capability concepts, “communicate imaging information,” HITSP/CAP128, for example, and to be more easily integrated into service oriented architecture implementations. More details on all HITSP items is provided at www.HITSP.org.

External Coordination

Finally, the technical note recognizes those standards-based organizations that are actively working in the device connectivity area, including IHE, HL7, ISO, IEEE, and the Continua Health Alliance. Thus, though a HITSP road map is presented, ultimate success is dependent on close coordination with these other standards groups to develop the technical solutions (base and composite standards and specifications) that will be referenced by the HITSP work products.

When all of the above is considered, it represents a formidable body of work indeed! The good news, though, is that the technical note was not created in a vacuum, but by many of those individuals who are working in the external coordination organizations identified above, and thus any wheel reinvention will hopefully be greatly minimized.

Your Opportunity to Affect the National Road Map

The window of opportunity for providing formal public comment to HITSP/TN905 will be open through the third week of December. You can retrieve the draft technical note and the online submissions tool at www.hitsp.org/public_review.aspx. Also, if you are interested in working on the final draft to be submitted for final approval by the HITSP panel at its January 25, 2010, meeting, please contact either Todd Cooper () or John Donnelly ().

Of course, after that the real fun begins—making good on the road map! Perhaps we are on a path to the device connectivity tipping point and the Holy Grail is even more within your reach now than even last February.8 Maybe even medical device interoperability by 2015!


Todd Cooper is president of Breakthrough Solutions Foundry Inc, San Diego, serving the medical device informatics and interoperability arena. He is a key contributor to the HITSP/TN905 Device Connectivity Technical Note, and a co-chair of the IEC 80001 standard and guidance documents that address risk management of medical IT networks. For more information, contact .

References

  1. US Department of Health and Human Services Office of the National Coordinator for Health Information Technology. Common device connectivity AHIC extension gap. December 31, 2008. Available at: healthit.hhs.gov/portal/server.pt/gateway/~pdf. Accessed November 20, 2009.
  2. The Healthcare Information Technology Standards Panel (HITSP) is a cooperative partnership between the public and private sectors. The panel was formed for the purpose of harmonizing and integrating standards that will meet clinical and business needs for sharing information among organizations and systems. Available at: www.HITSP.org. Accessed November 20, 2009.
  3. HIMSS. The American Recovery and Reinvestment Act of 2009. Summary of key health information technology provisions. July 1, 2009. Available at: www.himss.org/content/files/HIMSS_SummaryOfARRA.pdf. Accessed November 20, 2009.
  4. Health IT policy council recommendations to national coordinator for defining meaningful use. Final—August 2009. Available at: healthit.hhs.gov/portal/server.pt/gateway/~pdf. Accessed November 20, 2009.
  5. Health Information Technology Web site. healthIT.hhs.gov. Accessed November 20, 2009.
  6. ICE, or Integrated Clinical Environment, based on the ASTM F2961-2009 standard. Available at: www.MDPnP.org. Accessed November 20, 2009.
  7. HITSP common device connectivity (CDC) use case, section 2.2. Available at: wiki.hitsp.org/docs/IS77-3.html. Accessed November 20, 2009.
  8. Cooper T. Connecting to the holy grail. 24×7. 2009;14(2):32-33.