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!!

MUMPS and Healthcare

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

Leave it to David Chou to point out how odd it is to work in healthcare IT. What’s shocking about the image David Chou shared above is that there are so many languages listed. However, despite the vast number of languages listed, MUMPS is so far off the radar of most tech people that they literally didn’t care about it enough to add it to the chart. That’s pretty sad for those of us who care about healthcare.

If you want to get another view about the challenge of so much of healthcare being run on MUMPS, check out this MUMPS thread on Hacker News. For those not familiar with Hacker News, it’s a site that was started by YCombinator and has grown into a community of some of the most progressive tech startup people in the world. The Hacker News thread is really long, so for those who don’t want to read it all the message is simple: MUMPS? What’s that? That’s awful!

To be fair, there were a few dissenting voices who commented on the great features of MUMPS. However, I have to admit that these people sound a little bit like those who espouse the benefits of the fax machine. Sure, it has some extremely beneficial features, but it’s downsides far outweigh the benefits described.

The reality is that we’re not going to get away from MUMPS in healthcare. When you realize that Epic, MEDITECH, Vista (VA), and Intersystems all use some form of MUMPS (or M as they prefer to call it now), you can see why MUMPS will be part of healthcare for a long time to come.

What’s more disappointing to me after reading the Hacker News thread was how people described the culture of the EHR vendors that use MUMPS. They really described it as uninterested in even exploring other more modern options that could help them better able to innovate their products and serve their customers.

Plus, it also hurts to hear so many programmers in the thread talk about how they shunned healthcare because they saw working on something like MUMPS as a career killer. I’m sure this is a common refrain for most developers out there. It’s disheartening to think that many EHR vendors will never benefit from the best developers as long as we’re on MUMPS.

I’m sure MUMPS was great in its day. It seems to have been a wise choice by Epic to start using it when I was born back in 1979. However, can you imagine the technical debt that’s accumulated all these years? Is it any wonder that innovation in healthcare works so slow?

The Government EHR Mess – Coast Guard Publishes EHR RFI – VA Looking to Replace Vista

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

If you’re like me and enjoy a little inside baseball in the EHR world, then you have to watch what’s going on with EHR use in the government. In many ways, it’s like passing that car wreck on the freeway. There’s no way you can pass by without taking a look and seeing what’s gone on and what’s still going on. You want to know what’s happening.

A car wreck might be an apt comparison since we’re talking about the various government EHR situations. For those who haven’t followed this as closely, here’s a quick recap.

The DoD had the awful AHLTA EHR system. The VA had (and still has) their own homegrown VistA EHR system which most users seem to like. After a bunch of political jousting back and forth, the DoD did a $9+ billion RFP and finally selected Cerner EHR (although, Leidos was really the lead company and much of the $9 billion was going to them and not Cerner).

Meanwhile, the Coast Guard had selected Epic as their EHR. Long story short, things didn’t work out and the Coast Guard stopped implementing Epic and went back to paper. Yes, I said that right. They had to go back to paper.

Near the start of 2017, word came out that the VA was likely to replace their current VistA EHR with a commercial EHR replacement. That process is ongoing.

In the last week, the Coast Guard published their RFI to purchase an EHR. I guess that’s the final nail in the coffin for Epic at the Coast Guard.

I’m sure I’m leaving out some other government organizations that have EHR or are looking for an EHR. However, these are some of the high profile ones. As we sit here today, the question remains, which EHR will the VA and Coast Guard choose?

The obvious choice to everyone watching this is that the VA and Coast Guard and every other government organization that needs an EHR should go with Cerner. Interoperability between the DoD and VA has been awful and you’d think that having one EHR would help that situation. Plus, shouldn’t the VA be able to benefit from the experience the DoD has had implementing Cerner already? Not to mention, shouldn’t the VA and Coast Guard be able to get a discount from Cerner for bundling the purchase or does that not happen with $8 billion purchases.

The problem is that most of us (including me) don’t know all the politics at play. What seems completely obvious to us outside observers misses many of the political and cultural nuances at play in this situation. I’m not saying those nuances are right or accurate, but you can be sure that the EHR selection decision is going to have a lot of people chiming in with their own personal biases.

One simple example that’s easy to understand is you could see the VA making the case for why they should go with a commercial version of the VistA EHR that they’re already familiar within their organization. It’s hard for me to see them making this decision, but you can see why one could make a pretty solid argument for why choosing a commercial version of VistA would be a good idea.

When it comes to the interoperability potential I mentioned above, it’s sad to ask, but is having all of these organizations on the same EHR really that much better? We’re not talking about the government implementing a single instance EHR that’s shared across all organization. That would never happen, so even if the DoD and VA both buy from Cerner, they’re still going to need an interface between the systems. This should be presumably easier, but you can be sure it’s not going to be as turnkey as one might imagine it to be.

No doubt we’ll be watching to see what the Coast Guard and VA decide. Which EHR do you think they’ll choose? Which EHR should they choose and why? I look forward to hearing your thoughts in the comments.

HL7 Releases New FHIR Update

Posted on April 3, 2017 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

HL7 has announced the release of a new version of FHIR designed to link it with real-world concepts and players in healthcare, marking the third of five planned updates. It’s also issuing the first release of the US Core Implementation Guide.

FHIR release 3 was produced with the cooperation of hundreds of contributors, and the final product incorporates the input of more than 2,400 suggested changes, according to project director Grahame Grieve. The release is known as STU3 (Standard for Trial Use, release 3).

Key changes to the standard include additional support for clinical quality measures and clinical decision support, as well as broader functionality to cover key clinical workflows.

In addition, the new FHIR version includes incremental improvements and increased maturity of the RESTful API, further development of terminology services and new support for financial management. It also defined an RDF format, as well as how FHIR relates to linked data.

HL7 is already gearing up for the release of FHIR’s next version. It plans to publish the first draft of version 4 for comment in December 2017 and review comments on the draft. It will then have a ballot on the version, in April 2018, and publish the new standard by October 2018.

Among those contributing to the development of FHIR is the Argonaut project, which brings together major US EHR vendors to drive industry adoption of FHIR forward. Grieve calls the project a “particularly important” part of the FHIR community, though it’s hard to tell how far along its vendor members have come with the standard so far.

To date, few EHR vendors have offered concrete support for FHIR, but that’s changing gradually. For example, in early 2016 Cerner released an online sandbox for developers designed to help them interact with its platform. And earlier this month, Epic announced the launch of a new program, helping physician practices to build customized apps using FHIR.

In addition to the vendors, which include athenahealth, Cerner, Epic, MEDITECH and McKesson, several large providers are participating. Beth Israel Deaconess Medical Center, Intermountain Healthcare, the Mayo Clinic and Partners HealthCare System are on board, as well as the SMART team at the Boston Children’s Hospital Informatics Program.

Meanwhile, the progress of developing and improving FHIR will continue.  For release 4 of FHIR, the participants will focus on record-keeping and data exchange for the healthcare process. This will encompass clinical data such as allergies, problems and care plans; diagnostic data such observations, reports and imaging studies; medication functions such as order, dispense and administration; workflow features like task, appointment schedule and referral; and financial data such as claims, accounts and coverage.

Eventually, when release 5 of FHIR becomes available, developers should be able to help clinicians reason about the healthcare process, the organization says.

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.

Switching EHRs, The Trends And What To Consider

Posted on September 8, 2016 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.

The following is a guest blog post by Winyen Wu, Technology and Health Trend Blogger and Enthusiast at Stericycle Communication Solutions as part of the Communication Solutions Series of blog posts. Follow and engage with them on Twitter: @StericycleComms
Winyen Wu - Stericycle
In recent years, there has been a trend in providers switching Electronic Health Record (EHR) systems: according to Software Advice, the number of buyers replacing EHR software has increased 59% since 2014. In a survey by KLAS, 27% of medical practices are looking to replace their EHR while another 12% would like to but cannot due to financial or organizational constraints. By 2016, almost 50% of large hospitals will replace their current EHR. This indicates that the current EHR products on the market are not meeting the needs of physicians.

What are the reasons for switching EHRs?

  • Complexity and poor usability: Many physicians find that it takes too many clicks to find the screen that they need, or that it is too time consuming to fill out all the checkboxes and forms required
  • Poor technical support: Some physicians may be experiencing unresponsive or low quality support from their EHR vendor
  • Consolidation of multiple EHRs: After consolidating practices, an organization will choose to use only one EHR as opposed to having multiple systems in place
  • Outgrowing functionality or inadequate systems: Some current EHRs may meet stage 1 criteria for meaningful use, but will not meet stage 2 criteria, which demand more from an EHR system.

Which companies are gaining and losing customers?

  • Epic and Cerner are the top programs in terms of functionality according to a survey by KLAS; cloud-based programs Athenahealth and eClinicalWorks are also popular
  • Companies that are getting replaced include GE Healthcare, Allscripts, NextGen Healthcare, and McKesson; 40-50% of their customers reported potential plans to move

What are providers looking for in choosing an EHR?

  • Ability to meet Meaningful Use standards/criteria: In September 2013, 861 EHR vendors met stage 1 requirements of meaningful use while only 512 met stage 2 criteria for certification, according to the US Department of Health and Human Services. Because stage 2 criteria for meaningful is more demanding, EHRs systems are required to have more sophisticated analytics, standardization, and linkages with patient portals.
  • Interoperability: able to integrate workflows and exchange information with other products
  • Company reliability: Physicians are looking for vendors who are likely to be around in 20 years. Potential buyers may be deterred from switching to a company if there are factors like an impending merger/acquisition, senior management issues, declining market share, or internal staff system training issues.

Is it worth it?
In a survey conducted by Family Practice Management of physicians who switched EHRs since 2010, 59% said their new EHRs had added functionality, and 57% said that their new system allowed them to meet meaningful use criteria, but 43% said they were glad they switched systems and only 39% were happy with their new EHR.

5 Things to consider when planning to switch EHRs

  1. Certifications and Compliance: Do your research. Does your new vendor have customers who have achieved the level of certification your organization hopes to achieve? Does this new vendor continually invest in the system to make updates with changing regulations?
  2. Customer Service: Don’t be shy. Ask to speak to at least 3 current customers in your specialty and around your size. Ask the tough questions regarding level of service the vendor provides.
  3. Interoperability: Don’t be left unconnected. Ensure your new vendor is committed to interoperability and has concreate examples of integration with other EHR vendors and lab services.
  4. Reliability and Longevity: Don’t be left out to dry. Do digging into the vendor’s financials, leadership changes and staffing updates. If they appear to be slimming down and not growing this is a sign that this product is not a main focus of the company and could be phased out or sold.
  5. Integration with Current Services: Don’t wait until it’s too late. Reach out to your current providers (like appointment reminders) and ensure they integrate with your new system and set up a plan for integrating the two well in advance.

The Communication Solutions Series of blog posts is sponsored by Stericycle Communication Solutions, a leading provider of high quality telephone answering, appointment scheduling, and automated communication services. Stericycle Communication Solutions combines a human touch with innovative technology to deliver best-in-class communication services.  Connect with Stericycle Communication Solutions on social media:  @StericycleComms

VA May Drop VistA For Commercial EHR

Posted on July 12, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

It’s beginning to look like the famed VistA EHR may be shelved by the Department of Veterans Affairs, probably to be replaced by a commercial EHR rollout. If so, it could spell the end of the VA’s involvement in the highly-rated open source platform, which has been in use for 40 years. It will be interesting to see how the commercial EHR companies that support Vista would be impacted by this decision.

The first rumblings were heard in March, when VA CIO LaVerne Council  suggested that the VA wasn’t committed to VistA. Now Council, who supervises the agency’s $4 billion IT budget, sounds a bit more resolved. “I have a lot of respect for VistA but it’s a 40-year-old product,” Council told Politico. “Looking at what technology can do today that it couldn’t do then — it can do a lot.”

Her comments were echoed by VA undersecretary for health David Shulkin, who last month told a Senate hearing that the agency is likely to replace VistA with commercial software.

Apparently, the agency will leave VistA in place through 2018. At that point, the agency expects to begin creating a cloud-based platform which may include VistA elements at its core, Politico reports. Council told the hearing that VA IT leaders expect to work with the ONC, as well as the Department of Defense, in building its new digital health platform.

Particularly given its history, which includes some serious fumbles, it’s hardly surprising that some Senate members were critical of the VA’s plans. For example, Sen. Patty Murray said that she was still disappointed with the agency’s 2013 decision back to call of plans for an EHR that integrated fully with the DoD. And Sen. Richard Blumenthal expressed frustration as well. “The decades of unsuccessful attempts to establish an electronic health record system that is compatible across the VA in DoD has caused hundreds of millions of taxpayer dollars to be wasted,” he told the committee.

Now, the question is what commercial system the VA will select. While all the enterprise EHR vendors would seem to have a shot, it seems to me that Cerner is a likely bet. One major reason to anticipate such a move is that Cerner and its partners recently won the $4.3 billion contract to roll out a new health IT platform for the DoD.

Not only that, as I noted in a post earlier this year, the buzz around the deal suggested that Cerner won the DoD contract because it was seen as more open than Epic. I am taking no position on whether there’s any truth to this belief, nor how widespread such gossip may be. But if policymakers or politicians do see Cerner as more interoperability-friendly, that will certainly boost the odds that the VA will choose Cerner as partner.

Of course, any EHR selection process can take crazy turns, and when you grow in politics the process can even crazier. So obviously, no one knows what the VA will do. In fact, given their battles with the DoD maybe they’ll go with Epic just to be different. But if I were a Cerner marketer I’d like my odds.

Has Electronic Health Record Replacement Failed?

Posted on June 23, 2016 I Written By

The following is a guest blog post by Justin Campbell, Vice President, Galen Healthcare.
Justin Campbell
A recent Black Book survey of hospital executives and IT employees who have replaced their Electronic Health Record system in the past three years paints a grim picture. Respondents report higher than expected costs, layoffs, declining revenues, disenfranchised clinicians and serious misgivings about the benefits of switching systems. Specifically:

  • 14% of all hospitals that replaced their original EHR since 2011 were losing inpatient revenue at a pace that wouldn’t support the total cost of their replacement EHR
  • 87% of hospitals facing financial challenges now regret the decision to change systems
  • 63% of executive level respondents admitted they feared losing their jobs as a result of the EHR replacement process
  • 66% of system users believe that interoperability and patient data exchange functionality have declined

Surely, this was not the outcome expected when hospitals rushed to replace paper records in response to Congressional incentives (and penalties) included in the 2009 American Recovery and Reinvestment Act.

But the disappointment reflected in this survey only sheds light on part of the story. The majority of hospitals depicted here were already in financial difficulty. It is understandable that they felt impelled to make a significant change and to do so as quickly as possible. But installing an electronic record system, or replacing one that is antiquated, requires much more than a decision to do so. We should not be surprised that a complex undertaking like this would be burdened by complicated and confusing challenges, chief among which turned out to be “usability” and acceptance.

Another Black Book report, this one from 2013, revealed:

  • 66% of doctors using EHR systems did not do so willingly
  • 87% of those unwilling to use the system claimed usability as their primary complaint
  • 84% of physician groups chose their EHR to reach meaningful use incentives
  • 92% of practices described their EHR as “clunky” and/or difficult to use

None of this should surprise us but we need to ask: was usability really the key driver for EHR replacement? Is usability alone accountable for lost revenue, employment anxiety and buyers’ remorse? Surely organizations would not have dumped millions into failed EHR implementations only to rip-and-replace them due to usability problems and provider dissatisfaction. Indeed, despite the persistence of functional obstacles such as outdated technology, hospitals continue to make new EMR purchases. Maybe the “reason for the rip-and-replace approach by some hospitals is to reach interoperability between inpatient and outpatient data,” wrote Dr. Donald Voltz, MD in EMR and EHR.

Interoperability is linked to another one of the main drivers of EHR replacement: the mission to support value-based care, that is, to improve the delivery of care by streamlining operations and facilitating the exchange of health information between a hospital’s own providers and the caregivers at other hospitals or health facilities. This can be almost impossible to achieve if hospitals have legacy systems that include multiple and non-communicative EHRs.

As explained by Chief Nurse Executive Gail Carlson, in an article for Modern Healthcare, “Interoperability between EHRs has become crucial for their successful integration of operations – and sometimes requires dumping legacy systems that can’t talk to each other.”

Many hospitals have numerous ancillary services, each with their own programs. The EHRs are often “best of breed.” That means they employ highly specialized software that provides excellent service in specific areas such as emergency departments, obstetrics or lab work. But communication between these departments is compromised because they display data differently.

In order to judge EHR replacement outcomes objectively, one needs to not just examine the near-term financials and sentiment (admittedly, replacement causes disruption and is not easy), but to also take a holistic view of the impact to the system’s portfolio by way of simplification and future positioning for value-based care. The majority of the negative sentiment and disappointing outcomes may actually stem from the migration and new system implementation process in and of itself. Many groups likely underestimated the scope of the undertaking and compromised new system adoption through a lackluster migration.

Not everyone plunged into the replacement frenzy. Some pursued a solution such as dBMotion to foster care for patients via intercommunications across all care venues. In fact, Allscripts acquired dBMotion to solve for interoperability between its inpatient solution (Eclipsys SCM) and its outpatient EMR offering (Touchworks). dBMotion provides a solution for those organizations with different inpatient and outpatient vendors, offering semantic interoperability, vocabulary management, EMPI and ultimately facilitating a true community-based record.

Yet others chose to optimize what they had, driven by financial constraints. There is a thin line separating EHR replacement from EHR optimization. This is especially true for those HCOs that are neither large enough nor sufficiently funded to be able to afford a replacement; they are instead forced to squeeze out the most value they can from their current investment.

The optimization path is much more pronounced with MEDITECH clients, where a large percentage of their base remains on the legacy MAGIC and C/S platforms.

Denni McColm, a hospital CIO, told healthsystemCIO why many MEDITECH clients are watching and waiting before they commit to a more advanced platform:

“We’re on MEDITECH’s Client/Server version, which is not their older version and not their newest version, and we have it implemented really everywhere that MEDITECH serves. So we have the hospital systems, home care, long-term care, emergency services, surgical center — all the way across the continuum. We plan to go to their latest version sometime in the next few years to get the ambulatory interface for the providers. It should be very efficient — reduced clicks, it’s mobile friendly, and our docs are anxious to move to it,” but we’ll decide when the time is right, she says.

What can we discern from these different approaches and studies?  It’s too early to be sure of the final score. One thing is certain though: the migrations and archival underpinnings of system replacement are essential. They allow the replacement to deliver on the promise of improved usability, enhanced interoperability and take us closer to the goal of value-based care.

About Justin Campbell
Justin is Vice President, Strategy, at Galen Healthcare Solutions. He is responsible for market intelligence, segmentation, business and market development and competitive strategy. Justin has been consulting in Health IT for over 10 years, guiding clients in the implementation, integration and optimization of clinical systems. He has been on the front lines of system replacement and data migration and is passionate about advancing interoperability in healthcare and harnessing analytical insights to realize improvements in patient care. Justin can be found on Twitter at @TJustinCampbell

Sansoro Hopes Its Health Record API Will Unite Them All

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

After some seven years of watching the US government push interoperability among health records, and hearing how far we are from achieving it, I assumed that fundamental divergences among electronic health records at different sites posed problems of staggering complexity. I pricked up my ears, therefore, when John Orosco, CTO of Sansoro Health, said that they could get EHRs to expose real-time web services in a few hours, or at most a couple days.

What does Sansoro do? Its goal, like the FHIR standard, is to give health care providers and third-party developers a single go-to API where they can run their apps on any supported EHR. Done right, this service cuts down development costs and saves the developers from having to distribute a different version of their app for different customers. Note that the SMART project tries to achieve a similar goal by providing an API layer on top of EHRs for producing user interfaces, whereas Sansoro offers an API at a lower level on particular data items, like FHIR.

Sansoro was formed in the summer of 2014. Researching EHRs, its founders recognized that even though the vendors differed in many superficial ways (including the purportedly standard CCDs they create), all EHRs dealt at bottom with the same fields. Diagnoses, lab orders, allergies, medications, etc. are the same throughout the industry, so familiar items turn up under the varying semantics.

FHIR was just starting at that time, and is still maturing. Therefore, while planning to support FHIR as it becomes ready, Sansoro designed their own data model and API to meet industry’s needs right now. They are gradually adding FHIR interfaces that they consider mature to their Emissary application.

Sansoro aimed first at the acute care market, and is expanding to support ambulatory EHR platforms. At the beginning, based on market share, Sansoro chose to focus on the Cerner and Epic EHRs, both of which offer limited web services modules to their customers. Then, listening to customer needs, Sansoro added MEDITECH and Allscripts; it will continue to follow customer priorities.

Although Orosco acknowledged that EHR vendors are already moving toward interoperability, their services are currently limited and focus on their own platforms. For various reasons, they may implement the FHIR specification differently. (Health IT experts hope that Argonaut project will ensure semantic interoperability for at least the most common FHIR items.) Sansoro, in contrast can expose any field in the EHR using its APIs, thus serving the health care community’s immediate needs in an EHR-agnostic manner. Emissary may prevent the field from ending up again the way the CCD has fared, where each vendor can implement a different API and claim to be compliant.

This kind of fragmented interface is a constant risk in markets in which proprietary companies are rapidly entering an competing. There is also a risk, therefore, that many competitors will enter the API market as Sansoro has done, reproducing the minor and annoying differences between EHR vendors at a higher level.

But Orosco reminded me that Google, Facebook, and Microsoft all have competing APIs for messaging, identity management, and other services. The benefits of competition, even when people have to use different interfaces, drives a field forward, and the same can happen in healthcare. Two directions face us: to allow rapid entry of multiple vendors and learn from experience, or to spend a long time trying to develop a robust standard in an open manner for all to use. Luckily, given Sansoro and FHIR, we have both options.

April Fool’s Day – Health IT Edition

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

Most of you know that I love a good April Fool’s day joke. I don’t like those that hurt people, but I love good humor (ask me about the time my wife said she was going into labor and wasn’t). You may remember my past years’ pranks about the #HIT100 Health IT Company, the ONC Reality TV show, and my personal favorite where we announced we’d be selling our own EHR software. Good memories all around.

This year I’ve been busy organizing the Health IT Marketing and PR Conference, but that doesn’t mean I can’t enjoy other people’s work. I’m sure I’ve missed some of the great health IT related April Fool’s day jokes, so let me know of others in the comments.

The big winner for April Fool’s 2016 for me was SnapChart from Twine Health. You’ll particularly enjoy it if you’re a SnapChat user, but it’s a great one either way. This video should demonstrate what I mean:

Well done Twine Health! I think even patient privacy advocates would appreciate SnapChart. “We all know that EHRs suck. Well this EHR only sucks for 7 seconds….BOOM”

Another honorable mention goes to Epic who has a long standing tradition of offering something entertaining on April Fool’s Day:
Epic April Fool's Day 2016
*Click on the image to see a larger version

Nice work by Epic to keep it topical with reference to Clinton and Sanders. However, the one that takes the cake is Jonathan Bush using MyChart. The only thing that would make me laugh more would be if athenahealth put out a video response from Jonathan Bush. Please?!

Cureatr decided to go old school with a new technology called the Faxenatr:

Howard Green, MD posted this announcement from Alphabet Inc and Google Inc’s company Verily Life Sciences about the UHIT (Universal Health Information Technology).

So many others I could mention outside of health IT. This one from Samsung about a 3D holographic projection was cool:


Although, when you look at what’s happening with VR, maybe it will be more reality than we realize.

Gmail’s Mic Drop is pretty funny. Well, at least it was until people starting losing their job because of it. The concept of a mic drop on email or social media is pretty interesting though. I wonder if there’s a way you could really implement something like it.

What other April Fool’s day jokes have you seen. It’s Friday. We all need a good laugh.