Electronic Health Records On Agency Radar

Sometimes companies don't realize that the software they make is in fact a medical device.

FDA software compliance expert John Murray says any product can become a medical device if it meets the broad legal definition of a medical device: an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent or other similar article, including a component part or accessory, used in the diagnosis, mitigation, treatment or cure of disease.

"What's important is what the intended uses are," Murray says. "If you have an intended use that meets the definition of a device, then it will be a device under the law. That would be the strictest view or interpretation of that.

"People call me all the time. They say, 'I have some software that does the following three things. Is that a device?'" Murray continues. "But it doesn't matter to me that it's made out of software. It could be a black box; it doesn't matter what's inside that box. It could be pulleys and gears, belts and levers, vacuum tubes, transformers - even jellybeans could be in this box - but if you're selling this box for the intended use that meets the definition of a device, then it's a device."

Murray says manufacturers need to clearly identify the intended use of the software by describing the product's functionality and output. Firms also need to explain how the software will be used to diagnose, treat and cure a patient.

Companies often "provide me with a long description of their product, and it's always in engineering terms," Murray says. "They will say, 'I have a product, it has a 10 GB hard drive, it has a fiber-optic hotlink that connects me to the moon so I can store data in cheese in the moon, the data comes back from the moon and gets over to the patient, and does this.'

"But what good is that? The perfect engineering description does not help me decide if it's a medical device," he continues. "So I ask the following trick question: 'Pretend I'm a physician. I want you to tell me how your product can help me practice medicine better.' And immediately that salesperson turns on and says, 'We can do this, you can treat patients doing that, you can treat 25 more patients a day. You can make more money. You can diagnose this, you can diagnose that.' Now we're talking about intended use, which is what drives the device decisions."

Sherman Eagles, a consultant with SoftwareCPR and a former software developer for Medtronic, says there are shades of gray, however, when determining whether a product with software is a medical device.

For example, some firms make glucose management software for use on a PalmPilot personal digital assistant (PDA). Although the PalmPilot alone is not a medical device, a PalmPilot sold with the glucose management software pre-installed would be considered one.

"The company that makes the glucose management software is marketing a medical device," Eagles explains. "If they resell a PalmPilot with the software on it as a glucose management product, then the PalmPilot is part of the medical device. If they just sell a software application to run on a PalmPilot that the user already owns, then it is just the software that would be regulated as a medical device. [In that case,] the PalmPilot by itself is not sold for a medical purpose and would not be regulated."

The same applies to Apple's iPhone . San Antonio-based AirStrip Technologies received FDA clearance April 6 to market its AirStrip OB application for use on the iPhone.

Obstetricians can use the AirStrip software to remotely access real-time data for a mother and baby, including heart tracings and contraction patterns.

Further, Johnson & Johnson subsidiary LifeScan has produced a prototype system for the iPhone that aids patients with diabetes management.

However, Apple probably won't need to worry about meeting FDA regulations.

"If an iPhone is sold as a general-purpose mobile phone and a hospital decides to use it for some medical purpose, it would not be a medical device," Eagles says. But if Apple "marketed it for a purpose that met the definition of a medical device, such as a nurse call station, then it would be regulated as a medical device."

According to Murray, it simply boils down to the agency's legal definition of a device.

CDRH doesn't "regulate health IT. It doesn't regulate middleware. It doesn't regulate power supplies," Murray says. "The only thing it regulates is medical devices, and for your product to be a medical device it has to have an intended use that meets our legal definition."

CDRH Working Group Looking AtElectronic Health Records And Devices

In the case of electronic health record (EHR) systems, however, the line between IT software and medical devices is not always easy to discern.

Regulators are now questioning whether certain capabilities and functionalities of EHR systems and other health IT meet the legal definition of a medical device. If so, EHR systems would fall within FDA's purview.

The systems currently are subject only to certification requirements under the industry-based Certification Commission for Health Information Technology.

Carving out what kinds of systems or software fit into CDRH's domain is the top priority for the agency's EHR and health IT working group, chaired by Office of Device Evaluation Director Donna-Bea Tillman, with staff from all device center offices.

With $19 billion allotted in President Obama's stimulus plan to promote the adoption of electronic health records, experts anticipate that use of the systems will increase. And as the technology develops, the systems and software are becoming increasingly sophisticated.

This has led some, including Case Western Reserve University law and bioethics professor Sharona Hoffman, to call for increased federal oversight of EHR systems.

"There has to be recognition that these need to be regulated," Hoffman says. "They are more than just a data-entry product. If they fail, patient care fails."

While there is no hard-and-fast definition of an EHR system, the Institute of Medicine in 2003 identified some core functionalities: they display health information and data, facilitate the management of clinical results and medication orders, and may provide decision support through reminders and prompts. Central to EHR systems is electronic communication and connectivity.

"It could be that only certain portions or functionalities of the software or systems fall under the device definition," CDRH spokeswoman Peper Long says.

The working group "is trying to prepare the center as these issues related to EHRs expand into everyday reality so that any necessary safety and effectiveness evaluation, regulation or monitoring can occur as smoothly as possible," Long says.

FDA agrees that there are potential benefits to EHR systems - fewer medical errors, and more timely and complete access to a patient's medical data, for example - but warns that "those same benefits can easily become risks if the systems adopted aren't designed with an eye toward safety, privacy and connectivity."

The CDRH working group hopes to lay the groundwork for the agency to develop a risk-based, flexible approach that would accommodate different EHR systems and keep up with evolving technology.

EHR Vendors Unhappy About Possible FDA Oversight

FDA took a first step toward enforcing regulation of a type of software involved in electronic record-keeping - medical device data systems (MDDS) - with a February 2008 proposed rule.

The agency has exercised enforcement discretion on the systems, which comprise software that transfers, displays, reformats or stores data from a medical device without acting upon that device. The proposed rule would formally down-classify MDDS from Class III to Class I, but require MDDS makers to comply with quality system requirements and design controls ("The Silver Sheet" April 2008.)

The move has caused some anxiety in the health IT industry, including among EHR companies. In comments on the proposed rule, the Electronic Health Record Vendors Association - part of the Healthcare Information and Management Systems Society - argued that EHRs do not meet the definition of an MDDS or any kind of medical device.

"The unique role that EHRs play in helping manage the care delivery and related decision-support processes ... does not fit the current software medical device model," the association wrote last May. "In view of the nature and purpose of EHR technology, it is our belief that that regulation of EHR technology is outside the FDA's purview."

The group also warned that FDA regulation may hamper federal efforts to increase EHR adoption.

FDA still is reviewing the proposed rule and preparing a response to stakeholder comments, CDRH says.

IEC 80001-1 May Help Ensure IT Network Security

With many device software and IT systems working in tandem, an effort is underway to ensure that the links between the two remain secure and do not cause harm to patients or product users.

"Initially after HIPAA [the Health Insurance Portability and Accountability Act] came out, the whole emphasis was on data security and protection of patient information, but now we also have to consider safety and effectiveness in the delivery of health care along with that," consultant Eagles says.

"The hospital or clinic as a responsible organization owns this problem, and can't do it by itself," Eagles notes. "It needs help from others, including device manufacturers."

The International Electrotechnical Commission (IEC) is working on a draft standard to ensure secure links between medical device software and software systems used in clinical settings.

A final version of IEC 80001-1, "Application of Risk Management for IT Networks Incorporating Medical Devices," could be ready by the end of 2010.

IEC 80001-1 "deals with data and system security, and it's of particular interest to both the manufacturing community and the user community of medical devices," says Brian Fitzgerald, deputy division director for CDRH's Office of Science and Engineering Laboratories.

Fitzgerald's comments came during a March 18 session of the 19 Annual AAMI/FDA International Conference on Medical Device Standards and Regulation in Reston, Va.

"We have an increasing drive toward heterogeneous networks, and that's really being driven strongly for two reasons: first, to reduce common errors, and second, to reduce costs," consultant Eagles says.

"It's believed that automating some of these things will make health care more effective and will reduce the cost of delivering health care," he says. "There's a lot of drive toward trying to utilize IT in hospitals, and that means that we end up with multi-member, multi-mobile networks."

Further, "there's an increasing mix of medical devices and IT technologies, which results in 'systems of systems,' and is resulting in what we call 'unanticipated merchant behaviors' - problems that we didn't know existed until we started attaching all of these things together," Eagles says.

"The way we used to deal with some of those is by segregating the networks and keeping the things that might be high-risk separated as a subnet," he notes. "It's not attached to other parts of the network. However, now that we use wireless, you can't really separate things like [we could with] cable, so now we have to worry about that in many of our devices."

According to IEC 80001-1, "the incorporation of medical devices into IT networks in the clinical environment is a less-regulated area. Standards are in place covering common information technology activities including planning, design and maintenance of IT networks.

"However, at present, no standard addresses the detail of how medical devices may be connected to general-purpose IT networks to achieve interoperability without compromising the organization and delivery of health care in terms of safety, effectiveness and data and system security," the document notes.

IT security "has been done in a wide variety of different ways and a wide variety of different locations," Fitzgerald says. "Each location may have a different security context."

For example, an operating room "may have a different security context than the emergency room," he says. "You could easily imagine a device [used in an OR] that might have log-on capabilities and would require user authentication [that would be different] than devices used in an ER.

In addition, IT security needs "might be different again for a long-term health care environment," Fitzgerald says.

IEC 80001-1 points out that "IT networks are becoming increasingly vital to the clinical environment and are now required to carry increasingly diverse traffic, ranging from life-critical patient data requiring immediate delivery and response, to general corporate operations data and to e-mail containing potential malicious content (e.g. viruses)."

Because the links between device software and IT systems are becoming more prevalent, the standard gives manufacturers and clinical sites tips on how to set up a risk management program to avoid problems, including troublesome interoperability between the devices and IT systems, software viruses, and issues with "the availability or adequacy of information provided by the manufacturer to the operator of the IT network."

Risk management "should be used before the incorporation of a medical device into an IT network takes place, and during the entire lifecycle of the IT network incorporating the medical device to avoid unacceptable risks, including possible harm to patients resulting from the incorporation of the medical device into the IT network," the draft standard states.

"The manufacturer of a medical device intended to be incorporated into an IT network is responsible for providing information about the medical device sufficient to allow the responsible organization to manage risk," it adds.

Risk management principles outlined in IEC80001-1 help balance not only safety, but also effectiveness of delivering health care data and system security, and the interoperability of devices, Eagles says.

While manufacturers and clinical settings wait for IEC 80001-1 to be released, there are some steps they can take to ensure greater security links between device software and IT systems, including adding unique user ID technology to products and ensuring that devices have the ability to automatically log-off, FDA's Fitzgerald says.

Ensuring data transmission integrity also is important, he notes. "Is there a way to ensure that what you think you are transmitting to a different network is actually going to be received on the other end? Is there some sort of 'hand-shaking' to establish that it was both sent and received?"

Fitzgerald says he is looking forward to the release of the IT network risk management standard so firms and hospitals will know about these types of security tactics, because IT system security "is a very juvenile area where our thoughts have not yet concretized."

- Shawn M. Schmitt (sm.schmitt@elsevier.com)

Not Sure If Software Is A Device? It's All About 'Intended Use,' FDA Says

More from Archive

More from Medtech Insight