How to identify AMT in CDA documents and HL7 messages

Nov 25, 2011

One of the more controversial subjects that came up yesterday at the HL7 Australia meeting was how to represent AMT in CDA documents, and HL7 messages. The fundamental question is whether AMT is identified as the same coding system as SNOMED-CT or not. For CDA, this means, using the same OID (2.16.840.1.113883.6.96) in the CD.codeSystem attribute. For v2, this means using the same code in component 3 of the CE or CWE data type, which is used in many fields through the v2 message. (in terms of the actual code, some existing implementers are using “Snomed-CT” or “SNOMED-CT” for this, but in v2.6, HL7 settled on “SCT”. Our usual practice in IT-14-x committees would be to pre-adopt the SCT code, but no decision has been made on this one)

There’s several reasons why AMT should be identified as the same code system as Snomed-CT:

  • AMT uses the same logical infrastructure as Snomed-CT
  • AMT has the same root concept, and also the is-a concept is the same
  • AMT is distributed using the Snomed-CT distribution format
  • AMT uses an allocated Snomed-CT extension namespace, and IHTSDO has ruled that codes in the extension namespace of Snomed-CT are identified as part of the Snomed-CT code system. HL7 has agreed with this
  • At some point in the future, AMT will be distributed as part of Snomed-CT AU

For that reason, when AMT codes are exchanged in CDA documents they should have a codeSystem of 2.16.840.1.113883.6.96, and when they are exchanged in v2 messages, they should have a codeSystem of “SCT”. (the same applies to Snomed-CT AU, btw - it’s still Snomed)

That raises the obvious question, “hang on, how do you know that this is an AMT code as opposed to a SNOMED-CT code?” - and you do need to know this, since AMT is distributed separately from Snomed-CT (AU). The correct answer from HL7’s perspective is that this part of the codeSystemVersion attribute on CD, or components 7 & 8 on the CWE data type. Which really implies the same for CE. Hl7 never added codeSystem Version attributes to CE because it was deprecated and split to CWE and CNE. But it would make sense for us to pre-adopt components 7 & 8 on the CE data type).

Actually, that obvious question from the last paragraph isn’t that obvious - why do you need to know what kind of code it is? if you can’t figure out what kind of code it is for yourself, why would you care? It sounds like a bad system design driving interface specifications to me.

The problem with that is that IHTSDO is still to finalise the version string that should be used. The current candidate mapping is:

http://snomed.info/{?m,v}

where:

  • m is a Module Id
  • v is an effectiveTime

The syntax is a URI Template (http://tools.ietf.org/html/ ), and it unfolds to either of http://snomed.info/?m=

Even if this is finalised anytime soon, it’s hardly an obvious way to do the version references, and it would be nice to get something more directly applicable. (i.e. which version is that referring to?)Arguments people have given not use the same ID:

  • the problems with the version attribute above,

Yes, that’s a problem. It was hoped that IHTSDO would have resolved this by now, but it hasn’t.

  •   AMT uses longer descriptions than Snomed-CT allows.

This doesn’t seem to be true - the length limit for RF1 releases is 255 chars.

  • AMT hasn’t been good at following the guidelines for Snomed-CT extensions so it isn’t an extension

Well, even if that were true, Snomed-CT still thinks of it as an extension. It seems like a bad argument that because AMT hasn’t followed some rule or other of IHTSDO, we’ll break another one. Note that by the terms of the SNOMED CT licence, AMT is an “Extension” (this concept is defined in the licence).  If anyone wants to argue in the comments that it is not an extension (you know who you are!), then you’ll need to be more specific about why.

  •  It’s not practical to use the codeSystemVersion to pick AMT releases like that - hardly anyone uses a code system version

Well, that’s kind of like saying, we’re doing it wrong, let’s keep doing it wrong.

I’m not really happy with the approach to use the SNOMED-CT id for AMT, mostly because of the mess with the coding system version. But it’s not up to me - IHTSDO has ruled that snomed extensions - codes defined in an IHSTDO issued namespace - are represented as part of Snomed-CT.

Thanks to Michael Lawley for assistance with this post.

p.s. There’s another argument advanced that the different parts of AMT need to be identified. When I understand the rationale for that better, I’ll make another post about that