Pages

▼

Tuesday, September 25, 2012

Provisioning an Application to automatically find ABBI's BlueButton

One of the challenges for ABBI is how the user (the patient) will be able to find how to access their data from an application.  We could send them an e-mail they'd need to copy into their application, but that can often be challenging.  My big fingers are challenged typing in on my iPhone, and depending on what account you send the URL to, it might not be one that is accessible on my iPhone.

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
Type is a mime type, and so cannot be used to identify ABBI content distinctly from other sorts of content.  After all, what I'm proposing is simply application/atom+xml, the same as what I use for my blog above.  Title is supposed to be the human readable title of the content.  We want that to be customizable by portals, and so would not want to fix that value.  An href is where we need to go.  We could standardize the URL (and in fact, in my specifications, I have), to some degree.  So it could be uniquely identifiable as the ABBI endpoint.  But I don't like that answer.

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" 
  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
at

9 comments:

  1. John MoehrkeOctober 25, 2012 at 11:05 AM

    What about QR codes, or NFC?

    ReplyDelete
    Replies
    1. Keith W. BooneOctober 25, 2012 at 11:11 AM

      Why 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?

      Delete
  2. UnknownOctober 25, 2012 at 3:48 PM

    What communication loop are you aiming to close here? Is this about letting apps find ABBI data in a pull scenario?

    If 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).

    ReplyDelete
  3. Keith W. BooneOctober 25, 2012 at 3:57 PM

    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.

    ReplyDelete
    Replies
    1. UnknownOctober 25, 2012 at 4:03 PM

      But 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:
      MY-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?

      Delete
    2. Keith W. BooneOctober 25, 2012 at 4:12 PM

      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).

      Delete
    3. UnknownOctober 25, 2012 at 4:18 PM

      So 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?

      I'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...

      Delete
    4. UnknownOctober 25, 2012 at 4:35 PM

      You might also be interested in:
      http://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/'
      }

      Delete
    5. Keith W. BooneOctober 25, 2012 at 4:52 PM

      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