Monthly Archives: August 2012

Why I am withdrawing from the Australian Delegation to Baltimore

The Australian government has a program that supports Australian delegate’s travel expenses for the purpose of attending international standards meetings and representing Australia. We contribute our own time, but the government reimburses our direct expenses. In exchange, we must represent Australian interests and agreed positions, and we must contribute to a published report about what happened at the meeting. I’ve discussed the usefulness of this report before.

As part of the funding conditions, we are required to sign a “Moral Rights Deed Poll” that assigns the copyright of the report to Standards Australia so they can distribute it as they need to – that makes perfect sense, and I’d be fine with that. However this year, I can’t sign it. Not because of what the intent is, but because of what it says.

Warning: what follows is legalese…

The following definitions apply to this Deed:

Intellectual Property means all copyright (including rights in relation to phonograms and broadcasts), all rights in relation to inventions (including patent rights), plant varieties, registered and unregistered trade marks (including service marks), registered and unregistered designs, circuit layouts, know-how and all other rights resulting from intellectual activity in the industrial, scientific, literary or artistic fields.

Material means any documents, records, software (including source and object code), goods, images, information and data stored by any means including all copies and extracts of the same that is:

(a)   brought into existence for the purpose of the Multi Schedule Funding Agreement between Standards Australia and the Commonwealth dated 13 September 2011; or

(b)   incorporated in, supplied or required to be supplied along with the material described in (a);

that is included in any:

–       Project Plan Report;

–       Progress Report;

–       Report from ISO or HL7 International Standards Meetings; or

–       Final Report;

prepared in relation to the activities of IT-014.


The Author assigns to Standards Australia all Intellectual Property rights in the Material, including present and future copyright, whether created by the Author individually or as part of a group, throughout the world.

So what this actually says is that the author (me) assigns to Standards Australia all copyright, all rights, all trademarks, know-how and all other rights to *anything* in the report. Not just original contributions to the report (with which I’d be perfectly happy), but any material incorporated, or required to be supplied with it. (How can that not include the extensive material on the web linked from the report?)

I can’t sign this. The only things I produce or deal with in my business is intellectual property. The meeting report needs to cover much of what I do, and has, in the past, quoted liberally from all sorts of HL7 and other content, including things that I own or have owned (the content on my blog, for instance). I can’t sign a document that creates uncertainty – in a legal sense – over these things.

Even if this is not legally enforceable (we can hardly assign the rights to trademarks like HL7, Microsoft, etc to Standards Australia), what do I do when I later have to make a declaration that there is no question of ownership over something I own?

Other people have signed it – either they don’t read it at all, or they think that since the full provisions are not enforceable, they’re happy to sign. Some people think I’m worrying over nothing – that these things are not going to be enforced anyway, since what the agreement actually says is not what is intended (which is clearly the case). But I just can’t be so willing. Standards Australia tell me that I’m the only one with a problem – and I have signed the previous ones willingly (I didn’t know then what I know now, nor did I have so much to lose then). I asked for the agreement to explicitly exclude material that is incorporated with attribution, or that is pre-existing (though that doesn’t really cover the issue), but for procedural reasons, it’s not possible to change the agreement (Standards Australia and DOHA have a signed contract that includes the agreement, so they can’t change it).

So I’m afraid that I’m going to withdraw from the Australian delegation. I hope this doesn’t impact on my working relationship with Standards Australia – they’ve really tried hard to accommodate my concerns, but they are bound by their own agreements with DOHA.

p.s. I’m still going to be in Baltimore.

Identifying Humans

The third requirement for interoperability is good identification policies. And the most common problem in healthcare identification is identifying people.

Identifying humans, especially patients, is stupefyingly hard. Even after too many years of healthcare interoperability, I still can’t believe how hard it is. One of the reasons it’s so hard to grasp is because as humans, we are intrinsically good at identifying other humans. But it just doesn’t scale when it comes to successfully identifying humans in distributed systems with more than a few people who must perform the identification.

Many people look to biometrics to solve this problem. The common candidates are finger prints, retinal patterns, some form of phenotyping and most of all, genetic sequences.  But all these suffer from problems (and see particularly  Given the expense and reliability problems associated with biometric markers, most healthcare institutions rely on social identifiers. These typically are a selection taken from the candidates listed in the following table, which briefly discusses the issues associated with them.

Name Patients change their names regularly. Names are often linked to marriage customs, and the relationship between names and marriage is changing quickly around the world. Names can be mis-spelt, or mis-reported, and people often carry multiple names for use in different circumstances, and/or have names that don’t fit with local cultural expectations. People also use aliases for a variety of reasons.
Date of Birth Some people do not know their date of birth. This is more common in less developed countries, but there are immigrants everywhere. In addition, there are sometimes reasons to lie about dates of birth, and these can create persistent records that create confusion for many years
Addresses and
Telephone numbers
People change these all the time. Some people don’t have them. How people describe their address varies (is it for billing, or their actual living location?). Postal systems occasionally change addresses to suit their own processes
Gender Male and Female. Except when neither is perfectly applicable. There are all sorts of laws and customs about gender change and confusion that vary highly from country to country. Mostly gender doesn’t change – it’s highly reliable, but not a very good differentiator between individuals, since the vast majority of people have one of only 2 values
Externally supplied identifiers The classic examples are driver’s licenses and passport numbers. But these are very unreliable – they are re-issued for all sorts of reasons that are only of interest to the issuing authority. And the issuing authority is also subject to all the same identification problems as well, and also often the target of fraud
Mother’s maiden name This is no longer a guaranteed to be available concept due to changes in naming practices. More generally, it’s used as a shared secret, and shared secrets have no part in identifying a person (won’t be secret once you share it, which is what identification is for)

Given the expense and difficulty of these lists, the notion of some state/national identifier becomes attractive – it makes meeting the expense of doing it properly more viable. The registration authority quality is still variable, but it’s generally better than doing it locally (it’s mainly an economy of scale thing). The biggest problem with this approach is that people lose their details all the time.  Until institutions or governments are able to mark people directly with a master identifier, say with a tattoo, this will be continue to be a problem (and given the historical association of identifying tattoo’s – I’ve seen one myself, from Bergen-Belsen, on a tough old Czech who had been in the resistance and was betrayed to the SS shortly after the assassination of Heydrich – it seems exceedingly unlikely that this will be  acceptable in any culture at all in the foreseeable future).  In addition, the registration authority rapidly becomes the target of fraud for a variety of reasons, mostly to do with how healthcare is funded, or to facilitate fraudulent access to higher quantities of prescription-only drugs. These problems can be resolved, and a successful national registry set up – it has happened in a few countries. However it appears to me that the prospects for success have more to do with national cultural factors than administration policy.

Healthcare is occasionally provided to people whose identity is completely unknown. They present unconscious, and care is hardly going to wait until they are conscious. In English speaking countries it is customary to refer to such patients as “John Doe” or “Jane Doe”. Usually their identity is resolved unless they die. (In one case at a hospital I worked at, a John Doe spent 3 weeks in ICU after an automotive accident. Even when he was conscious, he refused to provide any identifying details. Eventually he passed away, and his body was collected somewhat sheepishly by the staff from an embassy of an “unfriendly” country – still with no identification details provided)

New born babies also often do not have a name, though they are not unidentified (though identifying them is a challenge). Also there is a variety of contexts in which patients are not prepared to be identified. Sexual health clinics are a common case in the developed world, and Red Cross and other similar relief agencies often work with patients who refuse to be identified for a number of valid reasons.

All these problems are well recognized and appreciated in Healthcare Administration and Healthcare informatics texts books etc, but I cover them here because they have potential to cause difficulties in interoperability. It’s easy, when doing interoperability, to get trapped between two slightly different policies. On their own, they might each work about as well as the other – but when you try to hook up different business processes, the clash between them creates problems that are difficult to resolve.

Patient Merging

This is particularly true when it comes to patient merging.

Patient Sarah Smailes attends the emergency department at Acme Hospital with an acute attack of abdominal pain. She is admitted to the hospital for a Cholecystectomy. The emergency department clerical assistant who enters her details gets her name right, but mishears her birthday as 30-Mar 1973, not 13-Mar 1973, because of a screaming match between other patients in the background. Later that year, Sarah finds herself back at the hospital with a severe flu attack (H1N1?). The clerical assistant didn’t quite catch Sarah’s surname, and Sarah can’t be bothered telling the him about the previous admission – she’s too sick, and clerical assistant can’t find a Sarah Sm*** with a birth date of 13-Mar 1973, so he just creates a new patient entry. Now Sarah has two patient records. Later, in the ward, another clerical assistant over hears Sarah complaining about her treatment during the previous stay, and goes looking. He finds that the system has two records for her.

 There are several options for what happens now. One is to simply leave things as they are, with two different records. But this raises the prospect of a mistreatment due to missing information from her record, so hospital records staff are very reluctant to do this. Another is to create a “link” between the two records – an entry in the system claiming that they are the same patient. But this leaves another problem – which record should be used going forward? What happens when Sarah comes back next time? A third option is to instruct the system to merge those two records. This means that you pick one of the two records, and move all the information about it into the other record. The patient identifier associated with the first record is deprecated. All the hospital systems that have information about Sarah must follow suit, or their (potentially life-saving) information will in effect be lost.

Let’s try another scenario.

Sue, a Health Information manager finds that there is a record for Sarah Ann Smailes, born 30-Mar 1973, and a record from 6 months later for Sarah Ann Petersen, born 13-Mar 1973. Both records have the same address. Are these the same person? Sue decides that this is the same person, and merges the records.

 Is Sue right? Is this the same woman, now married, with a common typo in the birth date? Or is it a different person who happened to have similar details? It can be tremendously hard to tell, even upon investigation. Let’s say that in this case, Sue was wrong: they are different people, but now the records have been merged. The laboratory notices that this is in error (they have two blood groups that are incompatible, so they dig deeper and prove it’s wrong). Now what?

If the records were only linked, then the link can be broken. But if the records have been merged, and further details added to the record (which happens every few minutes in a busy hospital), now what? How do you unwind this? So merges are much more dangerous than links – except that this is misleading: if the records are linked, so that it is asserted that the two records are the same patient, how do we know that things have been done on the right record?

All we know for sure is that mistaken links or merges are trouble. Yet they happen all the time. My own experience is that in Australia, it’s extraordinarily hard to get the number of merges needed down below 1% of the admission rate, and about 2-3% of the merges will be in error for one reason or another. It seems remarkably hard to get down below these numbers.

So that’s the theory. Now imagine an interconnected system or systems, with the PAS at the hub, but many of the systems exchanging data with each other directly, not mediated by the hub, and with a variety of policies for following patient merges (or initiating their own), and the sibling problem, episodes assigned to the wrong patient. When you consider this picture, all you can say for sure is that no one who does healthcare interoperability is going to be out of work any time soon.

Representing Pathology reports in NEHTA Clinical Documents : Date Time Field

In a previous post, I discussed how to represent a pathology report in a NEHTA clinical document. As part of that post, I wrote that a pathology report has the following data item:

Test Result Date Time The clinically relevant time of the pathology test OBR-7

However there’s a problem associated with this data item. The definition of Pathology Test Result > Pathology Test Result DateTime is:

The date and, optionally, time of the Pathology Test Result observation. If the Pathology Test Result Duration is non-zero, it is the time at which the Pathology Test Result observation was completed, i.e. the date (and time) of the trailing edge of the Pathology Test Result Duration.

This explanation is not tremendously useful for helping implementers know what the actual date that goes in here is. And a number of implementers have found this difficult. The resolution for this is documented here (password protected – see previous postcontact me for a password if you don’t have one).

Note: I’ll update this post with a link to a non-password protected version once it is available. This is an important clarification for anyone reading or writing diagnostic investigations in NEHTA Clinical Documents.

NEHTA Clinical Documents: The importance of the FAQs

The NEHTA Clinical Document Specifications are available at the Software Developers Resource Centre (Note that these are registration protected, because you have to make certain legal agreements before you can use the documents, and also so that you can be notified of any changes). But anyone can register, and get access to these documents.

The core CDA implementation Guides – the specifications that describe the actual document that is exchanged or persisted in the pcEHR, and the things they depend on, were all published on March 14. Changing these implementation guides is not currently possible, a policy decision made in order to create a stable base for implementation. That’s both good – you do need a stable base – and bad: what do you do if the specifications are unclear or ambiguous, or – more importantly, how to implement them correctly is unclear or ambiguous?

In practice, we’ve managed this by releasing “FAQs” – answers to common implementation questions. These FAQs have generally been released on the vendor partner site at This is a password protected site, and the password is not available by registration. If you are implementing the NEHTA clinical documents, and you don’t have this password from a different source, contact me. Hopefully the FAQs will be moved to a public location very soon.

The FAQs are important. Anyone implementing NEHTA CDA documents should read all of them, and get on the update notification list for them.

Even the vendors that have access to them – and that are notified of updates to them – aren’t paying sufficient attention to them. Given that the specifications are frozen, the FAQs become more important – some of them offer important interpretations of how to use the specification. If you take the attitude that you’re not going to read them until you know that you need to… you’ll miss important stuff. I’m not sure what we can do to make people more aware of them (this blog post is part of an effort to raise their profile).

Here’s the current list (as of 24-Aug 2012) of CDA related FAQs:

Note there will be more of these in the coming days/weeks

IP Gambit Ploys

Given that all my work products are inteclletual property, I always pay a great deal of attention to matters of copyright, moral rights, patents and so forth in documents that I sign, particularly including contracts.

Documents that I am asked to sign always assert ownership rights tilted unreasonably towards the author of the agreement – that is, whoever paid the lawyers. Lawyers seem to be competing with each other to claim ever more complete ownership of the IP in any material. (I always negotiate them back to reasonableness, and generally people are happy to do this).

Today, I’ve seen a new high (or low): I’ve been asked to sign a document that cedes all the IP (copyright, moral rights, patents, registered trade marks etc) in a document I’m surprised to write to a third party, specifically including incorporated materials. And this document is supposed to be a report on current state of [something] (if I named it, I’d be naming the guilty party). A report like this can’t be written without extensively quoting other sources (fair use).

There’s no way that I can sign agreements like this – this IP is not mine to transfer ownership of. And the lawyer who wrote it must know this too – so why write this?

I can only think that this is yet another sign of a coming collapse in IP arrangements. Patent, Copyright, etc: now that the technology of sharing information has moved along so far, these existing arrangements are not serving us anymore.

Interpreting RIM Objects Safely (Exclusion Statements)

One of the most difficult parts of the RIM based content models – including CDA – is how to interpret and/or query them safely. In the past I volunteered to write something about this:

Grahame: As mentioned in Q1 MnM this morning, I volunteered to do this in the past. I agree that we need to progress this

I did spend some time on this, and it’s rather complicated (which meant I never finished it). In addition to being asked about the status of this earlier in the week, I was reminded of this forcefully when I saw Keith’s post about exclusion statements, which was in response to my earlier post about them.

Keith proposes to represent the assertion of a lack of allergies like this:

<observation classCode="OBS" moodCode="EVN" negationInd="true">
  <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>
  <statusCode code="completed"/>
   <value xsi:type="CD" code="419199007"
     codeSystem="2.16.840.1.113883.6.96" displayName="Allergy to Substance"/>

I have stripped out the templateId, id, and effectiveTime attributes, since they are not relevant to the subject at hand. On the other hand, I left statusCode in, since it’s relevant. This compares with the NEHTA representation of the same concept:

<observation classCode="OBS" moodCode="EVN">
  <code code="103.16302.120.1.1" codeSystem="" 
    displayName="Global Statement" />
  <value code="01" codeSystem="" 
    displayName="Nil Known" xsi:type="CD" />

These are rather different approaches. I don’t believe that either is wrong, though I admit that the representation Keith proposes is more aligned with general HL7 thinking. The NEHTA approach works differently because it is constrained to be an implementation of a solution to this problem based on an entirely independent definitional stack that starts from the definitions in openEHR. This has both strengths and weaknesses. The primary weakness is that it’s hard to be well aligned with the CCDA community. The strength is that you get a simpler solution. In this case, the exclusion statement, which was defined by the clinical consultation process is represented as “I observe (observation) that there are no allergies (global statement) because there are ‘nil known’ (value)” whereas Keith’s representation is “I observe (observation) that I can assert (Assertion) that the patient has allergies (value) NOT (negationInd)”.

The first note with regard to querying/interpreting RIM statements, then, is that you can say pretty much the same thing in completely different ways. This is a widely made observation, but worth repeating here. The RIM is essentially the grammar for a constrained language. Like all useful languages, there’s more than one way to say the same thing. You can say the same thing in several different ways. The same thing can be said in multiple forms. I don’t think that it’s possible to strip the RIM down to the point where there’s only one way to say things without removing the ability to say many things that need to be said. In particular, I don’t think that removing the flexibility to choose between structure and terminology – the source of much of this variation – is possible or useful.

The second note is that you can’t really start to understand RIM statements until you understand the terminologies. This is no different to saying that you can’t understand English until you know what the words mean. But implementation is still highly focused on the structures, and formal terminology support in applications lags far behind. Safe interpretation of RIM statements depends on solid and correct interpretation and usage of the terms. I won’t pursue this further in this post other than to say, this is a hard thing to get right.

In NEHTA, the clinicians are very insistent about the limited scope of the negation statement: they are never claiming that the patient does not have any allergies – only that none are known. This is pretty important to clinicians. But there’s a common language substitution that happens, between “We (patient and clinician) don’t know of any allergies” and “there are no allergies”. This same substitution happens in the RIM, and is evident in Keith’s example. I’m sure that Keith would be happy to confirm that there is no intent to claim that there is certain knowledge that the patient has no undiscovered allergies – but that’s actually what the RIM statement he offers claims. Generally, my view is that the RIM is weak on negation – there’s often a scope limitation on negation and the RIM doesn’t really capture that. (In the same way, the RIM is weak around uncertainty. Note though, that both these things are tremendously hard to describe).

But there’s some much simpler things that Keith’s example brings up

Be careful interpreting RIM Statements

Consider the difference in Keith’s xml between an assertion that a patient does have allergies, and that none are known:

 <observation classCode="OBS" moodCode="EVN">
  <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>
  <value xsi:type="CD" code="419199007"
     codeSystem="2.16.840.1.113883.6.96" displayName="Allergy to Substance"/>


 <observation classCode="OBS" moodCode="EVN" negationInd="true">
  <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>
  <value xsi:type="CD" code="419199007"
     codeSystem="2.16.840.1.113883.6.96" displayName="Allergy to Substance"/>

An important consequence of this is that whenever you look at an observation, you have to check whether it’s been negated. I’m sure that most implementers of CCDA aren’t checking whether the observations as described in CCDA are negated or not, since CCDA doesn’t say that they can be – but since they can be, you have to check. Painful, and I’m sure that this is going to prove to be the source of a number of adverse patient outcomes.

Note that the first example is that the patient is allergic to a substance, but with no substance. In practice, who’s ever going to say that, or try to read it without an error? So, at least in this context, the negationInd doesn’t stand alone. But consider a system that wanted to claim that the patient wasn’t allergic to tree nuts (my daughter is allergic to tree nuts, so this example comes naturally):

<observation classCode="OBS" moodCode="EVN" negationInd="true">
   <templateId root="2.16.840.1.113883."/>
   <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>
   <value xsi:type="CD" code="282100009" codeSystem="2.16.840.1.113883.6.96"/>  
   <participant typeCode="CSM">
    <participantRole classCode="MANU">
     <playingEntity classCode="MMAT">
      <code code="FFY6MYO89N" displayName="TREE NUT"

The only way to pick is to explicitly read the negationInd. So, you must always consult the negationInd. I doubt that many implementers mining data from (C)CDA documents know that this is possible, or remember to do it every time.

Aside: this is not allowed in NEHTA documents. If an element is not explicitly described in the implementation guide, it cannot be used if it’s not safe to ignore. Clearly, negationInd is not safe to ignore. CCDA seems to allow it anywhere – it never says it is not allowed, which makes rules like “MAY contain zero or one [0..1] @negationInd” rather confusing. (oh, if a CCDA template is closed, then it can’t have a @negationInd, but there was only one of those as of the last ballot).

Keiths’s second example is this:

<observation classCode="OBS" moodCode="EVN" nullFlavor="NI">
   <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>
   <value xsi:type="CD" code="419199007"
     codeSystem="2.16.840.1.113883.6.96" displayName="Allergy to Substance"/>

This one is very subtle – there’s a nullFlavor on the observation, which means that all the content in the observation pertains to the thing that we don’t have any information about. It can be difficult to to interpret the scope of the NI – is the assertion that we have no information about? or the value? here, it’s probably not much difference. But not in other places. But the point is, you have to check the nullFlavor on the observation.

In a later post, I’ll get to the really complicated question (what my original intent was) – to what degree you have to walk up the heirarchy looking for @nullFlavor, @negationInd, and other things?

Unknown / Default Information

Keith’s example includes statusCode, with a status of completed. We eliminated this from the NEHTA representation because it’s just irrelevant to an implementer – what would it mean for the observation to be aborted? cancelled? suspended? Only one possible value makes sense, which is completed, so we eliminated this from the XML as just random noise that would confuse the implementers. But eliminating it leaves open the question, what is the value, and would it matter? It depends on context. But CDA itself eliminates uncertaintyCode, so you can never be sure whether an observation is uncertain or not – unless you are aware of any applicable guidance from the implementation guide.

So a final point (for this post) about interpreting RIM statements: it can only safely be done in partnership with good knowledge of the rules that were applied where the instance was generated. If you don’t know what these are, you won’t know how to intepret the content.

NEHTA Clinical Documents: SHS Medical History

In previous posts (here and here) I covered the exclusion statement. Now I can move on to talking about the SHS Medical History Section, which contains a simple list of a patient’s past procedures and problems/diagnoses.


Note, before I go on, that there are fundamental and important challenges around the question of what are procedures, and what are problems/diagnoses:

  • Is counselling a procedure?
  • Is “pregnancy” a problem or diagnosis?
  • Is “family history of heart disease” a problem?
  • What’s the difference between a problem and an alert, and also an adverse reaction?

This post is not about exploring these questions, but they are not irrelevant. These are official definitions (from the SCS):

Procedure A clinical activity carried out for therapeutic, evaluative, investigative, screening or diagnostic purposes
Problem/Diagnosis The problems and/or diagnoses that form part of the past and current medical history of the subject of care.An account of relevant identified health related problems as reported by a healthcare provider. This can include a disease, condition, injury , poisoning, sign, symptom, abnormal finding, complaint, or other factor influencing health status as assessed by a healthcare provider.

Section Design

The general design of the Medical History is:

  • A CDA section
  • a list of Problems/Diagoses, or an exclusion statement
    • Problems/Diagnoses have a code that identifies them, a date of onset, a date of resolution/remission, and a comment
  • a list of procedures, or an exclusion statement
    • Procedures have a code that identifies them, a comment, and a date on which they started
  • A list of “Other Medical History” items
    • Other Medical History Items have text description, an interval during which they applied or occurred, and a comment

This SHS section was intended to be a simple statement of a person’s medical history – as simple as possible. But 2 things complicate it considerably: dual exclusion statements, and the presence of “Other Medical History Item” means that it is far from simple.

Dual Exclusion Statements

Although, in the simplified SHS section, Procedure and Problem/Diagnosis contain very similar content, in general, their content is different, and so they are treated differently through the entire stack (archetypes in the clinical knowledge manager, DCMs derived from them, Core Information Components, SCSs, and in CDA itself. Hence, the Medical History list is broken into the two parts.

But because of the way the underlying definitional methodology works, we end up with two exclusion statements – one for procedures, and one for problems/diagnoses. From a strictly informational perspective, this makes sense: The patient has no listed procedures, a long with a reason (if it’s “nil known”, there’s generally not a lot of uncertainty about this one), and/or they have no known problems/diagnoses (young, and lucky – for now).

It’s important, though, to understand that fundamentally this is conceived of as a single list – the patient’s medical history, just with variant parts. From a user point of view, then, this a little difficult to present. If a patient has past procedures, but no problems/diagnoses, how do you present this?

Putting aside the obvious implicit relationship between procedures and problems as demonstrated here, this is just difficult to present. Especially since the user thinks of these as a combined list, and mostly edits them accordingly in their software (though not always – clinical systems vary wildly on this).

Other Medical History Item

Would that this was the only problem. However it’s worse than that – the common GP systems (planned  to be the major source of SHS generation) not only maintain a single list “medical history”, they are unable to determine the difference between procedures and problems/diagnoses. Usually this is because the coding systems they use (ICPC 2+, Docle, home grown or user defined code lists) don’t include the structural support to resolve the code to either a problem or a procedure (also, some of them allow symptoms and medications as proxies for problems or procedures). So although the methodology calls for separation between problem and procedure, not all the systems are able to do so – but some are.

Aside: If all the systems adopted Snomed-CT, and the users changed their practice when it comes to recording the medical history so that it was more rigorous, then we wouldn’t have to worry about this. But even if this magically happened instantly (as in, in the next 5 years), we’d still have decades worth of legacy data that we would want in SHSs. And it’s going to take a lot longer than 5 years to get clinicians to see the value – if it does exist – in spending a lot more time coding the medical history (that depends on how clinical decision support unfolds, which is not the subject of this post). So we have to solve this problem

The solution then is that we introduce “other medical history” – an entry in the list that is not known to be a procedure or a problem. It would be simpler to collapse both procedure and problem to a single content model, but this would lose the capability to differentiate them that some systems have, and it would either mean that you couldn’t differentiate them in other more sophisticated documents than the SHS, or these other documents would not have continuity with the SHS – which generates a whole slew of downstream problems.

Hence, we now have a list of 3 types of items: problem, procedure, or something that might be either?

What, then, is the effect of this on the exclusion statements? Well, if you have an “other” item, it might be a procedure, or a problem – you don’t know. So you can hardly make an exclusion statement about either of them in this case. This leads to the following rules:

  • If you have any entries in the “Other Medical History Item” list, then you can’t have an exclusion statement for either Procedures or Problems/Diagnoses
  • If you have neither procedures or other items, then you need a procedure exclusion statement
  • If you have neither problems/diagnoses or other items, then you need a problems/diagnoses exclusion statement

Because these rules are not clearly documented in the CDA Ig or the SCS, it has created much confusion – especially around people wanting a separate exclusion statement for Other Medical History Item. But this can’t be – it would only make the clinical problem worse.

In practice, there’s mostly only one exclusion statement – and this is actually implemented in most of the GP systems, where the user get’s to say “Nil known medical history” or something equivalent to this. This produces an exclusion statement for both procedures and problems/diagnoses.

Other Issues

There’s an additional problem here: the definitions of both Problem/Diagnosis and Procedure are loose and a bit tautological. In practice, things don’t go in them if they can go anywhere else. For instance, an adverse reaction – but a coding system that can’t differentiate between problem and procedure isn’t going to differentiate between them and an adverse reaction either. But there’s nothing we can do about that for now – adverse reactions will be found in either place. And when family history, alerts, etc are introduced in the other documents and maybe in the SHS, then that problem will become worse.

In terms of presenting this structure to the users, most of the systems have gone for a differentiated list like this:

Actually, this comes from a NEHTA sample for testing CDA rendering. From a real clinical system it would be unusual – it would imply that the system was able to differentiate two of the conditions but not a third (might happen if a coding system was upgraded, for example). So it’s not technically wrong.

But from a user point of view, separating the lists like this is sub-optimal. There should only be one list in chronological order – this is the medical history, a list of problems and procedures that have all sorts of implications between each other, and that tell a history. So one list:

Obviously the more dates you have, the more useful the list becomes. But these depends on the source system and the clinician who entered the data.


NEHTA Clinical Documents: Exclusion Statements 2

As promised in the last post, this is a summary of the sections in the 5 main clinical documents, which sections are required to be present, and which have exclusion statements:

Section Required? Exclusion Statement?
Adverse Reactions Yes Yes
Medications Yes Yes
Medical History Yes Yes (2)
Immunisations Yes Yes
Referral Detail Yes N/A
Medical History Yes No
Medications Yes Yes
Adverse Reactions Yes Yes
Diagnostic Investigations & sub-sections No No
Specialist Letter
Response Details Yes N/A
Recommendations Yes Yes
Medications Yes Yes
Newly Identified Adverse Reactions No No
Diagnostic Investigations & sub-sections No No
Event Summary
Event Details No No
Newly Identified Adverse Reactions No No
Medications No No
Diagnoses/Interventions No No
Immunisations No No
Diagnostic Investigations & sub-sections No No
Discharge Summary
Clinical Synopsis Yes N/A
Problems/Diagnoses this visit Yes Yes
Clinical Interventions Performed No No
Current Medications Yes Yes
Ceased Medications Yes Yes
Adverse Reactions Yes Yes
Alerts No No
Arranged Services No No
Record of Recommendations Yes No
Diagnostic Investigations & sub-sections No No

Generally, mandatory sections have exclusion statements. There’s a few exceptions, where the requirements analysis has indicated that there is always (or should be always) at least one value, and so the mandatory sections don’t allow exclusion statements. For instance, a discharge summary must have at least one recommendation. And notably – e-Referral Medical History. Another kind of exception is the clinical synopsis type sections, which are free formatted text – there’s no sense having exclusion statements for them.

Generally, optional sections don’t have exclusion statements; you just leave the section out. Since this leaves a clinical message gap, I think this will be reviewed for the next release (some time next year, maybe?).

The other document types (Advance Care Directive, Consumer Documents, and the Medicare documents) don’t have exclusion statements in them – though I personally think that there should be exclusion statements for medications and adverse reactions in the Consumer Entered Health Summary.

Note that the SHS Medical History has 2 exclusion statements. This rather complicated model will be discussed in the next post.


NEHTA Clinical Documents: ANZSCO codes

One of the coded values that appears throughout the NEHTA Clinical documents is ANZSCO (Australian and New Zealand Standard Classification of Occupations) codes. Most participants – particularly healthcare providers –  have a required code that indicates their occupation. This was not expected to be a problem because assigning an ANZSCO code is part of registration for an HPI-I, and therefore it was expected that sourcing the ANZSCO code would be straight-forward. However HPI-I take up is slow (see this Australian Article, or here if you aren’t registered). If there’s no HPI-I – and you don’t know the ANZSCO code for the provider – then what do you do? This leads you into an easily misunderstood area of ANZSCO itself.

ANZSCO itself is available from the ABS Website. From here, you can download a PDF version of the ANZSCO codes. The PDF lists specific occupation codes, by code. Here’s a sample:

  • 253 Medical Practitioner
    • 2539 Other Medical Practitioners
      • 253911 Dermatologist
      • 253912 Emergency Medicine Specialist
      • 253913 Obstetrician and Gynaecologist
      • 253914 Ophthalmologist
      • 253915 Pathologist
      • 253916 Radiologist
      • 253999 Medical Practitioners nec

This sample shows the structure of the coding system – the digits work from the left providing levels of categorisation:

  • 2 – Professionals
  • 25 – Health Professionals
  • 253 – Medical Practitioner
  • etc

The problem is that the correct full 6 digit code is not known because of the missing HPI-I infrastructure. There’s an easily missed section of the PDF document that explains what to do in this case (page 19):

For example, responses which cannot be identified as relating directly to a particular occupation category, but which are known to be within the range of occupations within a particular unit group are coded to that unit group. Such responses are allocated an nfd code consisting of the four-digit code of the unit group followed by ’00’. For instance, the response ‘Internal Medicine Specialist’ does not contain sufficient information to be coded directly to any particular occupation category, but it can be coded to Unit Group 2533 Internal Medicine Specialist, which encompasses all internal medicine specialists. It is thus allocated the code 253300 Internal Medicine Specialists, nfd.

So, if you don’t know what the exact ANZSCO code is, but you do know that the author is some kind of medical practitioner (this is a fact that operational clinical systems do generally keep, unlike the precise occupation), then you can assign the code 253000. This code will be the most commonly used ANZSCO code until HPI-Is start being widely used, though you could expect to see 250000 too.

I’m making this post because there’s some confusion about this – people using 253 instead of 253000, or systems not accepting 253000 as a valid code, etc.

p.s. Note the ANZSCO codes are another example of a code system that overlaps with nullFlavors, in that it defines the code 999999: “Not stated”

Update: two related questions around Revision 1 of the ANZSCO codes:

  • Does revision 1 apply? The specific reference to ANZSCO in the CDA implementation guides is “Australian Bureau Of Statistics, September 2006, 1220.0 – ANZSCO – Australian and New Zealand Standard Classification of Occupations, First Edition, 2006 – METeOR 350899, accessed 15 March 2010. [ABS2006] .au/ausstats/abs@.nsf/mf/1220.0”. Given that revision 1 was released in 2009, it would appear to mean that revision 1 applies
  • Revision 1 doesn’t mention code “X” (i.e. 253111) so it isn’t valid anymore? This isn’t true – Revision 1 is a delta document – it only describes changes to the basic codes. Unless it specifically rescinds a code (deletion/merging), then the code remains valid. The only code removed in healthcare: 253916 Radiologist was retired (253917 and 253918 were added in it’s place). (Other additional codes were added)



NEHTA Clinical Documents: Exclusion Statements

This is the first of a series of posts looking at implementation issues associated with NEHTA clinical documents. These are based on the common questions I get from implementers. The focus of the first few posts is going to be the “Medical History” Section in the SHS, and the related sections in other documents. But before I can consider those sections in detail, I need to talk about Exclusion Statements in general.

Many sections in the NEHTA Clinical Documents include an exclusion statement. The exclusion statement idea is adapted from openEHR. A typical use is in the Adverse Reactions, where you can list an series of adverse reactions, like this:

Well, that’s a single adverse reaction, and pretty straight forward. But what does it mean if the list is empty?Well, that might mean:

  • The system didn’t populate the section at all
  • The clinical user didn’t ask (or otherwise investigate)
  • The clinical user or the patient decided not to include any adverse reactions for their own reasons (ok, that’s silly for adverse reactions, but would make more sense for a medication that betrayed some sensitive problem, for instance)
  • the patient doesn’t have any known allergies

It might be possible to try handling these through a variety of nullFlavors (NI, NASK, ?, NA?) but that would be wrong: the last three, and particularly the important last one are statements of knowledge, not reason values for missing adverse reactions.

So to handle this, there’s a positive statement, called a global exclusion statement. You either provide 1 or more items (Adverse Reactions in this case), or an exclusion statement to explain why there’s no items in the list. The possible values for the exclusion statement are:

Code displayName
01 None known
02 Not asked
03 None supplied

This would be represented in CDA like this:

 <observation classCode="OBS" moodCode="EVN">
  <code code="103.16302.120.1.1" codeSystem="" 
    displayName="Global Statement" />
  <value code="02" codeSystem="" 
    displayName="Not asked" xsi:type="CD" />

The blue part – that code changes for the different exclusion statements to be clear about what the exclusion statement concerns.

Alert v3 type users might challenge the last value – none supplied; this crosses the line into nullFlavor territory. And maybe it is, but only partially. And it’s a lot cleaner to make a simple rule: either you have items, or an exclusion statement, but not both.

One issue with this is that the codes are not well defined. Here’s proper definitions for the codes above (sourced from here, but it’s behind a firewall):

“None Known” is a positive clinical statement that  investigation has not found any items:

  • For allergies, the patientor patient’s agent/guardian has asserted that he/she is not aware of any allergies (NKA – nil known all ergies)
  • For medications, the patient  or patient’s agent/guardian has asserted that the patient  is known to be taking no medications
  • For diagnoses, problems and procedures: the patientor patient’s agent/guardianhasasserted that there isno known events torecord.

“Not asked” is an affirmation from a clinical user  that they have not been able to ask the patient (for whatever reason)

“None supplied” is the default position, to be used when:

  • The patient or the clinical user choose to withhold information
  • The database lists nothing for the category, but it is not known whether the other two categories apply.

These definitions are important – programmers have a tendency to choose “nil known” when the database is empty, but this needs to be reserved for a clinical statement, not simply the absence of information.