What If The Medical Device Data Passes Through Other Systems First?
Let's say a piece of software gets data from a medical device four steps removed. There is no limitation based on how distant the original source of the data is, so long as the flow of that data is automated and not manual. The final rule indicates that medical device data are any electronic data that are available directly from a medical device or that were obtained originally from a medical device. This second clause implies there can be intervening steps between the medical device and the MDDS device.
Does MDDS Include Electronic Health Records Or Personal Health Records?
Well, yes and no. If an electronic health record or personal health record meet the core definition of MDDS, then it would be in this classification. FDA is anticipating, however, that many such records will not. The basis for their assumption is the view that electronic health records, at least the old-fashioned variety, depend on manual entry of data of any medical device data. Those who are watching the market realize, though, that more and more electronic health records are accepting automatic transfers of medical device data.
The strategy might therefore be to try to quarantine that portion of the record that would constitute an MDDS device. Thus, the part of the system into which the doctor or other caregivers simply input their information would fall outside the MDDS classification. The underlying software of health information exchanges—where patient data (including medical device data) are transferred between healthcare facilities—may now more easily fall within the definition of MDDS.
Does This Only Apply To Companies Traditionally Recognized As Manufacturers?
Nope. FDA makes it clear that hospitals and other healthcare institutions that choose to create this software will be treated as the manufacturer of an MDDS device. This includes those healthcare institutions that make these systems from scratch, and also those healthcare institutions that materially modify purchased MDDS systems outside the parameters set by the original manufacturer. The one exception is buying an off-the-shelf system not intended for medical purposes, and using it without modification.
How Does This Relate To Other Classifications?
Industry will need to sort that out. Basically, if a piece of software arguably fits into two different classifications, it may be regulated in the lowest classification it fits. In many ways, the MDDS classification is very narrow, and if a piece of software can fit that classification, then it will be in class I even if it might also arguably fit into another classification such as PACS. But if a piece of software has functionality elements that are found in the PACS classifications that are not found in the MDDS classification, it will be placed in the PACS classification.
Applying the Accessory Rule.
Remember the accessory rule says that any medical device promoted for use specifically with another medical device will be regulated in the same classification as that other medical device. Anticipating questions around this, FDA explains that if the piece of hardware such as a modem is promoted specifically for use with an MDDS, then that modem would itself become a part of the MDDS.
The converse raises some interesting questions. If a company selling an MDDS says that it is for use with another medical device such as a blood glucose meter, how will FDA regulate the MDDS? It would appear that so long as the MDDS manufacturer stays within the contours of what defines an MDDS, the product will stay in that MDDS classification, even though a blood glucose meter is in class II. I have to say, though, the language in the preamble is not crystal clear on this point.
The rule becomes effective on April 14. By May 14, companies that make MDDS must have registered with FDA and listed the MDDS product. By April 14, 2012, about 14 months from now, companies making MDDS must have fully functioning quality systems and be in compliance with the medical device reporting rules.
FDA says implementing a quality system should cost around $20,000. Unfortunately, in my experience, that estimate is simply way too low. The actual cost depends on the size of the operation, but also the degree to which the company has already implemented a quality system. As discussed in my prior post, a quality system meeting FDA requirements has some important differences from a quality system that implements just ISO standards. Fortunately, though, FDA seems willing not to require everyone to go back and try to create design controls that may not have been employed when the MDDS was made.
FDA justifies the costs that the rule imposes on industry by observing that these types of software have always been regulated, and by this action FDA technically is deregulating this category of software from its automatic class III designation. That's a bit of a stretch considering in reality FDA never enforced the class III designation. So all of this sure feels like new requirements.
As I said, reading the Federal Register notice does not shed a lot of light on the big picture of how software, broadly speaking, will be regulated by FDA. By design, FDA took one piece of the overall software puzzle, and a fairly small piece at that, and determined its classification. We will have to wait over the coming months and years to see how FDA classifies other related categories of software. That said, we have more clarity today than we did yesterday.