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!

A Circular Chat On Healthcare Interoperability

Posted on September 6, 2016 I Written By

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

About a week ago, a press release on health data interoperability came into my inbox. I read it over and shook my head. Then I pinged a health tech buddy for some help. This guy has seen it all, and I felt pretty confident that he would know whether there was any real news there.

And this is how our chat went.

—-

“So you got another interoperability pitch from one of those groups. Is this the one that Cerner kicked off to spite Epic?” he asked me.

“No, this is the one that Epic and its buddies kicked off to spite Cerner,” I told him. “You know, health data exchange that can work for anyone that gets involved.”

“Do you mean a set of technical specs? Maybe that one that everyone seems to think is the next big hope for application-based data sharing? The one ONC seems to like.” he observed. “Or at least it did during the DeSalvo administration.”

“No, I mean the group working on a common technical approach to sharing health data securely,” I said. “You know, the one that lets doctors send data straight to another provider without digging into an EMR.”

“You mean that technology that supports underground currency trading? That one seems a little bit too raw to support health data trading,” he said.

“Maybe so. But I was talking about data-sharing standards adopted by an industry group trying to get everyone together under one roof,” I said. “It’s led by vendors but it claims to be serving the entire health IT world. Like a charity, though not very much.”

“Oh, I get it. You must be talking about the industry group that throws that humungous trade show each year.” he told me. “A friend wore through two pairs of wingtips on the trade show floor last year. And he hardly left his booth!”

“Actually, I was talking about a different industry group. You know, one that a few top vendors have created to promote their approach to interoperability.” I said. “Big footprint. Big hopes. Big claims about the future.”

“Oh yeah. You’re talking about that group Epic created to steal a move from Cerner.” he said.

“Um, sure. That must have been it,” I told him. “I’m sure that’s what I meant.”

—-

OK, I made most of this up. You’ve got me. But it is a pretty accurate representation of how most conversations go when I try to figure out who has a chance of actually making interoperability happen. (Of course, I added some snark for laughs, but not much, believe it or not.)

Does this exchange sound familiar to anyone else?

And if it does, is it any wonder we don’t have interoperability in healthcare?

What Do Med Students Need To Know About EMRs?

Posted on August 16, 2016 I Written By

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

Recently, I was asked to write an introduction to EMRs, focusing on what medical students needed to know in preparation for their future careers. This actually turned out to be a very interesting exercise, as it called for balancing history with the future, challenges with benefits and predictable future developments with some very interesting possibilities. Put another way, the exercise reminded me that any attempt to “explain” EMR technology calls for some fancy dancing.

Here’s some of the questions I tackled:

  • Do future doctors need to know more about how EMRs function today, or how they should probably function to support increasingly important patient management approaches like population health?
  • Do med students need to understand major technical discussions – such as the benefits of FHIR or how to wrangle Big Data – to perform as doctors? If so, how much detail is helpful?
  • How important is it to prepare med students to understand the role of data generated outside of traditional patient care settings, such as wearables data, remote monitoring and telemedicine consults? What do they need to know to prepare for the gradual integration of such data?
  • What skills, attitudes and practices will help physician trainees make the best use of EMRs and ancillary systems? And how should they obtain that knowledge?

These questions are thornier than they may appear at first glance, in part because there no hard-and-fast standards in place as to how doctors who’ve never run a practice on paper charts should conduct themselves. While there have been endless discussions about how to help doctors adopt an EMR for the first time, or switch from one to the other, I’m not aware of a mature set of best practices available to med students on how next-gen, health IT-assisted practices should function.

Certainly, offering med school trainees a look at the history of EMRs makes sense, as understanding the reasons early innovators developed the first systems offers some interesting insights. And introducing soon-to-be physicians to the benefits of wearable or remote monitoring data makes sense. Physicians will almost certainly improve the care they deliver by understanding EMRs then, now and their near-term evolution as data sources.

On the other hand, I’m not sure it makes sense to indoctrinate med students in today’s take on evolving topics like population health management or interoperability via FHIR. These paradigms are evolving so rapidly that pinning down a set of teachable ideas may be a disservice to these students.

Morever, telling students how to think about EMRs, or articulating what skills are needed to manage them, might actually be a bad idea. I’m optimistic enough to think that now that the initial adoption frenzy funded by HITECH is over, EMRs will become far more usable and physician-shapeable over the next few years, allowing new docs to adapt the tool to them rather than adapt to the tool.

All that being said, educating med students on EMRs and health IT ancillary tools is a great idea. I just hope that such training encourages them to keep learning well after the training is over.

New ONC Scorecard Tool Grades C-CDA Documents

Posted on August 2, 2016 I Written By

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

The ONC has released a new scorecard tool which helps providers and developers find and resolve interoperability problems with C-CDA documents. According to HealthDataManagement, C-CDA docs that score well are coded with appropriate structure and semantics under HL7, and so have a better chance of being parseable by different systems.

The scorecard tool, which can be found here, actually offers two different types of scores for C-CDA documents, which must be uploaded to the site to be analyzed. One score diagnoses whether the document meets the requirements of the 2015 Edition Health IT Certification for Transitions of Care, granting a pass/fail grade. The other score, which is awarded as a letter grade ranging from A+ to D, is based on a set of enhanced interoperability rules developed by HL7.

The C-CDA scorecard takes advantage of the work done to develop SMART (Substitutable Medical Apps Resusable Technologies). SMART leverages FHIR, which is intended to make it simpler for app developers to access data and for EMR vendors to develop an API for this purpose. The scorecard, which leverages open-source technology, focuses on C-CDA 2.1 documents.

The SMART C-CDA scorecard was designed to promote best practices in C-CDA implementation by helping creators figure out how well and how often they follow best practices. The idea is also to highlight improvements that can be made right away (a welcome approach in a world where improvement can be elusive and even hard to define).

As SMART backers note, existing C-CDA validation tools like the Transport Testing Tool provided by NIST and Mode-Driven Health Tools, offer a comprehensive analysis of syntactic conformance to C-CDA specs, but don’t promote higher-level best practices. The new scorecard is intended to close this gap.

In case developers and providers have HIPAA concerns, the ONC makes a point of letting users know that the scorecard tool doesn’t retain submitted C-CDA files, and actually deletes them from the server after the files have been processed. That being said, ONC leaders still suggest that submitters not include any PHI or personally-identifiable information in the scorecards they have analyzed.

Checking up on C-CDA validity is becoming increasingly important, as this format is being used far more often than one might expect. For example, according to a story appearing last year in Modern Healthcare:

  • Epic customers shared 10.2 million C-CDA documents in March 2015, including 1.3 million outside the Epic ecosystem (non-Epic EMRs, HIEs and the health systems for the Defense and Veterans Affairs Departments)
  • Cerner customers sent 7.3 million C-CDA docs that month, more than half of which were consumed by non-Cerner systems.
  • Athenahealth customers sent about 117,000 C-CDA documents directly to other doctors during the first quarter of 2015.

Critics note that it’s still not clear how useful C-CDA information is to care, nor how often these documents are shared relative to the absolute number of patient visits. Still, even if the jury is still out on their benefits, it certainly makes sense to get C-CDA docs right if they’re going to be transmitted this often.

No, The Market Can’t Solve Health Data Interoperability Problems

Posted on July 6, 2016 I Written By

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

I seldom disagree with John Halamka, whose commentary on HIT generally strikes me as measured, sensible and well-grounded. But this time, Dr. Halamka, I’m afraid we’ll have to agree to disagree.

Dr. Halamka, chief information officer of Beth Israel Deaconess Medical Center and co-chair of the ONC’s Health IT Standards Committee, recently told Healthcare IT News that it’s time for ONC and other federal regulators to stop trying to regulate health data interoperability into existence.

“It’s time to return the agenda to the private sector in the clinician’s guide vendors reduce the products and services they want,” Halamka said. “We’re on the cusp of real breakthroughs in EHR usability and interoperability based on the new incentives for outcomes suggested by MACRA and MIPS. {T}he worst thing we could do it this time is to co-opt the private sector agenda more prescriptive regulations but EHR functionality, usability and quality measurement.”

Government regs could backfire

Don’t get me wrong — I certainly appreciate the sentiment. Government regulation of a dynamic goal like interoperability could certainly backfire spectacularly, if for no other reason than that technology evolves far more quickly than policy. Regulations could easily set approaches to interoperability in stone that become outmoded far too quickly.

Not only that, I sympathize with Halamka’s desire to let independent clinical organizations come together to figure out what their priorities are for health data sharing. Even if regulators hire the best, most insightful clinicians on the planet, they still won’t have quite the same perspective as those still working on the front lines every day. Hospitals and medical professionals are in a much better position to identify what data should be shared, how it should be shared and most importantly what they can accomplish with this data.

Nonetheless, it’s worth asking what the “private sector agenda” that Halamka cites is, actually. Is he referring to the goals of health IT vendors? Hospitals? Medical practices? Health plans? The dozens of standards and interoperability organization that exist, ranging from HL7 and FHIR to the CommonWell Health Alliance? CHIME? HIMSS? HIEs? To me, it looks like the private sector agenda is to avoid having one. At best, we might achieve the United Nations version of unity as an industry, but like that body it would be interesting but toothless.

Patients ready to snap

After many years of thought, I have come to believe that healthcare interoperability is far too important to leave to the undisciplined forces of the market. As things stand, patients like me are deeply affected by the inefficiencies and mistakes bred by the healthcare industry’ lack of interoperability — and we’re getting pretty tired of it. And readers, I guarantee that anyone who taps the healthcare system as frequently as I do feels the same way. We are on the verge of rebellion. Every time someone tells me they can’t get my records from a sister facility, we’re ready to snap.

So do I believe that government regulation is a wonderful thing? Certainly not. But after watching the HIT industry for about 20 years on health data sharing, I think it’s time for some central body to impose order on this chaos. And in such a fractured market as ours, no voluntary organization is going to have the clout to do so.

Sure, I’d love to think that providers could pressure vendors into coming up with solutions to this problem, but if they haven’t been able to do so yet, after spending a small nation’s GNP on EMRs, I doubt it’s going to happen. Rather than fighting it, let’s work together with the government and regulatory agencies to create a minimal data interoperability set everyone can live with. Any other way leads to madness.

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.

Ready For a Third-Party Market for Apps on Your EHR? athenahealth Explains How (Part 2 of 2)

Posted on July 20, 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.

In part 1 of this article, I explained why EHR vendors need to attract outside developers to remain competitive, and how athenahealth’s More Disruption Please (MDP) program pursued this goal by developing open APIs. This part goes on to describe how they made their athenahealth Marketplace an actuality.

Through experimentation, API developers throughout companies and governments have found a toolbox of best practices to develop and promote their APIs. athenahealth pretty much did everything in this toolbox:

  • A prominent public announcement (in this case, coming from the CEO Jonathan Bush himself)

  • A regular set of hackathons to answer developer questions and familiarize them with the APIs,

  • An early pilot partnership that created a demonstration project and produced insights for further development, described in Part 1 of this article

  • An accelerator program that offers seed funding, free office space, mentorship, technical resources, support, and contacts with the client base

  • A commitment to support both physicians and partners, including a requirement that athenahealth developers work on API documentation

Access to the APIs is easy–for security purposes, a developer has to agree to the run-of-the-mill terms and conditions, but the process is fast and there is no charge. The athenahealth Marketplace is large and thriving, with more than 2,500 members.

Having spent a lot of money for an EHR, clinicians who are growing more tech-savvy and have come to love their mobile apps will demand more and more value for the money. Vendors are coming to realize that they can’t produce all the value-added solutions and functionality their customers want.

The SMART Platform has, for several years, championed the availability of EHR data to fuel app development by EHR users and third-party companies. The recent FHIR standard has drawn enthusiasm from vendors. A number of them, including athenahealth, have formed the Argonauts project to develop shared definitions and ensure that, in an interoperable way, they can provide the most common types of data used by US clinicians.

But as explained before, supporting an API does not automatically lead to more effective, beneficial apps or services. athenahealth has gone to the next level to attract real-time, dynamic applications to its Marketplace, and in turn is reaping the benefits.

The Tower of EMR Babel

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

It’s the sad state of interoperability. This week when I was teaching an EHR workshop I asked for those attending to define what an Electronic Health Record was in their own words. I’d say 90% of them said something about making the healthcare data available to be shared or some variation on that idea. This wasn’t surprising for me since I’ve heard hundreds and possibly thousands of doctors say the same thing. EHR is suppose to make it so we can share data.

While people pay lip service to this idea and just assume that somehow EHR would make data sharing possible, that’s far from the reality today. This is true even in some organizations where they own both the hospital and the ambulatory provider. How sad is this? Extremely sad in my book.

I’ve often wondered what would change the tide. I’ve been long hopeful that ACOs and value based care would help to push the data sharing forward, but that’s going to be a long process. The private HIEs are working the best of any HIEs I’ve seen, so maybe the trend of hospitals acquiring small practices and hospital systems acquiring hospital systems will get us to EHR data sharing nirvana. Although, I don’t think it’s going to make it there in most communities. Instead it’s just going to have a number of large organizations not wanting to share data as opposed to some large and some small ones.

Do people really have much hope for true EHR data sharing? Does FHIR give you this hope? I’m personally not all that optimistic. We all know it’s the right thing to do, but there are some powerful forces fighting against us.

Innovative Collaboration on Medication Management and Community Resources

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

Although experts agree that the future of health is coordinated care, it is sorely lacking in the US health care system now. This article focuses on the single, relatively simple issue of medication management. Patients are prescribed barrels of pills, but there is little coordination other than looking for contra-indications and drug interactions–and these often suffer from the caretaker’s not knowing the patient’s full complement of drugs.

Sandra Raup, president of Datuit, points out that all kinds of subtleties get lost when patients are simply told how often to take a medication. For instance, if medications are spaced out throughout the day instead of being being taken all at once when we remember to take them (as so many people do), they may be absorbed more effectively and tolerated by the body. Patients–especially those with lower incomes and less education, who are more likely to be on multiple medications in the first place–need all sorts of support.

Here we come to an interesting twist: coordinated care does not have to be initiated by doctors. Given the doctor shortage and the forces keeping clinicians from adopting new models of treatment, other professionals can take on the long-term goals of improving patient health.

In a pilot ramping up in a residence for low-income seniors and the disabled in Maryland, Connected Health Resources is working with Alfa Specialty pharmacy using its Community Health Gateway to help patients straighten out their medications and keep to their schedules. This works because the pharmacy is in a somewhat unusual position: they have supported this community for some time and have built relationships with patients informally. The Gateway pilot has created a service, using Datuit’s SafeIX public API, that can potentially fulfill these needs with less work on the pharmacist’s part. The service is designed for easy navigation by the patients and their family caregivers, making it attractive to the patients and the pharmacists.

Connected Health Resources logo

The SafeIX Platform is designed using modern programming technologies to integrate data from multiple sources (including EHRs and HIEs) into a patient record for both patients and healthcare providers to use, based on their rights to access and share it. In the Gateway implementation, the pharmacist uses the SafeIX Platform to receive CDA documents from the HIE and to auto-assist medical data reconciliation between the various documents.

This information, along with the pharmacist recommendations, are organized into a daily medication calendar using an application from Polyglot Systems Incorporated, a company that offers medication regimen summaries in 18 languages. Low health literacy and the estimated 50 million people who do not speak English at home result in many patients not understanding their medication instructions. The plain language and multilingual, easy-to-use daily calendar can make the difference between understanding and total confusion.

Datuit’s SafeIX Platform uses interoperability standards (including, in test mode, the next-generation FHIR standard) to create a patient record that can show patients everything seen by multiple clinicians and allow a patient’s self-selected care team to view and add to a shared care plan. Datuit is encouraging app developers to build mobile apps for SafeIX that would prompt patients to take medications and record whether they did so, but that’s outside the scope of the pilot. There are plenty of challenges just fulfilling the tasks they have already taken on.

First, Connected Health Resources has to break down the clinical data silos that make it difficult for patients to collect their information. According to co-founder Shannah Koss, Maryland has a relatively advanced Health Information Exchange (HIE) called CRISP. However, it is defined as a provider-to-provider exchange, so it was only after a long-term relationship and negotiation that Connected Health Resources could collect medical data on behalf of the patients. This is the first time CRISP has allowed data to be retrieved for a patient-facing organization that is not a provider.

When enrolling, the patient gives the Gateway permission to get data through CRISP. Family and friends can be invited by patients to be part of their health community and enroll in the Gateway. The invitation includes a unique code that allows the Gateway to securely share records and help with health and social services navigation. If the patient wants help or is incapable of managing the medication list, a caregiver can do so.

CRISP transmits data primarily from hospitals. To round out a more comprehensive listing of medications from clinics and other healthcare providers, CRISP has enabled the ability to query Surescripts, which provides prescription fill data from chain pharmacies and pharmaceutical benefit management companies.

Pilot participants authorize the Gateway and the Alfa pharmacists to access their medication information and maintain, share, and augment the information in the secure SafeIX Platform. The CRISP data gives more complete medication records for the pilot participants. CRISP also provides an event notification system that let’s the pharmacist know whether a patient has been admitted to a hospital or visited the emergency department. These types of transition are precisely when medications get changed, but the clinicians at those crucial junctures often don’t know all of a patient’s current medications.

Finally, over-the-counter (OTC) medications can play an important role in a patient’s care. This has to be added to the daily calendar. The Alfa Pharmacist is helping round out the complete medication picture by working with the patient and family to identify OTC medications, supplements, and the medications that are actually being taken through the medication therapy management (MTM) program. The Gateway provides the means for everyone to better understand and manage the medicines for the best outcomes.

Further, the Gateway Community Resource Finder has enabled information about important resources such as transportation, meal delivery, social services, and home nursing. The MTM pharmacist knows that patients without food or transportation to their physicians cannot adequately manage their health or medications. The underlying SafeIX Platform also allows the Gateway to offer secure messaging that looks like email and lets the pharmacist, patient, friends, and family exchange messages about the patient’s care.

Traditional EHRs don’t accommodate treatment plans of the specificity designed by the pharmacy for patients in the pilot. This is where Datuit is pushing the EHR to new horizons: its SafeIX Platform helps multiple clinicians (including long term care providers), patients, and family caregivers contribute data. For example, patients can enter their own healthcare problems, such as fear of falling. The patients, families, and clinicians can then add interventions to address them.

Like other new organizations I’ve spoken too in health care, Connected Health Resources has grand plans beyond the current pilot. They are taking it slow, because Koss believes personal health records (PHRs) have tried to do too much at once and have overwhelmed their users with too many possibilities. But she would like Connected Health Resources to grow in response to what patients and families say they need. The Gateway tools already include the ability to generate multi-lingual discharge instruction from Polyglot. The initial pilot purposefully focuses on the more narrow scope of medications along with the health and social services support. The next step will be to engage hospitals to provide the plain language multi-lingual discharge instructions.

Chronic care ultimately goes beyond medications to things supported by a patient-centered medical home (PCMH), community health workers, and the many community-based service providers. The Gateway in partnership with the Datuit SafeIX Platform are poised to allow all participants identified by the patient and families to contribute to and be part of their health community.

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

Posted on April 14, 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 installment of this article was devoted to the various controversies whirling around Meaningful Use. But there are lots of other areas of technology and regulation affecting the progress (or stasis) of health IT.

FHIR: Great Promise, But So Far Just a Promise

After a decade or so of trying to make incompatible formats based on obsolete technology serve modern needs such as seamless data exchange, the health IT industry made a sudden turn to a standard invented by a few entrepreneurial developers. With FHIR they pulled on a thread that will unravel the whole garment of current practices and standards, while forming the basis for a beautiful new tapestry. FHIR will support modern data exchange (through a RESTful API), modern security, modern health practices such as using patient-generated data, and common standards that can be extended in a structured manner by different disciplines and communities.

When it’s done, that is. FHIR is still at version 0.82. Any version number less than 1, in the computer field, signals that all sorts of unanticipated changes may still be made and that anyone coding around the standard risks having to rip out their work and starting over. Furthermore, FHIR is a garment deliberately designed with big holes to be filled by others:

  • Many fields are defined precisely, but elements of the contents are left open, such as the units in which medicine is measured. This is obviously a pretty important detail to tie down.

  • Security relies on standards in the OpenID/OAuth area, which are dependable and well known by developers through their popularity on the Web. Still, somebody has to build this security in to health IT products.

  • Because countries and medical disciplines vary so greatly, the final word on FHIR data is left to “profiles” to be worked out by those communities.

One health data expert I talked to expressed the hope that market forces would compel the vendors to cooperate and make sure these various patches are interoperable as they are pieced into the garment. I would rather design a standard with firm support for these things.

Some of the missing pieces can be supplied relatively painlessly through SMART, an open API that predates FHIR but has been ported to it. An impressive set of major vendors and provider organizations have formed the Argonaut project to carry out some tasks with quick pay-offs, like making security work and implementing some high-value profiles. Let’s hope that FHIR and its accompanying projects start to have an impact soon.

The ONC has repeatedly expressed enthusiasm for FHIR, and CMS has alerted vendors that they need to start working on implementations. Interestingly, the Meaningful Use Stage 3 recommendation from CMS announces the opinion that health care providers shouldn’t charge their patients for access to their data through an API. An end to this scandalous exploitation of patients by both vendors and health care providers might have an impact on providers’ income.

Accountable Care Organizations: Walls Still Up

CMS created ACOs as a regulatory package delivering the gifts of coordinated care and pay-for-value. This was risky. ACOs require data exchange to effect smooth transfers of care, but data exchange was a rare occurrence as late as 2013, and the technical conditions have not changed since then so I can’t imagine it’s much better.

Pay-for-value also calls for analytics so providers can stratify populations and make rational choices. Finally, the degree of risk that CMS has asked ACOs to take on is pretty low, so they are not being pushed too hard to make the necessary culture changes to benefit from pay-for-value.

All that said, ACOs aren’t doing too badly. New ones are coming on board, albeit slowly, and cost savings have been demonstrated. An article titled “Poor interoperability, exchange hinders ACOs” actually reports much more positive results than the title suggests. There may be good grounds for ONC’s pronouncement that they will push more providers to form ACOs.

Still, ACOs are making a slow tack toward interoperability and coordinated care. The walls between health care settings are gradually lowering, but providers still huddle behind the larger walls of incompatible software that has trouble handling analytics.

I’ll wrap up this look at progress and its adversaries in the next installment of this article.

Looking Back at 2014: Thermidor for Health Care Reform?

Posted on December 29, 2014 I Written By

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

As money drains out of health care reform, there are indications that the impetus for change is receding as well. Yet some bright spots in health IT remain, so it’s not yet time to announce a Thermidor–the moment when a revolution is reversed and its leaders put to the guillotine. Let’s look back a bit at what went right and wrong in 2014.
Read more..