Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

FDA Under Pressure To Deliver Clinical Decision Support Guidelines

Posted on November 10, 2016 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

The world of clinical decision support technologies may change soon, as the FDA may soon be releasing guidelines on how it will regulate such technology. According to a new report in Politico, the agency has been working on such guidelines since 2011, but it’s not clear what standards it will use to establish these rules.

Software vendors in the CDS business are getting antsy. Early this year, a broad-based group known as the Clinical Decision Support Coalition made headlines when it challenged the agency to clarify the scope of CDS software it will regulate, as well as what it will require from any software that does fall under its authority.

At the time, the group released a survey which found that one-third of CDS developers were abandoning CDS product development due to uncertainty around FDA regulations. Of CDS developers that were moving ahead despite the uncertainty, the only two-thirds were seeing significant delays in development, and 20% of that group were seeing delays of greater than one year.

The delay has caught the attention of Congress, where Sens. Orrin Hatch (R-Utah) and Michael Bennet (D-Colo.) have filed the Medical Electronic Data Technology Enhancement for Consumers’ Health Act, legislation designed to resolve open questions around CDS software, but the problem still remains.

The FDA has had a research project in place since late 2014 which is creating and evaluating a CDS system for safe and appropriate use of antibiotics. The researcher-developed system generates alerts when a provider prescribes an antibiotic that poses a risk of serious cardiac adverse events for specific patients. Two of the 26 hospitals in the Banner Health network are participating in the study, one of which will use the system and the other which will not. The results aren’t due until April of next year.

It’s hard to say what’s holding the FDA up in this case, particularly given that the agency itself has put CDS guidance on his list of priority projects. But it could be a simple case of too much work and too few staff members to get the job done. As of late last year, the agency was planning to fill three new senior health scientist positions focused on digital health, a move which could at least help it keep up with the flood of new health technologies flooding in from all sides, but how many hours can they work?

The truth is, I’d submit, that health IT may be moving too quickly for the FDA to keep up with it. While it can throw new staff members at the problem, it could be that it needs an entirely new regulatory process to deal with emerging technology such as digital health and mobile device-based tools; after all, it seems to be challenged by dealing with CDS, which is hardly a new idea.

Practice Fusion Founder Launches Wearables Startup

Posted on May 31, 2016 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Free EMR vendor Practice Fusion has always been something of a newsmaker. Since its launch in 2005, the company has drawn both praise and controversy for its revenue-generation approach, which has included the analysis and sale of de-identified patient data and advertising to physicians.

But it’d be hard to question Practice Fusion’s success, particularly given that it found its legs during a hyper-competitive period of EMR vendor growth capped by the Meaningful Use incentive program. Over the company’s lifespan, it has grown to serve over 110 million patients, and reportedly supported more than 70 million patient visits over 2015. It also attracted over $150 million in venture and private equity funding. Will it provide a great return for investors, time will tell, but they’ve definitely left their mark on the EHR industry.

At the helm of Practice Fusion until last year was CEO and Founder Ryan Howard. Howard – whom I’ve interviewed now and again over the years — certainly doesn’t lack for confidence or creative thinking. So I was intrigued to learn that Howard has stuck his toe into the wearables market. Clearly, Howard has not wasted time since August 2015, when he was booted out as Practice Fusion CEO. And if he believes a wearables startup can make money in this rapidly-maturing niche, I’m inclined to give it a look.

Howard’s new startup, dubbed iBeat, is creating a watch which constantly monitors and analyzes users’ heart activity. The device, which transmits its data to a cloud platform, can alert emergency medical services and, using an onboard GPS, provide the wearer’s location when a user has a heart attack or their heart slows down below a certain level. Unlike competitor AliveCor, whose electrocardiogram device can detect heart rhythm abnormalities such as atrial fibrillation, it has no immediate plans to get FDA approval for its technology.

iBeat expects to sell the device for less than $200, though if users want the emergency alert service they’ll have to pay an as-yet unnamed extra monthly fee. That puts it smack in the middle of the pack with competitors like the Apple Watch. However, the startup’s focus on cardiac events is fairly unusual. Another unusual aspect to the launch is that Howard is targeting the 50- to 70-year-old Baby Boomer market. (Imagine a more-focused version of the LifeAlert “I’ve fallen and I can’t get up” service, which focuses on the 75-plus market, Howard told MobiHealthNews.)

My take on all of this is that there may very well be something here. As I wrote about previously, my own heart rhythm is being monitored by a set of devices created by Medtronic, a set-up which probably cost a few thousand dollars in addition to the surgical costs of implanting the monitoring device. While Medtronic’s technology is doubtless FDA approved, for not-so-serious cases such as my own a $200+ plus smart watch might be just the ticket.

On the other hand, I doubt that uncertified devices such as the iBeat watch will attract much support from providers, as they simply don’t trust the data. So consumers are really going to have to drive sales. And without a massive consumer marketing budget, it will be difficult to gain traction in a niche contested by Apple, Microsoft, Fitbit and many, many other competitors. Not to mention all the competitors in the “I’ve fallen and I can’t get up” category as well.

Regardless of whether iBeat survives, though, I think its strategy is smart. My guess is that more-specialized wearables (think, I don’t know, iSugar for diabetics?) have a bright future.

FDA Limitations Could Endanger Growth Of mHealth

Posted on December 28, 2015 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

mHealth technology has virtually unlimited potential. But until the FDA begins putting its stamp of approval on mHealth tools, many providers won’t take them seriously. And that could be a big problem for mHealth’s future.

Unfortunately, early signs seem to suggest that the FDA is in over its head when it comes to regulating mHealth. According to speakers at a recent FDA Law Institute conference, it could be years before the agency even has a solid idea of how to proceed, Bloomberg reports.

Jeffrey Shapiro, a member of the Washington, D.C. law firm of Hyman Phelps & McNamara P.C., told the conference the FDA just isn’t equipped to handle the flood of new mHealth approaches. “Experience has shown that the FDA’s almost 40-year-old regulatory framework is a bad fit for much of today’s health IT with its networked ecosystems, rapid iterative improvement, deep collaboration between providers and end-users and focus on clinical decision support rather than direct diagnosis or treatment,” he told the audience.

The FDA dismisses the notion that it’s not prepared to regulate mHealth technologies. Bakul Patel, the agency’s associate director for digital health, told Reuters that the agency is planning to fill three new senior health scientist positions focused on digital health soon. That’s an encouraging step, though given that there are more than 165,000 health apps on the market, probably an inadequate one.

Sure, few of those app developers will apply for FDA approval. And the agency only plans to demand approval for technologies that are designed to be used as an accessory to a regulated medical devices, or transform a mobile platform into a regulated medical device. mHealth devices it has already approved include Airstrip Remote Patient Monitoring, the AliveCor Heart Monitor for iPhone and McKesson Cardiology’s ECG Mobile.

On the other hand, if Shapiro is right, the FDA could become a bottleneck which could severely stunt the growth of the U.S. mHealth industry. If nothing else, mHealth developers who seek FDA approval could be faced with a particularly prolonged approval process. While vendors wait for approval, they can keep innovating, but if their proposed blockbuster product is in limbo, it won’t be easy for them to stay solvent.

Not only that, if the FDA doesn’t have the institutional experience to reasonably evaluate such technologies, the calls it makes as to what is safe and efficacious may be off base. After all, apps and remote monitoring tools don’t bear much resemblance to traditional medical devices.

In theory, upstart mHealth companies which don’t have the resources to go through the FDA approval process can just proceed with their rollout. After all, the agency’s guidelines for requiring its approval are reasonably narrow.

But in reality, it seems unlikely that providers will adopt mHealth devices and apps wholesale until they get the FDA stamp of approval.  Whether they geniunely consider non-approved devices to be too lightweight for use, or fear being sued for using questionable technology, providers seem unlikely to integrate mHealth technology into their daily practice without the agency’s green light.

Given these concerns, we’d best hope that the FDA doesn’t begin requiring its approval for EMRs. Or at the very least, we should be glad that it didn’t jump in early. Who knows where EMR infrastructure would be if vendors had had to play patty-cake with the FDA from day one?

Significant Articles in the Health IT Community in 2015

Posted on December 15, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

Have you kept current with changes in device connectivity, Meaningful Use, analytics in healthcare, and other health IT topics during 2015? Here are some of the articles I find significant that came out over the past year.

The year kicked off with an ominous poll about Stage 2 Meaningful Use, with implications that came to a head later with the release of Stage 3 requirements. Out of 1800 physicians polled around the beginning of the year, more than half were throwing in the towel–they were not even going to try to qualify for Stage 2 payments. Negotiations over Stage 3 of Meaningful Use were intense and fierce. A January 2015 letter from medical associations to ONC asked for more certainty around testing and certification, and mentioned the need for better data exchange (which the health field likes to call interoperability) in the C-CDA, the most popular document exchange format.

A number of expert panels asked ONC to cut back on some requirements, including public health measures and patient view-download-transmit. One major industry group asked for a delay of Stage 3 till 2019, essentially tolerating a lack of communication among EHRs. The final rules, absurdly described as a simplification, backed down on nothing from patient data access to quality measure reporting. Beth Israel CIO John Halamka–who has shuttled back and forth between his Massachusetts home and Washington, DC to advise ONC on how to achieve health IT reform–took aim at Meaningful Use and several other federal initiatives.

Another harbinger of emerging issues in health IT came in January with a speech about privacy risks in connected devices by the head of the Federal Trade Commission (not an organization we hear from often in the health IT space). The FTC is concerned about the security of recent trends in what industry analysts like to call the Internet of Things, and medical devices rank high in these risks. The speech was a lead-up to a major report issued by the FTC on protecting devices in the Internet of Things. Articles in WIRED and Bloomberg described serious security flaws. In August, John Halamka wrote own warning about medical devices, which have not yet started taking security really seriously. Smart watches are just as vulnerable as other devices.

Because so much medical innovation is happening in fast-moving software, and low-budget developers are hankering for quick and cheap ways to release their applications, in February, the FDA started to chip away at its bureaucratic gamut by releasing guidelines releasing developers from FDA regulation medical apps without impacts on treatment and apps used just to transfer data or do similarly non-transformative operations. They also released a rule for unique IDs on medical devices, a long-overdue measure that helps hospitals and researchers integrate devices into monitoring systems. Without clear and unambiguous IDs, one cannot trace which safety problems are associated with which devices. Other forms of automation may also now become possible. In September, the FDA announced a public advisory committee on devices.

Another FDA decision with a potential long-range impact was allowing 23andMe to market its genetic testing to consumers.

The Department of Health and Human Services has taken on exceedingly ambitious goals during 2015. In addition to the daunting Stage 3 of Meaningful Use, they announced a substantial increase in the use of fee-for-value, although they would still leave half of providers on the old system of doling out individual payments for individual procedures. In December, National Coordinator Karen DeSalvo announced that Health Information Exchanges (which limit themselves only to a small geographic area, or sometimes one state) would be able to exchange data throughout the country within one year. Observers immediately pointed out that the state of interoperability is not ready for this transition (and they could well have added the need for better analytics as well). HHS’s five-year plan includes the use of patient-generated and non-clinical data.

The poor state of interoperability was highlighted in an article about fees charged by EHR vendors just for setting up a connection and for each data transfer.

In the perennial search for why doctors are not exchanging patient information, attention has turned to rumors of deliberate information blocking. It’s a difficult accusation to pin down. Is information blocked by health care providers or by vendors? Does charging a fee, refusing to support a particular form of information exchange, or using a unique data format constitute information blocking? On the positive side, unnecessary imaging procedures can be reduced through information exchange.

Accountable Care Organizations are also having trouble, both because they are information-poor and because the CMS version of fee-for-value is too timid, along with other financial blows and perhaps an inability to retain patients. An August article analyzed the positives and negatives in a CMS announcement. On a large scale, fee-for-value may work. But a key component of improvement in chronic conditions is behavioral health which EHRs are also unsuited for.

Pricing and consumer choice have become a major battleground in the current health insurance business. The steep rise in health insurance deductibles and copays has been justified (somewhat retroactively) by claiming that patients should have more responsibility to control health care costs. But the reality of health care shopping points in the other direction. A report card on state price transparency laws found the situation “bleak.” Another article shows that efforts to list prices are hampered by interoperability and other problems. One personal account of a billing disaster shows the state of price transparency today, and may be dangerous to read because it could trigger traumatic memories of your own interactions with health providers and insurers. Narrow and confusing insurance networks as well as fragmented delivery of services hamper doctor shopping. You may go to a doctor who your insurance plan assures you is in their network, only to be charged outrageous out-of-network costs. Tools are often out of date overly simplistic.

In regard to the quality ratings that are supposed to allow intelligent choices to patients, A study found that four hospital rating sites have very different ratings for the same hospitals. The criteria used to rate them is inconsistent. Quality measures provided by government databases are marred by incorrect data. The American Medical Association, always disturbed by public ratings of doctors for obvious reasons, recently complained of incorrect numbers from the Centers for Medicare & Medicaid Services. In July, the ProPublica site offered a search service called the Surgeon Scorecard. One article summarized the many positive and negative reactions. The New England Journal of Medicine has called ratings of surgeons unreliable.

2015 was the year of the intensely watched Department of Defense upgrade to its health care system. One long article offered an in-depth examination of DoD options and their implications for the evolution of health care. Another article promoted the advantages of open-source VistA, an argument that was not persuasive enough for the DoD. Still, openness was one of the criteria sought by the DoD.

The remote delivery of information, monitoring, and treatment (which goes by the quaint term “telemedicine”) has been the subject of much discussion. Those concerned with this development can follow the links in a summary article to see the various positions of major industry players. One advocate of patient empowerment interviewed doctors to find that, contrary to common fears, they can offer email access to patients without becoming overwhelmed. In fact, they think it leads to better outcomes. (However, it still isn’t reimbursed.)

Laws permitting reimbursement for telemedicine continued to spread among the states. But a major battle shaped up around a ruling in Texas that doctors have a pre-existing face-to-face meeting with any patient whom they want to treat remotely. The spread of telemedicine depends also on reform of state licensing laws to permit practices across state lines.

Much wailing and tears welled up over the required transition from ICD-9 to ICD-10. The AMA, with some good arguments, suggested just waiting for ICD-11. But the transition cost much less than anticipated, making ICD-10 much less of a hot button, although it may be harmful to diagnosis.

Formal studies of EHR strengths and weaknesses are rare, so I’ll mention this survey finding that EHRs aid with public health but are ungainly for the sophisticated uses required for long-term, accountable patient care. Meanwhile, half of hospitals surveyed are unhappy with their EHRs’ usability and functionality and doctors are increasingly frustrated with EHRs. Nurses complained about technologies’s time demands and the eternal lack of interoperability. A HIMSS survey turned up somewhat more postive feelings.

EHRs are also expensive enough to hurt hospital balance sheets and force them to forgo other important expenditures.

Electronic health records also took a hit from ONC’s Sentinel Events program. To err, it seems, is not only human but now computer-aided. A Sentinel Event Alert indicated that more errors in health IT products should be reported, claiming that many go unreported because patient harm was avoided. The FDA started checking self-reported problems on PatientsLikeMe for adverse drug events.

The ONC reported gains in patient ability to view, download, and transmit their health information online, but found patient portals still limited. Although one article praised patient portals by Epic, Allscripts, and NextGen, an overview of studies found that patient portals are disappointing, partly because elderly patients have trouble with them. A literature review highlighted where patient portals fall short. In contrast, giving patients full access to doctors’ notes increases compliance and reduces errors. HHS’s Office of Civil Rights released rules underlining patients’ rights to access their data.

While we’re wallowing in downers, review a study questioning the value of patient-centered medical homes.

Reuters published a warning about employee wellness programs, which are nowhere near as fair or accurate as they claim to be. They are turning into just another expression of unequal power between employer and employee, with tendencies to punish sick people.

An interesting article questioned the industry narrative about the medical device tax in the Affordable Care Act, saying that the industry is expanding robustly in the face of the tax. However, this tax is still a hot political issue.

Does anyone remember that Republican congressmen published an alternative health care reform plan to replace the ACA? An analysis finds both good and bad points in its approach to mandates, malpractice, and insurance coverage.

Early reports on use of Apple’s open ResearchKit suggested problems with selection bias and diversity.

An in-depth look at the use of devices to enhance mental activity examined where they might be useful or harmful.

A major genetic data mining effort by pharma companies and Britain’s National Health Service was announced. The FDA announced a site called precisionFDA for sharing resources related to genetic testing. A recent site invites people to upload health and fitness data to support research.

As data becomes more liquid and is collected by more entities, patient privacy suffers. An analysis of web sites turned up shocking practices in , even at supposedly reputable sites like WebMD. Lax security in health care networks was addressed in a Forbes article.

Of minor interest to health IT workers, but eagerly awaited by doctors, was Congress’s “doc fix” to Medicare’s sustainable growth rate formula. The bill did contain additional clauses that were called significant by a number of observers, including former National Coordinator Farzad Mostashari no less, for opening up new initiatives in interoperability, telehealth, patient monitoring, and especially fee-for-value.

Connected health took a step forward when CMS issued reimbursement guidelines for patient monitoring in the community.

A wonky but important dispute concerned whether self-insured employers should be required to report public health measures, because public health by definition needs to draw information from as wide a population as possible.

Data breaches always make lurid news, sometimes under surprising circumstances, and not always caused by health care providers. The 2015 security news was dominated by a massive breach at the Anthem health insurer.

Along with great fanfare in Scientific American for “precision medicine,” another Scientific American article covered its privacy risks.

A blog posting promoted early and intensive interactions with end users during app design.

A study found that HIT implementations hamper clinicians, but could not identify the reasons.

Natural language processing was praised for its potential for simplifying data entry, and to discover useful side effects and treatment issues.

CVS’s refusal to stock tobacco products was called “a major sea-change for public health” and part of a general trend of pharmacies toward whole care of the patient.

A long interview with FHIR leader Grahame Grieve described the progress of the project, and its the need for clinicians to take data exchange seriously. A quiet milestone was reached in October with a a production version from Cerner.

Given the frequent invocation of Uber (even more than the Cheesecake Factory) as a model for health IT innovation, it’s worth seeing the reasons that model is inapplicable.

A number of hot new sensors and devices were announced, including a tiny sensor from Intel, a device from Google to measure blood sugar and another for multiple vital signs, enhancements to Microsoft products, a temperature monitor for babies, a headset for detecting epilepsy, cheap cameras from New Zealand and MIT for doing retinal scans, a smart phone app for recognizing respiratory illnesses, a smart-phone connected device for detecting brain injuries and one for detecting cancer, a sleep-tracking ring, bed sensors, ultrasound-guided needle placement, a device for detecting pneumonia, and a pill that can track heartbeats.

The medical field isn’t making extensive use yet of data collection and analysis–or uses analytics for financial gain rather than patient care–the potential is demonstrated by many isolated success stories, including one from Johns Hopkins study using 25 patient measures to study sepsis and another from an Ontario hospital. In an intriguing peek at our possible future, IBM Watson has started to integrate patient data with its base of clinical research studies.

Frustrated enough with 2015? To end on an upbeat note, envision a future made bright by predictive analytics.

Using APIs at the Department of Health and Human Services to Expand Web Content

Posted on October 21, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

Application Programming Interfaces (APIs) appeal mostly to statisticians and researchers whose careers depend on access to data. But these programming tools are also a useful part of a Web that is becoming increasingly supple and sophisticated. I have written a series of articles about the use of APIs to share and run analytics on patient data, but today I’ll cover a cool use of an API developed by the Department of Health and Human Services for disseminating educational material.

The locus for this activity started with the wealth of information created by the Centers for Disease Control for doctors, public health workers, and the general public. Striving to help the public understand vaccinations, West Nile fever, Ebola (when that was a major public issue), and even everyday conditions such as diabetes, the CDC realized they had to make their content simple to embed in web sites for all those audiences.

The CDC also realized that it would be helpful to let outsiders quickly choose content along a number of dimensions. Not only would a particular web site be interested in a particular topic (diabetes, for instance), but they would want to filter the content to offer information to a particular audience in a particular language. One Web page might offer content aimed at doctors in English, while another might offer content for the general public in English and yet another offer content in Spanish. To allow all these distinctions, a RESTful API called from JavaScript allows each Web page to bring in just what is needed. Topics and languages are offered now, and filtering by audience will be supported soon. At some point, the API will even recognize ICD-10 codes and find any content related to those disease conditions.

We are all familiar with Web pages that embed dynamic content from other sites, such as videos from YouTube or Vimeo. Web developers embed the content by visiting the desired page, clicking on an Embed button, and copying some dense HTML to their own pages. The CDC offers several ways for visitors to syndicate content in this manner to their own web sites. If they are using a popular content management system (WordPress, Drupal, or Joomla!) they can install a plug-in that uses familiar practices to embed the content. Mobile app support is also provided. But the API developed by the CDC takes the process to a much more advanced level.

First, as already described, the API lets each page specify filters that extract content on the desired topic for the desired audience. Second, if a new video, e-card, or microsite is added to the CDC site, the API automatically picks it up when a user revisits the embedding page. Thus, without fussing with HTML, a site can integrate CDC content that’s tailored pretty precisely to its needs.

This API is also in use at the FDA–see for instance their Center for Tobacco Products–and at HHS more broadly. A community is starting to build around the code, which is open source, and soon it will be on GitHub, the most popular site for code sharing. A terse documentation page is available.

The API from Health and Human Services offers several lessons for health IT. First, communications can be improved by using the advanced features provided by the Web. (In addition to the API, the CDC tools make sophisticated use of HTML5 and iFrames to offer dynamic content in ways that fit in smoothly with the sites that choose to embed it.) Second, sites need to consider the people at the other end of the transaction in order to design tools that deliver an easy-to-use and easy-to-understand experience. And finally, releasing code as open source maximizes its value to the health care community. These trends need to be more widely adopted.

FDA Adds Patient Engagement Advisory Committee

Posted on September 21, 2015 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

Today on the FDA blog they announced the first ever Patient Engagement Advisory Committee. I’m sure that patient advocates all over the US are celebrating this addition. I love this acknowledgement on the blog post announcement:

Although it may seem odd in retrospect, the development of new technologies intended to improve patients’ lives has largely relied upon expert opinions rather than asking patients and families directly what they consider most important.

But that’s changing.

This is a great first step for the FDA to have more involvement from the patient. It can be easy as a researcher to ignore the patient voice when looking at the data for a drug or medical device. Hopefully this new committee will provide a more well rounded view of the impact their choices have on the lives of patients.

Here’s the outline of ways the FDA thinks this patient committee can help the FDA:

  • to help identify the most important benefits and risks of a technology from a patient’s perspective;
  • to assess the relative importance to patients of different attributes of benefit and risk, and clarify how patients think about the tradeoffs of these benefits and risks for a given technology; and
  • to help understand how patient preferences vary across a population.

I’m excited to see how this works out for the FDA. Although, is it just me or does one patient committee feel like a bad strategy for engaging patients? How can one patient committee understand the impact of hundreds of drugs and medical devices. It almost seems like every drug or medical device needs its own patient committee to be able to provide quality feedback for that drug or medical device. Maybe you could narrow it a bit more to specific disease types or something.

I realize there’s a massive scaling problem when you start talking about one patient committee for every drug or medical device. I’d suggest that the company submitting the drug or medical device could provide the patient committee, but that would be fraught with conflict of interest. Even if the FDA opened up a virtually committee online you can imagine how the various companies would game that system by “encouraging” patients to submit comments to that virtual online committee.

Maybe the best solution would be to work with the healthcare organizations themselves and get them to encourage patient feedback on the various drugs and medical devices that are being approved. I’m sure there are ways that can be gamed as well. The key for me is making sure that a broader patient voice is heard. One committee is a great step forward, but that’s putting a lot of power into a few people’s hands and they may not have the time or understanding needed to provide quality feedback across the wide variety of drugs and medical devices that are being approved by the FDA.

Wearables Data May Prevent Health Plan Denials

Posted on August 27, 2015 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

This story begins, as many do, with a real-world experience. Our health plan just refused to pay for a sleep study for my husband, who suffers from severe sleep apnea, despite his being quite symptomatic. We’re following up with the Virginia Department of Insurance and fully expect to win the day, though we remain baffled as to how they could make such a decision. While beginning the complaint process, a thought occurred to me.

What if wearables were able to detect wakefulness and sleepiness, and my husband was being tracked 24 hours a day?  If so, assuming he was wearing one, wouldn’t it be harder for a health plan to deny him the test he needed? After all, it wouldn’t be the word of one doctor versus the word of another, it would be a raft of data plus his sleep doctor’s opinion going up against the health plan’s physician reviewer.

Now, I realize this is a big leap in several ways.

For one thing, today doctors are very skeptical about the value generated by patient-controlled smartphone apps and wearables. According to a recent survey by market research firm MedPanel, in fact, only 15% of doctors surveyed see wearables of health apps as tools patients can use to get better. Until more physicians get on board, it seems unlikely that device makers will take this market seriously and nudge it into full clinical respectability.

Also, data generated by apps and wearables is seldom organized in a form that can be accessed easily by clinicians, much less uploaded to EMRs or shared with health insurers. Tools like Apple HealthKit, which can move such data into EMRs, should address this issue over time, but at present a lack of wearable/app data interoperability is a major stumbling block to leveraging that data.

And then there’s the tech issues. In the world I’m envisioning, wearables and health apps would merge with remote monitoring technologies, with the data they generate becoming as important to doctors as it is to patients. But neither smartphone apps nor wearables are equipped for this task as things stand.

And finally, even if you have what passes for proof, sometimes health plans don’t care how right you are. (That, of course, is a story for another day!)

Ultimately, though, new data generates new ways of doing business. I believe that when doctors fully adapt to using wearable and app data in clinical practice, it will change the dynamics of their relationship with health plans. While sleep tracking may not be available in the near future, other types of sophisticated sensor-based monitoring are just about to emerge, and their impact could be explosive.

True, there’s no guarantee that health insurers will change their ways. But my guess is that if doctors have more data to back up their requests, health plans won’t be able to tune it out completely, even if their tactics issuing denials aren’t transformed. Moreover, as wearables and apps get FDA approval, they’ll have an even harder time ignoring the data they generate.

With any luck, a greater use of up-to-the-minute patient monitoring data will benefit every stakeholder in the healthcare system, including insurers. After all, not to be cliched about it, but knowledge is power. I choose to believe that if wearables and apps data are put into play, that power will be put to good use.

Where Medical Devices Fall Short: Can More Testing Help? (Part 2 of 2)

Posted on April 6, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

As we saw in the previous article, networks of medical devices suffer from many problems intrinsic to the use of wireless technology. But testimony at the joint workshop held by the FCC and FDA on March 31 revealed that problems with the devices themselves run deep. One speaker reported uncovering departures from the standards for transmitting information, which led to incompatibilities and failures. Another speaker found repeated violations of security standards. As a trivial example, many still use the insecure and long-deprecated WEP authentication instead of WPA.

Most devices incorporate generic radio transmitters from third parties, just as refrigerators use replaceable compressors and lawnmowers depend on engines from just a few manufacturers. When markets become commoditized in this way, one would expect reliability. Whatever problems radio transmitters may have, though, are compounded by the software layered on top. Each device needs unique software that can affect the transmissions.

The WiFi Alliance is a consortium of manufacturers that tests devices for reliability and interoperability. But because it doesn’t contain users or government representatives, some panelists thought it was too lenient toward manufacturers. The test plan itself is a trade secret (although it was described at a high level in the workshop by Mick Conley). Several speakers testified that devices could be certified by the Alliance and still perhaps fail to connect.

To my mind, testing is a weak response to design problems. It happens after the fact, and can punish a poor engineering process but not fix it. You can test-drive a car and note that the steering is a bit sluggish, but can you identify the software or the part that is causing the problem? And can you explain it to the salesman, presumably to be conveyed back to the engineers?

Cars tend to be reliable first because of widespread competition that extends internationally, and partly because lawsuits keep the managers of the automobile companies alert to engineering problems. It would be a shame to need lawsuits to correct technical problems with medical devices, but refusing to buy them might do the trick. Test beds do provide warnings that can aid purchase decisions.

Unfortunately, the forum produced no real progress on the leading question of the day, whether a national test bed would be a good idea. It was recognized generally that test beds have to reflect the particular conditions at different institutions, and that multiple test beds would be needed to cover a useful range of settings. Without further clarification of what a test bed would look like, or who would build it, a couple panelists called for the creation of national test beds. More usefully, in my opinion, one speaker suggested a public repository of tests, which are currently the proprietary sects of vendors or academic researchers.

So none of the questions about test beds received answers at the workshop, and no practical recommendations emerged. One would expect that gathering the leading experts in medical devices for seven and a half hours would allow them to come up with actionable next steps or at least a framework for proceeding, but much of the workshop was given over to rhetoric about the importance of medical devices, the need for them to interoperate, and other standard rallying cries of health care reform. I sometimes felt that I was in hearing a pitch for impressionable financial backers. And of course, there was always time taken up by vendors, providers, and regulators trying to point the finger at someone else for the problems.

Device and networking expert David Höglund has written up how the workshop fell short. I would like someone to add up all the doctors, all the senior engineers, all the leading policy makers in the room, calculate how much they are paid per minute, and add up the money wasted every time a speaker extols patient engagement, interoperability, or some other thesis that is already well known to everybody in the room. (Or perhaps they aren’t well-known–another challenge to the medical field.)

Personally, I would write off most of the day as a drain on the US economy. But I have tried to synthesize the points we need to look at going forward, so that I hope you feel the time you devoted to reading the article was well-spent.

Where Medical Devices Fall Short: Can More Testing Help? (Part 1 of 2)

Posted on April 3, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

Clinically, medical devices do amazing things–they monitor vital signs (which, as the term indicates, can have life-or-death implications), deliver care, and measure health in the form of fitness devices. But technologically, medical devices fall way short–particularly in areas of interference, interoperability, and security.

The weaknesses of devices, their networks, and the settings where they reside came up over and over again in a joint workshop held by the FCC and FDA on March 31. I had a chance to hear most of it via live broadcast, a modern miracle of networking in itself.

Officially, the topic of the gathering was test beds for medical devices. Test beds are physical centers set up to mimic real-life environments in which devices are used, hosting large numbers of devices from different manufacturers running the popular software and protocols that they would employ out in the field. The workshop may have been an outgrowth of a 2012 report from an FCC mHealth Task Force which recommended “FCC should encourage and lend its expertise for the creation and implementation of wireless test beds.” (Goal 4.4, page 13) I thought the workshop had little new to offer on test beds, however, as the panelists concentrated on gaps between clinical needs and the current crop of devices and networks.

Medical settings are notoriously difficult places to employ technology. One panelist even referred to them as “hostile environments,” which I think is going a bit far. After all, other industries employ devices outdoors where temperatures drop below zero or rise precariously, or underwater, or even on battlefields (which actually are also medical settings).

I don’t dispute that medical networks present their own particular challenges. Hospitals crowd many devices into small spaces (one picture displayed at the workshop showed 15 wireless devices in a hospital room). Some last for decades, churning away while networks, environments, and requirements change around them. Walls and equipment may contain lead, blocking signals. Meanwhile, patient safety requires correct operation, resilience, and iron-clad security. Meanwhile, patients and their families expect access to a WiFi networks just like they get in the cafe down the street.

And yet Shawn Jackman, Director of Strategic Planning at Kaiser Permanente IT, said that problems are usually not in the infrastructure but in the devices. Let’s look at the main issue, interference (on which the panelists spent much more time than interoperability or security) and then at the ideas emerging from the workshop.

All the devices we associate with everyday network use (the IEEE 802.11 devices called WiFi) are all squeezed into two bands of the radio spectrum at 2.4 Gigahertz and 5 Gigahertz. When the inventors of WiFi told the world’s regulators that they had a new technology requiring a bandwidth in which to operate, freeing up existing bandwidth was hard to do, and the inventors were mere engineers, not powerful institutions such as the military or television broadcasters. So they resigned themselves to the use of the 2.4 and 5 Gigahertz bands, which were known as “junk spectrum” because all sorts of other equipment were allowed to emit radio-frequency noise in those bands.

Thus, because the bands are relatively narrow and are crowded with all sorts of radio emissions, interference is hard to avoid. But you don’t want to enter a patient’s room and find her comatose while a key monitor was unable to send out its signal.

Ironically, at the request of health IT companies, the FCC set aside two sets of spectrum for medical use, the Medical Device Radiocommunications Service (MedRadio) established in 1999 and the Wireless Medical Telemetry Service (WMTS) established in 2002. But these are almost completely ignored.

According to Shahid Shah, a medical device and software development expert, technologies that are dedicated to narrow markets such as health are crippled from the outset. They can’t benefit from the economies of scale enjoyed by mass market technologies, so they tend to be expensive, poorly designed, and locked in to their vendors. Just witness the market for electronic health records. So the medical profession found devices designed for the medical bands unsatisfactory and turned to devices that used the WiFi spectrum.

In 2010, by the way, the FCC relaxed its rules and permitted new devices to enter the little-used spectrum at the edges of television channels, known as white spaces, but commercial exploitation of the new spectrum is still in its infancy.

Furthermore, the FCC has freed up the enormous bandwidth used for decades to broadcast TV networks, by kicking off the stubborn users (known with respect as the “last grandmas”) who didn’t want to pay more for cable. An enormous stretch of deliciously long-range spectrum is theoretically available for public use–but the FCC won’t release it that way. Instead, they will sell it to other large corporations.

Networks are unreliable across the field. How often do you notice the wireless Internet go down at a conference? (It happened to me at a conference I attended the next day after the FCC/FDA workshop. At one conference, somebody even stole the hubs!) Further problems include network equipment of different ages that use slightly different protocols, which prove particularly troublesome when devices have to change location. (Think of wheeling a patient down the hall.) And you can’t just make sure everything is working the first time a device is deployed. Changes in the environment and surrounding equipment can lead to a communications failure that never turned up before, or that turned up and you thought you had fixed.

Medical device and wireless expert David Höglund claims that WLAN can work in a healthcare environment for medical devices. He lays out three overarching tasks that administrators must do for success:

  • They have to understand how each application works and its communications patterns: real-time delivery of small packets, batch delivery of large volumes of data, etc.

  • They have to provide the coverage required for each device or application. Is it used in the hallways, the patient rooms, the labs? How about the elevators on which patients are transported?

  • They need to obey the application’s quality service requirements. For instance, how long is a failure tolerable? For a device monitoring a patient’s heart in the ICU, a five-second interruption may be too long.

Medical devices and hospital networks need to be more robust and more secure than the average WiFi network. This calls for redundant equipment, separate networks for different purposes, and lots of testing. Hence the need for test beds, which many hospitals and conglomerates set up for themselves. Should the FCC create a national test bed? We’ll look at that in the next installment of this article.

Adverse Event Reporting and EHRs: The MEDTECH Act’s Effects

Posted on December 18, 2014 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

Medical systems generate adverse event (AE) reports to improve service delivery and public safety.

As I described in my first blog post on Adverse Events, these reports are both a record of what went wrong and a rich source for improving workflow, process and policy. They can nail responsibility not only for bad acts, but also bad actors and can help distinguish between the two. The FDA gathers AE reports to look for important health related patterns, and if needed to trigger recalls, modifications and public alerts.

EHRs generate AEs, but the FDA doesn’t require reporting them. Reporting is only for medical devices defined by the FDA and EHRs aren’t. However, users sometimes report EHR related AEs. Now, there’s proposed legislation that would preclude EHRs as medical devices and stop any consideration of EHR reports.

MEDTECH Act’s Impact

EHRs are benign software systems that need minimal oversight. At least that’s what MEDTECH Act’s congressional sponsors, Senators Orrin Hatch (R- Utah) and Michael Bennett (D- Colorado) think. If they have their way – and much of the EHR industry hopes so – the FDA can forget regulating EHRs and tracking any EHR related AEs.

EHRs and Adverse Events

Currently, if you ask MAUD, the FDA’s device, adverse event tracking system about EHRs, you don’t get much, as you might expect. Up to October, MAUD has 320,000 AEs. Of these about 30 mention an EHR in passing. (There may be many more, but you can’t search for phrases such as “electronic health,” etc.) While the FDA hasn’t defined EHRs as a device, vendors are afraid it may. Their fear is based on this part of the FDA’s device definition standard:

[A]n instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:

…[I]ntended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals…

I think this section clearly covers EHRs. They are intended for diagnostic, cure, mitigation, etc., of disease. Consistent public policy in general and a regard for protecting the public’s health, I think, augers for mandatory reporting of EHR caused AEs.

Why then aren’t EHRs devices that require AE reporting? In a word, politics. The FDA’s been under pressure from vendors who contend their products aren’t devices just software. They also don’t want their products subject to being criticized for failures, especially in instances where they have no control over the process. That may be understandable from a corporate point of view, but there are several reasons for rejecting that point of view. Consider what the FDA currently defines as a medical device.

Other Devices. The FDA captures AE reports on an incredible number of devices. A few examples:

  • Blood pressure computers
  • Crutches
  • Drug dose calculators
  • Ice bags
  • Lab gear – practically all
  • Robotic telemedicine devices, and many, many more.

ECRI on EHR Adverse Events

The respected patient safety NGO, the ECRI Institute, puts the issue squarely. Each year, it publishes its Top Ten Health Technology Hazards. Number one is inadequate alarm configuration policies and practices. Number two: “Incorrect or missing data in electronic health records and other health IT systems.” Its report says:

Many care decisions today are based on data in an electronic health record (EHR) or other IT-based system. When functioning well, these systems provide the information clinicians need for making appropriate treatment decisions. When faults or errors exist, however, incomplete, inaccurate, or out-of-date information can end up in a patient’s record, potentially leading to incorrect treatment decisions and patient harm. What makes this problem so troubling is that the integrity of the data in health IT (HIT) systems can be compromised in a number of ways, and once errors are introduced, they can be difficult to spot and correct. Examples of data integrity failures include the following:

  • Appearance of one patient’s data in another patient’s record (i.e., a patient/data mismatch)
  • Missing data or delayed data delivery (e.g., because of network limitations, configuration errors, or data entry delays)
  • Clock synchronization errors between different medical devices and systems
  • Default values being used by mistake, or fields being prepopulated with erroneous data
  • Inconsistencies in patient information when both paper and electronic records are used
  • Outdated information being copied and pasted into a new report Programs for reporting and reviewing HIT-related problems can help organizations identify and rectify breakdowns and failures.

ECRI spells out why AE reporting is so important for EHRs:

…[S]uch programs face some unique challenges. Chief among these is that the frontline caregivers and system users who report an event—as well as the staff who typically review the reports—may not understand the role that an HIT system played in an event…

The MEDTECH Act’s Effects

The move to curtail the FDA’s EHR jurisdiction is heating up. Senators Hatch and Bennett’s proposed act exempts EHRs from FDA jurisdiction by defining EHRs as passive data repositories.

Most industry chatter about the act has been its exempting EHRs and others from the ACA’s medical device tax. However, by removing FDA’s jurisdiction, it would also exempt EHRs from AE reports. Repealing a tax is always popular. Preventing AE reports may make vendors happy, but clinicians, patients and the public may not be as sanguine.

The act’s first two sections declare that any software whose main purpose is administrative or financial won’t come under device reporting.

Subsection (c) is the heart of the act, which exempts:

Electronic patient records created, stored, transferred, or reviewed by health care professionals or individuals working under supervision of such professionals that functionally represent a medical chart, including patient history records,

Subsection (d) says that software that conveys lab or other test results are exempt.

Subsection (e) exempts any software that makes recommendations for patient care.

There are several problems with this language. The first is that while it goes to lengths to say what is not a device, it is silent about what is. Where is the line drawn? If an EHR includes workflow, as all do, is it exempt because it also has a chart function? The bill doesn’t say

Subsection (d) on lab gear is also distressing. Currently, most lab gear are FDA devices. Now, if your blood chemistry report is fouled by the lab’s equipment ends up harming you, it’s reportable. Under MEDTECH, it may not be.

Then there’s the question of who’s going to decide what’s in and what’s out? Is it the FDA or ONC, or both? Who knows Most important, the bill’s negative approach fails to account for those AEs, as ECRI puts it when: “Default values being used by mistake, or fields being prepopulated with erroneous data.”

Contradictory Terms

The act has a fascinating proviso in subsection (c):

…[P]rovided that software designed for use in maintaining such patient records is validated prior to marketing, consistent with the standards for software validation relied upon by the Secretary in reviewing premarket submissions for devices.

This language refers to information that device manufacturers file with HHS prior to marketing. Oddly, it implies that EHRs are medical devices under the FDA’s strictest purview, though the rest of the act says they are not. Go figure.

What’s It Mean?

The loud applause for the MEDTECH act coming from the EHR industry, is due to its letting vendors off the medical device hook. I think the industry should be careful about what it’s wishing for. Without effective reporting, adverse events will still occur, but without corrective action. In that case, everything will seem to go swimmingly. Vendors will be happy. Congress can claim to being responsive. All will be well.

However, this legislative penny in the fuse box will prove that keeping the lights on, regardless of consequences, isn’t the best policy. When something goes terribly wrong, but isn’t reported then, patients will pay a heavy price. Don’t be surprised when some member of Congress demands to know why the FDA didn’t catch it.