Blue Button+: A guide for EMR/EHR/PHR ISV’s (Part 2)

We had previously discussed the methodology for Bluebutton+ to access data in the EMR/EHR/PHR system in the first part of our discussion. In the previous post we had skipped the registration process, which we will be covering in this part.

The goal of Meaningful Use aims to provide consolidated information for patients and healthcare providers. This will require healthcare providers to receive information from multiple sources to provide these consolidated reports.  BlueButton+ allows for either push or pull of information between various systems.

Registration

Firstly, looking at the registration process. Registration is a complex process, consisting of 4 parts. Each application to be accessed by Bluebuton+ will be required to be registered prior to usage.  The registration process is defined in terms of RFC6749 (OAuth 2.0).

The 4 steps involved are:

1. Optionally, the client or developer is issued an initial access token giving access to the client registration endpoint. The method by which the initial access token is issued to the client or developer is out of scope of OAuth2.0.
2. Optionally, the client or developer is issued a software statement for use with the client registration endpoint. The method by which the software statement is issued to the client or developer is out of scope for OAuth 2.0.
3. The client or developer calls the client registration endpoint with its desired registration metadata, optionally including the initial access token from (A) if required by the authorization server.
4. The authorization server registers the client and returns the client’s registered metadata, a client identifier that is unique at the server, a set of client credentials such as a client secret if applicable for this client, and possibly other values.

A diagrammatic representation of the registration looks like:

Bluebutton+ API

Once an app is registered you are going to need some sort of naming convention. For example you tie yourself to Twitter for identification purposes, as a Twitter API.

Then we can implement a simple transaction: “When a user is signed in, handle requests to /my/ccda/summary by returning the contents of db/username/summary_ccda.xml, if available. Otherwise, return an HTTP 404 status.”

app.get(‘/my/ccda/summary’, function(req, res, next){

if (!req.user){

res.status(401);

return res.end(“Must log in to view a clinical summary”);

}

var user = asTwitterHandle(req.user.screen_name);

fs.exists(summaryFilePath(user), function( exists ) {

if (!exists){

res.status(404);

return res.end(“No summary available”);

}

res.header(‘Content-type’, ‘application/xml’);

fs.createReadStream(sfile).pipe(res);

})

});

We still have to parse the C-CDA file, which can be through such a program. The information will all be encoded using LOINC codes.  So 3141-9 for weight, 8302-2 for height etc. C-CDA also does not specify which units to use, though it does encode the ones, which have been inputted.

You can Google for standard converters (or write your own) as below:

var unit = {

cm: function(pq){

if(pq.unit == “cm”) return pq.value;

if(pq.unit == “m”) return 100*pq.value;

if(pq.unit == “in”) return 2.54*pq.value;

if(pq.unit == “[in_us]”) return 2.54*pq.value;

if(pq.unit == “[in_i]”) return 2.54*pq.value;

throw “Unrecognized length unit: ” + pq.unit

},

kg: function(pq){

if(pq.unit == “kg”) return pq.value;

if(pq.unit.match(/lb/)) return pq.value / 2.20462;

throw “Unrecognized weight unit: ” + pq.unit

},

any: function(pq){

return pq.value

}

};

Data extraction

With all these in place, you can extract the data required from the C-CDA and manipulate it for the specific requirements.

For example:

var name = bb.data.demographics.name;

p.demographics.name = name.given.join(” “) + ” ” +  name.family;

These will also allow you to pull data smoothly. Alternatively, you can set the system to subscribe to receive pushes from multiple data sources and just maintain a data store on your side.

Receiving pushes seems to be the preferred method in the case of most implementations, and a Blue Button+ setup can be described as below:

What we offer

If you would like any help at implementing this Nalashaa would love to speak with you. We have experience in integration and implementation of various healthcare systems and we understand the nuances, which help us, deliver results faster.