Category Archives: FHIR

Outcomes from Atlanta HL7 Meeting for FHIR

Posted on May 11, 2013 by
5 Comments

Well, I’m now nearly home from the long week that is the HL7 Working Group meeting. It now goes for 7 long days from Saturday morning through to Friday afternoon. This meeting was held in Atlanta – I’d like to make some comment about Atlanta but the only time I got out of the hotel was to go to Dave Shaver’s Corepoint Party (thanks Dave).

This post is a summary of the progress that occurred at the meeting for FHIR.

General

Two years ago, I conceived of something that has grown into FHIR. Since then, I’ve watched the ripples of our work expand – from just a narrow community in HL7, to include all of HL7 and the wider standards community, and then out into the middleware vendors. Now, the EMR vendors are starting to pay attention. The process is accelerating too – I never expected the EMR vendors to start paying attention to our work until at least after we had completed the DSTU phase (ballot for a “Draft Standard for Trial Use”). And as the ripples spread, the community of people working on FHIR or excited about it grows, and our growth accelerates. This creates it’s own firestorm.

(Oh, and yes, I’m now starting to come to terms with the never-ending FHIR jokes and puns).

Connectathon

For FHIR, this meeting commenced with the 3rd FHIR Connectathon. This Connectathon continued on the linear progress that we’ve been making, with more participants, more structure, and more success. We continue to have people turning up to do a cold start, where they have had their interest ignited, but have done no reading or code prior to the day. As usual, the participants are exchanging resources by the end of the first day.

Other participants have established code bases, and perhaps have attended Connectathons previously, and are honing the breadth of their implementations and working on their conformance.

Each Connectathon, we collect a list of issues – things that are broken in the specification, or where the decisions we’ve made make things harder than they should be. Also, each Connectathon, the list gets shorter and more about the corners of specification, which shows that the Connectathon process is really paying off.

The next Connectathon will (probably) be focused on PHR access to EMRs, and promises to be bigger and better (and some new participants are planning to bring physical devices that talk FHIR to the Connectathon, which should be cool).

Preparation

Our major focus right now is on preparing the specification for ballot. In order to be ready for ballot, there’s a bunch of things that we need to do around ensuring that the basic structures and quality assurance processes are in place that ensure that the resources really are useful. Like all such processes, the depth of detail that goes into this preparation is necessary but not of interest to the implementers. But it’s all going well, I think. And my particular thanks to the 30-40+ people from vendors, governments, consultants, and academics who are now working on the under-appreciated task of bringing the breadth of their experience to bear on the design of the resources.

Right now, out focus is on rounding out the resource definitions by mid-July so we can do quality assurance prior to opening the DSTU ballot in Mid-August.

There’s still some outstanding issues that we haven’t cracked yet. I’ll be making some blog posts on these in the future to solicit input from outside the community.

There’s been a little talk about FHIR having teething difficulties – and certainly there’s lots of heated discussion inside HL7 over design, approach, and so on. I’m not worried about this – these things need to happen and they bring value to the standard (see Establishing Compromise). It’s a dialectic thing.

Security

We made some real progress on the question of what the FHIR specification needs to say about security at this meeting. There’s a draft security page on this now – please look at this and comment.

Note that while the page says that it’s not really HL7′s business to develop the resources to administer the security engine, we’ve had a number of requests to do exactly that – given enough pressure from the users, it might happen, though if it does, we’ll have to find the right group of people to work on that.

Positioning & Marketing

One thing that we’re now going to have to start working on is how to position (and then market) the specification. As the specification has rounded out, it’s become quite fully featured, and a full fledged implementation is now quite a bit of work – not that simple. I’m not really concerned, though, because few systems will need to implement all the features that we’ve defined (this is a classic problem with standards).

But I’m starting to hear people express the belief that maybe FHIR isn’t quite as simple as they thought. Well, it’s never going to be simple – FHIR is going to be a standard for exchanging information about healthcare, not a simple cookbook for REST to be adapted to healthcare applications in a bespoke manner (why do that? there’s already plenty of advice and examples out there). The re-usability of FHIR, and the fact that it grapples with difficult things like patient linking/merging, for instance) means that it’s necessarily more complicated than a simple single application API, but also worth while. Still, I think that some people are thinking it’s more complicated than it is.

Part of the solution to this is to start working on a use-case based view of the specification: given a particular problem, how do I use FHIR to solve it? Some initial work is here. Contributions to this page are welcome. We’ll be doing other things as well, so watch this space. The FHIR Button is coming at you!

Using FHIR outside HL7

One big issue was resolved at this meeting. We’ve been having this running discussion about how to use FHIR outside the scope areas that HL7 plans to cover. I’ve blogged about this before. At this meeting we agreed that people will use the FHIR methodology to define their own resources, whether we want them to or not (and, indeed, we in the core team are all doing that ourselves).

So we’ve agreed that we’re going to define a process for people to do this, and work on enhancing the tooling and the public servers to support this process, and to work on ways to bring this work back towards HL7.

Partnerships

Finally, our partnerships outside HL7 are going well. We’re going to be balloting resources in partnership with DICOM, IHE and the ISO Healthcare Devices Community. There’s still some open process issues around quite how these are going to work, but the actual design is coming along well.

A commonly asked question is whether ONC is going to start using FHIR. ONC have been interested in FHIR from the start, but they are driven by their requirements to deliver working standards in very short time frames. ONC won’t be able to use FHIR in their work until it’s a DSTU, and even then they will have to take things on a case by case basis. Pretty much the same applies to other national programs – some things they need to do will lend themselves to FHIR, and they’re looking hard at what it might become, but you don’t lightly change direction of such a big and expensive ship.

IP Rules & the HL7 community

HL7 is starting to wrestle with a number of difficulties caused by the decision to make it’s IP freely available for implementation. The community is still trying to figure out exactly how free free is, how unencumbered free actually is, and what the consequences are for HL7 structure, revenue and expenditure. Maybe revenue will go up, maybe it will go down – we don’t know yet.

FHIR, on the other hand, remains truly free, open and unencumbered, and will continue to do so. FHIR is already driving new participation at HL7 – people who haven’t been able to take part before (or haven’t been interested). I’d like to think that this will make a significant contribution, but whether it does or not, FHIR is starting to really take off.

Categories: FHIR, HL7

Securing your REST API

Posted on April 22, 2013 by
9 Comments

Over the weekend, I spent several days working on integrating OAuth authentication and authorization into my FHIR server. Really, I’m primarily interested in authentication – if the user authenticates to the server, they get open access. So the functionality I implemented was that I will accept logins from any Facebook or Google user.

Integrating with Google and Facebook was almost ridiculously easy – The only thing that slowed me down was the documentation for the Google call to get a user’s profile details – I needed to provide an Application Key for charging purposes (not applicable at my volume though), and the documentation for the login process didn’t mention that (I found the solution on stack overflow).

But doing this generated some interesting discussion between the FHIR implementers preparing for the upcoming connectathon about the usefulness or otherwise of OAuth as a authentication protocol for a FHIR RESTful API. To illustrate the problem, consider this architecture, which seems like a pretty common architecture for the kind of  FHIR deployments involving OAuth:

Example fhir architecture

 

In this case, the user logs into the healthcare application – which is likely to be either a mobile or a web application, and authenticates to it using OAuth via something like Facebook, Google, etc as the OAuth server. For the user, this is convenient and observationally we know that this is really important. But, then, on their behalf, the application wants to use one or more FHIR services. How does this work? It’s pretty hard to find good information about this on the web, and the standard advice – such as this one here – really just doesn’t address this question well (at least, not that I could find).

As far as I can see, you have several options to handle this case:

  • The FHIR services – which offer the FHIR RESTful API – don’t authenticate the user. They authenticate the healthcare application, and the user is invisible to FHIR service, and vice versa
  • The FHIR services use OAuth themselves. The healthcare application asks the user to log in to each FHIR service provider independently using OAuth. 
  • The FHIR Services provide a custom login which allows the healthcare application to pass the OAuth access_token to the FHIR services – they can use this to authenticate the end-user

I find each of these unsatisfactory for different reasons.

The first option can work just fine, but the user (patient, for example) has no visibility of the data storage, and there’s no really any capacity for the user to share their own data in their own way. Whether that’s good or not depends on the context. If it’s good, then the first option is for you. And so in this case, OAuth is not appropriate on the RESTful server – just some kind of application secret

The second option has the advantage that the user is explicitly aware of the data storage, and manages that directly. They can have multiple data stores, and explicitly grant access to a particular application. That’s a different kind of use case that would work well for a few users, but would simply bamboozle the majority of users, especially those who most need healthcare and to share their data. I think that this would be a problem for the healthcare application offering. But this is the consequence of the RESTful API offering OAuth based authentication. (btw, There’s a supplementary technical problem for a web based healthcare application in this case – at the end of the authentication process, the user will get redirected away from the healthcare application to the RESTful API provider. There’s a variety of options to deal with this, but they all have problems).

The third option works well in practice, but does mean that the FHIR service provider gets the same level of access to the user as the healthcare application – and the healthcare application has to trust the FHIR service provider to impersonate it.

Tim Bray pointed out (thanks!) that there’s a 4th option if you login through Google – as part of the OAuth process, Google returns an OpenID connect JWT token, and rather than sharing the access token, the healthcare application could just pass the id_token to the FHIR Service. The FHIR service could use the id_token to verify the user identity, and that access has been granted to the application by the user. This would mean that the FHIR service has no access to any Google services associated with the user (including getting basic descriptions of the user) – it would need the access token for that. Another problem with this approach is that Facebook doesn’t generate a token like this (or any functional equivalent, so far as I could see anywhere).

Choosing to secure your RESTful api using OAuth isn’t as straightforward as it seems, then.

p.s. My server supports all 3 options from the top list – see the documentation.

 Update: Related Links

Categories: FHIR

FHIR – what is interoperability?

Posted on April 12, 2013 by
12 Comments

Well, FHIR is starting to really make progress. There’s been quite a few blog posts about it recently:

Not everyone is convinced yet, but the proof of this pudding is in the eating, not academic evaluation of the source of the ingredients.

Not only is the full breadth of the specification coming together (http://hl7.org/implement/standards/fhir/resourcelist.htm), the HL7 governance & development processes are settling down, the load on my test server is going up (I can tell, I get the amazon bill!), and implementation experience is growing, with some projects going into production this year.

Which means, yes, prior to the finalization of the specification itself. In fact, that’s always been a feature of the FHIR experience: the advantages of FHIR are sufficiently compelling that projects are choosing to adopt it now, in spite of the fact that it’s not final – it’s already the best option (or is that, the least worst option?). When people talk to me about the features of FHIR that drive this, they consistently mention the following things:

  • Simplicity
  • Current technology (REST, JSON..)
  • The tooling stack that’s part of FHIR
  • Extensibility

The really intriguing item in this list is the tooling stack – one of the things people really like about FHIR is that they can (potentially) leverage the existing approaches, resources, and technology to create functionality of their own in a new space.

That actually presents a challenge to HL7. One of the goals for HL7, which is an essential part of the goals for FHIR, is “Out of the Box” interoperability. It’s a widely shared experience of HL7 implementers – two different products have made different choices about how to implement v2, so when you try to connect them up, they can’t talk to each other. Typically, rectifying this costs >$50,000 all up (including project management, vendor costs, total life cycle etc). So the HL7 community really wants different implementations to simply work together. Note that by “the HL7 community” I am describing one part of it – the part where implementers buy software from vendors to meet their business requirements.

Meeting this goal means locking down FHIR so that only HL7 can publish the engineering constructs, so that everyone can just work together. On top of this, it means good definitions, careful induction of new use cases, etc. To me, this is the classic HL7 context.

But there’s a different group of implementers at the table too. Mostly, these are institutions that perform a substantial amount of in-house development. For these developers, the ability to naturally and seamlessly leverage FHIR in other directions is very much an attraction. The fact that the solutions they develop doing this won’t interoperate with other implementations “out of the box” is completely irrelevant since they’ll never interoperate with them at all anyway.

The problem with this is that we all actually live in a continuum between the two extremes – all implementers have a mix of custom and OTS software. It’s just that the percentages differ between them, and across time as the bespoke vs commodity pendulum swings. There’s a new component to this in FHIR: external public-ish web sites (such as if, e.g. Facebook decided to put up a FHIR server linked to face book accounts for people’s own PHR – it’s not quite public, but it’s certainly not private). These will change the weighting – but not the overall picture.

I think that we are going to have to define some special conformance level. something like “Commodity FHIR”, where out of the box interoperability is an expectation, and an alternative one like “FHIR-leveraged” where interoperability out of the box isn’t assured. Is going to be messy, and it’s going to cause everyone trouble. But this mess isn’t of FHIR’s making – it’s a problem inherent in the real world.

 

Categories: FHIR

Question: FHIR and un-semantic interoperability

Posted on March 12, 2013 by
3 Comments

Question:

 I did not understand the blog post about un-semantic interoperability.  Can you elaborate?  Will FHIR provide any of this un-semantic interoperability?

Answer:

Well, the original post on unsemantic interoperability is just pointing out that many people mis-understand the nature of what semantic interoperability is trying to achieve:

We’ve had semantic interoperability in healthcare since we started having healthcare. Since the beginning of healthcare (by whatever definition you can use), healthcare practitioners have exchanged data using spoken and written words, and the semantic meaning has been clear (well, as clear as it can be given that human knowledge is limited).

So whatever it is that we are doing, it’s not introducing semantic interoperability. In fact, what we are doing is introducing a new player into the mix: computers. And not, in actual fact, computers, but the notion that there is something to be gained by processing healthcare information by persons or devices who don’t properly understand it. So, in fact, what we are actually doing is seeking for unsemantic interoperability.

It’s a matter of perspective. Perhaps, one day, we’ll really be working on true semantic inteoperability. But right now, we can afford to chase a lesser goal, which is exchanging data that can be used usefully in some limited pre-ordained ways.

And FHIR provides lots of this – that’s what it’s good at – getting data that is passably well self-described to be exchanged as easily as possible.

For systems that is really working towards genuine semantic interoperability, FHIR is actually a step backwards (though I’d argue that the easy availability of information that is passably well described is a huge improvement over the non-availability of information that is well described).

Categories: FHIR, Question

Repository Based Exchange

Posted on March 3, 2013 by
22 Comments

Classically, HL7 has divided exchange of information between two applications into 3 different paradigms:

  • Messaging
  • Services
  • Documents

Messaging and services are closely related – you exchange messages between two applications, and the net effect of the messages is that the applications provide services to each other. In “services” mode, messages are still exchanged between the applications, but the way the messages are described is different, and they are described in the context of the overall service (rather than the other way around).

Document based exchange is primarily different by virtue of being looser – the focus is on the content of the messages, and the content is defined in such a way that while it can be used in messages/services, the content is also able to be stored in a database, or exchanged in other less well described forms such as email. (One natural consequence of this is that when you use documents in a service, there’s going to be some duplication between the service and the document).

The FHIR RESTful paradigm introduces a new way of conceptualising exchange between applications: a repository mediated exchange. Although there’s still a service, and messages are still exchanged, they exist in the context of a repository of content. In this paradigm, one of the applications is considered to have a repository of records that describe the content, and the other application can search, retrieve, and potentially update and delete from the repository.

The interesting thing about this exchange paradigm is that there are multiple ways to use it. Let’s take an example, a diagnostic service (i.e. a laboratory) that needs to contribute content to a clinical EHR. There’s a number of ways to use a repository based interface to build this:

  1. Configure the diagnostic service as the repository of diagnostic records. When the clinical EHR wants to access the diagnostic results, it searches the diagnostic service repository
  2. Configure the clinical EHR as the repository of diagnostic records. Whenever the diagnostic service has a new report, it creates a copy in the clinical EHR. The clinical EHR searches it’s own copy of the reports
  3. Use a third party repository; the diagnostic service uploads it’s reports to the repository, and the clinical EHR performs searches on it

Each of these three models works, but provides different pros and cons. Here’s some:

Model Pros Cons
1 No synchronising issues between applications (source is master) Reports not available when diagnostic service down

Diagnostic service needs to collaborate with regard to access control
2 Clinical EHR not dependent on diagnostic service Must ensure synchronisation is error-free
3 Specialised repository can out-perform other systems

More potential for re-use

 Additional cost to install & manage access control

 

Ideally, the institution hosting the exchange should be able to pick between the pros and cons for itself. (i.e. the diagnostic service and clinical EHR will be able to run in either mode depending on configuration, but this has its own costs)

I’ve found that this repository based exchange is one of the hardest things to understand about FHIR for someone who’s used to thinking about exchanging messages between applications. In particular, the notion that either side can act as the repository can be quite obtuse when you are reading the FHIR spec – I’ve still got to figure out how to explain this properly.

Of course, this paradigm isn’t really new, not even in healthcare – XDS is a repository mediated exchange paradigm which can be run in any of the 3 ways described above. #3 is the default around which XDS was designed, but by merging registry and repository, or by using XDR, you can have the other configurations.

Categories: FHIR, HL7, Standards

FHIR Resources and Unicode

Posted on February 9, 2013 by
3 Comments

In the FHIR specification we say that the basic language for resources is unicode:

The XML character set is always Unicode.

Actually, that’s not the right wording – what it should have said is “The character set of a resource is always Unicode”.

Now if the character set is unicode, then any character encoding that is fully mapped to unicode is therefore valid. However, elsewhere in the specification, it says:

FHIR uses UTF-8 for all request and response bodies

This attracted several comments, all along the same lines – why require UTF-8? Well, the logic is fairly simple:

  • content type negotiation doesn’t work very well for character sets
  • while it might be legal to represent a resource in any character encoding mapped to unicode, what would you do if someone asked you to represent a resource in a character set that doesn’t have a mapping for one or more characters in the unicode?
  • Even though it’s possible to convert resources between character sets, what happens to digital signatures?
  • What’s going to happen if systems with different encodings, or with different supported subsets try to interoperate?
  • As for which unicode encodings, why support more than one? and UTF-8 is widely supported, and required by several HL7 Asian affiliates for v2
  • It’s just simpler to say, everyone use UTF-8.

One problem with requiring UTF-8 is that the HTTP default is ISO-8859-1. This means that you have to specify UTF-8 as the character set on all the http requests and responses. But since it’s a parameter of the content type, and you have to specify the content type anyway, I didn’t see that as particularly painful – but it did get comment in the connectathons, because you do have to remember.

Unicode subsets

However if you don’t support unicode natively – which is still a large subset of systems – then the fact that resources are always in UTF-8 presents you with a problem – you have to do something about the unicode issue, even if you are positive that all your trading partners are using pure ASCII. There’s still so many systems that don’t support unicode (the reason for this is because even though the platforms support unicode relatively well, to support it in your application, the entire eco-system – database, UIs, printers, messaging formats, etc all have support unicode, and for many vendors sorting this out simply isn’t feasible in a financial sense).

What I see in practice, is systems that can’t interoperate safely because they thought they were using pure ASCII, but they weren’t. (In fact, it’s not that unusual to see systems that don’t fully operate, let alone interoperate.) So I’d always prefer unicode as the wire format – it makes everyone deal with the issue.

So, we have several comments – why require UTF-8? Why not allow at least ISO-8859-1? Or why not allow any round-trip encoding? What if we require all interfaces to “support” UTF-8 in addition to anything else that they also do? Or maybe we require all servers to support UTF-8 at least?

We’ve discussed this in committee several times, and we’re just not sure what to do here. Seen as an entire eco-system – and I do think FHIR interfaces will be highly interconnected – a simple blanket rule of always UTF-8 is obviously much simpler overall. But it imposes an entry cost on many systems – especially the existing data stores, which are generally older systems – and maybe this isn’t a very good idea?

HHS HIT Standards Committee & Character Set

The situation is somewhat complicated by this (private communication that made it’s way to me):

The HHS HIT Standards Committee was asked how EHR language display should be certified using standards and the recommendation was ISO 8859-15 aka “Latin 9″ which has character support for all the required ISO 639 languages including direct support for the Eastern European languages and transliteration to Latin characters for e.g. cyrillic and mandarin.  This EHR certification requirement is anticipated to raise issues for HL7 standards and HL7 implementers particularly for systems with interfaces to certified EHRS.  

I’ve got to say, I don’t really understand this. If you’re going to recommend something, why not Unicode? The point is, US EHR vendors (which includes all the multinationals) are going to be forced to change towards whatever this committee recommends. But now, instead of migrating to unicode, which is at least a sensible long term option, they’re going to spending their money changing from ISO-8859-1 – which is the default for all the systems I’ve ever looked at personally, to ISO-8859-15. I can only see that as a sideways move, and not a good investment on behalf of the end users. And how that will play in other countries, where ISO-8859-15 is not on the list of supported character sets in national standards?

In terms of FHIR and unicode, I’m not exactly sure what the impact of this is. ISO-8859-15 is fully mapped to unicode, so it probably doesn’t really change the basic question – unicode, or something else that makes subset support explicit? But EHR vendors are going to be important adopters of FHIR, so I think this weighs on the decision.

 

Categories: FHIR, Standards

Standards have no sense of humor

Posted on January 17, 2013 by
No Comments

FHIR is a draft standard that is early in it’s ballot cycle. It’s a reasonable anticipation that it will end up as a ISO standard in the fullness of time. But for now, it’s just a draft standard. Writing a standard is a huge piece of work, and you have find entertainment where you can…. with that in mind, I added a couple of jokes to the specification.

In the roadmap, after describing the general nature of FHIR, I add this line:

Compared to the all the other approaches, FHIR… [-- Obligatory: insert your FHIR FIRE related joke here --].

It’s not as if I won’t have heard the joke before – sometimes my life seems to consist of a continuous stream of people telling me FHIR related puns and jokes. There’s several different pronounciations, each with their own stream of jokes.

The other point is in the RESTful specification, where I added a new HTTP status code. The existing status codes describe the server rejecting an HTTP request for a variety of transport/negotiation/parsing/security failures, but there is no code to say that the request as submitted would violate server business rules – all there is is a general server error. But the case that a client makes a request that would violate business rules on the server is both common and important in FHIR, so it was proposed that we should add an HTTP status code to indicate this status. Since adding a new HTTP status code is a rather involved process, I added a custom code on a temporary basis:

  • 490 Talk to the Hand – the proposed resource violated server business rules.

Well, it turns out that HL7 balloters don’t have a sense of humor – both of these two attracted several negative ballot comments.

Guess I’ll have to find my entertainment somewhere else….

Categories: FHIR, Standards

FHIR Extensions, the 80/20 rule, DICOM and the LONG tail

Posted on January 9, 2013 by
1 Comment

As part of FHIR, we have said that resources will only contain the “core” elements, and those not widely used will be delegated to a robust extension mechanism.

As a rule of thumb, we’ve talked about using an 80/20 rule – elements should be included in a resource if they are catered for / used by 80% of the implementing systems. This rule of thumb has been quite controversial, even just as a rule of thumb, just used as a guide to help decide what is and isn’t out. One of the big question is 80% of what? And that’s not a simple question, with a simple answer, and it’s not meant to, though it’s one reason why FHIR resources need to have a well defined scope, so that it’s less opaque regarding 80% of what. And even then it’s hard, because it’s extremely difficult to get examples of real world exchanges, let alone a good representative collection, by which you can get even rough statistics.

As part of my preparation for the HL7 Phoenix meeting, I’m giving some thought to what a FHIR resource for RESTful access to DICOM images would look like (this is possible future joint work with NEMA). It’s early days – we don’t know what the scope of RESTful resources would be – study, series, image, plane? But as part of my preparative work, I prepared a scatter plot for the frequency of DICOM elements in my set of sample DICOM images (mostly derived from http://support.dcmtk.org/wiki/dicom/images, but also stuff I’ve collected through commercial use in Australia). Note that it’s easier to collect this for DICOM than for HL7 v2 and CDA documents, since it’s easy to pack messages into files and vice versa  (something that I’d like to be true of FHIR, because it really is good for the ecosystem). So we could take this sample set as somewhat illustrative of the situation in health care exchange generally (Note: I have only included data elements in the root of the file, not nested sequences, and the distribution includes manufacturer defined tags as well):

dicom-distribution

It’s really intriguing to see just how long the tail is – only 30 of 900 different DICOM elements I encountered appeared in >80% of the DICOM images, and about 700 of the 900 appeared in <1% of the images. This tail is longer here than it really is for several reasons:

  • it’s a set of DICOM images that cross modalities. One DICOM standard for all modalities, like if you had one HL7 message for all message types (though this set doesn’t include non-image related dicom content such as MPP or structured reports)
  • it’s based on the instances, not the systems. The tail will always be longer for instances, since some things only appear a few times, but are always important when they do (i.e. LMP in an image), so they are supported in all/most systems
  • it’s based on examples not production images (mostly) – though that might cut both ways

Nevertheless, a few of us that looked at this distribution were surprised by how long the tail is even given these caveats.

Note that the modality is an interesting one: a modality such as MRI is <20% of usage, but obviously important. It needs a whole set of custom data elements to properly describe the image. Perhaps, in a FHIR context, that implies that there might be modality specific resources for further image details? These details lie in front of us. Note that this is a common pattern that crops up in other areas too – such as medications, where 99% of medications are off the shelf retail formulations, but a few specific areas of medicine have highly specific and detailed formulation requirements (i.e. chemotherapy).

I present this primarily to demonstrate the length of the tail. These elements and features often occupy a significant portion of the standard – but a casual reader often can’t judge what to ignore or not until after they’ve read and understood the whole thing. So they add to the cost of implementation, even when they aren’t used. We’re trying to keep the long tail down in FHIR, without denying the functionality that they represent.

As for the FHIR Image resource – the table that underlies this graph will be useful for prioritising what to represent in the resource, but is hardly going to be a final determiner.

Top 30

Since people will no doubt be interested, here’s the top 30 root element list (the 100% are the mandatory elements, so that’s not really surprising):

 

0008,0016 100 (Image Properties/SOP Class UID)
0008,0018 100 (Image Properties/SOP Instance UID)
0008,0020 100 (Image Properties/Study Date)
0008,0030 100 (Image Properties/Study Time)
0008,0050 100 (Image Properties/Accession Number)
0008,0060 100 (Image Properties/Modality)
0008,0070 100 (Image Properties/Manufacturer)
0008,0090 100 (Image Properties/Referring Physician’s Name)
0010,0020 100 (Patient Details/Patient ID)
0020,000D 100 (Study Instance Properties/Study Instance UID)
0020,000E 100 (Study Instance Properties/Series Instance UID)
0020,0010 100 (Study Instance Properties/Study ID)
0020,0011 100 (Study Instance Properties/Series Number)
0020,0013 100 (Study Instance Properties/Instance Number)
0010,0010 99 (Patient Details/Patient’s Name)
0010,0030 99 (Patient Details/Patient’s Birth Date)
0010,0040 99 (Patient Details/Patient’s Sex)
0028,0010 85 (Sampling Property/Rows)
0028,0011 85 (Sampling Property/Columns)
0028,0002 84 (Sampling Property/Samples per Pixel)
0028,0004 84 (Sampling Property/Photometric Interpretation)
0028,0100 84 (Sampling Property/Bits Allocated)
0028,0101 84 (Sampling Property/Bits Stored)
0028,0102 84 (Sampling Property/High Bit)
0028,0103 84 (Sampling Property/Pixel Representation)
7FE0,0010 84 (Pixel Data/Pixel Data)
0008,1030 70 (Image Properties/Study Description)
0008,103E 62 (Image Properties/Series Description)
0008,0008 59 (Image Properties/Image Type)
0020,0020 56 (Study Instance Properties/Patient Orientation)
Categories: DICOM, FHIR

Implementing XDS on a FHIR Server

Posted on January 7, 2013 by
No Comments

This is a follow up to an earlier post, Implementing ATNA on a FHIR server, and a preparative post for the XDS-focused FHIR Connectathon to be held this weekend.

For the connectathon, I am providing an XDS.b interface to a FHIR Resource Repository. The server accepts and XDS.b “ProvideAndRegisterDocumentSet” operation, and converts it a set of FHIR resources, and then submits them to the FHIR Repository. It would be possible to support other XDS.b operations, but I don’t have time for this prior to the connectathon.

There’s some conceptual differences between a XDS.b approach, and the FHIR RESTful approach to XDS:

  • The XDS.b interface is very transactional – a focus on “submission sets”, things that are submitted together. On the other hand, the FHIR definitions for XDS are very focused on stable resources – documents, folders, authors, patients. The notion of a submission set is absent in FHIR (though you can submit groups of these resources as a “batch” to a FHIR Repository
  • Security: the FHIR definitions that support XDS functionality do not get involved with security – it is assumed that this comes from elsewhere, using standard functionality such as OAuth.
  • The classic XDS architecture has a document source submitting to a document repository, which notifies a patient registry of the existence of the document, so that document consumers can find it. FHIR handles this differently: registries, which are aggregators of content, subscribe to multiple repositories by using their atom feeds.

To explain the third point further, an XDS eco-system consists of a series of clients and servers that use the following resource types:

  • Patient/Person – patient demographics
  • Agent/Organization – author & provider information etc
  • XdsEntry – the actual index entry for a document
  • XdsFolder – when the document is allocated to a folder
  • SecurityEvent – equivalent of an ATNA record (see Implementing ATNA on a FHIR server)
  • Binary – the resource that actually stores the document itself

In FHIR, the difference between a registry and a Repository is that the repository supports the binary resource, and references from the XdsEntry to the Binary refer to local references on the server, whereas a registry has XdsEntry resources that refer to the content found elsewhere – either Binary Resources on another server, or some other kind of server that serves resources. A registry subscribes to XdsEntry updates, and converts (if necessary) relative references to Binary resources to absolute references. It would also subscribe to the other resource types (Patient, Person, Agent, Organization, XdsFolder)

This means that a server that provides “ProvideAndRegisterDocumentSet” has to take the submission, convert it to a set of resources, and store those resources in a FHIR repository. Documents submitted through the XDS.b interface become visible by watching the XdsEntry atom feed, or by searching the XdsEntry resources on the server. Done carefully, a ProvideAndRegisterDocumentSet can be converted to a FHIR batch in a single operation, which can then be submitted to a FHIR repository as a separate operation – this is called an “XDS 2 FHIR Bridge”.

A test implementation of an XDS 2 FHIR bridge can be found at http://hl7connect.healthintersections.com.au:3098/svc/xds. This accepts XDS ProvideAndRegisterDocumentSet operations. Submitted documents can be seen at http://hl7connect.healthintersections.com.au/svc/fhir/xdsentry. This is based on an IHE certified XDR implementation, though this version hasn’t been IHE certified. (No security, btw, since the outputs are public anyway, so don’t submit real clinical documents!) (And note that due to a technical limitation in the XDS side of the implementation, this interface only accepts CDA documents, not any other kind of document).

Note that this test implementation also builds an XdsEntry2 as well as an XdsEntry – the FHIR project team is evaluating two different granularity approaches to XDS, to see which provides the best balance of usability and re-useability.

Note also that this implementation makes extensive use of inline resources, as discussed previously, as a way of evaluating their use.

Implementation Details

The implementation of the bridge is done in javascript. The script is commented extensively to explain what is happening. As an overview, the script has to build the following kinds of resources:

  • XdsEntry (no XdsFolder support – I haven’t seen real world usage of that yet)
  • Patient/Person
  • XdsEntry2 / Agent

In addition to building their raw contents by extracting information from the XDS ExtrinsicObject, the script also has to figure out how the resources are identified, and link them up correctly in in the batch so that server will identify them properly. Much of the hard work is involved in this step (see previous post on this subject).

The script is called and provided with a handle to 3 parameters of interest: the ExtrinsicObject element in the submission set, the associated binary content as base64, and an empty batch to be filled out form the information provided in the ExtrinsicObject. The script makes use of some fairly obvious utility functions, and a FHIR factory object that is used to construct the objects that build out the batch.

I keep the current version of the script at http://www.healthintersections.com.au/xds2fhir.js – read the script for further information.

Categories: FHIR, IHE

Question: FHIR date formats in JSON

Posted on January 4, 2013 by
1 Comment

Question:

I’m reading a bit about FHIR … and I was wondering why you choose to specify date/time as strings instead of the notation below that is commonly used in JSON and supported by e.g. MongoDB tools for queries on date values ?

e.g.
“birthDate”: {
“$date”: “1968-04-08T23:00:00.000Z”
},

Answer:

When we considered the JSON date representation, we searched for any evidence that one of these date formats, of which there are several, was gaining real traction in the community. We could find no evidence that any one of these date formats was a clear winner, particularly in terms of support in common JSON parsing libraries.

As a consequence, we elected to use the same wire representation as all the other properties, and the same as in the XML – which happens to be, for full date times, exactly the same format you use above, though without the $date part. Note that the “$” part also causes problems for many json libraries as well – we tried to use that for something, and had to change away from that because several important platforms couldn’t work with that (I forget which ones).

JSON is real convenient for the users, but it’s very hard to use in a standard.

We’d be happy to receive solid feedback that the current solution doesn’t work with MongoDB – but note that a number of the implementers in the project team itself use MongoDB. Perhaps one of them might comment.

Categories: FHIR, Question