My first exposure to Mobisante and their disruptive diagnostic ultrasound system was the mHealth Summit in November of 2010. At that time, the consumerization of medical devices had been gaining traction, mostly in the physician office market. Consumerization offers medical device manufacturers advantages in lower design costs, shorter time-to-market, lower product costs, increased usability and lower training costs.
I recently got Sailesh Chutani, co-founder and CEO of Mobisante, on the phone and we discussed their product strategy — a software based diagnostic ultrasound that runs on a variety of consumer electronics platforms.
Your product is clearly a diagnostic ultrasound medical device, but one can’t help but notice the rather unique design and choice of components. What were the factors driving the eventual design and appearance of your diagnostic ultrasound?
For us, in terms of where we started, our goal was to make ultrasound imaging universally accessible; to democratize it. Currently, there are three very significant barriers to broader adoption of ultrasound imaging: cost, complexity and the difficulty of integration with workflows.
Traditional ultrasounds are the way they are because historically the only way to get the high performance and image quality you need was to do custom hardware, custom everything. This is by necessity very expensive. Then, in 2007, Qualcomm came up with Snapdragon chip sets. Now, for the first time, you had enough computing power in a smartphone to do the processing required for real time ultrasound imaging. So, we were looking at all of that and thinking, “Okay, so what are some the cost drivers?” Doing custom hardware is a pretty major driver of costs. If we could now use commodity electronics as building blocks for these devices, our costs would be dramatically lower.
The second big barrier was that a lot of the complexity you see in traditional devices comes from designs that are kind of one-off designs. And these devices are also designed for highly trained sonographers or experts. Those devices have dozens of knobs and controls. Sometimes weeks of training is required to just learn how to master a conventional ultrasound system. We questioned whether all of that complexity was necessary. Certainly, this complexity is an impediment if you’re going to make the diagnostic functionality more broadly accessible, especially to non-experts. As consumers, all of us are getting trained on the interaction paradigm of smartphones and tablets, so why not just make using ultrasound look like any other application you’d download? Stick to the interaction paradigm that the whole community has been trained on, and leverage that. So now, it takes someone five minutes now to learn to operate the device versus taking three weeks of class.
Breaking the third barrier entailed leveraging the connectivity that comes for free in all of these smart phones and tablets. So, we leverage those connectivity capabilities to offer functionality beyond image capture, but also managing and organizing these images through the diagnostic life cycle. We offer cloud-based image management and then eventually we’ll offer over-read services and analytics. These capabilities simplify integration of our devices into clinical workflows.
Those are the three key insights and drivers we had for our product, and I think you can clearly see them emerge out of the design and the actual product today. We are leveraging commodity smartphones, tablets and other off-the-shelf hardware, focusing on designing a simplified user interface that piggybacks off the training we all have in gestures and touch. The third piece is connectivity and increasing the value of the solution by not just capturing images at the device but also providing image management and access to other complementary services.
It seems that you intended to create a disruptive medical device from the get go? ?
That’s an accurate statement. [chuckle]
Our driver was really, how do you increase access. And maybe I can step back and ask, “Why does this even matter?” If you look at the broader issue, and this is really a global issue, the big question is, “How do you increase access to healthcare and do it in an affordable manner?“
There are two main drivers that determine the cost of healthcare. One is where are you delivering care? Are you delivering care in places like hospitals, in clinics, or in people’s own homes? And the other is who’s delivering that care? Is it highly trained MDs or nurses, nurse practitioners, or community workers or maybe patients themselves?
So, if you can move care closer to the patients, whether it’s a clinic out in the community or their own home, and you can move more of the care delivery to mid-level professionals and eventually patients themselves – if you can move along those two dimensions, that’s where you start to break the cost curve.
The problem is, in order to do that, you need a different kind of medical device or toolbox. Less skilled users need diagnostic and procedural guidance that you don’t have today. Today’s medical toolbox, the diagnostic toolbox included, is designed to be operated in a hospital environment by highly trained professionals. So, in some sense, that’s the problem we wanted to solve, and we picked ultrasound imaging as the tool to focus on first because it has very broad applicability.
Point of care imaging can take the guesswork out of medicine, right? So, you don’t have to palpate or poke to try and figure out what’s happening inside someone’s body – you can image and see what’s happening. That is the driver for what we’re doing. And yes, we also wanted to explore, how do you have a business model that would be difficult for incumbents to copy, and an approach, which as the newcomer, we could pioneer and build into a very strong position in the market?
Your product design has allowed you to carve out a segment of the market that really didn’t exist before.
That is correct. That is correct because, ultimately, if you think about who do we compete with? We compete with non-consumption (pdf), to use Clayton Christensen’s term, right? We are really making ultrasound imaging available to people who either didn’t have access before, had inconvenient access, or couldn’t afford it. Right? So, for them, they’re not looking for the dozens of features of a $100,000 device. They’re looking for something basic that allows them to do triage, quick looks. Essentially, answer yes/no questions.
So, while your disruptive product design significantly reduced the purchase price and per unit revenue for your product compared to traditional ultrasound systems, it sounds like it’s also created new business opportunities and new revenue opportunities?
Absolutely. An example would be, in addition to the imaging device, offering people image management in the cloud. Besides automating the diagnostic workflow, clinics and hospital systems can essentially start to use that to do quality control on the images being acquired. They can use it to do training. Radiologists can start to offer 24X7 over-read services for ultrasounds, which exists in CT and MRI, but is not as prevalent in ultrasound.
So, yes, you’re absolutely right, you got the new opportunities to provide better care and create new revenue opportunities for us. But, there’s one point I want to highlight. Traditionally, devices have been sold in a fee-for-service reimbursement world. Manufacturers sell big-ticket medical devices justified by the fees health care providers can charge for using the device to do procedures. In this scenario, capital equipment costs are less important than the provider’s revenue potential from procedure fees. Providers have an incentive to do as many procedures as possible because they’re receiving a fee for providing that service. Now with the change in the health care system, the Affordable Care Act, I think people are starting to look at costs, clinical effectiveness and overall value – this creates a very different kind of business environment where you’re looking at tools asking the questions, “Does it help you provide better care? Does it help you provide cheaper care?”
I think that’s the big opportunity for innovation in point-of-care devices because they essentially allow you to do much more effective triage very early to see who needs the more expensive modality or not. For example, you’re at your community clinic in a rural area, complaining of abdominal pain. Today, if they don’t have imaging, they’re referring you to a hospital due to the serious conditions your symptoms might indicate. You want to rule out a whole class of things. If they have a device like ours, they can do it right away, and then for a number of cases, they will be able to have confidence. “Yeah, you don’t need that extra level of screening or diagnosis. You’re fine. You can go home. You just have gas or you ate something that didn’t agree with you.” Early on, in the health care delivery process, it’s possible to really reduce the number of unneeded procedures and screenings that have been the norm, with these point-of-care devices.
Up to this point, we’ve talked mostly about market facing factors that have both driven your design and are a consequence of your design approach. What factors or what kind of impacts were there internally in your company as a consequence of taking this pretty radical approach to medical devices? And I’m thinking things like new core competencies, regulatory impacts, purchasing components, all those kinds of issues.
Oh, it’s huge. It starts with what kind of team do you put in place, right? We needed folks, not only from the medical device community, but people who knew how to operate in this environment where some of the building blocks are off the shelf. The next consideration had to do with what we were going to be building on a platform that would evolve very rapidly. We had to learn to architect our product’s stack, so that it can cope with the rapid change that occurs with consumer electronics without requiring extensive redesign. And then tied to that was “Well, how do we approach our regulatory strategy?” If every time something minor changes, we have to get a new 510(k), you’d go out of business pretty quickly.
If it were possible to be unaware of the general problem of cybersecurity, the recent Sony hack with its public disclosures of “private” e- conversations and then terroristic blackmail, following the earlier release of celebrity cloud photos, ought to have provided notice that what is electronically stored is likely to be available to those determined to have it. Moreover we know that cybersecurity can in principle also impact the function and availability of connected systems (Sony again) and/or the information they contain. We also need to be concerned about the malicious alteration of information or disruption of device performance. You may remember the hacked insulin pump story which is already a few years old, and the story that the wireless function of Vice President Cheney’s pacemaker was disabled to protect against hacking.
In this broad context it may be worth taking a look at the FDA’s now posted contents of the October 21-22, 2014 FDA workshop on “Collaborative Approaches for Medical Device and Healthcare Cybersecurity”. There is also a link there to the October 29 FDA Webinar on the Final Guidance on Premarket Submissions for Management of Cybersecurity in Medical Devices. (If that link doesn’t work, as it didn’t for me, try here.) I had not been not aware that October was National Cybersecurity Awareness Month under the auspices of the Department of Homeland Security (DHS).
The stated purpose of the workshop was to bring together all stakeholders in the healthcare and public health sector including medical device manufacturers, healthcare facilities and personnel (e.g. healthcare providers, biomedical engineers, IT system administrators), professional and trade organizations (including medical device cybersecurity consortia), insurance providers, cybersecurity researchers, local, State and Federal Governments, and information security firms in order to identify cybersecurity challenges and ways the sector can work together to address these challenges. Some 1300 people where there.
The posted contents provide a rich after-the-fact resource from the workshop including separate videos of each session, the slides presented, and a word-for-word transcript of the proceedings. The availability of the materials in relatively small chunks allows for selected viewing or digesting it in several viewing sessions. However for those into binge viewing, you can also do two days straight. There were ten sessions beginning with Framing the Question, traversing Gaps and Challenges, and addressing the NIST Framework for Improving Critical Infrastructure, and Risk Assessment. The concluding session was consideration of Building Potential Cybersecurity Solutions/Paths. Each of these sessions was either a panel discussion, or had one or more presenters and a group of discussants, resulting in a great deal of material and many perspectives. There were also four keynotes: Marty Edwards (DHS), Edward Gabriel (Assistant Secretary of Preparedness and Response), Michael Daniel (Special Assistant to the President), and Mary Logan (AAMI).
A potentially interesting sequel to the workshop is the creation of a limited access discussion forum provided by MITRE. Set up on its Handshake website, the intent is to continue the dialogue from the workshop around common challenges and possible paths forward in medical device and healthcare cybersecurity. Among its benefits, the collaboration space is said to afford the community the opportunity to share best practices and to join one or more of the 5 subgroups of specific interest. Of course no discussion venue these days can be free of its own privacy (or lack thereof) statement. MITRE states that” the user’s name, profile photo, connections (social graph), and activity stream of non-access controlled activities are visible to all participants in this collaborative space”. When I joined this forum there were 42 members but a minimal level of activity, so it remains to be seen whether this resource actually becomes of any value.
One might note in this regard that there is no shortage of electronic ways to discuss cybersecurity or anything else these days, and that in most cases discussion by itself does not solve problems as compared to actually doing something. This is perhaps the empty promise of social media where passing around snippets of ideas is confused with actual work and accomplishment. In fact social media participation often takes place instead of actual work. And yes, I realize the irony of making this observation in a blog post.
There is little doubt that cybersecurity concerns, in all its forms, will be with us for some time to come. I currently have three different identity security accounts provided by three different breached entities, including healthcare and the federal government. While cyber risk management practices provide some level of protection, and must be put in place, monitored and maintained, it seems that the threats will continue to exist and to evolve. Of course there are those that benefit from this challenge, reminding us that one person’s adversity is often another person’s source of income.
None-the-less, spend some time with the FDA workshop. There is much to learn.
The Office of the Inspector General (OIG) of the U.S Department of Health and Human Services has released a report (pdf) outlining its 2015 work plan. Among a host of subjects is “Information Technology Security, Protected Health Information, and Data Accuracy” with the subsection “Controls over networked medical devices at hospitals”. The focus here is on the security of patient electronic health information which is to be protected under law. Other risks associated with device networking are not addressed.
The relevant subsection (page 22) is relatively brief:
We will examine whether CMS oversight of hospitals’ security controls over networked medical devices is sufficient to effectively protect associated electronic protected health information (ePHI) and ensure beneficiary safety. Computerized medical devices, such as dialysis machines, radiology systems, and medication dispensing systems that are integrated with electronic medical records (EMRs) and the larger health network, pose a growing threat to the security and privacy of personal health information. Such medical devices use hardware, software, and networks to monitor a patient’s medical status and transmit and receive related data using wired or wireless communications. To participate in Medicare, providers such as hospitals are required to secure medical records and patient information, including ePHI. (42 CFR § 482.24(b).) Medical device manufacturers provide Manufacturer Disclosure Statement for Medical Device Security (MDS2) forms to assist health care providers in assessing the vulnerability and risks associated with ePHI that is transmitted or maintained by a medical device.
Note that this is the OIG’s intention to examine what CMS is doing, not directly what hospitals are doing. However it might be expected that CMS would endeavor to assure its performance in order to pass muster under OIG review.
The reference to MDS2 in this subsection should be noted. MDS2 is intended as a format for medical device manufacturers to provide a standard set of security/risk information to hospitals to be used in the hospital’s network risk management plan. MDS2 was developed by HIMSS and ACCE, and then further standardized through cooperation with other organizations. The use of MDS2 by manufacturers remains voluntary, and is driven by customer demand for this information in the MDS2 format. Some manufacturers have made their MDS2 forms openly available on the web which is certainly a good thing. Others have provided web availability to registered users which is a marginally good thing. And of course some manufacturers have not made them web available (assuming they have them) which is a bad thing.
But what does the sentence in the subsection about MDS2 mean? I ask this question in the personal context of having recently been attentive to the use of should, shall, may and must in requirements documents, as well as the advice of some to avoid all of these words. (This is a subject for a separate post.) The latter approach of not using such words appears to be the path that HHS has taken in crafting this sentence. As written, is it a statement that this is what all manufacturers are doing? Or is it an instruction to manufacturers, a demand on manufacturers, or an instruction/demand on hospitals? If the latter, does it mean that CMS during an inspection would expect the hospital to have and be able to produce its MDS2’s for all networked devices? The reference to MDS2 here can be contrasted with the FDA’s recent Guidance on Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (pdf) which makes no mention of MDS2.
Whether or not having MDS2’s is mandatory, hospitals requiring such forms from manufacturers and then actually using them is a good idea. As a consumer driven resource, the more that hospitals ask for (demand) the MDS2 the more likely they are to be readily available. This might remind us that the reason to do things is not limited to the government or other authority having jurisdiction (AHJ) forcing us to, and the absence of anyone forcing us is not in turn a reason not to do things. In an ideal world (in which we do not live) that which we were mandated to do would be the same as that which was otherwise the right thing to do.
For reference, 42CFR482.24(b) is part of the Medicare Conditions of Participation-Medical Record Services (i.e., these are hospital requirements). Part (b) is best understood in the context of the full 482 section, but here I only include the general statement and point 3 of part (b):
The hospital must have a medical record service that has administrative responsibility for medical records. A medical record must be maintained for every individual evaluated or treated in the hospital.
(b) Standard: Form and retention of record. The hospital must maintain a medical record for each inpatient and outpatient. Medical records must be accurately written, promptly completed, properly filed and retained, and accessible. The hospital must use a system of author identification and record maintenance that ensures the integrity of the authentication and protects the security of all record entries.
(b) (3) The hospital must have a procedure for ensuring the confidentiality of patient records. Information from or copies of records may be released only to authorized individuals, and the hospital must ensure that unauthorized individuals cannot gain access to or alter patient records. Original medical records must be released by the hospital only in accordance with Federal or State laws, court orders, or subpoenas.
It is interesting here that second and third sentences of (b) seem to speak to the deliberate release of records. The first sentence might just mean that also, but in the network context it is apparently being given a much broader interpretation. The emphasis here on procedure is also noteworthy. The requirement is not simply that the hospital has maintained confidentiality (i.e. no breaches) but that it has a methodology in place to prevent breaches.
In summary, the OIG intends to audit how CMS is assuring that the requirements for patient data security is being met by hospitals, here in the specific context of networked systems. This may mean that CMS will pay particular attention to this subject. This in turn means that hospitals probably need to do the same.
When I do presentations on the use of standards, I invariably have a slide which defines interoperability as “the ability of a system or a product to work with other systems or products without special effort on the part of the customer.” My second slide then defines syntactic and semantic interoperability.
Syntactic interoperability occurs when there are two or more systems capable of communicating and exchanging data and this is usually attainable with the use of physical standards, data standards, and messaging structures. Semantic interoperability is defined as the ability to automatically interpret the information exchanged meaningfully and accurately in order to produce useful results as defined by the end users of both systems.
Semantic interoperability is usually achieved with a common information exchange reference model where the content of the information exchange requests are unambiguously defined, i.e. what is sent is the same as what is understood. In order to have the type of interoperability as defined above, systems should drive their integration goals towards semantic interoperability. This idea of attempting to attain semantic interoperability was highlighted with two conversations I had this summer while working on a project.
This project entailed identifying and analyzing healthcare organizations that are integrating remote monitoring or patient generated data into their EMRs. With the proliferation of remotely generated data expanding greatly due to mobile application and wearable sensor vendors offering cloud based solutions, it is believed that personalized healthcare will become more prevalent. In addition, it is thought that if all of that data is aggregated and analyzed (Big Data), a better understanding of the underlying symptoms, possible diagnoses and ultimately cures for diseases will occur more rapidly. Notwithstanding that utopic vision, as usual, the hard work is done in the ‘trenches’ building the infrastructures, devices and workflows. Given the objective of incorporating patient generated medical device data into the EMR, it is useful to compare this to how medical device data is acquired and used in the acute care setting.
In the traditional healthcare enterprise medical device data integration workflow process, a medical device is connected to the hospital network, the data is aggregated with a medical device data system (MDDS) provided by the medical device manufacturer or a device integration vendor’s solution. The MDDS then sends HL7 messages to the integration broker of the EMR application. The data coming from the MDDS generally is delivered every 30 seconds or 1 minute to the EMR integration broker. Usually, the MDDS has a server with some buffering capability such that the device data can be queried or retrieved or stored for future forwarding if there is a problem at the interface.
From the perspective of the clinician in the hospital using a charting application in the EMR which has integrated medical device data, the data available for annotation into the flow chart is usually displayed in intervals and the clinician chooses one of those data points within that interval as the validated parameter for the EMR application. So, if the clinical protocol for that particular patient is Q15 or the required documentation frequency of the specific physiological parameters is every 15 minutes, 29 or 59 available data points are discarded once the clinician chooses one for charting purposes. This data being integrated into the EHR is usually located in the hospital or clinic (a controlled environment), the device is ‘trustworthy,’ and the data being entered into the EMR is validated by the clinician. The data ‘provenance’ of location of generation, trustworthiness of the measurement device, and validation is assumed based on the clinical workflow and technical infrastructure supporting integration.
In the remotely monitored or patient generated data situation, there is usually a vendor provided service which offers ‘cloud’ based access to the data. This server usually resides outside of the healthcare enterprise infrastructure and the data is not traditionally integrated into the healthcare EMR application. In this situation, ‘data provenance’ quality changes greatly. Compared to the acute care setting, the frequency or volume of data available is greatly reduced, perhaps once daily. Additionally, the clinical workflow does not have an immediate or near real-time clinician validation step. Lastly, the environment in which the physiological measurement is taken is not as controlled as in a clinic or hospital, data generation may be dependent on patient actions or technique and the medical device or sensor may not be as accurate as that found in the clinic or hospital setting.
EMR/EHRs are considered medical legal documents such that clinicians retain liability for any information in the document. This makes them and healthcare institutions more carefully vet any information or data that is integrated into the EMR/EHR. In addition to the medical legal reason cited above, there is the trust issue regarding data veracity. If a clinician doesn’t have the correct level of trust in the data, then any action they may or may not take can be inappropriate.
There are very few healthcare organizations that are integrating remotely monitored *and* in-hospital medical device data into their EMRs. Those that are integrating it are following these approaches: integrated data viewing in a patient context without data-comingling, and/or integrated viewing with a separate co-mingled data repository which provides separate data provenance. Integrated patient context viewing creates a viewing environment in which it may seem the data resides in the same place when in fact, it may be in separate physical repositories. Data co-mingling means the data resides in the same physical data repository.
Another idea that was discussed was that use of the HL7 3.0 messaging standard (object oriented and XML-based) merely ‘kicked the work’ downstream. “XML doesn’t solve the difficult problem of identifying data, it just allows for data to be identified with tags that have no semantics. The problem is not really syntax, but semantics. The different data codes do not identify when they are to be used or the difference between instances.” (See VA link below.) This is a bit of an extension to the idea above of data having provenance. Again, with having semantic interoperability, the data item being integrated would be understood with regard to not only the value and type, but where it came from, and a measure of the confidence one might have in the data value (this would help in the clinician trust with regard to data veracity).
The current data standards that are recommended for use in medical device information integration do not take into account the ‘provenance.’ The need for defining provenance comes into play if or when EMRs start making use of the data gathered outside of the ‘controlled’ healthcare environment.
For even more examples of the issues with remote monitoring data and semantics, readers may wish to visit the Center for Connected Health blog as well as read about the VA Telehealth integration activity (pdf file which will download). Both of these organizations in the USA are ahead in the thinking and implementation of incorporating remotely generated patient data into their EHRs. Each is using a different approach and yet both understand the difference between syntactic and semantic interoperability at a pragmatic level.
So as a healthcare organization starts planning to integrate medical device data generated outside the controlled healthcare enterprise, they should think about data provenance and how to effectively move towards semantic interoperability. Merely using standards at the interfaces will not guarantee semantic interoperability. A determination of the data gathering location, quality and timeliness will be required to properly place data in the proper context for a clinician to appropriately use that data. Providing this context will go a long way to alleviating clinician fears regarding the use of the patient generated data and/or allow the clinician to better judge any actions they may take based on the data.
This summer, FDA proposed lifting regulations from certain currently regulated medical devices. This unprecedented policy shift targets devices known as Medical Device Data Systems (MDDS) and is intended to benefit the mobile app industry and companies like Google, Apple and others. The current regulatory burden for MDDS devices is Class I, 510(k) exempt. This means manufacturers have to follow a basic quality system (i.e., design controls) on par with ISO9001, and report instances of patient injury or death in addition to any product recalls to FDA.
The following is a guest blog post embodied in an abridged version of a comment submitted to FDA in response to their draft guidance.
Many EHRs and a significant number of health IT (HIT) and clinical decision support (CDS) systems are, by current law, de facto Class III Medical Devices because they have not heretofore been regulated and classified. Class III devices are the high-risk devices and subject to the highest level of regulatory control. Because they are new and have never been regulated (and thus embody an unknown level of patient safety risk) new products are by default classified as Class III devices. Most products that come to market are “updates” of existing solutions based on older technology. These products can claim previously regulated devices, known as predicate devices, and are typically classified as Class II devices. After their initial regulation as a Class III device, new products for which there is no predicate device are often classified as Class II devices.
The FDA currently practices regulatory enforcement discretion over many HIT and CDS systems (but not quite all – e.g. Blood Bank software), leaving them in a sort of classification limbo. If properly classified, some might end up Class II, Class I, or even unregulated. (https://en.wikipedia.org/wiki/Enforcement_discretion)
In 2011 the FDA took a concrete step to rationalize regulation in the HIT space when it finalized the Medical Device Data System (MDDS) rule basically a new Class I, 510(k) exempt device regulation for the simplest type of HIT medical device interfaces that transmit, store, and display medical device data without significantly altering it. Since then at least 316 MDDS devices have been listed with the FDA. (To view current FDA registered MDDS devices, go here and enter “oug” into the Product Code field in the query form.)
In a surprising move, in June 2014 the FDA issued the Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices Draft Guidance for Industry and Food and Drug Administration Staff (MDDS Draft Guidance) that proposes to eliminate FDA regulatory oversight of MDDS through enforcement discretion. The agency’s justification was:
“Since down-classifying MDDS, the FDA has gained additional experience with these types of technologies, and has determined that these devices pose a low risk to the public.”
The MDDS Draft Guidance did not describe what the “additional experience” was to merit their determination, “that these devices pose a low risk to the public.” Separately, on public blogs FDA officials have stated they expect HIT products to be regulated by a different agency within HHS – even though no law or authority de-classifying those products (such as EHRs) as medical devices has been passed.
We personally don’t know anyone who doesn’t feel the FDA and their processes couldn’t be improved, but in our opinion it’s the best system we have in place now. Like other HIT, MDDS’s can create significant patient safety and cybersecurity risks even if their intended functionality is as a simple data pipe. Dropping regulatory oversight over MDDS devices is throwing the baby out with the bathwater. The quality and value of HIT technologies like MDDS and their connected EHR and CDS systems depends on having interfaces that provide trustworthy data. Otherwise garbage inputs will result in garbage outcomes.
We submitted a comment through regulation.gov opposing the proposal to eliminate enforcement of the MDDS rule. The major points are summarized below. The entire MDDS rule can be found here, and the MDDS Draft Guidance Document can be found here. Our full comments are available here, as published on www.regulation.gov.
Our Comment on the Draft MDDS Guidance Document covers three topics:
1) Cybersecurity Risks
2) Software Defects from Complex Connected Systems
3) Known MDDS Device Defects
In any component, system, or system of systems, the security of the whole is only as good as its weakest link. FDA’s “accessory rule” concept applies well in the domain of security and privacy. Any interface, as a component of a larger system, poses a potential security or privacy vulnerability. Additionally and importantly the functionality, classification, interface standard conformance, or intended use of the interface does not correlate with the potential for that interface to contain a security or privacy vulnerability. For example a wireless connection is not any more or less vulnerable to cyber attack if it is intended only to receive occasional physiological data. Every MDDS, especially wireless ones, create potential cybersecurity vulnerabilities. Design controls are a necessary, but not a sufficient, means to reduce those vulnerabilities. Without them MDDS’s and everything they touch becomes more vulnerable.
We believe providers and clinicians under-report security and privacy violations and will continue to do so until they have additional liability protection. Thus the FDA’s collection of cybersecurity vulnerabilities is incomplete. The only argument can be over how much they miss. Post-market surveillance of cyber security should probably be beefed up for all medical devices, particularly for HIT such as EHRs.
There may well be systemic, real, or imagined reasons why providers, hospitals and HIT manufacturers are reluctant to report cybersecurity vulnerabilities in their medical devices and HIT systems. Which is why we further suggest that the in addition to the FDA continuing regulatory oversight over MDDS’s including post-market surveillance, the FDA as well as other agencies such as NIST, FCC, and ONC should expand their cooperative efforts to improve collection and analysis of the nation’s entire HIT infrastructure’s cybersecurity vulnerabilities. But that is a large topic best left for another article.
In 2012 The Food and Drug Administration Center for Devices and Radiological Health Office of Compliance Division of Analysis and Program Operations published Medical Device Recall Report FY2003 to FY2012. The entire report can be found here (pdf).
The report concluded (see page 18) that software design failures were the most common cause of medical device recalls and recommended expanding regulatory oversight of software medical devices. We agreed with that finding in 2012 and still agree with it now. Increasingly connected, integrated, interfaced, or interoperable systems are more complex and have more complex interactions. Therefore they are more likely to contain defects in their individual components or the systems as a whole.
Basic Systems Engineering tells us that the FDA’s proposal to drop design controls over the MDDS “connection” part of such systems is exactly wrong. It creates a potential weak link, and makes detecting and fixing other defects within systems, more difficult. The MDDS Draft Guidance is a step backwards for cybersecurity, software quality, and patient safety.
A search of the FDA’s MAUDE database for the keyword “MDDS” returned 66 hits – reports on MDDS’s, or devices or EHRs connected to MDDS’s. Yet only 316 or so MDDS’s have been listed to FDA for commercial marketing, ever since April 18, 2011. This seemed on the surface to be a high rate of reports. We examined a few MDDS-related MAUDE reports, MEDSUN entries, and Recall Letters. None of the defect descriptions contained anything surprising to someone with even a modicum of hands-on IT experience. Four selected MDDS defect reports are described below. We quote directly from the FDA databases (typos may be from the original documents) and provide a link to the original complete documents.
The company has determined that at extremely high blood glucose levels of 1024 mg/dL and above, the FreeStyle lnsulinx Meter will display and store in memory an incorrect test result that is 1024 mg/dL below the measured result. For example, at a blood glucose value of 1066 mg/dL, the meter will display and store a value of 42 mg/dL (1066 mg/dL – 1024 mg/dL = 42 mg/dL). No other Abbott blood glucose meters are impacted by this issue.
The functionality described in the recall included only the communication, storage, and display of a physiological value (blood glucose levels) from a medical device. If those functions were compartmentalized they would be an MDDS. In other words, Abbott found a defect in an MDDS serious enough that they issued a voluntary recall of that device. Abbott is a large highly respected medical device manufacturer with vast experience in design controls and post-market surveillance. We are concerned that had a similar MDDS been developed by a different company without design controls and no experience with medical devices, this defect would unlikely have been detected and the product would not have been voluntarily recalled.
The following three reports describe defects in systems incorporating MDDS’s, and speak for themselves.
A critically ill pt under went radiographic eval of chest and abdomen. The last name of the pt contained one apostrophe. The radiograph images could not be accessed on the ehr results mdds. It was determined that the one entering the pt’s name at the imaging vendor entered a double apostrophe, rather than one. It could not be corrected for days, once the images were found, 5 days after they were done. It took another 3 days for pacs vendor to correct this misidentification issue. The vendor’s device is defective because it allowed absurdity (there is never a name with consecutive apostrophes) and it failed to warn of the error. These mdds devices need tighter regulation, surveillance, and safety.
Complex case with multi organ failure was on high doses of potassium supplements and potassium sparing medications. The potassium level obtained in the lab and electronically sent to the dhr mdds had increased from 4. 0 to 4. 9 mg% over a 24 hour period of tome. The nurses were not alerted by the mdds of new results, nor did they open the mdds to check the interval change of the potassium level prior to administering 40 meq potassium chloride twice. This points out the defect in the mdds, which is its failure to notify of new results and provide meaningfully useful decision support. These devices are not safe and require oversight.
Cultures were obtained from a deep skin infection involving an implanted medical device. Multiple cultures grew serratia marcescens. The antibiotic sensitivities were lost from the mdds section of the ehr, or they were never posted due to an interface failure. A work around was required to find the results, but they remain absent from the silo of the ehr where they should appear. This defect causes delays in care and adversity due to delays in pinpointing the correct antibiotic to use in this critical situation. This genre of flaw raises doubt in the health care professionals as to whether the presentation of results on any pt are accurate.
The last MAUDE report nicely summarizes systemic risks of MDDS devices. A flaw in any MDDS whose purpose is to populate a patient record with physiological data raises doubts on the accuracy of ALL patient data in ALL EHRs. Modernizing our country’s healthcare delivery system requires EHRs and associated HIT systems that are well designed, correctly implemented, diligently operated, and trusted by payers, providers and patients. If only a few MDDS’s are found to be significantly defective in functionality, reliability, operation, security, or privacy, then the trust placed in all EHR data (including financial and demographic data) by clinicians and patients will be broken – regardless of the quality of their own particular systems.
There is no doubt that implementing design controls is a non-trivial effort, particularly when compared to the pure development cost of small mobile software applications that may perform, on the surface, similar functionality. But the country is not in need of cheap vulnerable apps and untrustworthy interfaces. Improving healthcare requires high quality, reliable, and effective software that safely and correctly interacts with other regulated and unregulated HIT systems.
The FDA has been improving their regulatory processes and supporting innovation with the Mobile Medical Apps guidance document, recognizing more standards, and other published and in-process guidance’s and rules. We applaud the FDA for their diligent work protecting patient safety and improving their regulatory processes. However we disagree with the MDDS Draft Guidance. We recommend that for Systems Engineering, Cybersecurity, and Patient Safety reasons the FDA should continue regulatory oversight over MDDS class devices.
The authors would like to thank the numerous subject matter experts who have contributed suggestions, critiques, and edits to our comments and to this post, but for professional reasons choose to remain anonymous. You know who you are.
Respectfully,John Denning, MHA Lynn Haven, FL Robert J. Morris, MD (UK) Pasadena, CA Mikey Hagerty, Ed.D., CISSP/ISSAP, CIPP/IT Carmel, CA Michael Robkin, MBA Los Angeles, CA George Konstantinow, PhD Santa Barbara, CA
Pictured above is the Capsule Neuron, a major component of Capsule’s MDDS.