Response to comments on NEHTA ETP specification by Medical Objects
Jul 21, 2011Yesterday at the HL7 Australia meeting, Jarrod Davison from Medical Objects made a presentation about the NEHTA ETP (Electronic Transfer of Prescriptions) that was highly critical of the specification. Unfortunately it was a little misinformed, misleading, and in some respects, simply wrong.
Due to timing constraints, there was no opportunity to make comments at the appropriate time at the meeting, so none of what Jarrod said was challenged. Given that the event was sponsored by NEHTA, and that NEHTA asked many of its partners to attend the meeting, I have been asked to respond to the most pressing issues here, lest people think that NEHTA is not in a position to make any response.
Before I go on, I want to make it clear that I contract part time to NEHTA, and that part of ETP is my work, though I’m only a small part of a large team (and, btw, this post is my work, not an official response from NEHTA). Now I’m not against criticising NEHTA – even publically; if NEHTA gets it wrong, there’s no reason not to say so. But if you’re going to criticise NEHTA at an industry event, you’d better get it right.
Jarrod’s criticisms of ETP fell into several categories. I’ll deal with the most serious issue first.
Where’s the atomic data?
Jarrod showed this slide:
In this discussion, Jarrod talked about having to try and extract the atomic data out of this tabular form, and criticised ETP for not containing atomic data.
“Where is the atomic data in the example?” The answer is “60 lines further down in the example”:
(btw, the source for this example is inside http://www.nehta.gov.au/component/docman/doc_download/1221-11s-e-prescription-cda-schema-v31)
If Jarrod had only looked… in fact, anyone who understood CDA would have known where to look.
One CDA document per prescription item
Jarrod showed this slide:
This is from the data hierarchy summary of the document: one prescription item per ETP prescription document. When Jarrod put this slide up, I was pretty taken aback. It doesn’t make sense – a prescription is a document that may contain multiple line items (this is standard clinical practice here in Australia), and that’s exactly what Jarrod had to say. I thought that there must have been a typo somewhere or something – it was certainly multiple prescription items when I worked on the CDA mappings. But no, it’s not a typo, this is deliberate, I found out, after digging around.
Having one item per prescription document simplifies both system design and pharmacy workflow in the case of NEHTA’s ETP solution. The pharmacy workflow is the primary issue. Where a prescription contains multiple items, the pharmacist can choose to dispense one, some, or all of them. In the ETP solution, the pharmacy dispensing processes is driven by the pharmacist scanning the DAK off the paper form. The R1 design was heavily criticised by pharmacy stakeholders for the fact that after scanning the DAK, they still had to choose which item was to be dispensed. They demanded one DAK per item. This could have been achieved by extending the DAK with an item number but we would have sacrificed precious bits of encryption (given hard limits on barcode length). Multiple items also complicates repeat management, as there is a single item per dispense record and a need to manage separate repeat counts per item.
All of the above challenges are manageable, and ETP have defined a more complicated solution that allowed multiple items per prescription. However, through every discussion with every stakeholder, reason was found to have more than one item per prescription. There were of course perceptions that multiple items were a good thing, but the prescribing system can still prescribe multiple items on a single screen and in a single medical record entry, but then generate individual prescription documents for each one behind the scenes.
So there is a simple equation of some additional repeat management complexity and the sacrifice of precious encryption bits for zero benefit. But in the underlying clinical model the prescription item is repeating, and in general models where there does need to be a single document with multiple prescriptions, there can be (and would be).
So there’s a good reason why ETP has one prescription item per document. People might disagree (for instance, as Jarrod said, it means that you’ll have to move around a set of documents), but I think it’s important to understand the reasoning before criticising the specification (especially in public) – you just have to ask (better if the reasoning was explicit in the standard – I haven’t got round to checking whether it is or not).
Use of OPC Zip
CDA documents are actually bundles or packages. This post is too long to take that up, and it’s a subject in its own right, so I’m going to do that in a later post. The ETP specification as presented to Standards Australia says that the CDA package is contained in an OPC Zip package. The OPC zip package specification is the same storage format used in a .docx file, and is an ISO standard (ISO/IEC 29500-2).
Jarrod was critical of this – why not choose a domain relevant standard? (I.e. something that has actually been used in healthcare before). Why not use MIME, like as in the MTHML standard, or as recommended in the CDA specification itself in section 3? (Again, instead of asking us why, Jarrod speculated about us choosing OPC/zip because of concerns about data size).
Well, our natural first instinct was to use a MIME package – it’s an obvious thing to do. But we didn’t stop there. IHE didn’t use MIME – they used .zip. So we asked them why not, and the relevant experts said that they had tried MIME, but had too many tooling consistency issues when they tested implementations (private communication, I can’t find any reference to this in public).
So for XDM, IHE used zip not mime. So we considered using XDM. There’s a couple of reasons not use XDM: it’s really a solution for packaging multiple CDA documents together – and that carries complexity we didn’t need. Also, it includes the XDS metadata in the package, which is a great deal of complexity that wasn’t relevant, and we didn’t want to impose that on the implementers.
So we wanted a .zip file, consistent with IHE, and just a real light manifest that describes which parts are document, digital signature and attachments. Well, that’s what OPC is. And it’s an ISO standard, widely adopted, not too hard to implement, and comes with pre-built open source implementations in java and dotnet. So it seems like an obvious choice.
But it’s not one that’s been used in healthcare before. The great thing about standards is that there’s so many to choose from. And the thing about being NEHTA is that if you choose a healthcare specific standard, people will criticise you for choosing a weird healthcare specific one, and if you choose one that isn’t, people will criticise you for that too.
Though in this case, I don’t think this OPC Zip thing is the final word. The standards community is still pushing for XDM, in spite of the fact that this is much harder for implementers (well, parts of the community are, and I suspect they’ve got the numbers to win the day on the IT-14 committees). And it’s probably going to be mime packages in v2 in spite of the spectre of tooling difficulties.
Using CDA at all
I’m going to stop there, though I could go on. I think I can reasonably distil the rest of Jarrod’s comments down to a simple question:
“We have v2 messaging working now using an Australian standard, and it works sort of well – why not just use that for ETP”
That’s actually a reasonable question when phrased like that, and one on which there has been much debate.
All I’m going to say here is that in my experience of v2, achieving meaningful conformance is hard, and the way v2 messages confuse content and transport makes doing meaningful digital signatures real hard (a quick scan of the forthcoming ATS for signing HL7 v2 content makes that quite obvious) . Using CDA documents brings many advantages to the picture. Only time will tell whether the ETP package has made the correct choice.