Vocabulary Issues. HL7 Concept Codes Mnemonic vs Numeric
-
Upload
julia-arnold -
Category
Documents
-
view
226 -
download
1
Transcript of 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?...)