• Sun Q3 (in 45 minutes time), a tutorial to show committees how to build resources
• Mon Q3 (MnM): Datatypes R3 proposals arising from FHIR data types
• Mon Q4 (SOA): FHIR discussion with SOA (part of the session)
• Tues Q1 (MnM): profiles and extensions
• Tues Q2 (MnM): governance and ballot plans
• Tues Q4 (Devices): general discussion, CIMI and FHIR (first 30 minutes)
• Wed Q1 (ITS): formats – xml, atom, and json
• Wed Q1 (MnM/Vocab): Vocab binding Methodology in FHIR
• Wed Q2 (ITS): REST related issues
• Thurs Q1 (RIMBAA): FHIR implementation session
• Thurs Q4 (ArB): FHIR/SAIF/governance wrap-up
• Fri Q1 (Templates): Profiles and clinical templates
• Fri Q2 (Pharmacy): Prescription model design

There’s also some discussion about FHIR governance at TSC on Sunday evening (this evening).

Updates:

• methodology and SAIF implementation guide will be discussed MnM Mon Q1
• MnM Q1 will include FHIR SAIF IG
• RIMBAA Mon. Q2 will include CIMI & FHIR compare/contrast
• Tues Q3 in PA

* Tuesday Q3: PA FHIR next steps

We are looking at receiving referrals REF I12. Currently they are V2.3.1 AS 4700.6-2004. In these referrals we need to be able to identify the organisation of the referring provider, preferably with an HPI-O. It seems that the only place that this can go is in PRD.4. Do we need to use HL7 V2.5 and put the values in PRD.4.10 & PRD.4.11? Is there a better place we could put this in HL7 a V2.3.1 message?

Well, PRD.4 is named “Provider Location”, with the rather confusing definition (v2.3.1):

This field contains the location of the provider as needed when a provider that may be external to a given enterprise must be referenced.  For example, if this provider represented the referred-to physician, the PRD-4-provider location should identify the clinic of the physician or provider to whom this referral has been sent.  The identification of the provider’s location is specified by an application and facility identifier carried in the facility field.  The application ID and facility ID would be used in the same manner as their corresponding fields in the MSH segment (MSH-3-sending application, MSH-5-receiving application MSH-4-sending facility, MSH-6-receiving facility).

The facility field is PRD-4-4. This definition is… not helpful, because it confuses the physical, logical and organisational place, all of which are different perspectives. The definition is untouched through to HL7 v2.7. But given that the definition of the PL data type is quite orientated to physical location, and the definition of PRD-4 is orientated towards the logical/messaging place, I’d be wary of putting the organisational identifier there, particularly an HPI-O which is very location independent.

v2.6 provides more of an answer to this question, in the definitions of fields 10 – 14 in the PRD segment:

Given that v2.6 defines these fields, then it would be best to preadopt these in v2.3, particularly PRD-10

Pre-adopting v2 fields

This is a fairly widespread practice in Australia; it’s preferable to using a Z-segment, because the definition of the field is known – you have to look far enough forward to where the field is defined. It’s also the anointed “right place” for the information, and if you asked the relevant committee, you’d get the same answer again. Pre-adopting fields – and also lengths – can have the effect of breaking implementations, though it shouldn’t (same can be said for adding z-segments too).

In this case, you’ll have to have a trading partner negotiation whatever, and of the various choices – misusing PRD-4, using a Z-segment, and pre-adopting PRD-10, I’d be wanting to choose the latter, though your choice is always constrained by your trading partner(s).

This blog post is based on a presentation I made to The Australian Medical Software Industry Association (MSIA) at a recent meeting. The focus of this presentation was a CEO level summary of where HL7 is at, as context for how to understand the use of HL7 standards in Australia. Note that interoperability is a major piece of the landscape here in Australia, and most CEOs are somewhat (through to intimately) involved in it, and therefore at least familiar with the innards of a v2 message.

Use of HL7 in Australia

HL7 v2 was first used for exchanging patient management information in single-campus hospitals. Over the last 20 years, the use of HL7 v2 has grown from that to be used for diagnostic reports in hospitals and then between clinical providers, and also referrals and discharge summaries within and between providers. There is also some use for pharmacy messaging, though I am only aware of this internally to an institution.This use has been aided and fostered by a series of Australian standards known by AS 4700.x where x indicates the intended use of the standard.

Recently, the National e-Health Transition Authority (NEHTA) has been introducing a new set of exchange specifications based on a more recent HL7 specification called CDA (“Clinical Document Architecture”) and the first round of implementation is in high gear at the moment.

HL7 v2

HL7 v2 is a messaging based standards – the content is exchanged in messages that have codes that indicate what real world events they relate to. The messages are divided into segments, segments into fields, fields into components, and components into sub-components – 5 levels of nesting. The syntax is based on delimiter characters for each level. HL7 v2 messages are backwards compatible – what you see in the message will never move to a new “place”, or be re-used for something else. Here’s an example:

V2 has lasted amazingly well – it’s still getting a lot of use, new adoption, and has a serious fan club. What’s good about v2?

• It’s a real simple syntax – you can roll your own parser pretty quickly (though a caveat: we consistently have problems in Australia with characters not being escaped or un-escaped properly)
• The v2 concept is simple – it takes about 5 minutes to explain the various parts, and the implementation stack is shallow (programmer, analyst, support people – everyone looks at it the same way)
• There’s a heck of lot of v2 adoption out there- toolkits are mature, libraries thoroughly debugged
• it’s easy (relatively) to find experienced people – there’s lots of them
• the strictly enforced backwards compatibility preserves investment (in fact, it’s actually at least an order of magnitude easier to switch between versions than to deal with the variation between implementations, though this doesn’t stop large vendors charging $100,000+ for changing versions – shame on them)

On the other hand, there’s some real problems with v2:

• It really is old tech – you have to roll your own parser, it’s not xml or json, and you just can’t leverage it; it’s not a good fit to any coherent architecture
• The definitions and approach were never rigorous – the definitions are inconsistent and also – worse – incomplete. Much is left to two implementers coming to joint agreement about, and the messages can’t be understood outside that agreement
• The described syntax is very focused on admin/support
• The 5 level hierarchy, and the fact that things are defined at a particular level of the hierarchy, means that it’s very difficult to describe sophisticated clinical information well in v2. Clinical information is delegated to a tree of name-value pairs with no good way to control them
• Formatted text support is still based on a grid of fixed font characters and console features such as moving the cursor around
• The strict backwards compatibility rule ensures that old decisions seriously limit new ideas, and any kind of fix for these other issues
• And “if you’ve seen one v2 interface, you’ve seen one v2 interface” – every interface is different

A long time ago HL7 looked at that list and decided to do something better.

HL7 v3

The next version of HL7 would be different:

• Based on rigorous and complete definitions – no more needing to consult local agreements to understand the content
• Consistency would be enforced by deriving all instances from a common reference model that also imposed thorough and reliable modeling
• The base would be constrained to useable artifacts for particular business requirements
• which would produce generated artifacts and a specified XML format for exchange
• the whole stack would be computable to aid with implementation
• There would be notional backwards compatibility – it would be understood how to migrate from old to new formats, but changes would be possible

HL7 has spent 15+ years developing v3 now. It’s had an immense amount of work, but adoption is disappointing. But it’s not that there’s nothing good about v3:

• It does have rigorous definitions
• There is a computable base, and there’s a number of software tools and applications out there that use the RIM as a computable base (including Oracle’s HTB at the core of the Australian pcEHR)
• There was an absolutely massive requirements gathering effort that provides a very comprehensive international view of the healthcare landscape.
• And it’s XML, so you can use and leverage the XML tool stack

But that just hasn’t been enough to overcome the rather evident problems with v3:

• There’s a really deep implementation stack; it takes months to build it, and different participants have radically different perspectives on it once it’s built.
• V3 has complex concepts and syntax – everything must be understood at multiple levels and is documented in multiple long documents
• The core concept – constraint on a common model – fails to deliver on it’s basic goals (mostly because it’s just too hard not to introduce new semantics by stealth in the derived models)
• Common semantics doesn’t produce common engineering
• “if you’ve seen one v3 interface, you’ve seen one v3 interface”

So after 15+ years, there’s a few implementations by large national programs that cost lots of dollars, and require lots of implementation support and tooling. Realistically, there’s not going to be any more implementations, and v3 development is tailing off….

But all is not lost: enter v3 lite: CDA.

If you’ve seen one interface

But before we talk about CDA, a diversion about interfaces. They say “if you’ve seen one v2 interface, you’ve seen one v2 interface” – and it’s true. But I think that if I’ve seen one set of interface requirements, I’ve seen one set of interface requirements. The question we need to ask is “how much of the variation between interfaces is due to things internal to v2, and how much is external – because you won’t be able to get rid of the external variation.

There’s no question that some of the variation is due to v2′s incomplete and inconsistent definitions. But I think it turns that this is a small proportion of the total. With v3, we consciously delivered a standard that pushed back against variation between interfaces – and we discovered that it didn’t present a coherent way of dealing with that variation – in fact, it made the problem worse. With v3, you could actually joke that if you’ve seen one interface, you already seen lots of interfaces…

CDA

CDA is a clinical document. It has a header that identifies the document, who it is about, who wrote it and/or signed it, and a few other useful context things, some document narrative (formatted text with images), and some supporting structured data. The header and the structured data are based on the V3 RIM with constraint (which means that CDA is a v3 thing, though not “v3 messaging”). Compared to v3, CDA is easy to adopt. But CDA is a very different idea from a v2 message indeed.

It’s important to understand that CDA is a document – and it should be thought of like a word document. Word documents have properties, and you can make comments on them. Wouldn’t it be good if you the properties included some medically useful things, and you could add structured data in the comments?

That’s just what CDA is – a format for doing that. Because CDA is the bit of v3 that actually worked, a lot of people are using it for data exchange, rather than as a document but it’s not really a good fit for that use.

So what’s good about CDA?

• Its’ (relatively) easy to adopt – at least compared to some alternatives including v3
• It’s very flexible and adaptable, and all CDA documents have the same basic XML structure
• It’s got wide adoption across the world, and there’s a lot of implementation guides published
• The document semantics suit large EHR’s (i.e. national ones) where there is poor clinical governance across the scope of the EHR

(Aside: That last point is very definitely the context here in Australia. We are implementing a national EHR (the pcEHR – it is a national EHR, though carefully limited in functionality for political reasons), and we are doing so in the context of poor clinical governance. Now making that statement at the MSIA meeting seems to have caused some waves for me, because some thought I was criticizing NEHTA’s clinical leadership and governance (which I contribute to, btw). But no – that’s not my point. My point is, NEHTA and/or DOHA or anyone else can’t simply decide how a certain clinical fact (an allergy, say) should be represented, and then have everyone in Australia agree (let alone actually implement the agrement – hell we’re lucky if they even comment). Given that there’s no prospect of getting the clinical users to agree with each other, we have poor clinical governance, and we have to live that. In that context, a document based EHR – the EHR you can have – is better than a data based EHR – the one you can’t have.)

But there are also problems with CDA:

• A document is not a good fit with transactions
• We still have ongoing concern and confusion about narrative vs text
• Limping along with v2 transactions and CDA data sets (and I have a Standards Australia task against my name to somehow do something about that)
• The constraint methodology is time consuming and resource intensive – both to produce and implement the CDA Implementation Guides
• The structured data part of CDA is both too complex and too simple
• It’s too simple because it’s difficult to represent the agreed Australian clinical models (such as they are) cleanly in the CDA data
• It’s too complex because I work with the implementers every day at the moment, and I feel their pain

CDA is the near term future for Australia, but I hear rumbles across the community: there has to be a better way…

Where does that leave HL7?

Well, v2 is widely implemented, and we’ve used it harder than anyone else (so far as I can see), but it’s self limiting. There won’t be any more v3 implementations, and the national programs that used v3 will have to figure out what to do. CDA is a good for clinical documents, though I suspect there has to be an easier way, and it’s not a good fit for exchanging data. So what should HL7 do?

Few people at HL7 are happy with the current situation. They’ll support change – a fresh look – but what would you do. Well, there’s two ideas around: CIMI and FHIR. I’ve commented on them at length elsewhere (though my blog posts are a bit dated now – I’ll have to update them). But both CIMI and FHIR are still very early in their process. We’ll have to see what develops.

Dr Fernando called for clinical software for personal mobile devices to be regulated now rather than “waiting and letting the courts decide”. “I don’t want to constrain the use of what I think will be a potentially wonderful medical device, but I do think there is some guidance required and litigation is not the way to provide guidance,” she told Australian Doctor. Dr Fernando called on the TGA and the Australian Communications and Media Authority to work together with professional organisations to “list, evaluate and classify” software.

(cited from here, but the source is here). And also there was this, though the focus of that is different.

The thing is, this whole clinical safety governance thing is pretty arcane in the context of software. What does clinical safety actually mean? What would regulation actually achieve? I don’t think there’s any easy answers, and I thought I’d illustrate this using a safety case that we can all get our heads around: email.

The Problem

The problem is actually easy to describe, and I’m sure most of us have seen it in one way or another: when you hit send, where is your email going? Here’s two cases:

• When I look at an email that I have sent in gmail, and reply to it, the new message goes to the person(s) I sent the original to. When I do the same in outlook, the new message goes to me.
• When I respond to an email from a mailing list, some lists configure the mail to respond to the list by default, and some to respond to the sender by default.

What’s the safety risks here?

In the first case, I may think that I’ve sent a response to someone, but actually I haven’t. Of course, I’ll notice almost immediately – unless I’m in a hurry, and I rush off before checking for new email. The second case, on the other hand is both common and serious. It leads to one of two problems:

• You respond to a message, thinking that you’re sending it everyone, but you accidentally only send it to the person you are replying directly to. Sometimes you realize later, but only once the consequences of mis-sending the email become clear
• You respond to a message, thinking that you’re sending it just to the person you are responding to, as a side note, but you accidentally send it to everyone

The second case can be quite serious – in fact, I’m sure it’s cost lives in the wrong place. It seems like a regular occurrence on email lists where the default reply is to the lists: a passionate argument gets going, and someone sends a message worded on the lines of “gee, Bob, I don’t know why you bother, Alice is a total Moron”. No amount of “Eve desparately wishes to withdraw that last email which was sent, written and conceived entirely in error and Eve would like to assure you that she never meant a word of it” emails are going to undo the damage that’s been done.

So we have three problems with escalating levels of seriousness, but quite different manifestations of risk. But how do you quantify these risks and compare them to each other? And there’s a more insidious level of risk that’s even more intangible: the cumulative effect of these problems is to leave people wary of email, and to not use/rely on it too much (and, of course, I’ve only barely begun to scratch the surface of that problem, but it’s enough just to deal with these specific things for now).

I think that this is a good case for considering clinical safety not because I particularly think that clinicians should use email – though it is widely used – but because any e-health solution is going to involve messaging tools, and email is an instructive case. You can rewrite the use cases above around clinical messaging – I’ll leave that as an exercise for the reader.

Root Causes

As far as I am concerned, there’s three root causes underlying these problems:

• inconsistent behaviour between software products (the second case is complicated by inconsistent behavior between applications, though all the ones I use are now consistent around this case)
• (in the second case) the email standards allows emails to specify a reply-to address – usually from: and reply-to: are the same, but not always
• people send lots of emails (I send on average >100 emails per day)

If we’re going to do something useful in email safety in regards to governance and regulations, then clearly this is an important area to address: it costs us efficiency, lost opportunities, and has occasional social disasters from which anything will happen, and there’s a background loss of trust in the overall useability and reliability of the system.

Mitigation

What controls can we put in place to mitigate the danger here?

• The most obvious thing to try it to nag the user to ask if they’re sure. But this won’t help. Users will quickly come to click “yes” in the check as a pure reflex action, and even if they realise it’s wrong, they’ll still probably hit “yes” (a problem I have in different contexts where the software nags me about things I do all the time). Making the “yes” and “no” buttons appear in random places will annoy a user no end, but won’t make them think
• A better approach  is to implement an automatic 5 minute delay between sending, and actual sending. During this period, the message can be genuinely recalled. For various workflow and psychological reasons, users are more likely to realise that there’s a problem in those first 5 minutes rather than later (until the evidence of the mistake arises). Obviously this will only catch a portion of errors. (Note that this solution is implemented in several clinical reporting packages – reports sit in a holding tray for a configurable period of time before being distributed)
• It’d be nice to show the destination address in a different colour if it was for yourself, a single other person, or a whole list. Unfortunately, while this seems innately obvious to a person, it’s not at all obvious to software – addresses are all the same, and how would it know? but you could reliably show if the from: and reply-to: addresses are different – that’d be something.
• Gee, the rules so far haven’t achieved much, let’s just impose firewalls across all the email system ports and shut the entire system down. Not such a good idea? alright let’s try something else:
• It would be good to insist that all messaging systems work the same way, so that people only have to get used to one way of doing things, not more
• Similarly it would be good to insist that all email lists work the same way

So that’s my list of “controls” or mitigations. 1 that doesn’t work. 1 that mitigates a little on a % basis, but has an obvious price when you’re in a hurry, 1 that lead to a useful but still limited idea but that hasn’t been implemented, and 2 regulation ideas. If you have other ideas, feel free to make them in the comments. (I didn’t bother listing providing safety training – real users don’t show up for training, or don’t bother paying attention, and anyway, training would never address such a complex issue successfully if at all)

Regulation

Guess we’ll just have to regulate. We clearly can’t trust the software developers to have any idea what they are doing; they sure never think things through or do anything like useability and safety assessments. So let’s just go ahead and make two new regulations that all email systems have to follow:

• When a user chooses to reply to an email that they themselves sent, the reply should go to the destination address of the email
• All email lists must hence forth be set to fix the reply-to: header to the reply-to: header of the original email

Sounds good…. no. I’m sure I just made anyone who understands email and/or software development blow up. These rules are utterly ridiculous. There’s so many problems with them – they mean well, but they just won’t work. And by the time you’ve finished scoping and qualifying them enough so that they actually are realistic, they won’t mean anything anymore. Just a short list of problems with them:

• What’s email? Do you want to include facebook messaging? Internal system email? Or external email?  (Outcome: you can’t define the scope)
• What’s your governance scope? Do you have clean-room governance where all the systems inside the sandbox are under your governance, and all the systems outside your governance are outside the box? (Answer: no)
• Software packages actually work differently for reasons – both commercial and utility related. You can legislate against these factors, but you can’t make them actually go away
• The actual way that email addressing and routing works is way more complex that those rules describe. There’s all sorts of legitimate reasons for the complexity, and the rules as above would prevent many valid safe uses of email accidentally
• They still don’t actually fix the problem – just make it less likely

That’ll do -I could go on, but I think that’s enough to make the point. Regulation won’t work. But even worse, as well as not working, regulations are always written – have to be written – for today’s problems. And they require specific solutions for todays problems that end up preventing tomorrow’s solutions. (Email too open to abuse? build a social network and move your messaging in there…)

So if regulation isn’t the answer, then what? Some say, trust the developers

Trust the developers

Naturally, I’m drawn to this. I’m one myself, and I know how hard all the developers I’ve worked with work to develop safe useful software. We think about it (obsess about it). And most of us get judged on our success in this regard in a particularly harsh environment – the market.

On the other hand, I talk to users too. And so I know the gap between acceptable behaviour, and the things vendors/developers actually do. One story: one vendor had a system that only had one first name field. Users routinely entered middle names in the first name field. The vendor was required to write an interface that only accepted the actual given name in the first name field of the message. Solution: write a script to just delete all the middle names from the production clinical database. Enough said….

Conclusion

The safety risks are genuine, but we can’t mitigate them, and we can’t legislate them away, and we can’t trust the software developers? what to do…..?

Ideas are welcome in the comments as well, but what I think we should do is:

• Set up an e-health adverse clinical event reporting authority (like AusCert)
• Require every vendor selling clinical software in Australia to sign up for event notifications from the authority
• create a new sub-committee of IT-14 (Australian Health Informatics Standards committee) that tracks the notifications and develops handbooks and/or standards in response to reported the clinical events (yes, I know this is closing the door after the horse bolts, but this is how airlines work – and look, I’ve finally succumbed and made an airline comparison)

These are the ones I know about:

• Tutorial: Introduction to FHIR – Sun Q2
• Tutorial: Building with FHIR – Sun Q4 (FHIR for committees i.e. building resources)
• MnM: FHIR methodology & issues – Tues Q1?
• MnM/Vocab: FHIR / Vocab – Wed Q1  ?
• ITS: XML / JSON – Wed Q1
• ITS: REST – Wed Q2
• RIMBAA: Implementation Experience  – Thurs Q1
• Templates: Fri Q1
• Pharmacy: Fri Q2

In addition I’ll be presenting to the board about FHIR during Tues Q4, and I’ll be attending one of the two Mobile sessions with the aim of connecting the FHIR work with the mobile community that is forming.

Further, there may be a session with SOA – still working on that (or more correctly, trying to find a time to work on that)

If there’s anything else , make a comment. I’ll provide an updated list next week

Then there’s a difficult gestation, as the interface slowly becomes ready for birth. During this stage, people swing wildly between excitement about what the interface can be, and worrying about what might go wrong

Then, the interface goes live. There’s going to be lot of sleepless nights, and much wailing and gnashing of teeth (and that’s on the part of the new interface)

Eventually, things settle down, and the interface even stops falling over.

Finally, the interface is fully mature, and it knows how to behave properly in all circumstances. Now the interface enters the really profitable stage of it’s life – the bit that justifies the rest – it just sits in the background doing it’s job, and making money without fuss.

Finally, though, the changes around the interface start to catch up with it, and it’s starts to look rather aged. But it’ll soldier on, doing what it knows how to do, while people get increasingly frustrated with it.

Eventually, it moves onto life support – hardly anyone knows how to work with it anymore, and those that do would rather not – unless copious quantities of money are exchanged.

And then, way after anyone is happy anymore, the interface is finally laid peacefully to rest.

No wonder we think of them as individuals with their own personality…

We’ve been asked to update a patient’s “Interpreter Needed” flag across HL7 V2.x. I can see the Primary Language field as part of the PID, but cant see any reference to “Interpreter Required” in my reading of the specs. Have you come across this being sent as HL7 in your travels?

Well, no. I’ve seen the field in Patient Admin Systems, but I’ve not seen it in any HL7 message. And as you say, there’s no field for it. I’ve asked around, and no one else has seen it either. I have no idea why. I mean, you could assume that if the patient’s primary language isn’t the local language, an interpreter would be required… or maybe not. Whether you could or not would at least be dependent on local clerical policy. And obviously not in this case, or the question wouldn’t have come up.

So, it’s going to be yet another custom interface negotiation between you and the destination system vendor (or the source system).

In principle, there’s two ways to do this, both equally dubious. The first is simply to add a Z-segment, usually after the PID segment. This would look something like this:

 PID|1||12345^^^MR|...
 ZPD|true

Any random inspector of the message would have no idea what ZPD-1 meant – but you would, and anyone you told. This is actually the correct way, but people really hate Z-Segments because who knows what they mean? (Particularly next year when you’ve moved on, and the hospital loses the documentation).

An alternative is to use OBX. Let’s assume you’re using A01, in version 2.5. It has an OBX segment which can repeat after the PID, and you could add an observation about the patient that they need an interpreter. This wanton abuse of observations is a classic pattern of use of HL7 (both v2 and v3) … anyway, it would look like this:

 PID|1||12345^^^MR|...
 PV1...
 OBX|1|ST|code||true

There’s no boolean data type, so the nominal type is ST. The [code] value is some code that identifies whether an interpreter is required. Since there's no vaguely appropriate code in loinc, you could make any old code up, which means that the OBX is as uninterpretable as the Z-segment approach, though this does offer the interesting possibilities of bringing other poorly written systems (they abound) down when they try to make sense of you custom observation.

There is a better option though: SNOMED-CT has the term 315594003, which is a clinical finding with the preferred description: Interpreter needed. Frankly, for most systems, this would be no different than an invented code, but it does leave a clear signpost for anyone following later:

 PID|1||12345^^^MR|...
 PV1...
 OBX|1|ST|315594003^Interpreter needed^SCT||true

I'd choose the OBX method, simply because there happens to be a good SNOMED-CT code. If there wasn't.... it's toss a coin territory.

Kestral has been a long term committed supporter of HL7. As well as supporting my attendance and involvement in HL7 for over ten years, Kestral have also sent other staff to US working group meetings as well. My count is 6 people other than me (not including the several that went to the Sydney WGM).

The next meeting is in Vancouver, and Kestral will be sending yet another staff member (Sarah McGree).

Kestral is a serious supporter of interoperability standards – no other Australian company has a record anything like that.

In the following example from CCD there is an EntryRelationship has a type code of “SUBJ” However the CDA spec says the following which is only valid for OBS to OBS.

From the payers section (entry level template):

<entryRelationship typeCode="REFR">
 <act classCode="ACT" moodCode="EVN">
  <templateId root='2.16.840.1.113883.10.20.1.19'/>
  <id root="f4dce790-8328-11db-9fe1-0800200c9a66"/>
  <code nullFlavor="NA"/>
  <entryRelationship typeCode="SUBJ">
   <procedure classCode="PROC" moodCode="PRMS">
    <code code="73761001" codeSystem="2.16.840.1.113883.6.96"
       displayName="Colonoscopy"/>
    </procedure>
   </entryRelationship>
  </act>
 </entryRelationship>

The restriction from the CDA spec is (section 4.3.8.4):

Note the all important text at the top of that table, however:

NOTE: The CDA specification permits any CDA entry to relate to any CDA entry using any of the following relationship types. In many cases, this would result in nonsensical relationships. The following table is a guideline for reasonable relationships between CDA entries, and is not a conformance constraint.

So that’s just a guideline. A lot of implementers get caught out by that. Because of the shortness of the allowed list of act relationships, SUBJ and COMP are (ab)used quite a lot. This CCD usage is common.

Further SUBJ seems to be a strange choice of ER type code To me at least) it would seem to be more like a COMP.  What is the purpose of having the procedure nested within an Entity Relationship.  I cannot see what you gain over having the PROC ER directly under the . policy activity.

No, indeed, not in this case. However the key answer is here (from CCD spec):

NOTE: To the extent possible, the conformance statements in this section are isomorphic and compatible with the HL7 Financial Management (FM) domain model. In some cases, CDA R2 lacks class codes or other RIM components used by FM, in which case the closest corresponding CDA R2 representation is used.

The reasoning is not evident either in the CCD examples or the specification, but the full blown model (the claims and billing domain model) contains a richer model where the introduction of the intermediate act makes sense (aligns with a policy statement act, and the procedure is extra to the DMIM).

More generally, SUBJ is used where the extra information is “about” the act, whereas COMP is used when the extra information is “part” of the act. Sometimes, that’s a sensible differentiation, but often, from the perspective of the use case, it’s an arbitrary decision which to use (but note, in this case, that DMIM uses “PERT”, and that would sway me to SUBJ over COMP since I can’t use PERT in CDA R2).

Background

HL7 standards are not free for use. In order to use the standards in derived standards research or or production systems, implementers must pay a licensing fee. This can be done by joining HL7, or by purchasing the standards on a commercial basis. Neither option is particularly cheap; it costs a lot of money to produce, publish, and maintain the standards. Note that HL7 is a not-for-profit organization, and no one is drawing profits from selling the standards.

The fact that a licensing cost is required bothers many implementers, especially in countries where governments mandate use of HL7 standards, and the users don’t get to opt-in. HL7 is continually criticized for this, and compared to radically different standards organizations such as W3C, or OMG, which produce specifications that are not “encumbered” by having to pay for their use.

Not surprisingly, HL7 has looked repeatedly at how it converts it’s IP into a revenue stream, but each time, it elects not to change. Fundamentally the problem is that while these other models have been proven to work, no one knows whether they’ll work for HL7, and no one knows how to go about transitioning from where we are.

Hence, HL7 mostly is locked into a encumbrance model, though some newer products are being made available for free.

FHIR

Though FHIR is built entirely on the strengths of the existing standards HL7 has,in form and implementation it is entirely new. I’ve developed it personally, and while I’ve consulted widely, and there’s been a small team who’ve contributed, the entire content of FHIR is mine (© Health Intersections P/L). I’ve developed it with the express purpose of gifting it to the public domain.

Beyond the general principles of encumbered IP, and the question of why a bunch of volunteers would develop product in order to give it to some other organivation to sell, there’s a practical reason for that: existing HL7 members have spent many millions of dollars on existing HL7 standards. For all their flaws, they’re naturally going to be reluctant to implement new specifications, at least until their utility is well proven in practice. That’s a reasonable position to take. So how is a new specification going to become well proven in practice?

The answer is that the implementation experience is going to have to come from a new set of implementers, outside the HL7 community. And who is going to be doing interoperability in healthcare, who’s not an HL7 member? The answer is mobile apps, a tsunami of healthcare integration already winding up into high gear. These communities need a practical lightweight exchange standard, which is exactly what FHIR is. And if FHIR is going to appeal to them, it at least has to be free for use (it has to be other things too. for instance, I’d like to provide FHIR with an out of the box ObjectiveC reference implementation – I’m looking for volunteers to work on that).

So I’ve made an offer to HL7: I’ll gift FHIR to HL7 if HL7 will make it available to the public for free.

Specifically, we’re talking around something like this:

The agreement would hold until the first full normative publication of FHIR, after which the impact of this would be reassessed and other models could be considered.

I’ve been in discussions with the HL7 Board, and we seem to be in general agreement to this. I’m just waiting to get the agreement formalized, and then I’ll turn FHIR over to HL7.