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 HIPAA for FREE!!

The Healthcare IT Field is Unique, Yorktel Discovers

Posted on September 11, 2017 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.

Health care professionals love to vaunt the uniqueness of the medical industry, and tend to demand special, expensive treatment on that basis. Reformers tend to discount this special status. (For instance, the security problems in health care are identical to those in other industries, and are caused by the same factors of insufficient investment and training.) Yet telecommunications in hospitals and clinics really is special, and video giant Yorktel has spent the past five years adjusting to that reality. On September 5, Yorktel announced that it has enhanced its solutions for patient telemedicine with Univago HE that includes robust video connections, monitoring, and analytics as a service.

To learn how the company enhanced their video teleconferencing for healthcare, I recently talked to Peter McLain, Senior Vice President of Healthcare, and John Vitale, Senior Vice President of Project Management. They disassembled the various features of Univago that deal with hospital environments, which require reliable 24/7 connectivity, deal with a good deal of noise (both audible and electronic), and demand fast, faultless authorization to protect privacy.

Directional audio

The triangular table-top sets, familiar to so many of us from business teleconferencing, are omni-directional in order to facilitate use by people seated around the table. In a hospital, they pick up the whirr of carts going by, the chatter in the hallway, and the beeps and gurgles of machines in the patients’ rooms themselves. So Yorktel had to substitute directional microphones.

Camera positioning

Remote monitoring requires much more detail than talking heads in a teleconference. For instance, a remote nurse may want to check whether an IV bag is getting empty. So the person on the remote end of the video connection can direct the camera at particular points in the room and zoom in. Originally offering joystick-like controls for this purpose, Yorktel found them too confusing and cumbersome, so they created a system where a user can just double-click on her own screen to focus in on the place she indicated.

Infrared cameras

Remote monitoring takes place continuously, including when the room is dark. The staff don’t want to wake the patient while monitoring him, so Yorktel cameras support the display of scenes scanned from infrared light. A mild alert, such as a soft buzz, lets an awake patient know that he’s being monitored, without disturbing a sleeping patient.

Integration with dashboards

Yorktel software can be seamlessly integrated with other applications so that staff can see vital signs and other data while in a video call. The developers have made the systems adhere to relevant standards, including Skype, Web RTC, and H.323.

Robustness

Conventional business teleconference systems are used for a few hours each day; hospital systems are used 24/7 and must promise long mean times between failures. Yorktel addressed this on both a hardware and a software level. In hardware, they broke down large, integrated components into modules that would be easy to replace. In software, they built a custom operating system on Unix, feeling that would offer maximum reliability. They use artificial intelligence techniques to detect whether the camera has frozen (a common failure) and reboot the system before it interferes with a video session. Components can still fail, but McLain says they can be replaced within 15 minutes instead of 3 to 6 hours.

Security

Yorktel has hardened its authentication and authorization process to make sure that no one at random can dial into a system and see a patient in his bed. At the same time, they have integrated that process into mobile devices so the physician can check in from home or the road in case of an emergency.

The systems follow industry best practices, as specified by the ISO 27001 security standard and HIPAA. In order to expand into UK’s National Health Service and the European Union, Yorktel achieved Privacy Shield certification. They also get penetration testing from a third party expert, and incorporate anti-microbial technology into their systems. The systems are pending approval as Class 1 medical devices (the most reliable level of use) by the FDA.

Following security by design principles, Yorktel maintains no information for a patient. A physician finds the right room through an external service and calls that room. (If the patient wants to be called, he presses a button by the bedside, and a message is sent through some appropriate alert, such as a text message or a flashing screen.) No information on the traffic is preserved, and the call records have no personally identifying information.

Specialized services

Each department in a hospital has different needs, and Yorktel has provided specific enhancements to make their systems more useful in various settings.

For instance, family visits are an excellent use case for videoconferencing. A session can be shared with family members who can’t get in to the hospital. It can also be recorded and saved by the hospital (as mentioned earlier, Yorktel does not preserve session traffic) so it can be viewed again or brought out to prove that the hospital fulfilled its responsibility. To enable family visits, Yorktel allows the staff to designate members of the call as guests. The visitors are called “guests” because they have no control over the systems, but can see and hear what goes on during the session.

For general use in medical settings, Yorktel also allows sidebar conversations. The patient can be put on hold while physicians discuss treatment candidly and privately among themselves.

Via these enhancements targeted at hospitals and clinics, Yorktel has expanded its business in health care. It started with a common application, remote monitoring in the ICU, but expanded to telestroke care, family health, behavioral health, and translational services. They also knew that hospitals already have expensive, dedicated systems for many of these tasks, and don’t want to throw them away, especially if the outcome is to be locked in yet again to some proprietary system. Hence Yorktel’s dedication to standards.

Currently, video conferencing in the hospital is so expensive that it tends to be restricted to ICUs and a few other applications. Ultimately, Yorktel’s subscription plans should offer systems at a low enough cost that they can be deployed universally in hospitals and clinics.

What can other technology developers, outside of two-way video, learn about health care from the Yorktel experience? Most of all, go into the environments where you want your systems used and get to know the needs and workflows of the participants. Systems must be flexible, because each user is different. The systems must also be secure from the ground up, robust, and conformant to standards. Cost is also an important issue in most settings, particularly given the cuts in reimbursement that are widespread.

As it designs systems to interact along standards with other vendors, Yorktel’s strength in software has grown exponentially. This parallels trends throughout many industries, from manufacturers through retailers. Marc Andreessen famously said in 2011 that software is eating the world, and along these line, many analysts say that all companies will soon be software companies–or be drowned by their more agile competition. In this sense, we can all learn from Yorktel.

Analytics Take an Unusual Turn at PeraHealth

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

Data scientists in all fields have learned to take data from unusual places. You’d think that monitoring people in a hospital for changes in their conditions would be easier than other data-driven tasks, such as tracking planets in far-off solar systems, but in all cases some creativity is needed. That’s what PeraHealth, a surveillance system for hospital patients, found out while developing alerts for clinicians.

It’s remarkably hard to identify at-risk patients in hospitals, even with so many machines and staff busy monitoring them. For instance, a nurse on each shift may note in the patient’s record that certain vital signs are within normal range, and no one might notice that the vital signs are gradually trending worse and worse–until a crisis occurs.

PeraHealth identifies at-risk patients through analytics and dashboards that doctors and nurses can pull up. They can see trends over a period of several shifts, and quickly see which patients in the ward are the most at risk. PeraHealth is a tool for both clinical surveillance and communication.

Michael Rothman, co-founder and Chief Science Officer, personally learned the dangers of insufficient monitoring in 2003 when a low-risk operation on his mother led to complications and her unfortunate death. Rothman and his brother decided to make something positive from the tragedy. They got permission from the hospital to work there for three weeks, applying Michael’s background in math and data analysis (he has worked in the AI department of IBM’s Watson research labs, among other places) and his brother’s background in data visualization. Their goal, arguably naive: to find a single number that summarizes patient risk, and expose that information in a usable way to clinicians.

Starting with 70 patients from the cardiac unit, they built a statistical model that they tested repeatedly with 1,200 patients, 6,000 patients, and finally 25,000 patients. At first they hoped to identify extra data that the nurse could enter into the record, but the chief nurse laid down, in no uncertain terms, that the staff was already too busy and that collecting more data was out of the question. It came time to get creative with data that was already being collected and stored.

The unexpected finding was that vital signs were not a reliable basis for assessing a patient’s trends. Even though they’re “hard” (supposedly objective) data, they bounce around too much.

Instead of relying on just vital signs, PeraHealth also pulls in nursing assessments–an often under-utilized source of information. On each shift, a nurse records information on a dozen different physical systems as well as essential facts such as whether a patient stopping eating or was having trouble walking. It turns out that this sort of information reliably indicates whether there’s a problem. Many of the assessments are simple, yes/no questions.

Rothman analyzed hospital data to find variables that predicted risk. For instance, he compared the heart rates of 25,000 patients before they left the hospital and checked who lived for a year longer. The results formed a U-shaped curve, showing that heart rates above a certain level or below a certain level predicted a bad outcome. It turns out that this meaure works equally well within the hospital, helping to predict admission to the ICU, readmission to the ICU, and readmission after discharge.

The PeraHealth team integrated their tool with the hospital’s EHR and started producing graphs for the clinicians in 2007. Now they can point to more than 25 peer-reviewed articles endorsing their approach, some studies comparing before-and-after outcomes, and others comparing different parts of the hospital with some using PeraHealth and others not using it. The service is now integrated with major EHR vendors.

PeraHealth achieved Rothman’s goal of producing a single meaningful score to rate patient risk. Each new piece of data that goes into the EHR triggers a real-time recalculation of the score and a new dot on a graph presented to the nurses. In order to save the nurses from signing into the EHR, PeraHealth put a dashboard on the nurse’s kiosk with all the patients’ graphs. Color-coding denotes which patients are sickest. PeraHealth also shows which patients to attend to first. In case no one looks at the screen, at some hospitals the system sends out text alerts to doctors about the most concerned patients.

PeraHealth is now expanding. In an experiment, they did phone interviews with people in a senior residential facility, and identified many of those who were deteriorating. So the basic techniques may be widely applicable to data-driven clinical decision support. But without analytics, one never knows which data is most useful.

Wellpepper and SimplifiMed Meet the Patients Where They Are Through Modern Interaction Techniques

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

Over the past few weeks I found two companies seeking out natural and streamlined ways to connect patients with their doctors. Many of us have started using web portals for messaging–a stodgy communication method that involves logins and lots of clicking, often just for an outcome such as message “Test submitted. No further information available.” Web portals are better than unnecessary office visits or days of playing phone tag, and so are the various secure messaging apps (incompatible with one another, unfortunately) found in the online app stores. But Wellpepper and SimplifiMed are trying to bring us a bit further into the twenty-first century, through voice interfaces and natural language processing.

Wellpepper’s Sugarpod

Wellpepper recently ascended to finalist status in the Alexa Diabetes Challenge, which encourages research into the use of Amazon.com’s popular voice-activated device, Alexa, to improve the lives of people with Type 2 Diabetes. For this challenge, Wellpepper enhanced its existing service to deliver messages over Amazon Echo and interview patients. Wellpepper’s entry in the competition is an integrated care plan called Sugarpod.

The Wellpepper platform is organized around a care plan, and covers the entire cycle of treatment, such as delivering information to patients, managing their medications and food diaries, recording information from patients in the health care provider’s EHR, helping them prepare for surgery, and more. Messages adapt to the patient’s condition, attempting to present the right tone for adherent versus non-adherent patients. The data collected can be used for analytics benefitting both the provider and the patient–valuable alerts, for instance.

It must be emphasized at the outset that Wellpepper’s current support for Alexa is just a proof of concept. It cannot be rolled out to the public until Alexa itself is HIPAA-compliant.

I interviewed Anne Weiler, founder and CEO of Wellpepper. She explained that using Alexa would be helpful for people who have mobility problems or difficulties using their hands. The prototype proved quite popular, and people seem willing to open up to the machine. Alexa has some modest affective computing features; for instance, if the patient reports feeling pain, the device will may respond with “Ouch!”

Wellpepper is clinically validated. A study of patients with Parkinson’s showed that those using Wellpepper showed 9 percent improvement in mobility, whereas those without it showed a 12% decline. Wellpepper patients adhered to treatment plans 81% of the time.

I’ll end this section by mentioning that integration EHRs offer limited information of value to Wellpepper. Most EHRs don’t yet accept patient data, for instance. And how can you tell whether a patient was admitted to a hospital? It should be in the EHR, but Sugarpod has found the information to be unavailable. It’s especially hidden if the patient is admitted to a different health care providers; interoperability is a myth. Weiler said that Sugarpod doesn’t depend on the EHR for much information, using a much more reliable source of information instead: it asks the patient!

SimplifiMed

SimplifiMed is a chatbot service that helps clinics automate routine tasks such as appointments, refills, and other aspects of treatment. CEO Chinmay A. Singh emphasized to me that it is not an app, but a natural language processing tool that operates over standard SMS messaging. They enable a doctor’s landline phone to communicate via text messages and route patients’ messages to a chatbot capable of understanding natural language and partial sentences. The bot interacts with the patients to understand their needs, and helps them accomplish the task quickly. The result is round-the-clock access to the service with no waiting on the phone a huge convenience to busy patients.

SimplifiMed also collects insurance information when the patient signs up, and the patient can use the interface to change the information. Eventually, they expect the service to analyze patient’s symptom in light of data from the EHR and help the patient make the decision about whether to come in to the doctor.

SMS is not secure, but HIPAA does not get violated because the patient can choose what to send to the doctor, and the chatbot’s responses contain no personally identifiable information. Between the doctor and the SimplifiMed service, data is sent in encrypted form. Singh said that the company built its own natural language processing engine, because it didn’t want to share sensitive patient data with an outside service.

Due to complexity of care, insurance requirements, and regulations, a doctor today needs support from multiple staff members: front desk, MA, biller, etc. MACRA and value-based care will increase the burden on staff without providing the income to hire more. Automating routine activities adds value to clinics without breaking the bank.

Earlier this year I wrote about another company, HealthTap, that had added Alexa integration. This trend toward natural voice interfaces, which the Alexa Diabetes Challenge finalists are also pursuing, along with the natural language processing that they and SimplifiMed are implementing, could put health care on track to a new era of meeting patients where they are now. The potential improvements to care are considerable, because patients are more likely to share information, take educational interventions seriously, and become active participants in their own treatment.

Hands-On Guidance for Data Integration in Health: The CancerLinQ Story

Posted on June 15, 2017 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.

Institutions throughout the health care field are talking about data sharing and integration. Everyone knows that improved care, cost controls, and expanded research requires institutions who hold patient data to safely share it. The American Society of Clinical Oncology’s CancerLinQ, one of the leading projects analyzing data analysis to find new cures, has tackled data sharing with a large number of health providers and discovered just how labor-intensive it is.

CancerLinQ fosters deep relationships and collaborations with the clinicians from whom it takes data. The platform turns around results from analyzing the data quickly and to give the clinicians insights they can put to immediate use to improve the care of cancer patients. Issues in collecting, storing, and transmitting data intertwine with other discussion items around cancer care. Currently, CancerLinQ isolates the data from each institution, and de-identifies patient information in order to let it be shared among participating clinicians. CancerLinQ LLC is a wholly-owned nonprofit subsidiary of ASCO, which has registered CancerLinQ as a trademark.

CancerLinQ logo

Help from Jitterbit

In 2015, CancerLinQ began collaborating with Jitterbit, a company devoted to integrating data from different sources. According to Michele Hazard, Director of Healthcare Solutions, and George Gallegos, CEO, their company can recognize data from 300 different sources, including electronic health records. At the beginning, the diversity and incompatibility of EHRs was a real barrier. It took them several months to figure out each of the first EHRs they tackled, but now they can integrate a new one quickly. Oncology care, the key data needed by CancerLinQ, is a Jitterbit specialty.

Jitterbit logo

One of the barriers raised by EHRs is licensing. The vendor has to “bless” direct access to EHR and data imported from external sources. HIPAA and licensing agreements also make tight security a priority.

Another challenge to processing data is to find records in different institutions and accurately match data for the correct patient.

Although the health care industry is moving toward the FHIR standard, and a few EHRs already expose data through FHIR, others have idiosyncratic formats and support older HL7 standards in different ways. Many don’t even have an API yet. In some cases, Jitterbit has to export the EHR data to a file, transfer it, and unpack it to discover the patient data.

Lack of structure

Jitterbit had become accustomed to looking in different databases to find patient information, even when EHRs claimed to support the same standard. One doctor may put key information under “diagnosis” while another enters it under “patient problems,” and doctors in the same practice may choose different locations.

Worse still, doctors often ignore the structured fields that were meant to hold important patient details and just dictate or type it into a free-text note. CancerLinQ anticipated this, unpacking the free text through optical character recognition (OCR) and natural language processing (NLP), a branch of artificial intelligence.

It’s understandable that a doctor would evade the use of structured fields. Just think of the position she is in, trying to keep a complex cancer case in mind while half a dozen other patients sit in the waiting room for their turn. In order to use the structured field dedicated to each item of information, she would have to first remember which field to use–and if she has privileges at several different institutions, that means keeping the different fields for each hospital in mind.

Then she has to get access to the right field, which may take several clicks and require movement through several screens. The exact information she wants to enter may or may not be available through a drop-down menu. The exact abbreviation or wording may differ from EHR to EHR as well. And to carry through a commitment to using structured fields, she would have to go through this thought process many times per patient. (CancerLinQ itself looks at 18 Quality eMeasures today, with the plan to release additional measures each year.)

Finally, what is the point of all this? Up until recently, the information would never come back in a useful form. To retrieve it, she would have to retrace the same steps she used to enter the structured data in the first place. Simpler to dump what she knows into a free-text note and move on.

It’s worth mentioning that this Babyl of health care information imposes negative impacts on the billing and reimbursement process, even though the EHRs were designed to support those very processes from the start. Insurers have to deal with the same unstructured data that CancerLinQ and Jitterbit have learned to read. The intensive manual process of extracting information adds to the cost of insurance, and ultimately the entire health care system. The recent eClinicalWorks scandal, which resembles Volkswagon’s cheating on auto emissions and will probably spill out to other EHR vendors as well, highlights the failings of health data.

Making data useful

The clue to unblocking this information logjam is deriving insights from data that clinicians can immediately see will improve their interventions with patients. This is what the CancerLinQ team has been doing. They run analytics that suggest what works for different categories of patients, then return the information to oncologists. The CancerLinQ platform also explains which items of data were input to these insights, and urges the doctors to be more disciplined about collecting and storing the data. This is a human-centered, labor-intensive process that can take six to twelve months to set up for each institution. Richard Ross, Chief Operating Officer of CancerLinQ calls the process “trench warfare,” not because its contentious but because it is slow and requires determination.

Of the 18 measures currently requested by CancerLinQ, one of the most critical data elements driving the calculation of multiple measures is staging information: where the cancerous tumors are and how far it has progressed. Family history, treatment plan, and treatment recommendations are other examples of measures gathered.

The data collection process has to start by determining how each practice defines a cancer patient. The CancerLinQ team builds this definition into its request for data. Sometimes they submit “pull” requests at regular intervals to the hospital or clinic, whereas other times the health care provider submits the data to them at a time of its choosing.

Some institutions enforce workflows more rigorously than others. So in some hospitals, CancerLinQ can persuade the doctors to record important information at a certain point during the patient’s visit. In other hospitals, doctors may enter data at times of their own choosing. But if they understand the value that comes from this data, they are more likely to make sure it gets entered, and that it conforms to standards. Many EHRs provide templates that make it easier to use structured fields properly.

When accepting information from each provider, the team goes through a series of steps and does a check-in with the provider at each step. The team evaluates the data in a different stage for each criterion: completeness, accuracy of coding, the number of patients reported, and so on. By providing quick feedback, they can help the practice improve its reporting.

The CancerLinQ/Jitterbit story reveals how difficult it is to apply analytics to health care data. Few organizations can afford the expertise they apply to extracting and curating patient data. On the other hand, CancerLinQ and Jitterbit show that effective data analysis can be done, even in the current messy conditions of electronic data storage. As the next wave of technology standards, such as FHIR, fall into place, more institutions should be able to carry out analytics that save lives.

Scenarios for Health Care Reform (Part 2 of 2)

Posted on May 18, 2017 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 part of this article suggested two scenarios that could promote health care reform. We’ll finish off the scenarios in this part of the article.

Capitalism Disrupts Health Care

In the third scenario, reform is stimulated by an intrepid data science firm that takes on health care with greater success than most of its predecessors. After assembling an impressive analytics toolkit from open source software components–thus simplifying licensing–it approaches health care providers and offers them a deal they can’t refuse: analytics demonstrated to save them money and support their growth, all delivered for free. The data science firm asks in return only that they let it use deidentified data from their patients and practices to build an enhanced service that it will offer paying customers.

Some health care providers balk at the requirement to share data, but their legal and marketing teams explain that they have been doing it for years already with companies whose motives are less commendable. Increasingly, the providers are won over. The analytics service appeals particularly to small, rural, and safety-net providers. Hammered by payment cuts and growing needs among their populations, they are on the edge of going out of business and grasp the service as their last chance to stay in the black.

Participating in the program requires the extraction of data from electronic health records, and some EHR vendors try to stand in the way in order to protect their own monopoly on the data. Some even point to clauses in their licenses that prohibit the sharing. But they get a rude message in return: so valuable are the analytics that the providers are ready to jettison the vendors in a minute. The vendors ultimately go along and even compete on the basis of their ability to connect to the analytics.

Once stability and survival are established, the providers can use the analytics for more and more sophisticated benefits. Unlike the inadequate quality measures currently in use, the analytics provide a robust framework for assessing risk, stratifying populations, and determining how much a provider should be rewarded for treating each patient. Fee-for-outcome becomes standard.

Providers make deals to sign up patients for long-term relationships. Unlike the weak Medicare ACO model, which punishes a provider for things their patients do outside their relationship, the emerging system requires a commitment from the patient to stick with a provider. However, if the patient can demonstrate that she was neglected or failed to receive standard of care, she can switch to another provider and even require the misbehaving provider to cover costs. To hold up their end of this deal, providers find it necessary to reveal their practices and prices. Physician organizations develop quality-measurement platforms such as the recent PRIME registry in family medicine. A race to the top ensues.

What If Nothing Changes?

I’ll finish this upbeat article with a fourth scenario in which we muddle along as we have for years.

The ONC and Centers for Medicare & Medicaid Services continue to swat at waste in the health care system by pushing accountable care. But their ratings penalize safety-net providers, and payments fail to correlate with costs as hoped.

Fee-for-outcome flounders, so health care costs continue to rise to intolerable levels. Already, in Massachusetts, the US state that leads in universal health coverage, 40% of the state budget goes to Medicaid, where likely federal cuts will make it impossible to keep up coverage. Many other states and countries are witnessing the same pattern of rising costs.

The same pressures ride like a tidal wave through the rest of the health care system. Private insurers continue to withdraw from markets or lose money by staying. So either explicitly or through complex and inscrutable regulatory changes, the government allows insurers to cut sick people from their rolls and raise the cost burdens on patients and their employers. As patient rolls shrink, more hospitals close. Political rancor grows as the public watches employer money go into their health insurance instead of wages, and more of their own stagnant incomes go to health care costs, and government budgets tied up in health care instead of education and other social benefits.

Chronic diseases creep through the population, mocking crippled efforts at public health. Rampant obesity among children leads to more and earlier diabetes. Dementia also rises as the population ages, and climate change scatters its effects across all demographics.

Furthermore, when patients realize the costs they must take on to ask for health care, they delay doctor visits until their symptoms are unbearable. More people become disabled or perish, with negative impacts that spread through the economy. Output decline and more families become trapped in poverty. Self-medication for pain and mental illness becomes more popular, with predictable impacts on the opiate addiction crisis. Even our security is affected: the military finds it hard to recruit find healthy soldiers, and our foreign policy depends increasingly on drone strikes that kill civilians and inflame negative attitudes toward the US.

I think that, after considering this scenario, most of us would prefer one of the previous three I laid out in this article. If health care continues to be a major political issue for the next election, experts should try to direct discussion away from the current unproductive rhetoric toward advocacy for solutions. Some who read this article will hopefully feel impelled to apply themselves to one of the positive scenarios and bring it to fruition.

Scenarios for Health Care Reform (Part 1 of 2)

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

All reformers in health care know what the field needs to do; I laid out four years ago the consensus about patient-supplied data, widespread analytics, mHealth, and transparency. Our frustration comes in when trying to crack the current hide-bound system open and create change. Recent interventions by US Republicans to repeal the Affordable Care Act, whatever their effects on costs and insurance coverage, offer no promise to affect workflows or treatment. So this article suggests three potential scenarios where reform could succeed, along with a vision of what will happen if none of them take hold.

Patients Forge Their Own Way Forward

In the first scenario, a tiny group of selfer-trackers, athletes, and empowered patients start a movement that ultimately wins over hundreds of millions of individuals.

These scattered enthusiasts, driven to overcome debilitating health problems or achieve extraordinary athletic feats, start to pursue self-tracking with fanaticism. Consumer or medical-grade devices provide them with ongoing data about their progress, and an open source platform such as HIE of One gives them a personal health record (PHR).

They also take charge of their interactions with the health care system. They find that most primary care providers aren’t interested in the data and concerns they bring, or don’t have time to process those data and concerns in the depth they need, or don’t know how to. Therefore, while preserving standard relationships with primary care providers and specialists where appropriate, the self-trackers seek out doctors and other providers to provide consultation about their personal health programs. A small number of providers recognize an opportunity here and set up practices around these consultations. The interactions look quite different from standard doctor visits. The customers, instead of just submitting themselves to examination and gathering advice, steer the conversation and set the goals.

Power relationships between doctors and customers also start to change. Although traditional patients can (and often do) walk away and effectively boycott a practice with which they’re not comfortable, the new customers use this power to set the agenda and to sort out the health care providers they find beneficial.

The turning point probably comes when someone–probabaly a research facility, because it puts customer needs above business models–invents a cheap, comfortable, and easy-to-use device that meets the basic needs for monitoring and transmitting vital signs. It may rest on the waist or some other place where it can be hidden, so that there is no stigma to wearing it constantly and no reason to reject its use on fashion grounds. A beneficent foundation invests several million dollars to make the device available to schoolchildren or some other needy population, and suddenly the community of empowered patients leaps from a miniscule pool to a mainstream phenomenon.

Researchers join the community in search of subjects for their experiments, and patients offer data to the researchers in the hope of speeding up cures. At all times, the data is under control of the subjects, who help to direct research based on their needs. Analytics start to turn up findings that inform clinical decision support.

I haven’t mentioned the collection of genetic information so far, because it requires more expensive processes, presents numerous privacy risks, and isn’t usually useful–normally it tells you that you have something like a 2% risk of getting a disease instead of the general population’s 1% risk. But where genetic testing is useful, it can definitely fit into this system.

Ultimately, the market for consultants that started out tiny becomes the dominant model for delivering health care. Specialists and hospitals are brought in only when their specific contributions are needed. The savings that result bring down insurance costs for everyone. And chronic disease goes way down as people get quick feedback on their lifestyle choices.

Government Puts Its Foot Down

After a decade of cajoling health care providers to share data and adopt a fee-for-outcome model, only to witness progress at a snail’s pace, the federal government decides to try a totally different tack in this second scenario. As part of the Precision Medicine initiative (which originally planned to sign up one million volunteers), and leveraging the ever-growing database of Medicare data, the Office of the National Coordinator sets up a consortium and runs analytics on top of its data to be shared with all legitimate researchers. The government also promises to share the benefits of the analytics with anyone in the world who adds their data to the database.

The goals of the analytics are multi-faceted, combining fraud checks, a search for cures, and everyday recommendations about improving interventions to save money and treat patients earlier in the disease cycle. The notorious 17-year gap between research findings and widespread implementation shrinks radically. Now, best practices are available to any patient who chooses to participate.

As with the personal health records in the previous scenario, the government database in this scenario creates a research platform of unprecedented size, both in the number of records and the variety of participating researchers.

To further expand the power of the analytics, the government demands exponentially greater transparency not just in medical settings but in all things that make us sick: the food we eat (reversing the rulings that protect manufacturers and restaurants from revealing what they’re putting in our bodies), the air and water that surrounds us, the effects of climate change (a major public health issue, spreading scourges such as mosquito-borne diseases and heat exhaustion), disparities in food and exercise options among neighborhoods, and more. Public awareness leads to improvements in health that lagged for decades.

In the next section of this article, I’ll present a third scenario that achieves reform from a different angle.

Where HIMSS Can Take Health 2.0

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

I was quite privileged to talk to the leaders of Health 2.0, Dr. Indu Subaiya and Matthew Holt, in the busy days after their announced merger with HIMSS. I was revving to talk to them because the Health 2.0 events I have attended have always been stimulating and challenging. I wanted to make sure that after their incorporation into the HIMSS empire they would continue to push clinicians as well as technologists to re-evaluate their workflows, goals, and philosophies.

I’m not sure there is such a thing as a typical Health 2.0 event, but I generally see in such events a twofold mission. Sometimes they orient technologists to consider the needs of doctors and patients (as at a developer challenge). Other times they orient clinicians and health care institutions to consider the changes in goals and means that technology requires, as well as the strains caused by its adoption (as in a HxRefactored conference). Both of these activities disturb the cozy status quo in health IT, prodding its practitioners to try out new forms of research, design, and interaction. Health 2.0 was also happy to publish my own articles trying to untangle the standard confusion around health care.

For HIMSS, absorbing Health 2.0 is about as consequential as an ocean liner picking up a band of performing musicians along its ports of call. For Health 2.0, the impact could be much larger. Certainly, they gain the stability, funding opportunities, and administrative support that typically come with incorporation into a large, established institution. But can they keep their edge?

Subaiya and Holt assured me that Health 2.0 maintains its independence as part of HIMSS. They will be responsible for some presentations at the mammoth annual HIMSS conferences. They also hope to bring more buyers and sellers together through the HIMSS connection. They see three functions they can provide HIMSS:

  • A scanner for what’s new. HIMSS tends to showcase valuable new technologies a couple years after Health 2.0 discovers them.

  • A magnet to attract and retain highly innovative people in health IT.

  • A mechanism for finding partners for early-stage companies.

Aside from that, they will continue and expand their international presence, which includes the US, Japan, South Korea, China, and India. Interestingly, Subaiya told me that the needs expressed in different countries are similar. There aren’t separate mHealth or IT revolutions for the US and India. Instead, both call for increased used of IT for patient education, for remote monitoring and care, and for point-of-care diagnostics. Whether talking about busy yuppies in the city or isolated rural areas lacking doctors, clinicians find that health care has to go to the patient because the patient can’t always come to a health care center. If somebody can run a test using a cheap strip of paper and send results to a doctor over a cell phone, health coverage becomes more universal. Many areas are also dealing with the strains of aging populations.

HIMSS leadership and Health 2.0 share the recognition that health happens outside the walls of hospitals: in relationships, communities, schools, and homes. Health 2.0 will push that philosophy strongly at HIMSS. They will also hammer on what Subaiya calls health care’s “unacceptables”: disparities across race, gender, and geographic region, continued growth in chronic disease, and resulting cost burdens.

Subaiya and Holt see the original mission of HIMSS as a beneficial one: to create technologies that enhance physician workflows. Old technologies turned out to be brittle and unable to evolve, though, as workflows radically changed. As patient engagement and collaboration became more important, EHRs and other systems fell behind.

Meanwhile, the mobile revolution brought new attention to apps that could empower patients, improve monitoring, and connect everybody in the health care system. But technologists and venture capitalists jumped into health care without adequate research into what the users needed. Health 2.0 was created several years ago to represent the users, particular patients and health care consumers.

Holt says that investment is still increasing, although it may go into services instead of pure tech companies. Some is money moving from life sciences to computer technologies such as digital therapeutics. Furthermore, there are fewer companies getting funded than a few years ago, but each company is getting more money than before and getting it faster.

Subaiya and Holt celebrate the continued pull of health care for technologists, citing not only start-ups but substantial investment by large tech corporations, such as the Alphabet company Verily Life Sciences, Samsung, and Apple. There’s a particularly big increase in the use of data science within health care.

Some companies are integrating with Alexa to make interactions with consumers more natural. Intelligent decision support (as seen for instance in IBM’s Watson) is taking some of the burden off the clinician. For mental health, behavioral health, and addiction, digital tech is reducing stigma and barriers to those who need help.

In short, Health 2.0 should not be constrained by its new-found partner. The environment and funding is here for a tech transformation of health care, and Health 2.0’s work is cut out for it.

tranSMART and i2b2 Show that Open Source Software Can Fuel Precision Medicine

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

Medical reformers have said for years that the clinic and the research center have to start working closely together. The reformists’ ideal–rarely approached by any current institution–is for doctors to stream data about treatments and outcomes to the researchers, who in turn inject the insights that their analytics find back into the clinic to make a learning institution. But the clinicians and researchers have trouble getting on the same page culturally, and difficulties in data exchange exacerbate the problem.

On the data exchange front, software developers have long seen open source software as the solution. Proprietary companies are stingy in their willingness to connect. They parcel out gateways to other providers as expensive favors, and the formats often fail to mesh anyway (as we’ve always seen in electronic health records) because they are kept secret. In contrast, open source formats are out for everyone to peruse, and they tend to be simpler and more intuitive. As open source, the software can be enhanced by anyone with programming skill in order to work with other open source software.

Both of these principles are on display in the recent merger announced by two open source projects, the tranSMART Foundation and i2b2. As an organizational matter, this is perhaps a minor historical note–a long-awaited rectification of some organizational problems that have kept apart two groups of programmers who should always have been working together. But as a harbinger of progress in medicine, the announcement is very significant.

tranSMART logo

Here’s a bit about what these two projects do, to catch up readers who haven’t been following their achievements.

  • i2b2 allows doctors to transform clinical data into a common format suitable for research. The project started in 2004 in response to an NIH Roadmap initiative. It was the brainchild of medical researchers trying to overcome the frustrating barriers to extracting and sharing patient data from EHRs. The nugget from which i2b2 came was a project of the major Boston hospital consortium, Partners Healthcare. As described in another article, the project was housed at the Harvard Medical School and mostly funded by NIH.

  • The “trans” in tranSMART stands for translational research, the scientific effort that turns chemistry and biology into useful cures. It was a visionary impulse among several pharma companies that led them to create the tranSMART Foundation in 2013 from a Johnson & Johnson project, as I have documented elsewhere, and then to keep it open source and turn it into a model of successful collaboration. Their software helps researchers represent clinical and research data in ways that facilitate analytics and visualizations. In an inspired moment, the founders of the tranSMART project chose the i2b2 data format as the basis for their project. So the tranSMART and i2b2 foundations have always worked on joint projects and coordinated their progress, working also with the SMART open source API.

Why, then, have tranSMART and i2b2 remained separate organizations for the past three or four years? I talked recently with Keith Elliston, CEO of the tranSMART, who pointed to cultural differences as the factor that kept them apart. A physician culture drove i2b2, whereas a pharma and biochemistry research culture drove tranSMART. In addition, as development shops, they evolved in very different ways from the start.

tranSMART, as I said, adopted a robust open source strategy early on. They recognized the importance of developing a community, and the whole point of developing a foundation–just like other stalwarts of the free software community, such as the Apache Foundation, OpenStack Foundation, and Linux Foundation–was to provide a nurturing but neutral watering hole from which many different companies and contributors could draw what they need. Now the tranSMART code base benefits from 125 different individual contributors.

In contrast, i2b2 started and remained a small, closely-knit team. Although the software was under an open source license, the project operated in a more conservative model, although accepting external contributions.

Elliston says the two projects have been talking for the last two and a half years about improving integration and more recently merging, and that each has learned the best of what the other has to offer in order to meet in the middle. tranSMART is adopting some of i2b2’s planning, while i2b2 is learning how to organize a community around its work.

Together they believe their projects can improve more quickly. Ultimately, they’ll contribute to the movement to target cures to patients, proceeding now under the name Precision Medicine. Fund-raising and partnerships will be easier.

I have written repeatedly about these organizations to show the power that free and open source software brings to medicine. Their timely merger shows that open source overcomes cultural and institutional barriers. What it did for these two organizations it can do for the fractured landscape of hospitals, clinics, long-term care facilities, behavioral health centers, and other medical institutions struggling to work together. My hope is that the new foundation’s model for collaboration, as well as the results of its research, can slay the growing monster of health care costs and make us all healthier.

Epic and other EHR vendors caught in dilemmas by APIs (Part 2 of 2)

Posted on March 16, 2017 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 reported some news about Epic’s Orchard, a new attempt to provide an “app store” for health care. In this section we look over the role of APIs as seen by EHR vendors such as Epic.

The Roles of EHRs

Dr. Travis Good, with whom I spoke for this article, pointed out that EHRs glom together two distinct functions: a canonical, trusted store for patient data and an interface that becomes a key part of the clinician workflow. They are being challenged in both these areas, for different reasons.

As a data store, EHRs satisfied user needs for many years. The records organized the data for billing, treatment, and compliance with regulations. If there were problems with the data, they stemmed not from the EHRs but from how they were used. We should not blame the EHR if the doctor upcoded clinical information in order to charge more, or if coding was too primitive to represent the complexity of patient illness. But clinicians and regulators are now demanding functions that EHRs are fumbling at fulfillling:

  • More and more regulatory requirements, which intelligent software would calculate on its own from data already in the record, but which most EHRs require the physician to fill out manually

  • Patient-generated data, which may be entered by the patient manually or taken from devices

  • Data in streamlined formats for large-scale data analysis, for which institutions are licensing new forms of databases

Therefore, while the EHR still stores critical data, it is not the sole source of truth and is having to leave its borders porous in order to work with other data sources.

The EHR’s second function, as an interface that becomes part of the clinicians’ hourly workflow, has never been fulfilled well. EHRs are the most hated software among their users. And that’s why users are calling on them to provide APIs that permit third-party developers to compete at the interface level.

So if I were to write a section titled “The Future of Current EHRs” it could conceivably be followed by a blank page. But EHRs do move forward, albeit slowly. They must learn to be open systems.

With this perspective, Orchard looks like doubling down on an obsolete strategy. The limitations and terms of service give the impression that Epic wants to remain a one-stop shopping service for customers. But if Epic adopted the SMART approach, with more tolerance for failure and options for customers, it would start to reap the benefits promised by FHIR and foster health care innovation.

Epic and Other EHR Vendors Caught in Dilemmas by APIs (Part 1 of 2)

Posted on March 15, 2017 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 HITECH act of 2009 (part of the American Recovery and Reinvestment Act) gave an unprecedented boost to an obscure corner of the IT industry that produced electronic health records. For the next eight years they were given the opportunity to bring health care into the 21st century and implement common-sense reforms in data sharing and analytics. They largely squandered this opportunity, amassing hundreds of millions of dollars while watching health care costs ascend into the stratosphere, and preening themselves over modest improvements in their poorly functioning systems.

This was not solely a failure of EHR vendors, of course. Hospitals and clinicians also needed to adopt agile methods of collaborating and using data to reduce costs, and failed to do so. They’re sweating profusely now, as shown in protests by the American Medical Association and major health care providers over legislative changes that will drastically reduce their revenue through cuts to insurance coverage and Medicaid. EHR vendors will feel the pain of a thousand cuts as well.

I recently talked to Dr. Travis Good, CEO of Datica that provides data integration and storage to health care providers. We discussed the state of EHR interoperability, the roles of third-party software vendors, and in particular the new “app store” offered by Epic under the name Orchard. Although Datica supports integration with a dozen EHRs, 70% of their business involves Epic. So we’ll start with the new Orchard initiative.

The Epic App Store

Epic, like most vendors, has offered an API over the past few years that gives programmers at hospitals access to patient data in the EHR. This API now complies with the promising new standard for health data, FHIR, and uses the resources developed by the Argonaut Project. So far, this is all salutary and positive. Dr. Good points out, however, that EHR vendors such as Epic offer the API mostly to extract data. They are reluctant to allow data to be inserted programmatically, claiming it could allow errors into the database. The only change one can make, usually, is to add an annotation.

This seriously hampers the ability of hospitals or third-party vendors to add new value to the clinical experience. Analytics benefit from a read-only data store, but to reach in and improve the doctor’s workflow, an application must be able to write new data into the database.

More risk springs from controls that Epic is putting on the apps uploaded to Orchard. Like the Apple Computer store that inspired Orchard, Epic’s app store vets every app and allows in only the apps that it finds useful. For a while, the terms of service allowed Epic access to the data structures of the app. What this would mean in practice is hard to guess, but it suggests a prurient interest on the part of Epic in what its competitors are doing. We can’t tell where Epic’s thinking is headed, though, because the public link to the terms of service was recently removed, leaving a 404 message.

Good explained that Epic potentially could track all the transactions between the apps and their users, and in particular will know which ones are popular. This raises fears among third-party developers that Epic will adopt their best ideas and crowd them out of the market by adding the features to its own core system, as Microsoft notoriously did during the 1980s when it dominated the consumer software market.

Epic’s obsession with control can be contrasted with the SMART project, an open platform for health data developed by researchers at Harvard Medical School. They too offer an app gallery (not a store), but their goal is to open the repository to as wide a collection of contributors as possible. This maximizes the chances for innovation. As described at one of their conferences, control over quality and fitness for use would be exerted by the administrator of each hospital or other institution using the gallery. This administrator would choose which apps to make available for clinical staff to download.

Of course, SMART apps also work seamlessly cross-platform, which distinguishes them from the apps provided by individual vendors. Eventually–ideally–FHIR support will allow the apps in Orchard and from other vendors to work on all EHRs that support FHIR. But the standard is not firm enough to allow this–there are too many possible variations. People who have followed the course of HITECH implementation know the history of interoperability, and how years of interoperability showcases at HIMSS have been mocked by the real incompatibilities between EHRs out in the field.

To understand how EHRs are making use of APIs, we should look more broadly at their role in health care. That will be the topic of the next section of this article.