Blog Posts Business Management Health IT

Patient Portals versus APIs for Patient Access to Healthcare Information

Blog: KWKeirstead's Blog

Back in November 2015, Health Data Management, published an article called “Challenges Ahead for Portals”.

This is an interesting article because it indirectly describes the effect of too much regulatory involvement in healthcare services delivery.


In the article, Raj Ratwani, scientific director of MedStar Health’s National Center for Human Factors in Healthcare states that patient portals “.. do not present information in a manner that is understandable and useful”.

It’s likely that views regarding the inappropriateness of existing patient portals led to inclusion in the Stage 3 objective for Patient Electronic Access to address the patient needs to “ view their health information, download their health information, transmit their health information to a third party and access their health information through an API.

My point is it’s fine for regulatory agencies to set incentive objectives but not to narrowly specify the means by which such objectives should be met.

Whether a patient gains assess to PHI via a portal or via an API should be a decision best left to stakeholders who have a close connection to patients.

Under this scenario, if a vendor implements a portal that does not address patient needs, the patients will move to another healthcare service provider who either has a better portal implementation or an API that works well for such patients and the provider supposedly, would pick up on this and move to a different vendor.

Accordingly, portal/API selection should be the responsibility of vendors first, then healthcare service providers, picking solutions they feel their patients will find acceptable.

Vendor -> Provider Selection-> Patient Needs

The way things go when there is too much regulation is regulators impose demands on vendors, healthcare service providers then select solutions they feel will address internal/patient needs and the patients then decide whether the “solutions” meet their needs.   I doubt very much whether the regulators consulted patients before reaching the conclusion that patients would be best served via APIs.

See how far away the patient is from the regulators under this alternative scenario.

Regulatory Authority -> Vendor -> Restricted Solution Selection for Providers-> Patient Needs

The reality is you can deliver patient healthcare information to patients using a number of technologies, one of which is an API at a Patient Portal (i.e. a hybrid solution). This avoids the need for the patient to download and install an API on the various devices they may want to use to access their healthcare information. All they need with a portal/API is to type in a URL and enter a user name/password.

The danger with the phraseology in the Stage 3 Final Rule is that software systems that do not have a traditional API could be categorized as not meeting the Stage 3 Final Rule.

Filed under: FIXING HEALTHCARE, Interconnectivity, Interoperability, Meaningful Use, Uncategorized Tagged: EHR, healthcare, meaningful use, medical software, practice management software

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples