Monthly Archives: November 2013

Question: Multi-part surnames

Question:

How do we handle multiple family/last names? Andhow to re-construct the complete family name with multiple parts stored in db?
How about, for an example: Josep Puig i Cadafalch – Puig is the last name of his father, Cadafalch of his mother; i means “and” (see Iberian naming customs).

Answer:

Human Names are quite difficult in healthcare standards, because there’s fairly wide variety of cultural practices, and because they get involved ubiquitously across the process – and because most implementations work within a narrow cultural profile.

Let start with the simple case – how should this be represented in v2, CDA, and FHIR:

V2.7 XPN
Puig i Cadafalch^Josep
CDA PN
<name>
  <family>Puig</family>
  <family>i</family>
  <family>Cadafalch</family>
  <given>Josep</given>
</name>
FHIR HumanName
<name>
  <family value="Puig"/>
  <family value="i"/>
  <family value="Cadafalch"/>
  <given value="Josep"/>
</name>

So these are different. You can’t reproduce the CDA/FHIR structure in v2, but you can represent the v2 structure in CDA and FHIR:

CDA PN
<name>
  <family>Puig i Cadafalch</family>
  <given>Josep</given>
</name>
FHIR HumanName
<name>
  <family value="Puig i Cadafalch"/>
  <given value="Josep"/>
</name>

So that creates an inherent problem: there’s no one right way to represent this name in CDA (for FHIR, this is something you SHOULD NOT do – see below). The first form is preferred, but the second is still legal. Well, the thing is, we can’t make it illegal, because maybe the space really is part of a single surname (that would play out in a legal/jurisdictional system where pragmatic solutions aren’t always possible). So why do we even allow it to be broken up? That’s because not all parts of the surname have equal meaning, and the different meaning impacts on how you use names (searching and matching considerations). So you can break names up in CDA and FHIR to allow parts to be marked up. CDA provides qualifier for this, and in FHIR it would be extensions.

But there’s two different forms that are (in the case above), identical. How does this work in practice? Well, that brings the database question into focus. In practice, there’s a range of approaches. There are applications out there that handle names exactly as CDA/FHIR/ISO 21090 handle them- but in my experience, these were written from scratch to be conformant, not to solve particular real world problems. But mostly, there’s some combination of single or multiple given and surnames, with prefixes, sometimes suffixes, and occasionally surname prefixes (“van”). In english speaking countries, applications mostly only have a single surname.

So the ambiguity in the specification is faithfully reproducing variation in practice. We’d like to impose a single model of naming, but there isn’t one. In fact, the situation is much complicated by a person with a name from one culture trying to represent their name in another culture’s systems (tourists, or immigrants. Immigrants actually often take different name just to get by), which leads to some weird intersections of practice.

Implementation in FHIR

In FHIR, we’ve make this implementation note:

The parts of a name SHOULD NOT contain whitespace. For family name, hyphenated names such as “Smith-Jones” are a single name, but names with spaces such as “Smith Jones” are broken into multiple parts

and this one:

Systems that do not support as many name parts as are provided in an instance they are processing may wish to append parts together using spaces, so that this becomes “van Hentenryck”.

This makes things workable – it doesn’t matter how you store it, there’s guidance for interoperating with other applications, and in most circumstances, this will work fine.

But its’ SHOULD not SHALL  because we know of edge cases like the jurisdictional one above where you mightn’t be able to follow the simple rules.

 

Question: More Starting with HL7

Question:

I am working in a web based startup which deals with health care data and I am looking specifically at how to import/export certain data in HL7 compliant manner.

I read your post “Question : Starting with HL7” and it was really helpful and also looked at different questions people already asked. Thanks for the responses.

I have spent last few days in reading documentation on HL7 from official site and I must say its a huge amount of info to process. It seems most of the existing system are using 2.X version so it would be a wise choice to start with 2.7 protocol?

I wanted to ask you if you could point me to a simple tutorial or blog which shows how to implement the steps you mentioned in “Starting with HL7” post. I am just looking for a simple example which can just show for example how to import/export minimum patient info(may be Id, First and last name).

I also wanted to ask if there are tools or APIs I can use to avoid reinventing the wheel. We are using Java technology stack. I found some Java APIs which claim to help in implementation of HL7 but I wanted take your opinion about it. What APIs I should look to which can help me in reuse instead of rewrite.

I provided as much detail as I could 🙂 I know it might be more than you expect in a single question. Thanks for reading it.

Answer:

Yes, a great deal of information to process.

Some comments on the above:

  • importing/exporting patient info isn’t directly easy – you have to implement ADT messaging (chapter 3) and then figure out which events you are going to be implementing. Ao1? A08? (that’s for import). Or are you going to be doing query (A19?) Probably, you will have to do something different at each site..
  • Tools – since you say Java, then there’s two choices: HAPI, or the code I wrote for Eclipse (org.eclipse.ohf.hl7.v2). But the HAPI code has a big community around it, where as my code doesn’t, so the obvious thing to do would be to use HAPI
  • v2.7 isn’t being used in the wild to my knowledge. I regularly see v2.4, and once I’ve seen 2.5. If I was in USA, I’d see 2.5.1 a lot. But that may not be the right question – it depends on how you implement. The way v2.x works, version is somewhat optional, and I, for instance, mostly use v2.5 as my implementation base, and just process extra fields that the infrastructure doesn’t know as I see fit – but you need infrastructure that knows how to behave like that. I don’t know if HAPI does

 

Underlying Issues for the pcEHR

There’s an enquiry into the pcEHR at the moment. As one of the small cogs in the large pcEHR wheel, I’ve been trying to figure out whether I have an opinion, and if I do, whether I should express it. However an intersection of communications with many people both in regard to the PCEHR, and FHIR, and other things, have all convinced me that I do have an opinion, and that it’s worth offering here.

There’s a lot of choices to be made when trying to create something like the pcEHR. In many cases, people had to pick one approach out of a set of equivocal choices, and quite often, the choice was driven by pragmatic and political considerations, and is wrong from different points of view, particularly with regard to long-term outcomes. That’s a tough call – you have to survive the short-term challenges in order to even have long term questions. On the other hand, if the short term decisions are bad enough, there’s no point existing into the long term. And the beauty of this, of course, is that you only find out how you went in the long term. The historians are the ones who decide.

So now that there’s an enquiry, we all get to second guess all these decisions, and make new ones. They’ll be different… but better? That, we’ll have to wait and see. Better is easier cause you have hindsight, and harder because you have existing structure/investment to deal with.

But it seems to me that there’s two underlying issues that need to be confronted, and that if we don’t, we’ll just be moving deck chairs around on the Titanic.

Social/Legal Problems around sharing information

It always seemed to me that in the abstract, the pcEHR make perfect sense: sharing the patient’s information via the person most invested in having the information shared: the patient. The patient is the sick one, and if they choose to hide information, one presumes that this is the same information they wouldn’t volunteer to their treating clinician anyway, so what difference would it make?

Well, the difference between theory and practice is bigger in practice than in theory.

And the thing I’ve heard most often in the last couple of weeks with regard to the pcEHR is “it’s neither fish nor fowl” – is it a clinical record, or a patient record? I’m sure that the enquiry will be inundated with comments about this, but there’s a deeper underlying question here: what’s the clinician’s liability in regards to sharing information? (both outgoing and incoming). If a clinician does not discover a condition because it’s not listed in the pcEHR, and they didn’t ask the patient, would it (ever) be an acceptable defense that you would expect it to be? Is that something that would come about naturally by osmosis (or something), or is there active cultural and legal changes needed here?

I’m not a clinician, but I rather think it’s the second. But there’s probably a mexican stand-off here – you couldn’t find out whether this would be reasonable till the (x)EHR is a Big Thing, and it won’t ever have any chance of being a Big Thing until this is resolved.

So the enquiry can recommend whatever it wants, but this underlying question isn’t in it’s scope, so far as I can see – and so it probably won’t make much difference?

Now I raise this – in spite of the fact I’m not a clinician – because it actually frames my second issue, and that’s something I do know about. The way it frames the second issue is that I don’t know whether the pcEHR is just a path for sharing information with the patient, or whether it’s actually intended to grow into the real patient care system that everything else is an extension of (the pcEHR documentation is a dollar each way on this issue, so I’m never sure). If the answer is the first – it’s a one way pipe to the patient, then my second issue is irrelevant. But I’ll still raise it anyway because lots of people are behaving as if the goal is a real healthcare provision system.
Lack of Technical Agreement

The underlying pcEHR specifications for clinical agreement are the CDA document specification stack, consisting of the “Core Information Components”, the “Structured Document Templates” (aka Structured Content Specifications), and the CDA Implementation Guides. At interest here is the Core Information Components, which say:

The purpose of the [X] Information Requirements is to define the information requirements for a nationally agreed exchange of information between healthcare providers in Australia, independent of exchange or presentation formats.

Then they say:

Note that some of the data elements included in this specification are required for ALL [X], whereas others need only be completed where appropriate. That is, a conformant [X] implementation must be capable of collecting and transferring/receiving all Information Requirement elements.

What this means is that these documents are a minimum required functional set – all parties redesign their systems to do things this way, and we’ll all be able to exchange data seamlessly.

There’s no discussion in these documents about the idea of systems doing extra pieces of data not discussed by the core information components, but the underlying approach really only works if there aren’t any. The problem is that this is “core” components – and that’s very much a reflection of the process – these are things everyone agreed to (where “everyone” turns out to mean, the people who were talking to NEHTA back then, which is far short of everyone who will implement). That leaves a lot of things out of scope.

So there’s problems here in two directions – what if systems don’t support the core components? What if they have other things?

Now the pcEHR was built on top of these specifications, and some parts of the pcEHR design expected that things would follow the core components – particularly, any part that implied data aggregation, analysis, or extraction. As long as the pcEHR is documents inbound, document navigation, and document view, the conceptual gaps the core information components leave don’t matter.

But as soon as you start wanting to do composite views, summaries, etc, you need to be sure about the data. And deviations from the Core Information Components make that impossible. And, in practice, many of the contributing systems deviate from the core information component specifications by not supporting required fields, adding extra fields, or having slightly different value sets for coded values etc. There was this expectation that all the systems would be “adjusted” to conform to these core information components. And some were, though sometimes in some strictly notional sense that the users will never use. But many systems never even tried, and it just wasn’t going to be practical to make them.

It probably sounds like I think the core information components are flawed, but I don’t really think they are – I think the issues I have listed should be understood as that we have found the limits of agreement within Australia in these regards. Given a much longer development time, a lot more money, and a lot better engagement, we could have added a few more fields, but I don’t think it would’ve made much more difference. The problem is the existing systems – they are different. And may be they could be rewritten, but that would cost a vast amount of money, and what would happen to the legacy data?

So any useful clinical leverage from the pcEHR in terms of using the data is pretty much a non-starter right now. Only the NPDR, where the prescribe and dispense documents are locked right down – only there do we have useful data analysis happening (and so far, we have only a few providers set up to push data to the NPDR. I wonder how others will go – but prescription is a fairly proscribed area, so this might be ok).

I don’t see how the enquiry can make much difference in this area either – this is a generational problem. I guess there can be lots of moving the deck-chairs around, and blaming the symptoms. That’s how these large projects usually go….

 

Complexity of Standards – Updated

Someone asked me to update the diagram, from The Complexity Of Standards:

A rough plot of the internal complexity of the standard (y, log) vs the complexity of content that the technique/standard describes

They wanted to know where FHIR sits on the graph. Well, here’s a guess:

complexity-fhir

 

Comments:

  • The goal is go downwards and right
  • While I think that FHIR is inherently simpler than HL7 v2, it’s breadth of functionality is a lot wider, so I couldn’t rate it as overall simpler
  • FHIR has more semantic depth than CDA in several directions, though the core clinical statement in CDA can go further – but both CDA and FHIR become exercise in extension at that level. So FHIR wins by a little

When I look at this graph, and the position of openEHR, I know I’m going to get comments, so a note about that: this ranking of openEHR is based on the whole openEHR stack. OpenEHR has a methodology (templating) which they use to take the full awesome breadth of the openEHR eco-system, and produce simple XML that’s easy to use. If I put that on the graph, it would be near the FHIR slot – probably a little less breadth, but a little more semantic depth, and round about the same complexity.  I guess.

Look, this is rough anyway, so don’t read too much into it. It’s really meant to be just pointing out that what we all want is down and right.

p.s. Snomed is still off the top for complexity, and not far enough to the right.

 

Standards and Research: like Slinky-Dog

From my friend Heather over at Archetypical:

I’m not knocking the standards development process. Where there are well established processes and a chance of consensus amongst parties being achieved we have a great starting point for a standard, and the potential for ongoing engagement and refinement into the future. But…

A standards organisation is NOT the place to conduct research. It is like oil and water – they should be clearly separated. A standards development organisation is a place to consolidate and formalise well established knowledge and/or processes.

It’s not that I disagree with Heather, but..

It’s not quite so simple in collaborative spaces.

I certainly agree that standards development is not the place to do real research – that needs to be risky: to have a real chance of failure. Or it’s not innovation, and if it’s not innovative, it can’t be called research (see The Pipeline’s rant on this subject). And standards aren’t structured to do research, and shouldn’t.

But in order to be effective, researchers need to work together, and to investigate the novel in the presence of a common base, so that their work is comparable. And to create that, you need standards.

So research needs standards so it can happen.

And standards need research so they know where to go.

It’s kind of like this, with research at the front, and standards at the back:

I find this a useful mental model when evaluating the direction that standards I’m involved should go with:

  • Standards and Research shouldn’t try to stretch too far apart
  • Standards enable research, and then catch up so research can go further

(And, btw, I think that the DCM standard Heather was actually blogging about fails this test here – it’s trying to get standards in front of research)

 

 

Change to HL7 Ballot sign-up processes

From HL7:

Important Announcement Regarding Ballot Pool Sign Up Date Changes

We want to make you aware of an important change to the ballot signup period for HL7 standards balloting. A recent ANSI audit has prompted a significant change in our ballot pool signup procedure. This change was required to address shortcomings in the way HL7 addresses balance of interest in our pools.

In the past, ballot pool signup for any pool remained open until a week before that pool was scheduled to close; however, starting with the upcoming January 2014 ballot, the ballot pool signup period for any pool will close when that pool opens for voting. This means that for this cycle, with pools scheduled to open on Friday, December 13, 2013, ballot pool signup will close at end-of-day Thursday, December 12, 2013.

My personal opinion: I can’t imagine what this actually achieves on the real world other than to reduce the quality of the overall standard that comes out the other end. But it’s a typical thing – measurable markers of steps towards progress are more important than the progress itself. At least I know that HL7 itself thoroughly dislikes this change.

Documents are only immutable as a matter of policy

One of the issues that kept coming up when we were discussing documents in FHIR last week is that notion that documents are immutable, and can’t change. Take, for instance, this, from the comments:

Document should be immutable

Only, documents aren’t immutable. That’ll be a shock for CDA centric readers, where the immutability of documents is a fundamental notion that is hammered into implementers by the specification and the community around it, but it’s true.

First, you have to build the document. Clearly, it’s not immutable while you’re doing that – it needs to be edited, changed, assembled, and this can be a piece meal process. So the technical artifacts that underly building a document aren’t immutable. Even after you have it, you can break it down, change things, reassemble them. It’s still the same technical constructs – so even then, it’s not immutable.

The immutability is affixed as a matter of policy – once a document is “done”, then it’s treated as immutable by choice, to establish clinical traceability. This is important, and necessary.

In CDA, the existence of a CDA document is evidence that the document is done, and so they are treated as unchangeable. If you, privately, choose to keep partially formed CDA documents that you don’t treat as immutable, well, that’s your private business, and there’s no need to let anyone else see your private business. So even with CDA, it turns out, immutability is a matter of policy.

FHIR is different to CDA, because the FHIR spec defines a whole lot of functionality that’s relevant and important during the building and processing phases. So it would be a mistake to restrict that functionality at the technical level to ensure that documents are immutable – because they actually aren’t at that level. What FHIR needs to do is ensure that the control points to enforce and audit immutability exist so that the policy imperative of clinical traceability can be delivered. That’s something that we’re keeping in mind as we work on the document design.

This same dichotomy exists, btw, in the v3 data types, where the abstract specification describes the data types as “immutable”, because they are, in concept. But the ISO 21090 concrete version implicitly caters for non-immutable definitions, and there’s discussion in the spec around the difference between immutable in technical terms, and immutable in policy terms.

 

 

UUID in CDA/SPL? – uppercase or lowercase?

UUIDs may be represented either in uppercase or lowercase. Lowercase is common in Unix, and uppercase is common on windows (COM).

HL7 never said, in the context of data types R1, whether UUIDs should be uppercase, lowercase, or either. Though the literal form implies that it should be uppercase:

   INT hexDigit : "0"     { $.equal(0); }
                | "1"     { $.equal(1); }
                | "2"     { $.equal(2); }
                | "3"     { $.equal(3); }
                | "4"     { $.equal(4); }
                | "5"     { $.equal(5); }
                | "6"     { $.equal(6); }
                | "7"     { $.equal(7); }
                | "8"     { $.equal(8); }
                | "9"     { $.equal(9); }
                | "A"     { $.equal(10); }
                | "B"     { $.equal(11); }
                | "C"     { $.equal(12); }
                | "D"     { $.equal(13); }
                | "E"     { $.equal(14); }
                | "F"     { $.equal(15); }

But no one ever read or understood the literal form anyway ;-). More importantly, the schema allows both. Here’s the regex:

 [0-9a-zA-Z]{8}-[0-9a-zA-Z]{4}-[0-9a-zA-Z]{4}-[0-9a-zA-Z]{4}-[0-9a-zA-Z]{12}

Actually, there were earlier versions where it only allowed uppercase, consistent with the abstract literal form. In practice, though, people used a mix of either, and by the time it was brought to committee, it was too late to close the door. We did publish a technical clarification that uppercase only UUIDs were required, but too many implementers had existing CDA and SPL documents with lowercase GUIDs, and so we have to accept either.

In the Australian pcEHR, about 95% of UUIDs are lowercase, and 5% are uppercase. Implementers should be aware that comparison of UUIDs is case insensitive – don’t get caught out doing a case sensitive comparison, because eventually a bug may happen (though when is unsure, since the only cases of re-use of the same UUID at the moments are from the same authoring system, and so far, systems have been consistent. So it’s unlikely, but not impossible).

What we won’t allow in the PCEHR is to use mixed case within the one UUID – all uppercase, or all lowercase.

p.s. The subject came up in conformance, so I thought I’d clarify here, since many PCEHR implementers follow my blog

Question: When should you adopt FHIR?

Question: 

Need your opinion on this matter of encouraging people to adopt FHIR for national programs/ national standards for healthcare exchange.

What will be your counter arguments if some cowboys say

  1. FHIR is still new, we will wait and see till it matures.
  2. Standard Development is cumbersome process, and it takes extremely long time for them to incorporate new requirements. It is much faster to cook our own unique xml to suit our requirements.

You talked about XML cowboys on your website in the past – hopefully you can provide much stronger fire power after two years spent developing FHIR.

Answer:

Well, FHIR is still new, and it will change. The “DSTU” that is coming out soon will be a Draft Standard undergoing Trial use, and users should expect breaking change after trail use. Right now, users that are risk adverse should consider long and hard before using FHIR. Implementing bleeding edge standards is a process that involves the shedding of a great deal of blood – and early adopters of FHIR will be have additional costs due to change in FHIR that people who wait the process out won’t.

Except… the risks of the alternative standards are also well known. I’m constantly surprised at the level of interest that risk-adverse implementers have in FHIR, but they uniformly cite the known problems around cost and complexity in other approaches to me. They think that even given the risk of future change in the FHIR specification, it’s still their least risk option. People say, “better the devil you know” – but it seems that if people think the devil is that bad, they’ll try out new devils to see if they’re better.

Of course, you could also consider not using a standard at all. After all, standards development is a slow, cumbersome process. From conception to the first draft version will have taken FHIR 2.5 years – and for a standard, that’s warp speed. The full normative version of FHIR certainly won’t come quickly. Given this, and the fact that the standards process is not only slow, it often doesn’t give you the outcome that you wanted (Ask for something simple, get something complex back), the impulse to just define your own thing can be overwhelming. It’s tempting just to roll your own format, and go with that. And sometimes, I actually think it’s the best approach – I’ve certainly done it at times in the past.

But the whole process of standards development, the fact that it’s slow and cumbersome – that’s actually it’s value. The point of a standard is that it’s stable, that you can develop to it, and plan for it, and that it’s developed in an open and transparent manner that ensures that a wide base of requirements have been taken into account. Because standards development is cheap compared to the real costly thing: product development. Vendors don’t like to develop product based on unstable interface formats. (Actually, it’s not vendors, it’s their customers, who don’t like paying more than they have to. Vendors just do whatever people will pay for).

So the real problem with XML cowboys is not that they develop their own formats, but that often, they’re externalizing the costs. A national program that develops it’s own formats, thinking it’s saving money…. no, they’re not. The project team might be (probably are) saving their own project money, but they’re certainly going to cost their nation a bucket load of $$$ in the long run. I’m written about the problems of national programs before – there’s lots of drivers to get them to adopt their own formats, and it’s not that’s a bad idea; it’s just the risk of externalizing cost, and by so doing, running up the total cost greatly. Also, there’s the risk that they won’t know what they’re doing, and that they’ll make bad decisions in haste which they rue later – we get enough of that at the standards level, with a wide input. How much easier to do it in a small team with deadlines looming.

Fundamentally, this is a governance question. The sponsors of those programs need to ask themselves hard questions about where they want their money to be spent, what outcomes they want. But politicians aren’t good at asking those questions. Governance is just hard.

When FHIR is stable, there’s every reason to think that leveraging it in general national standards will save money. For now, if national level programs really want to adopt FHIR, they need to contain the risks of future change to specific projects where it’s OK for them to left in a bywater called the DSTU version, or where they have some other strategy to ameliorate the risks.

p.s. If you thought XML cowboys were bad – you ain’t seen nothing. JSON Cowboys.. they’re leagues ahead!