But I can readily point a browser to my favorite sites. In fact, those are pretty easy to find on any of my devices. So what if we made it possible for the provider website to "provision" the third party application that wants to access my data?
If you view source on this website, you'll find the following links in the HTML header.
<link rel="alternate" type="application/atom+xml"
title="Healthcare Standards - Atom"
href="http://motorcycleguy.blogspot.com/feeds/posts/default" />
<link rel="alternate" type="application/rss+xml"
title="Healthcare Standards - RSS"
href="http://motorcycleguy.blogspot.com/feeds/posts/default?alt=rss" />
These are commonly understood by browsers to be the where the atom and RSS feeds for this web site are found. Because of those, browsers are able to automatically identify the feeds, and allow you to subscribe to the site.
[I'll give you just a brief moment to subscribe to this site...]
Every patient portal that wants to support ABBI should have a similarly easy mechanism to point their users to the search URL that the application needs. That way, third party applications can readily be configured by just pointing them to the patient's portal, and they'll automatically configure themselves correctly.
The <link> tag has several attributes:
- rel
- The relationship between the content and the linked URL
- type
- The mime type of the linked URL
- title
- The title of the content associated with this link
- href
- The URL to go to get the linked content
HTML defines a number of standard relationships, including alternate, appendix, bookmark, chapter, contents, copyright, glossary, help, home, index, next, prev, section, start, stylesheet, and subsection; but none of these are really appropriate in any case. So, let's just use ABBI as the value for rel. If the portal has a <link rel='ABBI'>, then an application could know to use that as the endpoint for requests.
<link rel="ABBI" type="application/atom+xml"
title="Automated Blue Button Download"
title="Automated Blue Button Download"
href="URL to atom search feed" />
This same sort of mechanism is widely adopted not just to associate feeds with a web page, but also stylesheets, icons, and a number of other readily accessible resources. We just use this with ABBI to make it easy for applications (and users) to navigate the their data sources.
-- Keith
This same sort of mechanism is widely adopted not just to associate feeds with a web page, but also stylesheets, icons, and a number of other readily accessible resources. We just use this with ABBI to make it easy for applications (and users) to navigate the their data sources.
-- Keith
What about QR codes, or NFC?
ReplyDeleteWhy would you put a QR Code ON a website? You might use it on the card you give the patient. QR codes go from print to the web. From the web, you'd just hit a link, right?
DeleteWhat communication loop are you aiming to close here? Is this about letting apps find ABBI data in a pull scenario?
ReplyDeleteIf I'm looking at this correctly, the apps need /authenticated/ access to the data, which will require some user-directed activity to kick things off. That is: the patient will have to tell the app /something/.
Are you thinking that patients will find it easier to copy/paste a portal URL from their browser's location bar rather than copy/paste an ABBI URL from within a portal page?
Could you spell out your idea in a bit more detail and possibly comment on my assumptions below?
I'd imagine the process would start in one of two places:
1. In the patient-facing ABBI-enabled portal. Here the portal itself might know about some apps, and might offer the patient an ability to add a new one.
2. In a 3rd party app that doesn't yet have access to data. Here, the patient would have to point the app at the correct server explicitly. (Of course the app could know about several common servers in advance, offering a picklist like mint.com does with banks.)
-- but in either case, allowing apps pull access will require the app to have registered an oauth consumer with the ABBI provider (or act anonymously).
I'm dealing with #2, where the patient has an application, but the application doesn't know which of many possible portals they could use to make a request. Sure, they could offer a pick list, but not every portal would be known.
ReplyDeleteBut in this solution to #2, you're still asking the patient to paste *something*, right? That something just happens to be a link to the patient's portal, like:
DeleteMY-PORTAL == http://my-doctor.com/patient-portal/patients/123
... instead of an ABBI link like
MY-ABBI == http://my-doctor.com/patient-portal/patients/123/abbi ?
And your proposal is for a way to derive MY-ABBI from MY-PORTAL?
How would the patient learn what to paste in the first place?
No, my proposal is not to derive, but to simply point. If I happened to have a portal that was hosted somewhere on xyz.org, but I didn't know exactly where on the site, I could just simple point to xyz.org. The ABBI application would then be able to read that page on the site and be able to figure out where to find the API endpoints. They might exist on some other site completely (e.g., abc.com).
DeleteSo your proposal is to embed this link in the top-level HTML content of a domain, and then have the patient know just the domain?
DeleteI'm still not sure why it's easier to inform the patient of the domain than it is inform the patient of her own ABBI URL directly...
You might also be interested in:
Deletehttp://www.rfc-editor.org/rfc/rfc5785.txt
E.g. host a simple JSON manifest at
GET http://my-doctor.com/.well-known/abbi
{
'landing-page': 'http://ui.my-doctor.com/',
'abbi-server': 'http://abbi-api.my-docgtor.com/'
}
That works great, and has a similar effect. The main problem that I'm trying to solve is that URLs are long, not very memorable, and challenging to type in. I want an easy way for patients to configure their app to use their portal.
Delete