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

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 ( 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.

Will Personal Health Information Exchanges (PHIE) Lead the Consumer Medical Record Revolution and Bridge the Gap Between PHRs and EHRs? (Part 2 of 2)

Posted on August 5, 2015 I Written By

The following is a guest blog post by Cora Alisuag, RN, MN, MA, CFP, President & CEO, CORAnet Solutions, Inc.
Cora Alisuag, CEO, CORAnet Solutions
Be sure to check out part 1 in this series where we talked about the movement towards an empowered patient who controls their health record.

Lack of Interoperability Continues to Hamper Patient Record Access

However, it has been six years since the HITECH Act passed, yet most Americans seeking medical care are still unable to obtain their full medical records for a variety of reasons. Some hospitals will simply not release them or proprietary EHR system vendors not allowing hospitals, let alone patients, direct access.

This capability also comes at a critical time as enormous obstacles hamper the ability of people to obtain their medical records. This is documented in the ONC’s “2015 Report to Congress on Health Information Blocking” which concludes that it is apparent that some health care providers and health IT developers are knowingly interfering with the exchange of health information in ways that limit its availability and use to improve health and health care.

This situation is only going to worsen as the Centers for Medicaid and Medicare (CMS) is considering a change to the EHR meaningful use rule that requires five percent of patients must view or download or transmit their health data to only one patient; not one percent, one patient.

Blue Button Not Gaining traction

In the meantime, other PHR technology has been introduced, but has not gained popularity including forays from Microsoft and Google. The ONC and other government organizations’ initiative to adopt and use the Blue Button platform for exchanging healthcare data between clinicians equipped with electronic health-record systems and patients with mobile computing devices is stalled, according to a recent survey by the not-for-profit Workgroup for Electronic Data Interchange (WEDI).

WEDI questioned 274 providers, health plans, HIT vendors and claims clearinghouses in the Second Annual Survey of Industry Awareness of Blue Button, conducted late in 2014. Only eight percent of respondents noted that their organizations actually used Blue Button, down from 15% of survey respondents in 2013.

PHRs Largely Unpopular

PHRs joined the lexicon of medical terminology several years ago as a convenience way for consumers to have copies of their medical records. It was largely born out of EHR’s lack of interoperability and access. However, as far back as 2009, a Health Affairs article detailed the major factors behind the slow adoption of PHRs. The article reviewed some of the reasons and includes cost, access, interoperability, security concerns, and data ownership.

Because health records which include clinical data, laboratory results and medical images do not flow freely among multiple organizations due to lack on EHR interoperability, PHRs do not automatically receive data. This means that the data must often be entered manually by consumers—a time-consuming and error-prone process. For most consumers, this lack of safe and reliable automation makes it problematic to maintain a PHR, and a PHR that is not up-to-date likely will not be used. Unlike PHIEs, the API-EHR connectivity connection is the missing link in PHRs.

However, the authors of the Health Affairs article offered a challenge. They described a gap between today’s personal health records (PHRs) and what patients say they want and need from this electronic tool for managing their health information. They noted that until that gap is bridged, it is unlikely that PHRs would be widely adopted, but noted that in the future; when these concerns are addressed, and health data is portable and understandable in content and format, PHRs will likely prove to be invaluable.

“While we all agree that lack of interoperability continues to stymie patient health record access and PHRs might not be the ultimate solution, but if a PHIE can bridge the gap by accessing EHR data through an open API while offering the security and convenience of a PHR. I believe PHIEs offer a solution that should satisfy the spontaneity of millennials’ and more frequent use of middle-aged and elderly users,” says Tiffany Casper, RNC, CNM, MSN and President of EMR Consultants which helps medical organizations transition to EMR systems.

About Cora Alisuag
Cora Alisuag is the CEO of CORAnet Solutions, Inc., a health information technology company. She is the inventor of CORAnet technology, the software engine that drives CORAnet’s Personal Health Information Exchange (PHIE), allowing patients’ mobile device access to their complete medical records. She is also an MN, MA, CFP and healthcare industry speaker and serial medical entrepreneur.

EHR Partner Programs

Posted on May 22, 2015 I Written By

John Lynn is the Founder of the 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 and John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

Amazing Charts just announced a new EHR partner program. This isn’t something that’s particularly new for EHR vendors. They all have lots of partners. Some have formalized them into a program like athenahealth has done with their More Disruption Please (MDP) program. Others are much more quiet about the partners they work with and how they work with them.

What’s clear to me in the EHR industry is that an EHR vendor won’t be able to do everything. There are some that like to try (See Epic), but even the largest EHR vendor isn’t going to be able to provide all the services that are needed by a healthcare organization. This is true for ambulatory and hospitals.

Since an EHR vendor won’t be able to do everything, it makes a lot of sense for an EHR vendor to have some sort of partners program. The challenge for an EHR vendor is that a partner program comes with two major expectations. First, the partner has a high quality integration with the EHR software. Second, that the partner is something that the EHR vendor has vetted.

The first challenge is mostly a challenge because most EHR vendors aren’t great at integrating with outside companies. This is a major culture shift for many EHR vendors and it will take time for them to get up to speed on these types of integrations. Plus, these integrations do take some time and investment on the part of the EHR vendor. When there’s time and investment involved, the EHR vendor starts to be much more selective about which companies they want to be working with long term. They don’t want to spend their time and money integrating with a company which none of its users will actually use.

The second challenge is that EHR users assume that an EHR partner is one that’s been vetted by the EHR vendor. Even if the EHR vendor puts all sorts of disclaimers on their partner page, the EHR vendor is still associated with their partners. The written disclaimers might help you avoid legal issues, but working with shady partners can do a lot of damage to your reputation and credibility in the marketplace. I actually think this is probably the biggest reason that EHR vendors have been reluctant to implement partner programs.

I think over time we’ll see the first problem solved as EHR vendors work to standardize their APIs for partner companies. As those APIs become more mature, we’ll see much deeper EHR integrations and the costs to an EHR vendor will drop dramatically when it comes to new partner integrations.

The second problem is much harder to solve. My best suggestion for EHR vendors is to create a platform which allows your users to help you vet potential partners. Not only can they participate in the vetting process, but it can also help you know which partners would be useful to your users. Is there anything more valuable than user driven partnerships? It also puts you in a good position with potential partners if you already have users interested in the integration.

However, an EHR vendor shouldn’t just leave potential partnership requests to their users. Many of their users don’t know of all the potential partner companies. Users are so busy dealing with their day jobs that they often don’t know of all the potential companies that could benefit their practice or hospital. Certainly you should accept user input on potential partnerships, but an EHR vendor should also seed the potential partner feedback platform with a list of potential partners as well. The mix of an EHR vendor created list together with user generated partner lists is much more powerful than one or the other.

We’re just at the beginning of companies partnering and integrating with EHR vendors. I expect that over the next 5 years an EHR vendor will be defined as much by the organizations it chooses to partner with as the features and functions it chooses to develop itself.

How Do We Achieve Continuous Healthcare Interoperability?

Posted on February 2, 2015 I Written By

John Lynn is the Founder of the 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 and John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

Today I had a really interesting chat about healthcare interoperability with Mario Hyland, Founder of AEGIS. I’m looking at a number of ways that Mario and I can work together to move healthcare interoperability forward. We’ll probably start with a video hangout with Mario and then expand from there.

Until then, I was struck by something Mario said in our conversation: “Healthcare interoperability is not a point in time. You can be interoperable today and then not be tomorrow.

This really resonated with me and no doubt resonates with doctors and hospitals who have an interface with some other medical organization. You know how easy it is for your interface to break. It’s never intentional, but these software are so large and complex that someone will make a change and not realize the impact that change will have across all your connections. As I wrote on Hospital EMR and EHR, API’s are Hard!

Currently we don’t even have a bunch of complex APIs with hundreds of companies connecting to the EHR. We’re lucky if an EHR has a lab interface, ePrescribing, maybe a radiology interface, and maybe a connection to a local hospital. Now imagine the issues that crop up when you’re connecting to hundreds of companies and systems. Mario was right when he told me, “Healthcare thinks we’re dealing with the complex challenges of healthcare interoperability. Healthcare doesn’t know the interoperability challenges that still wait for them and they’re so much more complex than what we’re dealing with today.”

I don’t want to say this as discouragement, but it should encourage us to be really thoughtful about how we handle healthcare interoperability so it can scale up. The title of this post asks a tough question that isn’t being solved by our current one time approach to certification. How do we achieve continuous healthcare interoperability that won’t break on the next upgrade cycle?

I asked Mario why the current EHR certification process hasn’t been able to solve this problem and he said that current EHR certification is more of a one time visual inspection of interoperability. Unfortunately it doesn’t include a single testing platform that really tests an EHR against a specific interoperability standard, let alone ongoing tests to make sure that any changes to the EHR don’t affect future interoperability.

I’ve long chewed on why it is that we can have a “standard” for interoperability, but unfortunately that doesn’t mean that EHR systems can actually interoperate. I’ve heard people tell me that there are flavors of the standard and each organization has a different flavor. I’ve seen this, but what I’ve found is that there are different interpretations of the same standard. When you dig into the details of any standard, you can see how it’s easy for an organization to interpret a standard multiple ways.

In my post API’s are Hard, the article that is linked talks about the written promise and the behavioral promise of an API. The same thing applies to a healthcare interoperability standard. There’s the documented standard (written promise), and then there’s the way the EHR implements the standard (behavioral promise).

In the API world, one company creates the API and so you have one behavioral promise to those who use it. Even with one company, tracking the behavioral promise can be a challenge. In the EHR world, each EHR vendor has implemented interoperability according to their own interpretation of the standard and so there are 300+ behavioral promises that have to be tracked and considered. One from each company and heaven help us if and when a company changes that behavioral promise. It’s impossible to keep up with and explains one reason why healthcare intoperability isn’t a reality today.

What’s the solution? One solution is to create a set of standard test scripts that can be tested against by any EHR vendor on an ongoing basis. This way any EHR vendor can test the interoperability functionality of their application throughout their development cycle. Ideally these test scripts would be offered in an open source manner which would allow multiple contributors to continue to provide feedback and improve the test scripts as errors in the test scripts are found. Yes, it’s just the nature of any standard and testing of that standard that exceptions and errors will be found that need to be addressed and improved.

I mentioned that I was really interested in diving in deeper to healthcare interoperability. I still have a lot more deeper to go, but consider this the first toe dip into the healthcare interoperability waters. I really want to see this problem solved.

Are Client Server EHR Holding Back Healthcare?

Posted on December 19, 2014 I Written By

John Lynn is the Founder of the 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 and 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 number one topic of debate on this blog has definitely been Client Server EHR versus SaaS EHR. There are staunch parties on both sides of this aisle. No doubt both sides have a case to make and we’ll see both in healthcare for a long time to come. Although, I think that long term the SaaS EHR will win out.

As I was thinking about this recently, I realized that while client server EHR can do everything a SaaS EHR can do, it definitely makes a lot of things much harder to accomplish.

It’s much harder to create an API that connects to 2000 client server EHR installs.

It’s much harder to make 2000 client server EHR installs interoperable.

It’s much harder to evaluate data across 2000 client server EHR installs.

I’m sure I could keep going with this list, but you get the point. Even though something is possible, it doesn’t mean that they’re actually going to do it. In fact, if it’s hard to do, then it takes extreme pressure for them to do it.

All of this has me begging the question of whether client server installs are holding back the EHR industry. Up until now, many of the things I mention above haven’t been that important. Going forward I think that all three of the things I mention above are going to be very important.

The good thing is that I see many client server EHR moving to some kind of hosted EHR solution. That solves some of the problems mentioned above. At least if it’s a hosted EHR solution, they can control the environment and more easily implement things like API access and interoperability. That’s much harder in the client server world where if you have 2000 EHR installs, you have 2000 unique setups.

Of course, as soon as a large SaaS EHR has a massive breach, healthcare will go running after the client server EHR. The battle lines are drawn and each side knows each other very well. Although, I think the SaaS EHR have the high ground right now. We’ll see how that continues over time. Client server EHR have done an amazing job battling.

What a Real Open EHR API Should Accomplish

Posted on June 17, 2013 I Written By

John Lynn is the Founder of the 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 and John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

There’s been a lot of talk in the EHR world about APIs and most of the time they talk about it as an open API. The problem is that there’s been a lot of talk about EHR APIs and not a lot of action. Having an open API is more than just giving a couple people access to some really small subset of your EHR. We need truly open EHR APIs that are more than just a nice press release.

A successful EHR API requires two core elements: Access to EHR Data and a User Base.

The first element is the obvious one and the one that everyone focuses on. An API needs to have access to the data in the EHR. This includes accessing that data for display in an outside application. Plus, it requires that an EHR accept data from an outside application. EHR APIs seem to fall short on both of these areas. Most only give you access to some really small portion of the EHR data. Even fewer let you write any sort of data to the EHR.

If you don’t give an outside application the ability to access the EHR data and write data to the EHR, there are very few applications you can build on top of it. Is it any wonder that the third party EHR developer community isn’t doing more things with EHR software? If they had these two things, EHR vendors would be amazed at what they’d build. I love Jonathan Bush’s idea of “every surface area” of athenahealth being available in an API. If he achieves this vision, third party developers will flock to that EHR and enhance it in ways that would have never been possible for athenahealth to do on their own.

The second piece is just as important to an API. EHR API developers need to get access to your existing EHR user base. This doesn’t mean you have to give them a list of all your clients. It does mean you need to feature the work of these third party developers to your existing user base. This can be in your application, in an email list, at your user conference, etc.

Think about the message you’re sending to your developer community and your existing user base when you do this. The developer community wants to build even more functionality into your product. Your EHR users get more value out of your EHR application thanks to the development efforts of an outside party. Plus, ambitious EHR users can even create their own functionality using the EHR API.

I can’t wait for the day that EHR vendors fully embrace the idea of a third party EHR API. There are so many outside companies that would benefit from an EHR API, but the EHR vendor will benefit just as much. Plus, the real winners will be the EHR users and patients who get the functionality they’ve been wanting from their EHR that the EHR vendor couldn’t deliver.

Rip & Replace EHR, 3rd Party EHR Connections, and EHR Advice from a Physician

Posted on December 23, 2012 I Written By

John Lynn is the Founder of the 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 and 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 not good for morale, finances, or patient care. Although, it might be better than being stuck with an EHR that is worse for morale, finances and patient care. It’s not an easy decision to switch EHR, but sometimes it’s necessary. Although, this is an almost impossible decision for a hospital. See this post about the “Wrong EHR” conundrum.

I’m not sure how much of this twitter thread will embed. If it doesn’t, then here’s a link to see the full thread. I hope that we can continue to raise the call for more open systems and access to EHR by third party software! Which EHR will set themselves apart in this regard?

Great advice for every doctor when it comes to EMR. It’s a hard shift for many, but I expect Dr. Noah won’t have any issues with this advice.

EMR Add-On’s that Provide Physician Benefit

Posted on November 21, 2012 I Written By

John Lynn is the Founder of the 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 and 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 the companies I met in New York City at the Digital Health Conference was MedCPU. I had a great time talking with the effervescent Founder and President, Sonia Ben-Yehuda and the Founder and CEO, Eyal Ephrat, MD. MedCPU is part of the inaugural New York Digital Health Accelerator class. Plus, they’ve created a pretty interesting concept and way to simplify their message down to a single button that analyzes both free text notes and structured data to check for compliance to best practice guidelines or for deviations from expected care.

The idea of a single button that does all the work is a decent one. Sure, real time analysis is good as well, but EHR software isn’t there yet and won’t be for a while to come. Very few EHR seem to be offering real time meaningful use compliance checking. Forget about real time clinical compliance checking.

What I found even more interesting was something that MedCPU told me when they were describing their product. Dr. Ephrat told me that one hospital was using the services MedCPU provides as the benefit that doctors will receive for using EHR. I find this concept quite interesting. I won’t belabor the point that EHR is the database of healthcare, but it’s amazing to consider that a third party application could provide enough benefit to be the reason why doctors want an EHR.

Many EHR vendors realize this is true. That’s why many are trying to offer API (application interfaces) which will allow third party vendors to interact and integrate with their EHR. I wonder what apps can be created by third parties that would really take EHR software to the next level. A thriving third party eco-system of developers can be much more powerful than trying to do all the innovation in house.

Do you know of other EHR add-ons that provide the real benefits physicians want out of an EHR? I’d love to hear of ones you think fit that test.

EHR Is the Database of Healthcare

Posted on March 1, 2012 I Written By

John Lynn is the Founder of the 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 and 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 regularly writing and thinking for the past few months about something I’ve branded as the “Smart EMR.” Basically, the EMR of the future won’t be a repository of documents and information like before. Instead, doctors will have an expectation that the EMR is smart and can do something valuable with all the health information that’s stored in the EMR. I love this subject. I should put together a presentation on it and start touring it around the country, but I digress.

While at HIMSS I had the pleasure of talking with Sean Benson, VP of Innovation at Wolters Kluwer Health. In our discussion, he said something that hit me like a ton of bricks. He suggested that EHR software is the database of healthcare. The implication being that EHR software is good at collecting healthcare data and storing that data. What they’re not good at doing is actually providing the smart layer that goes on top of that data.

I’m sure that many who know about Wolters Kluwer Health’s (WKH) software offerings might see Sean’s view as bias since WKH, as best I can tell, wants to be the smart layer that goes on top of EHR software. In fact, they showed me some really interesting technology they have for processing all the medical information out there into a really digestible format, but that’s a post for another day. Their interests and clinical decision support software aside, the idea of the EHR software being the database of healthcare seemed to resonate with me.

I’ve often described EHR software to date as a big billing engine. Some EHR are trying to break that mold, but that’s a hard mold to break since a big billing engine is what the market has asked them to create (for the most part). With that in mind, it’s certainly hard for an EHR software to develop a true Smart EHR platform.

I can see in my mind’s eye a product development team going into the EHR vendor executives office and pitching some amazingly smart and effective EHR software for improving patient care. The cynical me then sees the EHR vendor executive saying, “We can’t monetize that.” or a related “That won’t sell more EHR.” The sad thing is that the executive is probably right…at least today. The market hasn’t started demanding a Smart EHR and improved patient care. I’m hopeful that the new ACO model will help to shift that focus, but it’s still too early to tell if that will provide the impetus for change.

Another part of me hopes that a true entrepreneur will come along and build an EHR that provides such a stark contrast in how it provides patient care that doctors won’t be able to resist using it. Something impactful like the stethoscope, that if a doctor isn’t using it patients won’t go to that doctor. However, this line of thinking seems to push the concept of EHRs being the database of healthcare and not the All in One Smart EHR.

If I’m an entrepreneur with the vision of transforming patient care through smart use of EHR data, why would I want to build an EHR from the ground up when there are a number of very large EHR vendors that have APIs that allow me to build upon their data? If the data’s already been collected, then I’m likely to focus all of my energy creating innovative solutions with that data, not creating the mechanism to collect the data.

What’s a database? Tools to collect data, store data and then retrieve data. What’s an EHR today? Mechanisms to collect health data, store the data and then retrieve the data.

Ok, that’s a bit of an over simplification, but the analogy is there. You can see why so many EHR vendors are trying to become “the platform” of healthcare. Turns out that being the repository of data that everyone else builds cool stuff on top of is very valuable. However, building that platform requires a very different culture and focus than building Smart EHR solutions.

This is why I’m sure many EHR vendors will try to develop some Smart EHR solutions, but in the end EHR will be the Database of Healthcare that other Smart EHR applications connect into. I don’t think that’s a bad thing at all.

Interview with SRSsoft EMR CEO Evan Steele

Posted on October 1, 2009 I Written By

John Lynn is the Founder of the 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 and 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 finding what SRSsoft and in particular their CEO, Evan Steele has been saying about the ARRA EHR stimulus money on the SRSsoft blog called EMR Straight Talk really interesting. They’re an EMR company that I think has taken a different approach to marketing their EMR software. So, I thought it would be interesting to interview Evan on a number of relevant topics related to his EMR and the ARRA stimulus money.

Let me know if you like the following interview and I’ll think about doing more of them.

Describe what you define a hybrid EMR is.

Hybrid EMR satisfies the demands of high performance physicians by providing process efficiency. This benefit is delivered through click minimization, ergonomic design, product flexibility and a non-proprietary, open software platform. The hybrid EMR is not exam note-centric, and therefore spares physicians the onerous data entry requirements associated with traditional EMRs.

Can you describe 3 features and how it’s done in a hybrid EMR versus a traditional EMR?
*Generating a ePrescription with only two clicks
*Reviewing a message, viewing the attached document (like a lab or a radiology report) and signing the document with one click.
*Generating a fully templated exam note from anywhere within the software with three clicks.

Will SRSsoft be participating in the ARRA EMR stimulus money program?

It all comes down to the meaningful use requirements – although, after 3 rounds of meaningful use discussions, the requirements are likely not to change significantly.  As listed in the most current “Meaningful Use” Matrix, they are quite onerous for physicians. The cost associated with reduced productivity that a high-volume, high-performance physician would incur by entering the data to meet the meaningful use requirements dwarfs the incentives being offered and the relatively small penalties which starting six years from now (in 2015).

How come I don’t see a CCHIT certified badge on your website?

CCHIT reached the apex of onerous requirements when it released its 2009 certification criteria which contained nearly 500 items. Since its formation in 2004, CCHIT has layered on more and more criteria each year, and vendors have been on a wild goose chase to program those requirements.  Most of these feature requirements are not used or valued by busy physicians. SRS made a conscious decision not to follow the herd and, instead focuses on features that busy physicians need to make their practices efficient so that they can manage their costs and take better care of patients.  The result is a highly ergonomic, usable EMR that actually meets the needs of high-performance physicians.  Sales have skyrocketed.

Interestingly, the new certification will be an HHS badge and not a CCHIT badge and there will be multiple certifying bodies. In addition, the HHS certification criteria will be only those features that are required to meet the meaningful use requirements.  CCHIT actually eviscerated their almost 500 requirements and announced that 88 requirements will be needed to meet meaningful use guidelines.  I feel sorry for the scores of companies that programmed hundreds of complex features only to find that they were unnecessary (all the while not focusing on what physicians actually want).  I also feel sorry for the physicians that paid for those unnecessarily complex products.

Listening to the voice of the physician is a winning strategy and always will be.

How did the HIT Policy Committee react to your “Voice of the Physician” petition?

Lynn Scheps, our Vice President of Government Affairs, went to Washington to present the “Voice of the Physician Petition” to the HIT Policy Committee in person, because we felt it was so important that the decision-makers understand how private-practice, community-based physicians view the expectations being placed on them. The government’s goal of widespread EHR adoption cannot be accomplished without buy-in from the physicians themselves, and the fact that a relatively small company like SRS could generate such a sizeable response in a short time, with minimal outreach efforts, indicates the deep level of concern among physicians. The “Voice of the Physician” petition was signed by SRS clients and non-clients alike, and over 150 of them feel so strongly that they took the time to submit additional comments.

As the petition was presented to the Committee, a number of members were observed browsing through the comments. I can only hope that all of the members take at least the amount of time to read them as the physicians took to write them. I think they will find them very insightful.

Is the government wasting their $19 billion in EMR stimulus money?

The government actually set aside $36 billion, anticipating $17 billion in costs savings from EMR adoption, so the net cost would be $19.2 billion if all goes as planned.
They won’t be spending it if doctors choose not to participate or if they are not able to meet the onerous meaningful use requirements (similar to their experience with the PQRI program.) In the latter case—a likely scenario—in which high-performance, high-volume physicians purchase the required software but are unsuccessful, the doctors will have wasted their money and the EMR vendor coffers will have been filled.

You claim increased productivity using SRSsoft.  Where does the productivity come from? Have you had any practices that haven’t had an increase in productivity?

It’s such a luxury to wake up in the morning, come to work and have 18 programmers who can carry out the vision of focusing purely on what physicians need to make them more productive. Productivity stems from automating processes and organizing information. The fewer clicks and less mouse movement it takes to store and access information, the better the result. Our mantra for the past 12 years is “DO NOT SLOW PHYSICIANS DOWN.”  We found that by automating the myriad of repetitive, labor intensive processes found in every medical office, massive productivity increases result every time. It’s just like any other business process improvement software that replaces antiquated paper workflows. It’s a big win if software directly addresses process improvement while positively impacting a company’s executives (in this case, the physicians). Employees become more productive and the executives benefit from having key critical information at their fingertips.

There is a huge difference when a company is not shackled by someone else’s vision (e.g., the government, certification bodies, etc.) of how technology should be applied in a medical practice.  Plain and simple: physicians know what they want for their practices and know what works, non-physician bureaucrats do not.

Every EMR company will claim that they focus on process and workflow improvement in medical practices. Not true! Just count the clicks required for simple, repetitive tasks and it becomes crystal clear what happens when companies cater to non-physician stakeholders. Any company can slap together a lab management module, an ePrescribing module, a messaging and tasking module, or a forms module, but it takes tremendous focus and dedication to integrate it tightly with the core software, make it intuitive to use and make it ‘fly’ in a medical practice. Clicks are the biggest source of lost productivity for physicians using EMR. Most private practicing physicians’ income is tied to productivity, so time is money. Therefore, every click costs money.

If EMR vendors focused 100% of their resources on usability, click-reduction and module integration rather than on hundreds of pie-in-the-sky features dreamed up by bureaucrats, adoption would flourish.

What are your thoughts on open source and open APIs in EMR software and how does your OpenPath technology fit into it?

SRS is a strong proponent of open architecture software.  At SRS, we have built the web right into the core parts of the software so anyone can customize it. They don’t have to rely on SRS to customize the software for them. SRS has many clients that have talented, tech-savvy employees who have used our Software Development Kit (SDK) to customize their SRS in amazing ways.

SRS spent a great deal of time developing its OpenPath™ technology so clients aren’t beholden to us for customizations. Many other vendors do just the opposite and require that clients go through them for customizations. It’s analogous to buying a house and then a few years later, when you want to add a new room, you find that you are handcuffed because you have to go to the builder for the addition and accept his design, his pricing and his timing. If SRS were the builder, we would be happy to build the addition, but you would also be free to choose your own builder, your own design and negotiate pricing and timing. That level of client control is sorely lacking in the EMR industry. For example, we have many prospective clients that have a strong desire to switch from an antiquated, traditional point-and-click EMR to SRS and they are petrified to ask the legacy vendor for assistance in moving the data from their system to ours. Over the short term, this is good for the legacy vendor, but it puts the medical practices’ long-term IT plans in jeopardy – they feel like the legacy vendor has put them in a straightjacket.  With the SRS OpenPath™ SDK, our clients have a document with our database schema clearly outlined so as to facilitate customizing our software or having the option to migrate to another software package should they want to at any point in the future.

What other customizations have been done by end users using your OpenPath™ technology?

SRS and its clients have created a myriad of customizations that leverage our OpenPath™ technology. Here are some examples:
*Using the SRS software development kit (SDK), a 100 provider primary care group completely rewrote their Clinical Summary web page that resides on the SRS desktop. In addition to a detailed summary of a patient’s key clinical information, the new Clinical Summary includes custom alerts and information fetched from their practice management software database (e.g., balance, alerts when balance is past due, etc.).
*A solo practicing ophthalmologist had SRS rewrite the Clinical Summary to match, perfectly, his thought process when reviewing clinical information before an exam.
*A 52 provider multi-specialty group had SRS customize their Clinical Summary so that with one click, they log the date and time a dictation was completed. They also created a custom transcription exception report that flags all transcriptions that have not been received within a certain timeframe.
*A 20 provider orthopaedic group also leveraged the SRS SDK to self-create a “PowerTab” that pulls up a fully integrated web page (right inside SRS) where the physician orders prescriptions for the patient which is then sent to the in-house drug dispensary.

What do you see happening in the future with EMR software?  What’s going to happen and what’s likely to happen?

Physicians are going to get hurt when they are “incented” to buy systems without being fully aware of what will be required and the lost productivity that they will incur. This will lead to non-use, and the consideration and purchase of more usable alternative solutions in the future. This is exactly what we are seeing in the marketplace today with legacy point-and-click EMRs.

Is EMR and HIPAA part of your daily reading?  If not, why not?  Lol

Of course, I love the writing and commentary!