Author: William Hyman

Have You Read a Disclaimer Lately?

Some time ago Tim Gee pointed out that a major vendor for an in hospital communication system included the following statement in its documentation: "This product is not intended for use with patient monitoring devices or other patient care devices. Do not use this product as the primary communications tool in health care environments, as it may use an unregulated frequency band that is susceptible to interference from other devices or equipment." Of course "primary communication" was exactly why the product was being purchased, and arguably what it was being sold for. When discussing Clinical Decision Support (CDS) (here) I have pointed that it is common for CDS creators to in essence say that one should not rely on the output of the product, but instead always second guess the advice provided. This perhaps approaches a warning that I proposed for a product that I thought was seriously defective: DO NOT USE THIS PRODUCT. Maybe I was being facetious. These examples may pale in comparison to the following disclaimer for medical image processing software: <The manufacturer> " SHALL HAVE NO LIABILITY OF ANY KIND FOR ANY DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES BASED ON ANY DEFECT, FAILURE OR MALFUNCTION OF THE SOFTWARE, OR USE OF ANY <manufacturer> DOCUMENTATION, WHETHER THE CLAIM IS BASED UPON WARRANTY, CONTRACT, TORT OR OTHERWISE. <Manufacturer> MAKES NO WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, ANY WARRANTY OF...

Read More

Medical Mobile App Draft Guidance Reaches 2nd Birthday

On July 21, 2011 the FDA released its "Draft Guidance for Industry and Food and Drug Administration Staff - Mobile Medical Application." We have discussed this draft and mobile apps generally here, here, and here. As with all draft guidance documents, following the release of the draft the FDA is supposed to receive and review comments (reported to be about 130), and then issue a revised draft, a final guidance document, withdraw the draft, or do none of these for an extended period, just letting the draft sit. The latter appears to be the  fate of many drafts. The two years that this draft has been out probably qualifies as an extended period. However the FDA did tell Congress, and the public, that the guidance would be released by the end of this fiscal year. Outsiders cannot tell if the appropriate FDA people are hard at work on this item, or if they are distracted in part by other issues. The FDA's claimed devotion to transparency does not include being able to see how such things are progressing. Once finalized, the guidance document will provide the FDA's "current thinking" on the subject, but it does not (or should not) officially create any new regulations since new regulations require actual rulemaking. Thus a guidance document is the FDA's interpretation of the current law and regulations, but is not itself a...

Read More

FDA Offers (draft) Guidance on Cyber Security

The FDA has issued a draft guidance document on the expected content of premarket submissions with respect to medical device cybersecurity.  This guidance targets individual medical devices rather than the network they may be resident on, and it also includes non-networked devices. The FDA notes that both networking capability and  portable media increase vulnerability. The latter issue might be called intermittent or remote connectivity. Guidance documents tell interested people what the FDA's current thinking is relevant to its regulatory authority, in this case the review of 510(k), PMA and related submissions. A draft guidance is in effect what the FDA is thinking about thinking. Drafts go through a comment period (90 days in this case) after which the FDA contemplates the comments and, after an unspecified time, either issues a guidance document, issues a revised draft, withdraws the draft, or just lets it sit there. Since guidance documents are not requirements, there is standard language that you can use an alternate approach if you can justify it. An open question for me is whether even a draft sufficiently establishes an FDA expectation that should be followed in the interest of a smooth submission review.There are many draft guidances currently under comment or post-comment review, including the long awaited guidance on medical apps discussed here. The current relatively brief draft has three interesting sections. The first defines the cybersecurity issue, the second...

Read More

Valuing Private Certification

There are currently several private entities that seek to certify medical apps, connectivity solutions, EHR record exchange, and other products, services and people in our sphere of interest. Given the ongoing proliferation of private certifications, there is a growing need to evaluate them, judge their relative costs and benefits, and determine which – if any –  are worth adopting as either the one certified or as the consumer of certified products or services. These private activities are usually distinct from governmental requirements (e.g. FDA or FTC  compliance, or state licensing), although in the case of EHR Meaningful Use (MU) certification, private entities function on behalf of the federal government to certify compliant EHRs.  Note here that compliant EHRs are those that are capable of achieving MU. Purchasing a product that is thus certified is a prerequisite for a provider then achieving MU. Government/private interaction is also relevant to some Class II FDA device regulation which are eligible under third party review. Internationally, private  notified bodies are part of the CE process necessary to meet EU requirements. Private efforts can also become public when an authority having jurisdiction (AHJ) adopts or cites compliance with a non-governmental standard or certification as required by law or regulation. Private certifications can also have secondary private impacts such as when a third party requires compliance with a certification or standard. For example a seller of a product might require that...

Read More

How Big a Loophole is “Wellness”?

The medical app and regulatory pot is being stirred as products continue to appear, including those with questionable FDA credentials, or lack of credentials. As discussed in our earlier posts on apps regulation (here and here), an app is a medical device if its meets the congressionally mandated and FDA enforced definition of a medical device as something whose intended use "is for the diagnosis of disease or other conditions, or the cure, mitigation, treatment, or prevention of disease, or is intended to affect the structure or any function of the body of man".  As stated in the FDA's Draft Guidance, omitted from this definition, and therefore not medical devices, are apps "that are solely used to log, record, track, evaluate, or make decisions or suggestions related to developing or maintaining general health and wellness." Some manufacturers have identified this health and wellness exception as fertile ground for asserting that their product falls within this exception, and therefore is free of FDA before-market scrutiny. In some cases this ground is plowed in the form of an express disclaimer, even though such a disclaimer may not be particularly credible. For example Brad Thompson, in a post for MD&DI cites the example of a urinalysis phone app and hardware system that includes the disclaimer that the device "is intended to be used for health and wellness information purposes and as a demonstration of technology. It is...

Read More

EHR MU – Interoperability, but of what?

In preparing for my presentation on Stage 2 Meaningful Use (MU) requirements for the November, 2012 Fourth Annual Medical Connectivity Conference I had the opportunity to delve further into the question of what had to be connected to what, and interoperable with what, in order for providers seeking EHR incentive payments to satisfy their MU obligations.  (I ended up making this presentation by phone from New York to Boston because of the lack of transportation out of New York post hurricane Sandy.) Stage 2 of the federally defined Meaningful Use (MU) is now upon us (details here), and a recurring theme is clearly interoperability. But what this means, and to whom, has not always been clearly presented. In this regard there has been occasional talk from the medical device engineering side of the room that MU requires that a variety of "traditional" medical devices must be able to send data to the EHR. (I introduce the term traditional here to distinguish common bedside medical devices from new players such as Clinical Decision Support systems (CDS) and perhaps EHRs themselves.) However, with a few exceptions, these traditional devices are not part of the MU requirements, and an actual reading of the Stage 2 regulations, and the means to test EHRs for certification, shows that there is no required call for such direct communication. This does preclude that some elements of the Stage...

Read More

The FTC Weighs in With Mobile App Advice

Those of us engaged in medical devices and their connectivity often (or perhaps not often enough) look to the FDA for regulation and guidance. In these pages there has been discussion of FDA regulation generally (here), as applied to Medical Device Data Systems (MDDS) (here), medical device mobile apps (here and here), and clinical decision support systems (here) We sometimes remember that there are also other government agencies that may have impact on what we do. For examples the role of  the FCC has been discussed here with respect to medical device wireless applications, and more recently the prospect of the FCC taking away part of the Wireless Medical Telemetry Spectrum (WMTS) has received attention in clinical engineering circles (while no one else seems to care). CMS is always of interest with respect to medical device reimbursement, and more recently with respect to meaningful use of electronic health records (EHR), which may or may not be medical devices. Advertising of medical devices is regulated by both the FDA and the FTC, and some over-the-counter devices bridge the FDA and Consumer Products Safety Commission divide. The FTC (but curiously not the FDA) has previously gone after smart phone  acne treatment apps because of their "baseless claims."  When there is dual authority and a need for regulatory action I have wondered if having two responsible agencies is worse than having just one (leading to some...

Read More

More on Clinical Decison Support and EMRs

I have previously discussed Meaningful Use (MU) criteria for EHRs  (here and here) , and Clinical Decision Support (CDS) (here). These topics are closely linked since the  MU requirements mandate the inclusion of CDS. On February 22, 2012 the Centers for Medicare and Medicaid Services (CMS) released (in a mere 455 pages in manuscript form) a proposed rule for Stage 2 criteria for qualification of an EHR for the Medicare incentive program. Among many topics, the proposed rule includes some elaboration on the mandatory use of CDS's as well as issues related to their design and utilization. This mandate might be viewed in the context of AHRQ's statement (here) that "Despite thoughtful efforts over the last three decades to translate clinical guidelines into CDS rules, there has not been widespread and successful use of such rules to improve patient care." Of course limited success to date does not mean that CDS cannot be beneficial in the future. In addition there is a wide range of sophistication in systems that might be called CDS, and which would in part satisfy the MU requirements. In general the CDS Stage 2 objective is to "Use clinical decision support to improve performance on high-priority health conditions."  The associated Stage 2 measure as proposed is to, "Implement 5 clinical decision support interventions related to 5 or more clinical quality measures at a relevant point in patient care", including enabling and implementing drug-drug and drug-allergy interaction checks.  The...

Read More

Lessons from a Recent Recall

A recent Class I recall (not pictured) of a medical monitor with a hospital network connected central station stimulates some generalities about software, "fixes", and connectivity. (Class I recalls are defined by the FDA as  a situation in which there is a reasonable probability that the use of, or exposure to, a violative product will cause serious adverse health consequences or death.) The use of the product in question was given as: a networked solution system used to monitor a patient’s vital signs and therapy, control alarms, review Web-based diagnostic images, and access patient records. The number of monitored vital signs can be increased or decreased based on the patient’s needs Curiously only one customer was identified as having received the product, or at least this particular version of the product. While the manufacturer and product in question is a matter of public record, and available at the link, I chose not to include it here because my objective is not to repeat the recall information, but to suggest the reasons for the recall, an associated labeling issue, and offer some general lessons. The reason given for the recall had two seemingly separate parts. The first is that "The weight-based drug dosage calculation may indicate incorrect recommended values, including a drug dosage up to ten times the indicated dosage". This sounds like a software problem yet the fix was not to "upgrade"...

Read More

The IOM on EHRs

The   issue of the EHR relative to safety and effectiveness has again made the news with the November 7, 2011 pre-publication (and downloadable) release of an Institute of Medicine report on EHR safety, commissioned by the U.S. Department of Health and Human Services (HHS). This report expands the discussion beyond the EHR (used henceforth for both EHR and EMR) to include other related electronic information tools collectively called health IT. Health IT Risks The potential for health IT to improve both the quality and efficiency of medical care has been much noted to include more complete and timely records, ready exchange of information between providers, clinical decision support, and in turn a reduction in errors associated with the quality and availability of patient information. Efficiencies may arise from electronic capture of data which would eliminate manual entry, and time savings in accessing and reviewing patient information, and perhaps in passing information to third party payers. Additional public health value might accrue from the enhanced searchability of electronic records with respects to trends, treatments and outcomes. These benefits assume well designed, user friendly, compatible systems not withstanding that the U.S. model is to allow for numerous independent products that may or may not be able to exchange information nor display it in a consistent manner. Not surprisingly the report notes that the IT imperative will likely not be fruitful without associated attention to the people...

Read More

Recent Tweets