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.
http://www.healthdatamanagement.com/news/challenges-ahead-for-portals-51630-1.html
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
You must be logged in to post a comment.
