Vocabulary Issues. HL7 Concept Codes Mnemonic vs Numeric

Vocabulary Issues

HL7 Concept Codes‘Mnemonic’ vs Numeric

<administrative_gender_cd

C="M"

D="Male"

S="&HL7.USA.Gender"

R="3.0"/>

<administrative_gender_cd

C=“10173"

D="Male"

S="&HL7.USA"

R="3.0"/>

‘Mnemonic’ Codes

• NOT a mandate to use mnemonics

• With relatively small code sets (~2-50 codes), it would be permissible to use an alpha-numeric concept codes that may provide ‘hints’ about the referenced concept

• -

‘Mnemonic’ Codes(Continued)

• Once assigned, codes could not be changed:

Code Designation

MG Medium Granularity

IG Intermediate Granularity

Numeric Codes

• Unique, meaningless identifier assigned from HL7 V3 namespace

Mnemonic Codes

• Advantages– Compatible w/ HL7 V2– More intuitive and

directly human readable

– If folks intend to use them anyway, we might as well deal with them for what they are

• Disadvantages– Issues resulting from

confusion w/ designations

– English-centric– Potentially misleading

if incorrectly interpreted

– Smaller namespace

‘M’ vs 10173

Numeric Codes

• Advantages– Reduces possibility of

misinterpretation– Reduces (but doesn’t

eliminate) language / case / character set / multi code issues

– Reduces potential for confusion (‘M’ – Male, Married, …)

• Disadvantages– Requires outside

resources to interpret– Requires central

number assignment– Not directly compatible

with existing HL7 V2 codes

We could have it both ways

• Code System 2.16.840.1.113883.5.1‘M’ Male‘F’ Female‘UN’ Unknown

• Code System 2.16.840.1.113883.510173 Male10174 Female10175 Unknown

• Map2.16.840.1.113883.5.1 M : 2.16.840.1.113883.5 10173

2.16.840.1.113883.5.1 F : 2.16.840.1.113883.5 10174

Questions

1) Should we allow the assignment of alpha-numeric concept codes in the HL7 V3 Code Systems?

2) If the answer to 1 is yes, should we support both schemes with a mapping or abandon the unique (within the HL7 V3 namespace) numbers completely?

Vocabulary Issues

Issue 2: Multiple Codes per Concept

Multiple Codes per Concept

<route_cd

C=“PO”

D=“Swallow, Oral"

S="RouteOfAdministration"

R="3.0"/>

<route_cd

C=“ORAL”

D=“Swallow, Oral"

S="RouteOfAdministration"

R="3.0"/>

Multiple Codes per Concept

• Depending on earlier decision, may or may not be an issue for HL7 internal codes

• Still have to address external code sets

• Question: Do we need to support multiple codes per concept?

Vocabulary Issues

Issue 3: Case Sensitive Codes

Case Sensitive Codes

<unit_code

C=“m”

D=“milli"

S=“UnitsOfMeasure"

R="3.0"/>

<route_cd

C=“M”

D=“Meter"

S=“UnitsOfMeasure"

R="3.0"/>

Case Sensitive Codes

• Issues1) Many SQL databases (including Access)

default to case insensitive

2) Possibility for confusion

3) Cannot control external code content

Case Sensitive Codes

• Proposed policya) No two concept codes within the same code

system may have the same value if case is ignored

uL (microLiter) UL (Underline)

b) Codes must match the case in the code system

<units c=“UL” ….

Vocabulary Issues

Issue 4: Code Character Set

Code Character Set

• Question: Do we support concept codes drawn from non 8859-1 character sets?

Vocabulary Issues

Issue 5: ISO Code Sets

ISO Code Sets

• HL7 supports 3 categories of code system:– Internal– External– Imported

• Question: How do we deal with language codes, country codes, etc?

ISO Code Sets

• Policy as it stands today– ISO: You can publish for free but vendors

must purchase a license (~$100-200 per ???)– ANSI: You have to pay us $1000 just to

publish the codes

• ISO codes are widely used (but not widely paid for)

ISO Code Sets

• Do we:A) Purchase the code sets and request that the

vendors / institutions purchase licenses?

B) Try to negotiate a package deal?

C) Build our own? If so, how should translation be handled?

D) Eliminate imported category for priced systems?

E) Continue to research options? (How does W3C do it? How about IETF? UN? Post Office?...)