FHIR and the need for identified resources
Dec 31, 2012One of the fundamental tenets of REST is that resources are unambiguously identified. Specifically, for REST, the identification is an accessible URL that can be used to address the resource with certainty. The fact that resources are unambiguously identified and that the reference to them can be handled with confidence is a big part of what makes a RESTful implementation simpler and cheaper than other approaches. I’ve found this to be true in my own implementation work based on it – it’s just so much easier to process the information when it’s explicitly identified. This is very different to existing HL7 approaches, such as v2, or CDA, where information is generally carried anonymously – just the information, with no formal record identification.
To illustrate the difference, consider the v2 PID segment. It has several fields of interest:
| 3 | Patient Identifiers |
| 5 | Patient Names |
| 7 | Date of Birth |
| 8 | Patient Sex |
The patient identifiers list includes all the patient identifiers, each potentially labelled with a type. The type list is a mess, and is focused on human relevant types such as “Medical record number”, “Person number”. There is a type for “Patient internal identifier” but I’ve never seen it used in production, and there’s no explicit rules about it’s behaviour
In FHIR, on the other hand, in addition to having these same fields, there’s an explicit and required concept called the logical id of the resource, which is the URL by which it is identified. There are very specific rules about how this URL is maintained, and these are written into the base RESTful spec part of FHIR. Even if you aren’t using REST (you don’t at all have to use REST with FHIR), the rules about how the logical identifier is handled are still the same. This logical identifier can be used confidently when processing the content – and it makes it oh so much easier to handle the content (though it’s not simple – there’s still issues about how records are maintained and synchronised in distributed systems, these haven’t gone away. But their manifestation is now explicit).
One consequence of this is that in order to play with FHIR, you have to pay a price at the entrance – you have to identify your resources. Once you’ve done that, you’re welcome to play, and things are much easier. But if you don’t pay your gate fee… you can’t play.
But what if you can’t afford to pay it?
XDS
This is a problem for FHIR that manifests in the XDS implementation we are working on for the connectathon. In a properly defined RESTful implementation of XDS (at least from the FHIR perspective), we should make the resource design as granular as possible, and re-use existing shared resources for basic concepts as much as possible. So we should use Agent and/or person for the author of a document. In this case, the XdsEntry resource has an element author, which refers to another resource that has the details.
The problem is that in classic XDS, the only required item for the author is a name. Just the name. And a name is not enough to identify a person – they can change, and they can be duplicated. The name field is an HL7 v2 XCN, which has an identifier (component 1), but this is often not populated, or if it’s populated, the quality of the identifier is not well described, and it’s unclear to what extent you can rely on it. So in XDS, an author is pretty much unidentified.
This gives you a problem if you are writing a bridge from XDS.b to a FHIR XDS implementation: you have to identify the author (pay the gate fee) as you convert from XDS.b to FHIR – and you usually can’t because you don’t have enough information. Well, perhaps you can, if you know the identifier is good, or you can connect back to the source system to query it for the identification – but that’s going to be custom solution per document provider, and simply isn’t feasible. Alternatively, you can construct phantom identities using UUIds (just give every record a new UUID) – but this just creates reams of duplicate records (millions, in some instances)
Unidentified resources
So this is a real problem – and it’s not about XDS, or unique to XDS. In fact, it crops up anywhere where you want to migrate content from v2, CDA to FHIR as well. And it crops up anywhere you are connecting content to FHIR – the gate fee has to be paid.
But sometimes, it’s just too expensive to pay, such as when you are writing middleware, and you don’t have access to the source records.
What can we do about this in FHIR? Do we need to do anything about it?
One option is simply to stick to the principle, and insist that the gate fee has to be paid, and everything has to be identified. I like this idea when I’m inside the gate – it makes everything so simple. But when I’m outside the gate, it doesn’t look like such a good idea. And I see that other people implementing FHIR have the same experience.
An alternative is to identify the kind of information that you might have if you don’t have a properly identified resource, and allow either a resource reference or some minimal details. You can see that pattern in the contact person for organisation, where it might have a name, address, telecom details, or it might be a reference to an actual person that contains the same details with identity.
But this solution doesn’t scale. Firstly, it creates duplication between the one place and another, and now every implementer has to look in both places. The other problem is that you have to pick and choose – which fields do you allow? So ultimately this is an unsatisfying solution.
An alternative is to allow resources that have no identity. This is a subject that has come up several times on the FHIR mailing list, and again recently amongst the project team and implementers preparing for the connectathon – and it keeps coming up because of the reasons I’ve outlined above.
And in principle, it’s easy. A reference from one resource to another looks like this:
<author>
<type>Person</type>
<id>http://fhir.org/svc/person/034AB16</id>
<subject>
But if you don’t have an identity for the resource, then you could simply replace the content like this:
<author>
<Person>
<name>
<family>Falsaperla</family>
<given>Saro</given>
</name>
<!—- etc -->
</Person>
<author>
The original FHIR draft included exactly this option, but it was removed because allowing this choice complicates implementation in a number of ways:
- At every resource join, there’s a choice: by reference or by value?
- XPath processing is much more complicated
- Server side searching becomes more difficult
- The schemas become more complex and nested
The biggest issue is that allowing anonymous resources like this allows people to avoid paying the gate fee, and making implementation within the fences more expensive. That’s because there’s a basic rule of thumb: once a resource has been de-identified like this, it’s not feasible to re-identify it, and if an information provider choose not the to the pay price, then the information consumers will have to – and there’s usually more consumers than providers.
I think that we have to allow this choice for resource references – by value or by reference. I’ll be making a ballot comment on FHIR that we should, and implementing this choice for the connectathon so that we can see how it works in practice.