Canadian Connectathon

March 20, 2015 1 Comment

For those who don’t mind snow (though I’m told that by April 29 – the connectathon date – the snow has mostly gone).

Here’s the link to the registration site.

There doesn’t appear to be a website (yet) though there are details in a PDF that you can get from the organizers I’m sure. The tracks are listed as:

  1. Patient resource client
  2. SMART server or client
  3. Questionnaire
  4. Experimental

cheers…

BTW – Lloyd did offer to arrange for snow if I came, but alas…

Filed under connectathon

SMART on FHIR: Part 1

August 2, 2014 3 Comments

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

Filed under connectathon Tagged with ,

Project Argonaut and FHIR

March 1, 2015 6 Comments

Most readers of this blog will be familiar with Project Argonaut – a project announced last year under the aegis of HL7 but funded by a number of US Vendors & Healthcare Providers to help accelerate the development of FHIR, and also the ‘SMART on FHIR‘ project.

Last week there was an on-line kick-off meeting attended by almost 100 people to describe the scope and purpose of the project, and to invite participation in the next phase. The project team were at pains to emphasise that the purpose of Argonaut is to accelerate the current work – it is not a ‘fork’ of the specification, or in competition with it in any way. All of the outputs remain fully open source – in fact they define it as a ‘code and documentation sprint’ – one that is time based and will finish once the objectives have been achieved (though, to my mind, follow-on projects are likely).

Read more of this post

Filed under Argonaut Tagged with

CORS in FHIR

August 8, 2014 4 Comments

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

Filed under connectathon, OAuth2

Project Argonaut: from Grahame

December 11, 2014 1 Comment

I guess that most readers of this blog are also subscribed to the FHIR list, but in case you’re not – the following email from Grahame was sent last night, so I’ve taken the liberty of reproducing it in full here:

From Grahame Grieve on the FHIR List:

Read more of this post

Filed under Uncategorized

New Zealand FHIR Seminar

June 6, 2014 7 Comments

Yesterday we (HL7 New Zealand) gave a full day presentation on FHIR (and some related standards) to a local audience. We had over 40 people present – which is pretty good for a seminar on Informatics Standards in New Zealand!

And for those who did attend – thank you for giving up your time for this! I do hope you found it useful…

We had a couple of objectives in giving this presentation.

  • Firstly, to educate and raise awareness of the value of FHIR to healthcare Interoperability in New Zealand.
  • Secondly, we are planning some FHIR related sessions at our upcoming HINZ conference at the end of the year, and wanted to encourage people to participate.

I think we succeeded on both counts. The audience was engaged and we had a large number of questions (most of which I could answer <s>) – except towards the end when I was running out of time and had to talk fast! (note to self – must manage time better…). Oh, and thanks to Richard (Blaze server author) for helping when my brain went on hold…

Thinking now about the HINZ conference, what we’d like to do is to have real demonstrations from multiple vendors (and others) showing how FHIR can be used to facilitate access to healthcare information – similar to the example I gave at the seminar where Josh Mandel had organized a SMART demonstration at HIMSS this year.

We’re thinking of a ‘showcase’ of applications showing how FHIR can support an ecosystem of information exchange, and we’ll provide support to participants over the rest of the year in the lead-up.

We’re planning on establishing a set of sample services (Patient/Provider lookup, XDS style Document Registry, Document Store, Clinical data, Profile registry and the like, which will be supplied by the Orion Health Blaze server). This will have sample data in it, and we’ll encourage anyone – vendors and individuals – to write applications that use those services.

There will also be a number of existing systems that have shareable data who could expose that as FHIR services – and we’ll be reaching out to them to participate as well.

The idea is to show those holding the purse strings both how FHIR can facilitate interoperability with orders of magnitude less effort than the current alternatives – and also how vendors can work together to achieve that interoperability (which is something that we did when working on the GP2GP project).

And as the purpose is to show functionality, we won’t concern ourselves with security for the moment. All going well, that will be something that we can look at more seriously when we deploy real applications next year.  FHIR does have recommendations for security, but implementing it does raise the bar for participation considerably, so that can be the next step.

I may be overly optimistic – but, nothing ventured…

Talking to people between the presentations, there are a few vendors who are interested in participating, which is great – and we’ve got the rest of the year to recruit others!

So, any New Zealanders (or overseas readers for that matter) who are interested in participating – just click on the ‘Contact’ button at the top of the blog and send me a message. We’re looking for anyone interested – client or server, desktop or mobile, and any scenario that has value to clinicians or patients.

As promised, I’ve uploaded the presentations to slideshare, and the links follow. And, although mentioned in the presentations, I’d like to acknowledge and thank Lloyd, Ewout and Grahame as many of the slides were adapted from presentations they have made.

Again – to those who did come along – thank you for your support!

I had intended to provide links to slideshare rather than embedding content – but can’t seem to get that to work. (If anyone does know how, then let me know!). The list of presentations is:

  • Introduction to FHIR (David hay)
  • FHIR for architects and developers (David hay)
  • Archetypes and FHIR (Koray Atalag)
  • Please don’t spell SNOMED with a w (Alastair Kenworthy)
  • Possible uses for FHIR in New Zealand (Peter Jordan)

If you do want to download a presentation then click the ‘share’ icon in the top right hand corner of the presentation. The link is shown in the dialog that is presented. Copy and paste it into a browser which will show the presentation in slideshare. You can download it from there.

Sorry about that…

Introduction to FHIR (David hay)

FHIR for architects and developers (David hay)

Archetypes and FHIR (Koray Atalag)

Please don’t spell SNOMED with a w (Alastair Kenworthy)

Possible uses for FHIR in New Zealand (Peter Jordan)

Filed under Uncategorized

Using the mailbox endpoint for Immunization Decision Support

May 16, 2014 Leave a comment

One of the great things about attending a FHIR connectathon is that you get to meet smart people who are doing interesting things with FHIR.

At the recent connectathon in phoenix, I saw some work that Richard Ettema of AEGIS  had done with an Immunization forecasting application (these are the same guys helping out with the HL7 conformance testing pilot).

The idea is that there is an immunization Decision Support service (in this case supplied by Nathan Bunker http://tchforecasttester.org/  ) that can take as input  patient demographics  (it only needs their Gender & Date of Birth) and immunizations that they have already received, and returns a list of the immunizations that they are overdue for – and ones that are due in the future.

Now, this application resonated with me for a couple of reasons.

In a previous life I was a PMS (Practice Management System / EMR) vendor, and I recall than one of the hardest things I had to do was to cope with changes to an immunization protocol. It’s just plain hard dealing with children who are part way through a programme to figure out what ‘catch-up’ vaccines they should receive – and when – plus the new ones they need. I remember at the time thinking ‘there must be a better way than everyone doing the same thing’. I also worried about getting it wrong. What if I made a mistake and children got the wrong immunizations? Who would know?

The second reason was that this is a use of the mailbox endpoint in FHIR – and I simply hadn’t picked up on the value of using a real-time messaging paradigm in this way. The mailbox endpoint takes a bundle with a MessageHeader (or Composition) as the first resource, and whatever resources are required for the particular business process. In the case of a message, the MessageHeader resource has an ‘event’ property that indicates the event that caused the message to be created (and by implication/agreement what the server is expected to do with the message). The server performs whatever processing is appropriate and returns a bundle with the response – in this case a collection of ImmunizationRecommendation resources.

Now, I admit that in many cases there does need to be an agreement between sender and server about what the server responsibility for particular event codes in (this is called ‘trading partner agreements’ in the spec) – though I’m sure that the existing v2 event codes and their meanings will apply –  but this does seem to be a neat way of implementing task orientated services within the standard spec.

I ‘borrowed’ these images from the presentation that Richard gave at the WGM (sorry about the image quality – they are screen grabs).

This one shows the overall principle – using FHIR as a common interface to potentially different Immunization DSS engines

Screen Shot 2014-05-16 at 8.37.16 am

The next image shows a couple of implementation architectures. The top image using a ‘proxy’ to interface between FHIR and the DSS engine, and the bottom being where the DSS engine implements the FHIR interface directly (both were demoed at the WGM).

Screen Shot 2014-05-16 at 8.38.13 am

 

So go check out the demo – it’s all on-line at  http://wildfhir.aegis.net/fhirgui

Click the “Mailbox” tab, and select “TCH Forecaster” as the FHIR provider (Nathan Bunker’s forecaster service.)

All forecasts assume the current date for the basis of the results returned.  You need to enter the patient demographics (gender and Date Of Birth) at a minimum.  You can then enter up to three (3) immunizations and the date they were administered. (in reality you’d get this from the PMS of course).

Now click the ‘Forecast’ button next to the provider dropdown.

After a short delay, the results are displayed in the tab panel below. The nicest display is the ‘Display Results’ tab that is most useful for a practitioner – the other tabs show the details of the FHIR response from the DSS service, which is what a PMS vendor would use for internal workflow, displays within the product etc.

And please be nice – this sample is supplied as an example service to the community – it’s not a hardened, production level implementation with sophisticated UI, so you could break it I’m sure if you’re that way inclined (and I’d rather you weren’t reading this blog if you are)…

Thanks Richard and AEGIS!

 

Filed under Uncategorized

Processing FHIR Bundles using HAPI

August 18, 2014 7 Comments

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

Filed under Code Tagged with ,

FHIR and OAuth2

June 17, 2014 4 Comments

I’ve mentioned before that one of the reasons I started this blog was to document for myself things I find out about FHIR so that when I forget them, I know where to go and look to find them…

Thus far I’ve focussed on the FHIR standard itself, but one thing that has become increasingly significant are some of the aspects of security – notably Identity, Authentication, Authorization and Audit. Here at Orion Health, we’re building a FHIR interface to support the uploading of glucose results from a patient device and so these are issues we need to address right now. A perfect opportunity for a post!

First let’s agree on some definitions.

  • Identity (in the IT sense) are specific attributes of an entity that identify that entity – such as name, gender, date of birth etc. Note that a single person may have multiple identities – for example I might keep separate identities for LinkedIn and my Bank even though there’s only one of me.
  • Authentication is when we ‘prove’ to some system that the Identity accessing it is who they claim to be. Generally the system will have some piece (or pieces) of information that can be used to make this assertion. For example a username and password is a common way of doing this (though increasingly insecure).
  • Authorization is about specifying and controlling access to certain types of resource. For example, that to access clinical data a user needs to be in the role of a clinician.
  • Audit is where you keep a track of what has been done in the system, about and by whom. In FHIR this is represented by the SecurityEvent resource, which is modelled on the IHE ATNA profile.

And these are all inter-dependant. For example in order to perform authorization you need to have first authenticated the identity of the person wanting to access the particular data and create an audit record when they actually do something which will link to the identity and possibly the authenticator. (I’m well aware that these are very incomplete definitions – but enough for us to move forwards).

Now, FHIR quite explicitly is not a security protocol, and for very good reason as this is really hard to do properly – and there are other groups who do this stuff and produce the required standards. It does provide ‘hooks’ where security-related considerations can be applied (e.g. tags for privacy) and some resources that are useful (such as SecurityEvent and Provenance), and when used over HTTP/S can take advantage of standards like TLS (Transport Layer Security), OAuth2 and OpenID Connect – and it is these latter two that we’re going to focus on in this series of posts.

OAuth2 is a framework that allows an application to access a users data on another server, without that application needing to have a copy of the users credentials on that system.

For example, suppose you write a simple web based application to allow a patient to access their data from a FHIR server. Here’s how your architecture might look:

oauth-1

The user is interacting with pages in their browser which have been served up by the application over the Internet. The application is server side code that is retrieving (and possibly updating) information from the FHIR server – let’s say that’s the users weight observations over time.

Now, the user will have logged into the application (maybe using a username and password), but how does the FHIR server know that it’s OK to deliver up the results for that patient?

One way would be for the user to have an account on the FHIR server, and for the Application to store those credentials and pass them across to the FHIR server when it makes the request. There are a number of problems with this approach.

  • The application now has a copy of the users credentials in it’s store thus increasing the possibility of loss to an attacker. (Weakest links in a chain and all that stuff)
  • What happens when another FHIR server needs to be accessed? Either the user has the same account details on all servers (unlikely), or the application now needs to store multiple sets of credentials for the user.
  • What happens if the user no longer wants the application to be able to access their data? The application has their account details – the user will need to change those account details on all of the FHIR servers holding data about them.
  • Every application and every server will need to store copies of every users credentials – this is going to become a real mess as applications are enabled and disabled, credential details change, and as new FHIR servers are brought into the mix. And the risk of exposure rises significantly…

OAuth2 approaches this problem by separating the role of Authentication & Authorizing, from the role of supplying information (or other services).

oauth-2 (1)

As you can see in the diagram above, there is now a separate component – the Authorization Server. It’s this component alone that holds the users credentials – the other components (the application and the FHIR server) trust the Authorization Server to identify the user and indicate if (and what) data about them can be released to the calling application. (Oh, and note that the components have specific names on OAuth2).

Commonly, the Authorization Server will be some trusted system where the user already has an account – such as Google or Amazon, but can be a separate component – or even functionality of the FHIR server.

At a high level it works something like this.

OAuth2sequencediagram

  1. The user (via their browser) makes a request to the Application (client) and the application needs to get some information from the FHIR server (Resource Server). The Application sends a ‘browser redirect’ back to the users browser, which causes the users browser to make a login request to the Authorization Server.
  2. The Authorization Server delivers a login page to the user.
  3. The user completes the login information, and agrees that the application can access their data (and can also give permission at quite a granular level for the type of information they are prepared to allow access to).
  4. They submit the page back to the Authorization Server.
  5. The Authorization Server validates the login details
  6. The Authorization Server sends another browser redirect back to the users browser, which causes it to navigate to a special endpoint on the application. The redirect contains an ‘authentication code’ that gives the users permissions to access their data.
  7. The users browser is re-directed to a callback end-point hosted by the application. The application:
    1. Calls the Authorization Server with the authentication code it was supplied (plus some other data), and the Authorization Server returns an Access Token (and a Refresh token – we’ll talk about that in a minute).
    2. The Application makes the FHIR query to the Resource Server (the FHIR Server), including the access token in the request (usually the Authorization header).
    3. The Resource Server confirms that the Access token is legitimate, fulfils the request and returns the FHIR data to the application.
    4. The application constructs the page and returns it to the users browser.

 

Some notes:

  • This is a high level summary of the process only, and there are many details omitted. Refer to the spec for details but – as we’ll talk about in a moment – you’ll almost always use a library to implement OAuth2.
  • The Resource Server that requires OAuth2 authorization is commonly referred to as ‘OAuth2 protected’.
  • The mechanism by which the Resource Server (the FHIR server) validates the Access Token is up to the implementer, and there are a number of options:
    • If the Authorization Server component is actually part of the FHIR server, then it could do it directly.
    • The FHIR server could make a separate call to the Authorization Server to confirm it
    • The Authorization Server could sign the Access Token, proving to the FHIR server that it is legitimate.
  • When the Authorization Server returns the Access Token, it also returns a separate token – the Refresh Token, which the application saves locally. The Access Token generally has limited life span – often an hour, and when it expires, the application can use the Refresh Token (which has a much longer lifetime) to get another Access Token. The reason for this complexity is that it allows the Authorization Server to revoke the Refresh Token, which will stop the application from being able to get more Access Tokens and prevent it from accessing the FHIR server after it’s current Access Token expires. Without this mechanism, the FHIR server would have to check with the Authorization Server every time to see if the Access Token had been revoked.
  • This description is a flow that is called the ‘Code’ request type, and is only applicable when the application is capable of keeping the Refresh Token secret. In this scenario it is able to do so as it is hosted on a server (this is a web application remember). If the application (client) is, say, a desktop application or a mobile application, then it cannot do this (someone could hack the device/computer and get it). In this case there is another flow – the ‘implicit’ flow that is used. We’ll talk about that in the next post.
  • The application needs to be registered with the Authorization Server separately to this flow. During this process (which is one-off) the application receives a code by which it can identify itself to the Authorization Server, and also supplies the applications callback address where the browser will be redirected after the user logs in.
  • The security of OAuth2 absolutely depends on using secure transport mechanisms – which is why Transport Level Security (TLS) such as SSL is absolutely required.
  • In addition, the details of the flow is quite complex (the description above is just a summary – there are lots of other details) and there is a strong recommendation to use one of the open source libraries that are available. There’s a list on the spec page.

Well that’s about enough for now – but there’s much more to talk about. Next time we’ll cover:

  • The Implicit flow which is used by Desktops and Mobiles
  • The OpenID Connect standard – which sits on top of Oauth2 and provides some identity functionality
  • Some thoughts on Architecture – specifically in the New Zealand realm!

And finally – I’m not a security expert – if I’ve made mistakes or if something is unclear then do let me know and I’ll make whatever corrections are required.

Some references:

The OAuth2 Specification

A post on Grahames Blog. This points out some issues with delegating authorization..

A tutorial by Jakob Jenkov

Blue Button

SMART on FHIR

Filed under OAuth2 Tagged with ,

A REST primer – FHIR style – part 1.

October 15, 2013 11 Comments

In this post I’m going to talk a little about REST – REpresentational State Transfer – in the context of FHIR. The FHIR specification goes into some detail about how REST and FHIR work together, so go there for more details.

As mentioned in a previous post, FHIR works across many different interoperability paradigms, but REST is the best established at this point in time – and by far the easiest to use (as you will see). It’s the one used by companies such as google, amazon and twitter to provide access to their services (as well as 37 signals – which was the original inspiration for FHIR).

Despite the complicated sounding name, it’s actually quite simple – in fact, it’s the way the web works. The term REST was first used by a chap called Roy Feilding – one of those uber-smart guys that defined many of the basic web protocols that we take for granted today. In a PhD dissertation, he took some of the basic web concepts, and described an ‘architectural style’ that took advantage of those concepts in an easy to use way. (sounds like the goals of FHIR – right)?

The basics are really quite simple.

  • REST is built on top of the HTTP protocol – the same protocol you use when requesting a web page in your browser. HTTP (short for HyperText Transfer Protocol) is simply a set of rules that both server and client (in this case a browser) use to exchange data over the web. HTTP is a ‘request/response’ protocol – you make a request (which can contain data), the server responds and that’s it.
  • REST thinks in terms of resources, each of which has an identity by which it can be manipulated. This is the URI (Uniform Resource Identifier), and uniquely specifies the location of a resource. It is specific to a particular server.
  • When manipulating resources, there are a fixed number of methods that you can use. The ones that are of particular interest to FHIR include:
    • GET – retrieve a particular resource based on its URI (server location + id). FHIR uses the GET method both to retrieve a single resource, and to perform a search which could potentially return multiple resources.
    • POST – create a new resource at a specified endpoint. In REST the server will assign an id, and the combination of server location and id becomes the URI for that resource.
    • PUT – update an existing resource. The client that is executing the PUT needs to know the URI of the resource (which, in FHIR, means that they know the id of the resource as well as the server where it is stored). In FHIR, this will create a new version of the resource.
    • DELETE – remove a resource. Again the URI must be known. It is recommended (though not mandated) in FHIR that a copy of the resource is maintained, and potentially reachable using a version aware read, and the history by a history request, but a plain GET should not return the resource any more. (It will, however, return a status code telling the user that a resource was deleted – read on!)
    • OPTIONS – this is a ‘special’ method in FHIR, that is directed to the root of the server, and returns a conformance resource that informs the client what the capabilities of the server are. I’ll write about this some other time – it’s actually quite useful, though not necessary to know for normal operation.
  • When a server responds to an HTTP REST request, it processes the request according to the method and its internal business logic, and then returns a response to the client. The response has a number of parts to it:
    • The body of the response is what the client is requesting from the server – generally in response to a GET request. Most of the other methods do not return a response. (Note: in the current version of the spec they actually do – but that will be removed soon).
    • The server always returns a status code – which informs the client what the outcome of the request was – did it succeed, or did it fail – with some further details about the nature of the outcome. The status code is a number, which has a well defined meaning within the HTTP protocol. FHIR defines an operationOutcome resource, which the server can use to give the client detailed information about any failure.
    • Both the request and the response can contain headers. These provide extra information about the request or response to assist the server or client to properly process the transaction. Examples include:
      • Both request and response use the Content-type header to tell the other party whether a resource is in xml or json format.
      • A client will use the Accept header to tell the server what format (xml/json) it would prefer to get back when making a GET (though the server is not obligated to honor this)
      • The server will use the Location header to tell the client the URI of a newly created resource
      • And so on.

    Well, that’s enough background – lets actually do something in FHIR. Let’s get a patient resource from one of the on line FHIR test servers.

    Paste the following command (which is actually a URI) into your browser:

    What this does is to instruct your browser to make a GET request to the specified URI, and display the results in your browser. You should see an XML version of the Patient resource that has the id of 4165431. Simple – eh?

    http://fhirtest.uhn.ca/baseDstu3/Patient/4165431

    Dissecting the instruction a bit:

    • HTTP:// – specified the HTTP protocol
    • fhirtest.uhn.ca/baseDstu3/ – the endpoint on the Public HAPI server that responds to FHIR requests
    • Patient/ – specified that the operation was to be on the Patient resource
    • 4665431 – specified the patient with the id of 4665431.

    A couple of notes:

    • I needed to know what the Id was. It was fairly safe in this case because the public HAPI server is a test server with some fixed resources, and unless someone else deletes that resource it should be available (try another number if that happens). You could use this technique to retrieve any type of resource from any FHIR server – provided that you knew the Id – and passed any security mechanisms.
    • The only thing you can do through the browser (at least this way) is to issue GET requests.
    • For better results (and to use the other verbs) use a REST client like POSTMan
    • I haven’t talked at all about security.

    In the next post I’m going to delve into REST a bit further – how to search for resources if you don’t know the id, how to change existing ones or create new one. And, if there is time, how to do queries across resources – e.g. all the conditions associated with a specific patient.

    BTW – if the link above doesn’t work, then try    http://fhirtest.uhn.ca/baseDstu3/Patient.  What you’ll get is a collection of Patients rather than a single one. 

Filed under Uncategorized Tagged with

Newer posts →