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!

E-Patient Update: Time To Share EMR Data With Apps

Posted on November 18, 2016 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Like most Americans, I’ve used many a health-related app, in categories including vitals tracking, weight control, sleep management, medication management and exercise tracking. While I’ve continued to use a few, I’ve dropped most after a few uses because they didn’t contribute anything to my life.

Now, those of you who are reading this might assume that I lost interest in the apps because they were poorly designed. I admit that this was true in some cases. But in others, I’ve ceased to use the apps because the data they collect and display hasn’t been terribly useful, as most of it lives in a vacuum. Sure, I might be able to create line graph of my heart rate or pulse ox level, but that’s mildly interesting at best. (I doubt physicians would find it terribly interesting either.)

That being said, I believe there is a way healthcare organizations can make the app experience more useful. I’d argue that hospitals and clinics, as well as other organizations caring for patients, need to connect with major app developers and synch their data with those platforms. If done right, the addition of outside data would enrich the patient experience dramatically, and hopefully, provide more targeted feedback that would help shape their health behaviors.

How it would work

How would this work? Here’s an example from my own life, as an e-patient who digitally manages a handful of chronic, sometimes-complex conditions.

I have tested a handful of medication management apps, whose interfaces were quite different but whose goals seem to be quite similar — the primary one being to track the date and time each medicine on my regimen was taken. In each case, I could access my med compliance history rather easily, but had no information on what results my level of compliance might have accomplished.

However, if I could have overlaid those compliance results with changes in my med regimen, changes in my vital signs and changes in my lab values, I have a better picture of how all of my health efforts fit together. Such a picture would be far more likely to prompt changes in my health behavior than uncontextualized data points based on my self-report alone.

I should mention that I know of at least one medication management app developer (the inspiration for this essay) which hopes to accomplish just this result already, and is hard at work enriching its platform to make such integration possible. In other words, developers may not need much convincing to come on board.

The benefits of added data

“Yes,” I hear you saying, “but why should I share my proprietary data?” The answer is fairly simple; in the world of value-based reimbursement, you need patients to get and stay well, and helping them better manage their health fits this goal.

Admittedly, achieving this level of synchronization between apps and provider data won’t be simple. However, my guess is that it would be easier for app developers to import, say, pharmacy or EMR data than the other way around. After all, app platforms aren’t at the center of nearly as many overlapping data systems as a health organization or even a clinic. While they might not be starting from zero, they have less bridges to build.

And once providers have synchronized key data with app developers, they might be able to forge long-term partnerships in which each side learned from the exchange. After all, I’d submit that few app developers would turn up the chance to make their data more valuable — at least if they have bigger goals than displaying a few dots on a smartphone screen.

I realize that for many providers, doing this might be a tall order, as they can’t lose their focus on cultivating their own data. But as a patient, I’d welcome working with any provider that wanted to give this a try. I think it would be a real win-win.

OpenUMA: New Privacy Tools for Health Care Data

Posted on August 10, 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 ( 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 health care field, becoming more computer-savvy, is starting to take advantage of conveniences and flexibilities that were developed over the past decade for the Web and mobile platforms. A couple weeks ago, a new open source project was announced to increase options for offering data over the Internet with proper controls–options with particular relevance for patient control over health data.

The User-Managed Access (UMA) standard supports privacy through a combination of encryption and network protocols that have a thirty-year history. UMA reached a stable release, 1.0 in April of this year. A number of implementations are being developed, some of them open source.

Before I try to navigate the complexities of privacy protocols and standards, let’s look at a few use cases (currently still hypothetical) for UMA:

  • A parent wants to show the child’s school records from the doctor’s office just long enough for the school nurse to verify that the child has received the necessary vaccinations.

  • A traveler taking a temporary job in a foreign city wants to grant a local clinic access to the health records stored by her primary care physician for the six months during which the job lasts.

The open source implementation I’ll highlight in this article is OpenUMA from a company named ForgeRock. ForgeRock specializes in identity management online and creates a number of open source projects that can be found on their web page. They are also a leading participant in the non-profit Kantara Initiative, where they helped develop UMA as part of the UMA Developer Resources Work Group.

The advantage of open source libraries and tools for UMA is that the standard involves many different pieces of software run by different parts of the system: anyone with data to share, and anyone who wants access to it. The technology is not aimed at any one field, but health IT experts are among its greatest enthusiasts.

The fundamental technology behind UMA is OAuth, a well-tested means of authorizing people on web sites. When you want to leave a comment on a news article and see a button that says, “Log in using Facebook” or some other popular site, OAuth is in use.

OAuth is an enabling technology, by which I mean that it opens up huge possibilities for more complex and feature-rich tools to be built on top. It provides hooks for such tools through its notion of profiles–new standards that anyone can create to work with it. UMA is one such profile.

What UMA contributes over and above OAuth was described to me by Eve Maler, a leading member of the UMA working group who wrote their work up in the specification I cited earlier, and who currently works for ForgeRock. OAuth lets you manage different services for yourself. When you run an app that posts to Twitter on your behalf, or log in to a new site through your Facebook account, OAuth lets your account on one service do something for your account on another service.

UMA, in contrast, lets you grant access to other people. It’s not your account at a doctor’s office that is accessing data, but the doctor himself.

UMA can take on some nitty-gritty real-life situations that are hard to handle with OAuth alone. OAuth provides a single yes/no decision: is a person authorized or not? It’s UMA that can handle the wide variety of conditions that affect whether you want information released. These vary from field to field, but the conditions of time and credentials mentioned earlier are important examples in health care. I covered one project using UMA in an earlier article.

With OAuth, you can grant access to an account and then revoke it later (with some technical dexterity). But UMA allows you to build a time limit into the original access. Of course, the recipient does not lose the data to which you granted access, but when the time expires he cannot return to get new data.

UMA also allows you to define resource sets to segment data. You could put vaccinations in a resource set that you share with others, withholding other kinds of data.

OpenUMA contains two crucial elements of a UMA implementation:

The authorization server

This server accepts a list of restrictions from the site holding the data and the credentials submitted by the person requesting access to the data. The server is a very generic function: any UMA request can use any authorization server, and the server can run anywhere. Theoretically, you could run your own. But it would be more practical for a site that hosts data–Microsoft HealthVault, for instance, or some general cloud provider–to run an authorization server. In any case, the site publicizes a URL where it can be contacted by people with data or people requesting data.

The resource server

These submit requests to the authorization server from applications and servers that hold people’s data. The resource server handles the complex interactions with the authorization server so that application developers can focus on their core business.

Instead of the OpenUMA resource server, apps can link in libraries that provide the same functions. These libraries are being developed by the Kantara Initiative.

So before we can safely share and withhold data, what’s missing?

The UMA standard doesn’t offer any way to specify a condition, such as “Release my data only this week.” This gap is filled by policy languages, which standards groups will have to develop and code up in a compatible manner. A few exist already.

Maler points out that developers could also benefit from tools for editing and testing code, along with other supporting software that projects build up over time. The UMA resource working group is still at the beginning of their efforts, but we can look forward to a time when fine-grained patient control over access to data becomes as simple as using any of the other RESTful APIs that have filled the programmer’s toolbox.

Rep. Phil Gingrey Comes After Healthcare Interoperability and Epic in House Subcommittee

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

On July 17th, the House Energy and Commerce Committee’s subcommittee on Communications and Technology and Health (that’s a mouthful) held a hearing which you can see summarized here. Brought into question were the billions of dollars that have been spent on EHR without requiring that the EHR systems be interoperable.

In the meeting Rep. Phil Gingrey offered this comment, “It may be time for this committee to take a closer look at the practices of vendor companies in this space given the possibility that fraud may be perpetrated against the American taxpayer.”

At least Rep. Gingrey is a former physician, but I think he went way too far when he used the word fraud. I don’t think the fact that many EHR vendors don’t want to share their healthcare data is fraud. I imagine Rep. Gingrey would agree if he dug into the situation as well. However, it is worth discussing if the government should be spending billions of dollars on EHR software that can’t or in more cases won’t share data. Epic was called out specifically since their users have been paid such a huge portion of the EHR incentive money and Epic is notorious for not wanting to share data with other EHR even if Judy likes to claim otherwise.

The other discussion I’ve seen coming out related to this is the idea of de-certifying EHR vendors who don’t share data. I’m not sure the legality of this since the EHR certification went through the rule making process. Although, I imagine Congress could pass something to change what’s required with EHR certification. I’ve suggested that making interoperability the focus of EHR certification and the EHR incentive money is exactly what should be done. Although, I don’t have faith that the government could make the EHR Certification meaningful and so I’d rather see it gone. Just attach the money to what you want done.

I have wondered if a third party might be the right way to get vendors on board with EHR data sharing. I’d avoid the term certification, but some sort of tool that reports and promotes those EHR vendors who share data would be really valuable. It’s a tricky tight rope to walk though with a challenging business model until you build your credibility.

Tom Giannulli, CMIO at Kareo, offers an additional insight, “The problem of data isolationism is that it’s practiced by both the vendor and the enterprise. Both need to have clear incentives and disincentives to promote sharing.” It’s a great point. The EHR vendors aren’t the only problem when it comes to not sharing health data. The healthcare organizations themselves have been part of the problem as well. Although, I see that starting to change. If they don’t change, it seems the government’s ready to step in and make them change.

EHR Question and Answer Video: EMR Data Sharing

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

Yesterday I started testing out a new idea where I’d film some original EMR and EHR videos where I answer questions about healthcare IT and EMR that people have sent to me. I’ll post the first video here and possibly another one this weekend. Then, I’ll probably start posting the videos on my new EMR and EHR video website. Although, I may do some updates with links to the latest videos that are posted.

It’s a low budget production as you can imagine. I also was streaming it live on the internet, so you’ll see me look down a number of times to check how many were viewing it live. Those things aside, hopefully you’ll find the content of the video interesting and useful.

This first video tries to answer the question:
Does the EMR allow data sharing with the patient’s PHR and/or Social Net account(s)?

As always, I’m interested to hear your thoughts on the subject as well. Was there anything I missed? Was I wrong about anything? What else is important about EMR data sharing? Should we be able to share our EMR data with social networks like Facebook, Twitter, etc?

Also, if you have other questions you’d like me to answer in a future video, be sure to leave a comment or let me know on the contact us page.