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!

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.

How Open mHealth Designed a Popular Standard (Part 3 of 3)

Posted on December 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.

The first section of this article introduced the common schemas for mobile health designed by Open mHealth, and the second section covered the first two design principles driving their schemas. We’ll finish off the design principles in this section.

Balancing permissiveness and constraints

Here, the ideal is to get accurate measurements to the precision needed by users and researchers. But many devices are known to give fuzzy results, or results that are internally consistent but out of line with absolute measurements.

The goal adopted by Open mHealth is to firm up the things that are simple to get right and also critical to accuracy, such as units of measurement discussed earlier. They also require care in reporting the time interval that a measurement covers: day, week, month. There’s no excuse if you add up the walks recorded for the day and the sum doesn’t match the total steps that the device reports for that day.

Some participants suggested putting in checks, such as whether the BMI is wildly out of range. The problem (in terms of public health as well as technology) is that there are often outlier cases in health care, and the range of what’s a “normal” BMI can change. The concept of a maximum BMI is therefore too strict and ultimately unhelpful.

Designing for data liquidity

Provenance is the big challenge here: where does data come from, how was it collected, and what algorithm was used to manipulate it? Open mHealth expects data to go far and wide among researchers and solution providers, so the schema must keep a trail of all the things done to it from its origin.

Dr. Sim said the ecosystem is not yet ready to ensure quality. For instance, a small error introduced at each step of data collection and processing can add up to a yawning gap between the reported measure and the truth. This can make a difference not only to researchers, but to the device’s consumers. Think, for instance, of a payer basing the consumer’s insurance premium on analytics performed on data from the device over time.

Alignment with clinical data standards

Electronic health records are starting to accept medical device data. Eventually, all EHRs will need to do this so that monitoring and connected health can become mainstream. Open mHealth adopted widespread medical ontologies such as SNOMED, which may seem like an obvious choice but is not at all what the devices do. Luckily, Open mHealth’s schemas come pre-labelled with appropriate terminology codes, so device developers don’t need to get into the painful weeds of medical coding.

Modeling of Time

A seemingly simple matter, time is quite challenging. The Open mHealth schema can represent both points in time and time intervals. There are still subtleties that must be handled properly, as when a measurement for one day is reported on the next day because the device was offline. These concerns feed into provenance, discussed under “Designing for data liquidity.”

Preliminary adoption is looking good. The schema will certainly evolve, hopefully allowing for diversity while not splintering into incompatible standards. This is the same balance that FHIR must strike under much more difficult circumstances. From a distance, it appears like Open mHealth, by keeping a clear eye on the goal and a firm hand on the development process, have avoided some of the pitfalls that the FHIR team has encountered.

How Open mHealth Designed a Popular Standard (Part 2 of 3)

Posted on December 2, 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.

The previous section of this article introduced the intensive research and consultation strategy used by Open mHealth to develop a common schema for exploiting health data by app developers, researchers, clinicians, individuals, and manufacturers of medical and fitness devices. Next we’ll go through the design principles with a look at specific choices and trade-offs.

Atomicity

Normally, one wants to break information down into chunks as small as possible. By doing this, you allow data holders to minimize the amount of data they need to send data users, and data users are free to scrutinize individual items or combine them any way they want. But some values in health need to be chunked together. When someone requests blood pressure, both the systolic and diastolic measures should be sent. The time zone should go with the time.

On the other hand, mHealth doesn’t need combinations of information that are common in medical settings. For instance, a dose may be interesting to know, but you don’t need the prescribing doctor, when the prescription was written, etc. On the other hand, some app developers have asked the prescription to include the number of refills remaining, so the app can issue reminders.

Balancing parsimony and complexity

Everybody wants all the data items they find useful, but don’t want to scroll through screenfuls of documentation for other people’s items. So how do you give a bewildering variety of consumers and researchers what they need most without overwhelming them?

An example of the process used by Open mHealth was the measurement for blood sugar. For people with Type 1 or Type 2 diabetes, the canonical measurement is fasting blood sugar first thing in the morning (the measurement can be very different at different times of the day). This helps the patients and their clinicians determine their overall blood sugar control. Measurements of blood sugar in relation to meals (e.g., two hours after lunch) or to sleep (e.g., at bedtime) is also clinically useful for both patients and clinicians.

Many of these users are curious what their blood sugar level is at other times, such as after a run. But to extend the schema this way would render it mind-boggling. And Dr. Sim says these values have far less direct clinical value for people with Type 2 diabetes, who are the majority of diabetic patients. So the schema sticks with reporting blood sugar related to meals and sleep. If users and vendors work together, they are free to extend the standard–after all, it is open source.

Another reason to avoid fine-grained options is that it leads to many values being reported inconsistently or incorrectly. This is a concern with the ICD-10 standard for diagnoses, which has been in use in europe for a long time and became a requirement for billing in the US since early October. ICD-9 is woefully outdated, but so much was dumped into ICD-10 that its implementation has left clinicians staying up nights and ignoring real opportunities for innovation. (Because ICD is aimed mostly at billing, it is not used for coding in Open mHealth schemas.)

Thanks to the Open mHealth schema, a dialog has started between users and device manufacturers about what new items to include. For instance, it could include average blood sugar over a fixed period of time, such as one month.

In the final section of this article, we’ll cover the rest of the design principles.

How Open mHealth Designed a Popular Standard (Part 1 of 3)

Posted on December 1, 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.

If standards have not been universally adopted in the health care field, and are often implemented incorrectly when adopted, the reason may simply be that good standards are hard to design. A recent study found that mobile health app developers would like to share data, but “Less progress has been made in enabling apps to connect and communicate with provider healthcare systems–a fundamental requirement for mHealth to realize its full value in healthcare management.”

Open mHealth faced this challenge when they decided to provide a schema to represent the health data that app developers, research teams, and other individuals want to plug into useful applications. This article is about how they mined the health community for good design decisions and decided what necessary trade-offs to make.

Designing a good schema involves intensive conversations with several communities that depend on each other but often have trouble communicating their needs to each other:

Consumers/users

They can tell you what they’re really interested in, and give you surprising insights about what a product should produce. In the fitness device space, for instance, Open mHealth was told that consumers would like time zones including with timing data–something that currently is supported rarely and poorly. Manufacturers find time zones hard to do, and feel little competitive pressure to offer them.

Vendors/developers

They can fill you in on the details of their measurements, which might be hard to discern from the documentation or the devices themselves. A simple example: APIs often retrieve weight values without units. If you’re collecting data across many people and devices for clinical or scientific purposes (e.g., across one million people for the new Precision Medicine Initiative), you can’t be guessing whether someone weighs 70 pounds or 70 kilograms.

Clinicians/Researchers

They offer insights on long-range uses of data and subtleties that aren’t noticeable in routine use by consumers. For example, in the elderly and those on some types of medications, blood pressure can be quite different standing up or lying down. Open mHealth captures this distinction.

With everybody weighing in, listening well and applying good medical principles is a must, otherwise, you get (as co-founder Ida Sim repeatedly said in our phone call) “a mess.” Over the course of many interviews, one can determine the right Pareto distribution: finding the 20% of possible items that satisfy 90% of the most central uses for mobile health data.

Open mHealth apparently made good use of these connections, because the schema is increasingly being adhered to by manufacturers and adopted by researchers as well as developers throughout the medical industry. In the next section of this article I’ll take a look at some of the legwork that that went into turning the design principles into a useful schema.

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.

WearDuino Shows That Open Source Devices Are a Key Plank in Personal Health

Posted on August 13, 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.

New devices are democratizing health. We see it not only in the array or wearable fitness gear that an estimated 21 percent of Americans own (and that some actually wear), but also in innovative uses for mobile phones (such as testing vision in regions that lack doctors or checking athletes for concussions) and now in low-cost devices that are often open source hardware and software. Recent examples of the latter include the eyeSelfie, which lets a non-professional take an image of his retina, and the WearDuino, a general-purpose personal device that is the focus of this article.

WearDuino is the brainchild of Mark Leavitt, a medical internist who turned to technology (as have so many doctors pursuing visions of radical reform in health care). I ran into Leavitt at the 2015 Open Source convention, where he also described his work briefly in a video interview.

Leavitt’s goal is to produce a useful platform that satisfies two key criteria for innovation: low-cost and open. Although some of the functions of the WearDuino resembles devices on the market, you can take apart the WearDuino, muck with it, and enhance it in ways those closed platforms don’t allow.

Traits and Uses of WearDuino
Technically, the device has simple components found everywhere, but is primed for expansion. A small Bluetooth radio module provides the processing, and as the device’s name indicates, it supports the Arduino programming language. To keep power consumption low there’s no WiFi, and the device can run on a cheap coin cell battery for several months under normal use.

Out of the box, the WearDuino could be an excellent fitness device. Whereas most commercial fitness wearables collect their data through an accelerometer, the WearDuino has an accelerometer (which can measure motion), a gyroscope (which is useful for more complex measurements as people twist and turn), and a magnetometer (which acts as a compass). This kind of three-part device is often called a “9-degree of freedom sensor,” because each of those three measurements is taken in three dimensions.

When you want more from the device, such as measuring heartbeat, muscle activity, joint flexing, or eye motion, a board can be added to one of the Arduino’s 7 digital I/O pins. Leavitt said that one user experimented with a device that lets a parent know when to change a baby’s diaper, through an added moisture detector.

Benefits of an Open Architecture
Proprietary device manufacturers often cite safety reasons for keeping their devices closed. But Leavitt believes that openness is quite safe through most phases of data use in health. Throughout the stages of collecting data, visualizing the relationships, and drawing insights, Leavitt believes people should be trusted with any technologies they want. (I am not sure these activities are so benign–if one comes up with an incorrect insight it could lead you to dangerous behavior.) It is only when you get to giving drugs or other medical treatments that the normal restrictions to professional clinicians makes sense.

Whatever safety may adhere to keeping devices closed, there can be no justification on the side of the user for keeping the data closed. And yet proprietary device manufacturers play games with the user’s data (and not just games for health). Leavitt, for instance, who wears a fitness monitor, says he can programmatically download a daily summary of his footsteps, but not the exact amounts taken at different parts of the day.

The game is that device manufacturers cannot recoup the costs of making and selling the devices through the price of the device alone. Therefore, they keep hold of users’ data and monetize it through marketing, special services, and other uses.

Leavitt doesn’t have a business plan yet. Instead, in classic open source practice, he is building community. Where he lives in Portland, Oregon a number of programmers and medical personnel have shown interest. The key to the WearDuino project is not the features of the device, but whether it succeeds in encouraging an ecosystem of useful personal monitors around it.

Early Warnings Demonstrate an Early Advance in the Use of Analytics to Improve Health Care

Posted on May 4, 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.

Early warning systems–such as the popular Modified Early Warning System (MEWS) used in many hospitals–form one of the first waves in the ocean of analytics we need to wash over our health care system. Eventually, health care will elegantly integrate medical device output, electronic patient records, research findings, software algorithms, and–yes, let us not forget–the clinician’s expertise in a timely intervention into patient care. Because early warning systems are more mature than many of the analytics that researchers are currently trying out, it’s useful to look at advances in early warning to see trends that can benefit the rest of health care as well.

I talked this week to Susan Niemeier, Chief Nursing Officer at CapsuleTech, a provider of medical device integration solutions. They sell (among other things) a bedside mobile clinical computer called the Neuron that collects, displays, and sends to the electronic medical record vital signs from medical devices: temperature, pulse, respiration, pulse oximetry, and so on. A recent enhancement called the Early Warning Scoring System (EWSS) adds an extra level of analytics that, according to Niemeier, can identify subtle signs of patient deterioration well before a critical event. It’s part of Capsule’s overarching aim to enable hospitals to do more with the massive amount of data generated by devices.

For more than 18 years, CapsuleTech provided bedside medical device connectivity products and services that captured patient vital signs and communicated that data to the hospital EMR. Rudimentary as this functionality may appear to people using automated systems in other industries, it was a welcome advance for nurses and doctors in hospitals. Formerly, according to Niemeier, nurses would scribble down on a scrap of paper or a napkin the vital signs they saw on the monitors. It might be a few hours before they could enter these into the record–and lots could go wrong in that time. Furthermore, the record was a simple repository, with no software observing trends or drawing conclusions.

Neuron 2 running Early Warning Scoring System

Neuron 2 running Early Warning Scoring System

So in addition to relieving the nurse of clerical work (along with likely errors that it entails), and enhancing workflow, the Neuron could make sure the record immediately reflected vital signs. Now the Neuron performs an even more important function: it can run a kind of clinical support to warn of patients whose conditions are deteriorating.

The Neuron EWSS application assigns a numerical score to each vital sign parameter. The total early warning score is then calculated on the basis of the algorithm implemented. The higher the score, the greater the likelihood of deterioration. The score is displayed on the Neuron along with actionable steps for immediate intervention. These might include more monitoring, or even calling the rapid response team right away.

The software algorithm is configured in a secure management tool accessible through a web browser and sent wirelessly to the Neuron at a scheduled time. The management tool is password protected and administered by a trained designee at the hospital, allowing for greater flexibility and complete ownership of the solution.

Naturally, the key to making this simple system effective is to choose the right algorithm for combining vital signs. The United Kingdom is out in front in this area. They developed a variety of algorithms in the late 1990s, whereas US hospitals started doing so only 5 years ago. The US cannot simply adopt the UK algorithms, though, because our care delivery and nursing model is different. Furthermore, each hospital has different patient demographics, priorities, and practices.

On the other hand, according to Niemeier, assigning different algorithms to different patients (young gun-shot victims versus elderly cardiac patients, for instance) would be impractical because mobile Neuron computers are used across the entire hospital facility. If you tune an algorithm for one patient demographic, a nurse might inadvertently use it on a different kind of patient as the computer moves from unit to unit. Better, then, to create a single algorithm that does its best to reflect the average patient. The algorithm should use vital signs and observations that are consistently collected, not vitals that are intermittently measured and documented.

Furthermore, algorithms can be tuned over time. Not only do patient populations evolve, but hospitals can learn from the data they collect. CapsuleTech advises a retrospective chart review of rapid response events prior to selecting an algorithm. What vital signs did the patient have during the eight hours before the urgent event? Retrospectively apply the EWSS to the vital signs to determine the right algorithm and trends in that data to recognize deterioration earlier.

Without help such as the Early Warning Scoring System, rapid response teams have to be called when a clear crisis emerges or when a nurse’s intuition suggests they are needed. Now the nurse can check his intuition against the number generated by the system.

I think clinicians are open to the value of analytics in early warning systems because they dramatically heighten chances for avoiding disaster (and the resulting expense). The successes in early warning systems give us a glimpse of what data can do for more mundane aspects of health care as well. Naturally, effective use of data takes a lot more research: we need to know the best ways to collect the data, what standards allow us to aggregate it, and ultimately what the data can tell us. Advances in this research, along with rich new data sources, can put information at the center of medicine.

Annual Evaluation of Health IT: Are We Stuck in a Holding Pattern? (Part 3 of 3)

Posted on April 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.

The previous installments of this article covered major regulatory initiatives and standards projects. Some of the same questions have a direct impact on technological advances.

Medical Devices: Always With You, But Neither Here Nor There

One ad I saw compares a fitness device to a friend whispering in your ear wherever you go. Leaving aside control freak issues, what could be better for a modern patient with a condition that responds to behavior change than a personal device? Through such devices, we can implement a 24/7 cycle of medical care. We can also save enormous sums of money by treating the patient in his natural environment instead of a hospital or rehab facility.

The rapid spread of health devices was a foregone conclusion even before Apple thrust it into the mainstream with HealthKit. Last month’s launch of ResearchKit suggests that Apple will do the same for the big data revolution in health care championed by the Personal Genome Project, 23andMe (now back in the business after being reined in by the FDA), PatientsLikeMe, and other pioneer organizations. Apple Watch, an indulgence expected to grab the hearts of the affluent, might pull off the paradigm shift in how we interact digitally that Google Glass aimed at.

For these devices to make the leap from digital pets to real medical intervention, including a strengthening of the bond between clinicians and patients, they must satisfy stringent requirements for safety and accuracy. Current FDA regulations distinguish (in very rough terms–I am not a lawyer) between devices that make diagnoses or recommend treatments and other devices that merely measure vital signs or deliver reminders. If you make a diagnosis or recommend a treatment, you need to undergo a complex and expensive evaluation. People can also submit problems they find about your device to FDA’s medical device database.

Safety, accuracy, and transparency are goals well worth pursuing. The problem is not the cost of certification techniques, but the vast gulf between the development model assumed by certification and the one followed by modern developers of both software and hardware.

Development methods nowadays are agile. Developers incrementally release versions of software or hardware and upgrade them every few months. But certification processes require retesting every time the smallest change is made. And that’s reasonble because any tweak (even a configuration change out in the field) can cause a working device to fail. Such certifications work well for embedded systems in airplanes and nuclear facilities, and even critical medical devices that may live in patients’ bodies for decades. But they slow innovation to a crawl and raise prices precipitously.

Oddly enough, the tension between agile development and certification affects medical devices and electronic health records (EHRs) equally, and EHRs are equally prone to errors or misleading interfaces. Yet medical devices are regulated while EHRs are not. This contradiction must be resolved–but perhaps not by dropping the anvil of safety certification on all software used in medicine. The FDA can search for a more supple regulatory process that blesses certain classes of hardware and software while allowing for variation within them, backed up by guidelines for robust development and testing.

The FDA understands that it’s in an untenable situation but doesn’t know what to do. They have shaved off certain devices and marked them for lower levels of scrutiny, such as devices that transfer or display data collected elsewhere. The FDA has also led a muddled discussion over a national “test bed” for medical devices. More regulatory clarity in the area of both devices and EHRs, along with a push by regulators and users for better development practices, could help the field take off and realize the promise of personal devices.

Conclusion

I’m excited about the possibilities of health IT, but concerned that the current environment is insufficiently friendly for its deployment. On top of all the other factors I’ve cited that hold back the field, consider the urgent shortage of health IT staff. Providers and development firms have been bidding up salaries to steal each other’s employees, and attempts to increase the pool have shown disappointing results.

What I hear is that IT experts would love to get into health care, knowing that it can help the public immensely as well as pay off financially. But they have balked at the technical and working conditions in the field: hide-bound institutions, 50-year-old standards and tools, and of course the weight of standards and regulations to study.

How many of these topics will be covered at HIMSS? FHIR will be widely considered, I know, and the buzz over Meaningful Use is always strong. The question what will prod change in the system. Ultimately, it may come from a combination of consumer demand and regulatory pressure. Progress for the sake of progress has not been a prominent trait of health IT.

Remote Patient Monitoring and Small Practices

Posted on February 18, 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.

We’ve started to see the proliferation of wireless health devices that can track a wide variety of health data and more of these devices are becoming common place in the home. Here’s a great tweet that contains an image of some of the popular devices:

While many of these devices are being purchased by the patients and used in the home, there are a number of other programs where healthcare organizations (usually hospitals) are purchasing the devices for the patients who then use the device at home. These programs are designed for hospitals to remotely monitor a patient and identify potential health issues early in order to avoid a hospital readmission.

For those who work in hospitals, you know how important (financially and otherwise) it is for hospitals to reduce their readmissions. While this is great for hospitals, how does this apply to small practices and general and family practice doctors in particular. There’s no extra payment for a small practice doctor to help reduce the readmission of their patient to the hospital. At least I haven’t seen a hospital pay a doctor for their help in this service yet.

What then would motivate a small practice doctor to leverage these types of remote patient monitoring tools?

Sadly, I don’t think there is much motivation for the standard small practice office to use them. It’s easy to see where a concierge doctor might be interested in these technologies. As a concierge doctor or direct primary care doctor, it’s in their best interest to keep their patient population as healthy as possible. As this form of care becomes more popular, I think these types of technology will become incredibly important to their business model.

The other trend in play is the shift to value based reimbursement and ACOs. Will these types of remote patient monitoring technologies become important in this new reimbursement world? I think the jury is still out on this one, but you could see how they could work together.

I’ve recently had a number of doctors hammering me on Twitter and in the comments of blog posts about how technology is not the solution to the problems and that technology is just getting in the way of the personal face to face connection that doctors have been able to make in the office visit of the past. Their concern is real and those implementing the technology need to take this into account. The technology can get in the way if it’s implemented poorly.

However, these people who smack the technology down are usually speaking from a very narrow perspective. EHR and other technology can and does disrupt many office visits. We all know the common refrain that the doctor was looking at the computer not at me. This is a challenge that can be addressed.

While the above is true, how impersonal is a rushed 10-15 minute office visit with a doctor? How impersonal is it for the doctor to prescribe a medication to you and never know if you actually filed it? How impersonal is it for a doctor to prescribed a treatment and never follow up with you to know if the treatment worked? How impersonal is it for the doctor to never talk or interact with you and your health unless you proactively go to that doctor because you’re sick?

Technology is going to be the way that we bridge that gap and these remote patient monitoring technologies are one piece of that puzzle. I believe these technologies and others make healthcare so much more personal than it is today. It changes a short office visit to treat a chief complaint into actually caring for the patient.

This is what most doctors I know would rather be doing anyway. They don’t want to churn patients anymore than the patient wants to be churned, but that’s how they get paid. Hopefully the tide is changing and we’ll see more and more focus on paying providers for using technology that provides this type of personal care.

The Future of Health Involves Human-Agent Collectives (Part 1 of 2)

Posted on February 2, 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.

Everyone understands that isolated interventions in the doctor’s office will not solve the chronic health conditions that plague developed nations and inflate health care costs. So as the health field shyly tries on new collaborative styles–including coordinated care, patient-centered medical homes, and accountable care organizations–participants are learning that the supporting technologies must also enable collaboration in ways vastly more sophisticated than current EHRs and devices.
Read more..