Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

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

Posted on July 17, 2015 I Written By

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

A number of electronic health record vendors now grant access to EHR data to programmers at user sites through an application programming interface (API). Hospitals and ambulatory practices are making great use of APIs to extract data on patients and analyze it to improve care (or at least their bottom lines–it’s good for marketing to patients as well as protecting them from adverse medical events).

Far fewer EHRs allow totally new applications to be built by outsiders, suitable for sale or free distribution to health care providers. To find out more about how this can be jump-started, I talked recently to Chip Ach at athenahealth, whose outspoken CEO Jonathan Bush has committed to dealing with health care in new ways. (I reviewed Bush’s book, Where Does It Hurt?,in another article.) Chip Ach is senior architect for athenahealth’s More Disruption Please (MDP) program.

MDP is building an open, API-based ecosystem on athenahealth’s cloud-based platform for entrepreneurs to connect, collaborate, and scale more efficiently in health care. athenahealth allows both established and start-up health IT companies to sign up as partners, creating a large marketplace of innovative, third-party health care solutions. Applications solve such problems as scheduling, speeding up payments, and increasing engagement with patients.

The value of a third-party market
Let’s step back a minute to look at why both vendors and health care providers would want a marketplace for companies to write apps based on their EHR data. Start with the obscurity of the data itself: very few health care providers can find out from their EHRs which patients are frequent ER visitors or which surgeons have consistently better outcomes–data that could trigger critical interventions. Even fewer EHRs provide information to patients, and the patient portals that some providers have made available usually offer extremely limited views.

Second, most EHRs have poor interfaces, a gawkiness that becomes especially evident on the tablets and cell phones that are just as popular among clinicians as the general population. A healthy competition and atmosphere of experimentation among interface developers will greatly improve EHR usability.

Clinicians are just too diverse for one vendor to take into account all their needs. More often than now, clinicians report a drop in productivity after the introduction of EHRs, even after the users get acclimated. If an agile development process could create unique and customizable interfaces, doctors and nurses could go back to focusing on patients.

Finally, unanticipated uses for patient data can emerge from an open marketplace. The use of analytics and clinical decision support could skyrocket.

athenahealth management decided several years ago that the health care system needs a radical change toward generating and accepting new solutions to its pain points. Calling this a “Health Care Internet,” they see it as a place for health care providers to compare and “shop” for nearly any product or service they might want or need, whether it be data management, digital check-in, self-pay, mobile charge capture, or transcription. MDP and the athenahealth Marketplace are their contributions to change.

Steps toward athenahealth’s Marketplace
It takes a special program like MDP to draw developers to a platform, particularly in health care where so many developers are deterred by the field’s complexity and issues of liability. In keeping with the company vision to straighten out the operation of the health care system, athenahealth embraced an open platform, adhering to industry standards such as HL7 and investigating the publication of open APIs.

At the same time, their programmers were modularizing a rather monolithic code to reap the productivity benefits that this would offer. Modularization facilitated the design of APIs to connect one module with another. After announcing a few open APIs and seeing the program catch on, the MDP team asked itself: why not make all their modules available to outside programmers, including those that were previously considered internal?

Early in the program, they found a company eager to develop an appointment scheduling application, and worked closely with them to make it possible. Ach’s team promised to get the API working in three months, which was quite a tight deadline. None of the team had prior experience doing an open API for a market, and they needed to face a lot of new requirements that openness created–for instance, adding an authentication layer, deciding how to deliver documentation on the APIs, and offering the opportunity for developers to get a feel for using the APIs. They now have a developer’s portal open to those who sign their modest terms and conditions. There is no fee or vetting process.

To speed up delivery of an API, athenahealth developers sought out a management service and chose Mashery to do the job. In the end, after a lot of long workdays, they met their three-month deadline. The partner was so sure they’d miss the deadline that it wasn’t ready to use the API–but it caught up and successfully released the app. Along the way, the MDP team learned some of the range of data that needed to be exposed by their APIs.

Eventually, athenahealth dedicated itself to rigorously modularizing their code with well-defined interfaces between all components–like Amazon.com–and to exposing as many interfaces as they could to partners. Naturally, this was potentially frightening; both managers and programmers have to take a leap of faith. What would design decisions made years ago look like when put out in the light of day? How many changes would they have to make?

According to Ach, developers were not resistant for ego reasons (they didn’t mind showing the architecture to outsiders), but worried about their ability to seamlessly upgrade the API in the future. A lot of decisions had to be made quickly before opening the APIs to third-party developers, who would come to depend on them and assume they would remain unchanged. Ach says the teams have been happy with their choices, although early on, in the effort to keep the process moving forward, they didn’t create all their naming standards and left that to be done later.

So the process went smoothly on the inside–but how did it fare externally? That’s the subject of part 2 of this article.

Could Standard Interfaces for EHR Data Kill the EHR Business?

Posted on May 14, 2014 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 was reading some people’s comments on a LinkedIn group and it sparked this interesting question:

If you can move healthcare data wherever we want it, then will the EHR’s have to change their business model?

I think this is a really important question. I’m sure that some will question whether we’ll be able to ever move healthcare data wherever we want it. I can’t remember the exact stat, but I recently saw that a huge percentage of the granular health data is stored in lab results. We’re already moving lab result data pretty well between systems. The same can be said for eRX. We’ve kind of cracked those nuts and eventually we’ll make the rest of the data available as well.

I think the answer to the question is that EHR vendors will have to change. I’m not sure they’ll have to change their business model per se, but they will have to change. The fact that a healthcare organization could take their healthcare data and go somewhere else will mean that an EHR vendor will have to be much more accountable to the software they produce and release.

I’ve often used the comparison on my blog. It is powered by WordPress and one of the great features of WordPress is that I can export my entire blog into one file and then import it wherever I want. This makes the cost of switching from WordPress to some other blogging platform simple.

While it’s really simple for me to change, I’m fiercely loyal to WordPress. Largely because WordPress has delivered a high quality product that keeps improving in the 9 years I’ve been using it. Just because I can switch products doesn’t mean I will switch.

The same very much applies to EHR software. Plus, there are other costs that won’t be recovered if I switch. For example, training costs and configuration costs. There are certainly plenty of reasons why someone wouldn’t want to switch EHR software even if they could get their data out. In fact, I’d argue that if you’re to the point where you’re willing to go through the hassle of switching EHR software, you should do it. It’s not easy to get that uncomfortable with an EHR software that you want to go through the hassle. Although, I guess a few might be naive to the EHR switching costs.

Long story short, I think standard interfaces for EHR data wouldn’t kill the EHR business, but it would cause it to change and change for the good. I’d welcome such a change. A few EHR vendors wouldn’t, but that actually is just another reason we should make it a reality. It would be the first thing on my list if I were to create a “meaningful certification.”

Are EHR Lab Interfaces Finally A Standard?

Posted on May 1, 2014 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 was getting a demo of an EHR software a couple days ago and they were showing me the results area of the EHR. As I looked at the interface for the lab results it basically assumed there was a lab interface with the EHR. I imagine they have some way to manage scanned lab results for someone who doesn’t have a lab interface with their EHR, but I realized at that moment that lab interfaces are now just a standard with every EHR.

Are any EHR users not doing a lab interface?

I imagine there are some exceptions and some stragglers. I bet there are also quite a few places where the lab won’t interface with the EHR software or vice versa. It’s too bad when this is the case, but it’s understandable when an organization chooses not to do it if the EHR vendor and/or lab is charging them to create the interface.

With those exceptions in mind, I expect that most EHR implementations will have a lab interface. I remember on my first EHR implementation implementing the lab interface was one of the best decisions we made. It was hard work making sure that the lab interface worked properly since we had a custom lab interface done, but once we verified that the interface worked properly it was like manna from heaven.

Sure, lab interfaces can have their own quirks and downtime issues, but those times just remind you how nice it is when the interface does work (which should be most of the time).

I love to think that our EHR’s have gotten to the point where they can basically assume granular lab data. This is a very powerful thing and will become even more powerful over time. I’m sure people can point out plenty of issues with the quality of the lab data. I’d still rather we had data to talk about quality versus wishing we had data at all.

Specialty EHR Speaks that Specialty

Posted on June 19, 2013 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 long been a proponent of the role of specialty specific EHRs. In fact, at one point I suggested that a really great EHR company could be a roll up of the top specialty specific EHRs. I still think this would be an extraordinary company that could really compete with the top EHR vendors out there. For now, I haven’t seen anyone take that strategy.

There are just some really compelling reasons to focus your EHR on a specific specialty. In fact, what you find is that even the EHR vendor that claims to support every medical specialty is usually best fit for one or a couple specific specialties. Just ask for their client list and you’ll have a good idea of which specialty likes their system the most.

I was recently talking with a specialty EHR vendor and they made a good case for why specialists love working with them. The obvious one he didn’t mention was that the EHR functions are tailored to that specialty. Everyone sees and understands this.

What most people don’t think about is when they talk to the support or sales people at that company. This is particularly important with the support people. It’s a very different experience calling an EHR vendor call center that supports every medical specialty from one that supports only your specialty. They understand your specialties unique needs, terminology, and language. Plus, any reference clients they give you are going to be in your specialty so you can compare apples to apples.

Certainly there can be weaknesses in a specialty specific EHR. For example, if you’re in a large multi specialty organization you really can’t go with a specialty specific EHR. It’s just not going to happen. With so many practices being acquired by hospitals, this does put the specialty specific EHR at risk (depending on the specialty).

Another weakness is when you want to connect your EHR to an outside organization. Most of them can handle lab and prescription interfaces without too much pain. However, connecting to a hospital or HIE can often be a challenge or cost you a lot of money to make happen. Certainly the meaningful use interoperability requirements and HL7 standards help some. We’ll see if it’s enough or if the future of healthcare interoperability will need something more. For example, will specialty specific EHR be able to participate in CommonWell if it achieves its goals?

There’s a case to be made on both sides of the specialty specific EHR debate. As with most EHR decisions, you have to choose which things matter most to your clinic.

HealthSpot Full Patient Visit Kiosk at CES

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

For those of you who also read EMR and HIPAA, you know that this week I’ll be attending CES and the Digital Health Summit.

Today I stopped by the convention center and got an early look at the incredible setup that’s going on to make the CES show happen. By all accounts, I expect this to be as big and crazy as any CES show I’ve attended. Plus, I got an early look at the Health Spot kiosk which is stationed in the lobby between the central and north halls of CES. I’m glad I went today, because I’m sure that kiosk is going to be crazy the next 3 days.

With that said, I’d suggest that anyone in healthcare take the chance to stop by the HealthSpot kiosk. HealthSpot is taking on an enormous challenge. They’ve created a kiosk that provides a whole suite of medical tools and an online connection to a remote doctor. It’s a fascinating mix of medical technology to try and make the patient visit a much smoother experience for the patient.
HealthSpot Station
One use case that I found really fascinating is having a HealthSpot kiosk located in a hospital ED. In many cases one hospital ED might have a long line of patients waiting to be seen while their other hospital ED or quick care center across town might be sitting empty. Instead of making the patient wait or get sent across town to be seen, the patients can use the HealthSpot kiosk to be seen by an available doctor in the other hospital’s ED across town. It’s a fascinating use of technology to try and utilize the available medical resources across a health system.

There are a number of other use cases with one of the biggest being in retail pharmacies. Many have already started going to their local pharmacy for shots. It’s not hard to see retail pharmacies supporting some sort of office visit as well. If the price is right and the access to the doctor is more streamlined than your regular office visit, then this could become a common option. Plus, you can imagine that the price will be good since it’s a way for the retail pharmacy to get you as a customer. Once your HealthSpot visit is done, the pharmacy will have your prescription waiting for you before you leave. At least that’s what HealthSpot envisions happening.

Although, that’s really only the beginning of what HealthSpot hopes to achieve. HealthSpot isn’t selling these devices to other organizations. Instead, they still own the HealthSpot kiosks and plan to have a network of HealthSpot kiosks across the nation that are available to patients. In fact, they showed me a mobile app they’re developing that will allow someone to book an appointment with a doctor at a HealthSpot kiosk right from their mobile phone. In many ways it reminded me of how I reserve a RedBox movie from my mobile phone. I choose the movie and then find the nearest RedBox that has that movie. Replace movie with doctor visit and RedBox with HealthSpot and you get the basic idea.

Yes, they do have protocols in the mobile app and the kiosk that are defined by the providers to ensure that the HealthSpot kiosk visits are ones that can be treated through the kiosk interface. For example, I couldn’t book a HealthSpot kiosk visit for chest pain.

It seemed to me that HealthSpot still needed to work on the workflow for office visits that didn’t fit into a HealthSpot kiosk visit. They didn’t have the chest pain option. If I’m really experiencing chest pain, I’m likely to just choose another option if chest pain is not available and just wait until the visit to tell the doctor my real reason for the visit. This seems like an accident waiting to happen. Instead, I think HealthSpot should offer chest pain as an option. Then, if a patient selects it, they get a message to call 911 immediately (or some similar clinical protocol). I expect these types of issues will be worked out as HealthSpot refines the clinical workflows with their beta customers.

One part of HealthSpot that’s hard to describe in a blog post is how the patient kiosk handles the medical devices. First, a medical attendant (similar to an MA or front desk staff I’d assume) is their to assist a patient through the visit as needed. The kiosk has doors that fall open to present various medical devices such as a: Blood Pressure Cuff, Dermascope, Otoscope, Pulse Oximeter, Stethoscope, and Thermometer. Each of the devices is made available to the patient as needed by the doctor who is doing the visit remotely via video for the visit.

This video will also help to demonstrate how the HealthSpot kiosk works:

I’m sure that many are wondering about the cleaning and sanitizing that is provided for the kiosk. After the visit, the medical attendant is provided a check list of items that need to be cleaned, replaced and sanitized. Plus, the kiosk has a UV light that can clean and sanitize the kiosk similar to what is used in surgeries to clean instruments.

Like I said, it’s an experience that’s hard to explain in words. So, stop by the HealthSpot kiosk at CES to see what I mean. I also believe they’ll be at HIMSS in March where you can see it as well.

I’d of course be remiss if I didn’t talk about its connection with EHR software. They don’t plan on having HealthSpot be the full EHR. Instead they plan to integrate HealthSpot data with outside EHR software. Considering how casually they talked about integrating the HealthSpot data into an EHR, I’m pretty sure they haven’t started down that road. Maybe they have some in house expertise that has dealt with the challenge of this before, but I think they’re in for a big surprise as they try to get their HealthSpot data into EHR software. It should be academic, but it certainly is not.

Obviously, there is a lot that goes into the HealthSpot kiosk experience and I’ve only covered a few pieces of it. Like I said, they’ve chosen to take on an enormous challenge. I’ll just point out one other challenge: reimbursement for the visit. I was assured that HealthSpot has talked with all the payers and the payers are looking at the HealthSpot patient visit experience much more like an office visit than a telemedicine visit. We’ll see how that works over time and how the new e-visit laws effect this, but I expect that any changes to e-visit laws will benefit someone like HealthSpot.

101 Tips to Make Your EMR and EHR More Useful – EHR Tips 51-55

Posted on August 30, 2011 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.

Time for the next entry covering Shawn Riley’s list of 101 Tips to Make your EMR and EHR More Useful. I hope you’re enjoying the series.

55 Discover how easy it is to interface to the EMR.
One good indication of how easy an EMR system is to interface is to look at how many companies they interface with. Another is to talk with other users of that EMR that have had to have an interface created with said EMR. As I mentioned in a recent comment response, just because they say they “can” or “could” do an interface doesn’t mean that they actually will. Add interface requirements in your contract if they’re needed. Be sure to include the expenses related to the interface in there as well.

54. Make sure to understand the licensing model
There are a lot of ways for an EHR vendor to make you pay. So, be sure you’re aware of all the expenses related to buying and implementing an EHR. Instead of recounting all the possible EHR costs here, I’m just going to link you to my pretty comprehensive list of unexpected EHR costs. Going through that list will help make sure you know what you’re getting into cost wise. You can be sure the EHR salesperson won’t be giving you this list.

53. Does your product handle billing?
Many people love the integrated billing in an EHR. Some can get away without it, but most people I know prefer some billing component as part of the EHR.

52. How is licensing managed?
While related to #54, I see this EHR tip as understanding when and how they’ll charge for licenses. Do you have to buy a whole group of licenses which you may or may not use or can you add licenses later as you grow your practice? As Shawn suggests in this tip, it’s best if you can do “just in time licensing.”

51. Make certain you know what upgrades for license expansions cost
Understand the costs related to expanding into a new line of service. Do you have all the modules you need? What’s the cost to add new modules? Will your server support that new module?

If you want to see my analysis of the other 101 EMR and EHR tips, I’ll be updating this page with my 101 EMR and EHR tips analysis. So, click on that link to see the other EMR tips.