Free Hospital EMR and EHR 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 Hospital EMR and EHR for FREE!

2 Core Healthcare IT Principles

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

One of my favorite bloggers I found when I first starting blogging about Healthcare IT was a hospital CIO named Will Weider who blogged on a site he called Candid CIO. At the time he was CIO of Ministry Health Care and he always offered exceptional insights from his perspective as a hospital CIO. A little over a month ago, Will decided to move on as CIO after 22 years. That was great news for me since it meant he’d probably have more time to blog. The good news is that he has been posting more.

In a recent post, Will offered two guiding principles that I thought were very applicable to any company working to take part in the hospital health IT space:

1. Embed everything in the EHR
2. Don’t hijack the physician workflow

Go and read Will’s post to get his insights, but I agree with both of these principles.

I would add one clarification to his first point. I think there is a space for an outside provider to work outside of the EHR. Think of someone like a care manager. EHR software doesn’t do care management well and so I think there’s a space for a third party care management platform. However, if you want the doctor to access it, then it has to be embedded in the EHR. It’s amazing how much of a barrier a second system is for a doctor.

Ironically, we’ve seen the opposite is also true for people like radiologists. If it’s not in their PACS interface, then it takes a nearly herculean effort for them to leave their PACS system to look something up in the EHR. That’s why I was excited to see some PACS interfaces at RSNA last year which had the EHR data integrated into the radiologists’ interface. The same is true for doctors working in an EHR.

Will’s second point is a really strong one. In his description of this principle, he even suggests that alerts should all but be done away within an EHR except for “the most critical safety situations. He’s right that alert blindness is real and I haven’t seen anyone nail the alerts so well that doctors aren’t happy to see the alerts. That’s the bar we should place on alerts that hijack the physician workflow. Will the doctor be happy you hijacked their workflow and gave them the alert? If the answer is no, then you probably shouldn’t send it.

Welcome back to the blogosphere Will! I look forward to many more posts from you in the future.

Two Competing Challenges: Integration and Innovation

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

In my other post about BIDMC’s webOMR acquisition by Athenahealth, I found this old post from John Halamka about the best of breed healthcare IT application approach and the all in one integrated EHR approach. In that post, I was really struck by the way John Halamka describes the challenge of balancing innovation and integration:

Innovation:

Epic eases the burden of demand management. Every day, clinicians ask me for innovations because they know our self-built, cloud hosted, mobile friendly core clinical systems are limited only by our imagination. Further, they know that we integrate department specific niche applications very well, so best of breed or best of suite is still a possibility. Demand for automation is infinite but supply is always limited. My governance committees balance requests with scope, time, and resources. It takes a great deal of effort and political capital. With Epic, demand is more easily managed by noting that desired features and functions depend on Epic’s release schedule. It’s not under IT control.

Integration:

Most significantly, the industry pendulum has swung from best of breed/deep clinical functionality to the need for integration. Certainly Epic has many features and overall is a good product. It has few competitors, although Meditech and Cerner may provide a lower total cost of ownership which can be a deciding factor for some customers. There are niche products that provide superior features for a department or specific workflow. However, many hospital senior managers see that Accountable Care/global capitated risk depends upon maintaining continuous wellness not treating episodic illness, so a fully integrated record for all aspects of a patient care at all sites seems desirable. In my experience, hospitals are now willing to give up functionality so that they can achieve the integration they believe is needed for care management and population health.

These comments also say something significant about IT governance as well. It’s a challenging balance. Although, it also illustrates why a well done EHR API is so powerful. It allows a large organization to have deep integration into an EHR while not having to sacrifice the ability to innovate. Too bad APIs are Hard and so many EHR vendors haven’t executed on them. We’ll see if FHIR can get us at least part of the way there.

How do you approach innovation and integration in your hospital? What’s the right balance?

EHR APIs Are Hard

Posted on January 22, 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.

I’ve been thinking a lot about healthcare interoperability lately. I’ve long argued that it’s one way we can really lower the costs of healthcare. Plus, I’m a true believer in the value of doctors having all the information possible in the right place at the right time. I’ve also advocated strongly for EHR vendors to create APIs that allow other entrepreneurs to build really amazing functionality on top of the EHR.

This last point is the one I want to address now. I still think an EHR API is going to be essential to the future success of an EHR vendor. The reality is that the EHR isn’t going to do everything for everyone. My favorite example is genomic analysis. EHR vendors are not going to do this. Some other company is going to take care of the genomic analysis and then they’re going to need to want to have to integrate with the EHR for their to be a beautiful workflow for everyone involved. This integration is going to best be done by an API. Plus, genomics is just one example of hundreds of integrations that might be needed.

To me the case is clear why there’s a benefit to having an open EHR API. Why then, don’t we see more of them in the EHR world? The simple answer seems to be that APIs are hard!

I found a great description of the challenge of creating a quality API on the WordPress developer blog:

Developing APIs is hard.
You pour your blood, sweat, and tears into this interface that bares the soul of your company and of your product to the world. The machinery under the hood, though, is often a lot less polished than the fancy paint job would lead the rest of the world to believe. You have to be careful, then, not to inflict your own rough edges on the people you expect to be consuming your API because…

Using APIs is hard.
As an app developer you’re trying to take someone else’s product and somehow integrate it into whatever vision you have in your head. Whether it’s simply getting a list of things from another service (such as embedding a reading list) or wrapping your entire product around another product (using Amazon S3 as your primary binary storage mechanism, for example), you have a lot of things to reconcile.

You have your own programming language (or languages) that you’re using. There’s the use case you have in mind, and the ones the remote devs had in mind for the API. There’s the programming language they used to create the API (and that they used to test it). Finally, don’t forget the encoding or representation of the data — and its limitations. Reconciling all of the slight (or major) differences between these elements is a real challenge sometimes. Despite years of attempts at best practices and industry standards, things just don’t always fit together like we pretend that they will.

He also offers 3 recommendations when you choose to provide an API:
#1 You want people to use your API.
#2 You have no control over what tools others are using.
#3 Your API is a promise.

Let’s also be clear that a WordPress API is much simpler than what a quality EHR API would require. The principles still apply, but the complexity makes it even harder. I think this is a major reason why many EHR vendors haven’t yet done an API to their EHR. An EHR API is not a one time job where you set it and forget it. It’s an ongoing project that has to be updated and improved with every release. Plus, you have to make those changes and additions without breaking things for your partners who use the API. That’s not a simple job.

Despite being hard, I still believe that EHR APIs are going to be the future of EHR. Plus, an EHR vendor should be glad that EHR APIs are hard. That means that if they put in the effort to do one the right way, they’ll have an advantage over the others who don’t. There are hundreds of healthcare startup companies that would love to tap into a quality EHR API. If you build it, they will come.