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!

How Are Ambulatory Practices Going to Compete with Health Systems?

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

We’ve all seen the stories about the explosion of data and the way healthcare is getting more personalized. However, David Chou recently pointed out how the data is one thing, but figuring out the role everyone plays in your healthcare organization is just as important as the data itself. It gets complex quickly as this graphic David shared shows:

This is a great graphic of the healthcare analytics roles and responsibilities that will be needed to make the personalized medicine future a reality. Plus, it will be key to getting a lot of the value out of our past EHR investments. Many hospitals and health systems already have these roles filled or are working to have them filled. We’ve seen this first hand when we see data jobs being posted to our healthcare IT job board.

While this work is extremely exciting and shows a lot of promise, I imagine a graphic like the one above is just completely overwhelming to consider for a small ambulatory practice. Even a large group practice would likely find the above graphic challenging to consider in their relatively small healthcare organization. How can they compete with a large health system with that kind of complexity? Do graphics like the one above just provide one other illustration of why small practices are going to soon be extinct?

I don’t think so and I hope not. However, graphics like the one above do illustrate the tremendous challenges that ambulatory practices face when they don’t have a massive health system behind them. What’s the path forward for smaller practices then?

The first thing to remember is that even though a health system is large, it doesn’t mean it’s going to do things well. In fact, it’s easy to argue how large organizations are much less efficient. It’s not hard to see how a large health system will focus all of their analytics work on the acute care environment and leaves out ambulatory practices. Smaller healthcare organizations are going to have to use this to their advantage.

While it’s unlikely that ambulatory practices will do all of the healthcare analytics work on their own, it is possible for ambulatory practices to tap into third party vendors that do the work for them and hundreds of other ambulatory practices. Smaller healthcare organizations partnering with corporate and entrepreneurial vendors is going to be the best way for these healthcare organizations to compete with the large health system. In fact, it’s a huge opportunity for them to show why patients should visit their practice instead of the large health system.

One thing that’s holding these efforts back is EHR vendors’ decision to close the doors to outside vendors. There are a few EHR vendor exceptions and areas where every EHR vendor is more open (ie. labs, pharmacy, etc), but it won’t be enough going forward. My friend Jeremy Coleman recently described why in this series of tweets:

I don’t see any healthcare future where centralization will survive. Sure, it will put up a good fight for a while, but the number and variety of applications that are coming out in healthcare are going to be so varied and dramatically important for doctors to incorporate into the care they provide that EHR vendors won’t have a choice but to create APIs that facilitate all of these applications.

An EHR vendor that embraces this approach is going to be essential for every ambulatory practice. Eventually, ambulatory practices will be stuck with the need to switch EHR systems or sell to the health system (which generally means switching EHR systems too). However, an ambulatory EHR that provides an open ecosystem for the latest and greatest in health IT will allow ambulatory practices to thrive even against the much larger health systems.

Open Standards Advance in Health Care Through the Appeal of FHIR and SMART

Posted on October 13, 2014 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site ( 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 poor state of interoperability between EHRs–target of fulminations and curses from health care activists over the years–is starting to grind its way forward. Dr. Kenneth Mandl, a leader of the SMART Platform and professor at the Boston Children’s Hospital Informatics Program, found that out when his team, including lead architect Josh Mandel, went to HIMSS this year to support Cerner’s implementation of his standard, and discovered three other vendors running it.

That’s the beauty of open source and standards. Put them out there and anyone can use them without a by-your-leave. Standards can diffuse in ways the original developers never anticipated.

A bit of background. The SMART platform, which I covered a few years ago, was developed by Mandl’s team at Harvard Medical School and Children’s Hospital to solve the festering problem of inaccessibility in EHRs and other health care software. SMART fulfilled the long-time vision of open source advocates to provide a common platform for every vendor that chose to support it, and that would allow third-party developers to create useful applications.

Without a standard, third-party developers were in limbo. They had to write special code to support each EHR they want to run on. Worse still, they may have to ask the EHR vendor for permission to connect. This has been stunting the market for apps expanding the use of patient data by clinicians as well as the patients themselves.

SMART’s prospects have been energized by the creation of a modern interoperability resource called FHIR. It breaks with the traditional health care standards by being lean, extendible in controllable ways, and in tune with modern development standards such as REST and JSON.

It helps that SMART was supported by funds from the ONC, and that FHIR was adopted by the leading health care standards group, HL7. HL7’s backing of FHIR in particular lent these standards authority among the vendor and health care provider community. Now the chocolate and peanut butter favored by health IT advocates have come together in the SMART on FHIR project, which I wrote about earlier this year.

Mandl explains that SMART allows innovators to get access to the point of care. As more organizations and products adopt the SMART on FHIR, API, a SMART app written once will run anywhere.

Vendors have been coming to FHIR meetings and expressing approval in the abstract for these standards. But it was still a pleasant surprise for Mandl to hear of SMART implementations demo’d at HIMSS by Intermountain, Hewlett-Packard, and Harris as well as Cerner.

The SMART project has just released guidlines for health care providers who want to issue RFPs soliciting vendors for SMART implementations. This will help ensure that providers get what they ask and pay for: an API that reliably runs any app written for SMART.

It’s wise to be cautious and very specific when soliciting products based on standards. The notion of “openness” is often misunderstood and taken to places it wasn’t meant to go. In health care, one major vendor can trumpet its “openness” while picking and choosing which vendors to allow use of its API, and charging money for every document transferred.

The slipperiness of the “open” concept is not limited to health IT. For years, Microsoft promulgated an “open source” initiative while keeping to the old proprietary practices of exerting patent rights and restricting who had access to code. Currently they have made great progress and are a major contributor to Linux and other projects, including tools used with their HealthVault PHR.

Google, too, although a major supporter of open source projects, plays games with its Android platform. The code is nominally under an open license–and is being exploited by numerous embedded systems developers that way–but is developed in anything but an open manner at Google, and is hedged by so many requirements that it’s hard to release a product with the Android moniker unless one partners closely with Google.

After talking to Mandl, I had a phone interview with Stan Huff, Chief Informatics Officer for Intermountain. Huff is an expert in interoperability and active in HL7. About a year ago he led an effort at Intermountain to improve interoperability. The motivation was not some ethereal vision of openness but the realization that Intermountain couldn’t do everything it needed to be competitive on its own–it would have to seek out the contributions of outsiders.

When Intermountain partnered with Cerner, senior management had by that time received a good education in the value of a standard API. Cerner was also committed to it, luckily, and the two companies collaborated on FHIR and SMART. Cerner’s task was to wrap their services in a FHIR-compliant API and to make sure to use standard technology, such as in codes for lab data.

Intermountain also participated in launching a not-for-profit corporation, the Healthcare Services Platform Consortium, that promotes SMART-on-FHIR and other standards. A lot of vendors have joined up, and Huff encourages other vendors to give up their fears that standardization is a catheter siphoning away business and to try the consortium out.

Intermountain currently is offering several applications that run in web browsers (and therefore should be widely usable on different platforms). Although currently in the prototype stage, the applications should be available later this year. Besides an application developed by Intermountain to monitor hemolytic disease among neonates and suggest paths for doctors to take, they support several demonstration apps produced by the SMART project, including a growth chart app, a blood pressure management app, and a cardiovascular app.

Huff reports that apps are easy to build on SMART. In at least one case, it took just two weeks for the coding.

Attendees at HIMSS were very excited about Intermountain’s support for SMART. The health care providers want more flexible and innovative software with good user interfaces, and see SMART providing that. Many vendors look to replicate what Intermountain has done (although some hold back). Understanding that progress is possible can empower doctors and advocates to call for more.

Practice Vine Enables API for Any EHR

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

I was recently introduced to a new company that is working to take traditional client server based EMR software and connecting them to the cloud. The company is called PracticeVine. I think they have an interesting approach to consider.

While many people love to proclaim the future of cloud based EHR, they underestimate the install base of client server based EMR and some of the advantages of a locally hosted EHR. PracticeVine provides a way for client server based EMR to have some cloud based functionality. Their first implementation is a Patient Forms tool for MacPractice EHR.

When you dig into a PracticeVine implementation, you see that if they’re successful, they’re essentially building a powerful API to an EHR software. With MacPractice they started with forms, but over time I could see PracticeVine building out other features which continue to expand the API like functionality that they need to provide cloud based functionality to client server based EHR software. Could PracticeVine become the ultimate EHR API provider?

Obviously, that’s an ambitious goal and far more than what they’re trying to chew off now. However, it’s really interesting to think about what the ultimate EHR API provider would look like. It’s even more exciting to think about what could be possible if we had deep EHR APIs for all the EHR vendors.

The real challenge that PracticeVine faces is resistance from EHR vendors to let them build this out. It’s not like most EHR vendors are even thinking about an API for their EHR. In fact, most of them can’t see past meaningful use stage 2. I’ll be interested to see where PracticeVine takes this. I really hope they’re successful at getting EHR vendors to interface with them.