Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

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="" />
<link rel="alternate" type="application/rss+xml"
  title="Healthcare Standards - RSS" 
  href="" />

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:
The relationship between the content and the linked URL
The mime type of the linked URL
The title of the content associated with this link
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