Major trends in health care software development include the move to service-oriented architectures, reusable software components and shared services like database servers, rules engines and messaging engines. This approach to enterprise software development costs less, is easier to integrate, is more flexible and can result in fewer software defects than traditional approaches.
As medical device vendors have moved into the systems business, they have clung to most of their embedded systems business models. The application of 21CFR medical device regulations to the world beyond the black box of embedded systems, gives us things like device vendors designing and manufacturing their own PCs, verification and validation of a specific manufacturer's model of 802.3 Ethernet switch, and insufficiently flexible systems products that can't be integrated into a hospital's IT infrastructure.
Connectivity swings both ways, and as medical device vendors adopt systems health care IT vendors are eyeing medical device markets. The software guys have their issues too, especially the dreaded 510(k). There are presently whole categories of products on the market that should be regulated but aren't.
Better interoperability between information systems and medical devices can improve patient safety, reduce length of stay, and lower operating costs. In my experience, hospitals look first to their medical device vendor to automate workflow around a particular device or clinical area. If device vendors don't come through, they are quick to go with someone else. After years of market consolidation, many companies are both medical device and information systems vendors - that's not to say that the groups get along any better because they're in the same company.
There is a way to harmonize the needs of closed embedded systems and open information systems to comply with the FDA's requirements. What is required is a middle way - you can't treat an IT system like an embedded device and expect Oracle to conform to Part 820, the Quality System regulation (QSR) - they won't nor are they required to. The irony is that all you need to know is in the regulation and guidance documents. To make it easier, I've compiled some links:
- How to classify your device. In the FDA's view, anything can be a "medical device" depending on what it does. Most clinical software is classified as Class I and not subject to pre market approval 510(k) or QSR. But if your system is used for diagnosis, continuous monitoring, or therapy, it is a Class II device and requires a 510(k) and must comply with the QSR.
- Here's some Guidance for the Content of Premarket Submission for Software Contained in Medical Devices. Hint: the intended use statement is almost everything.
- And Guidance on Off-the-Shelf Software Use in Medical Devices. This is one of the trickier parts and is frequently bungled.
- General Principles of Software Validation. Key words here, "Least burdensome approach."
- And finally medical device security, or what the FDA calls Cybersecurity for Networked Medical Devices.
And finally, if you've still got questions you can follow the FDA's 513(g) process to request clarification (scroll or search for 513) on your device's regulatory status.
There's a lot of information here, and of course it helps if you're a Connectologist and have guided the regulatory strategy for a variety of systems products.
Trackbacks/Pingbacks