Processing FHIR Bundles using HAPI

A month or so back, we talked about a project we had to import glucose results into a repository using FHIR. That post was focused on using the transaction search facility to indicate that there was a resource in the bundle that may or may not exist on the server, and giving the search parameters for the server to use to make the determination. The example we looked at was the Patient resource – specifying the identifier value to use as the lookup.

We didn’t really talk about the other aspects of processing a bundle such as this, so let’s see how we can implement this scenario using the HAPI library.

Read more of this post

SMART on FHIR – adding OAuth2

You may recall that a week back we had a look at one of the connectathon scenarios – the SMART scenario.

In this post we’re going to take the work that we had done in the last post, and make it secure using the SMART version of the OAuth2 standard. As always, a primary reason I’m writing it down is so that when I forget what I did to make it work – I’ll have this as a reference to remind me <s>. And a reminder – I’m using the Java based HAPI FHIR client, in a web based application running in a Tomcat servlet engine, with IntelliJ IDEA as my IDE.
Read more of this post

CORS in FHIR

The following is a copy of an email sent to the FHIR list by Peter Bernhardt (and copied with permission). I’ve not read through it in detail, but it’s something that I’m grappling with myself as I prepare for the SMART track in the up-coming Connectathon.

I suspect that it’s something that a lot of folk are going to have ‘fun’ with, so I suggested to Peter that we copy it here so it can be found later!

(btw – all the servers that Peter refers to are described in the spec)

  Read more of this post

Creating examples in FHIR

One of the things that the FHIR project team is particularly keen on is having lots of examples in the spec. People (especially implementers & developers) understand examples more easily than just plain text – and an example helps illustrate what the spec is trying to say.

And the examples in the spec are guaranteed to be correct – they are automatically validated as the spec is generated.

Creating examples of FHIR resources is actually quite easy – all you need are the schema and a validating XML editor (like XML Spy or Oxygen) and you’re good to go (a validating editor will ensure that the example you create is valid according to the schema – which is 90% of the way there).

There’s a couple of ways of doing this – those who are actually building the spec can do it from their local copy of the spec and commit directly to the version control system – but this does require setting up the environment and having commit privileges into the repository, so is not suitable for everyone.

In this post, we’ll assume that we don’t have that, and will create the examples externally. It’s actually quite easy.

Read more of this post

Referral requests in FHIR

In conjunction with the Patient Care workgroup, we’re currently working on the ReferralRequest Resource. You can see a draft here, and the here is the resource request (but do be aware that it is very much a work in progress, and WILL change prior to appearing in the next DSTU).

Referrals are one of the most interesting (and contentious) aspects of the ‘art of medicine’ – particularly in this era of increasing ‘shared care’ where many providers (clinical and other) are going to be involved in a patients care.
Read more of this post

CDA & FHIR

A nice blog and position statement on the relationship between CDA & FHIR. Grahames comment here.

 

SMART on FHIR: Part 1

With the 7th connectathon coming up, we’ve looked at the first scenario (Patient access) in a couple of posts and how we can use a couple of the libraries (.net and java) to make this almost trivial to achieve. (btw you don’t have to use these libraries of course – FHIR by itself uses standard technologies so there are a ton of different ways to do this if you already have the technology to do so, or use a different language).

In this post we’re going to take a look at the 3rd connectathon scenario – SMART on FHIR. There’s a lot of information about what this is trying to achieve (the connectathon site has links) so we won’t repeat that here – the ‘elevator pitch’ is that it establishes standards that enable the development of independent applications that can securely access data in any server supporting those standards – this could be an EHR, EMR, Portal or HIE.

Read more of this post