${taskforce.name} Avatar
  1. OMG Task Force

LQS RTF 2 — Open Issues

  • Key: LQS11
  • Issues Count: 1
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
LQS11-1 LQS: parsing of QualifiedNameStrs LQS 1.1 open

Issues Descriptions

LQS: parsing of QualifiedNameStrs

  • Key: LQS11-1
  • Legacy Issue Number: 7597
  • Status: open  
  • Source: Foundation for Research and Technology ( Stelios Sfakianakis)
  • Summary:

    According to the LQS specification (00-06-31), paragraph 2.1.4, the
    delimiter between a NamingEntity (NE) and a LocalName (LN) is the
    character '/', possibly excluding only the case of the 'OTHER'
    RegistrationAuthority.

    Reading this paragraph it is clear to me that in order to parse a
    QualifiedNameStr that starts with "DNS", "ISO", "DCE" (so that it's
    not 'IDL' or 'OTHER'), the first '/' is the delimiter between a NE
    and a LN, which also means that, in these cases, a '/' is not
    permitted inside a NE. If a QualifiedNameStr starts with "IDL" then
    the delimiter is the last occurence of '/'.

    The problem is that subsequent paragraphs in the specification (and
    also coding schemes and codes defined in the idls of LQS) DO NOT use
    these rules. For example the ICD-9-CM coding scheme should be
    represented as "DNS:hl7.omg.org/I9C" according to par. 3.5, which
    clearly is illegal because it uses the slash character inside the NE
    (which is the "hl7.omg.org/I9C"). There are numerous such cases
    throughout the spec.

    It is clear that if this kind of QualifiedNameStrs is acceptable then
    it is not feasible to have a "generic" implementation of the
    translation_library's str_to_qualified_code method: If I have a PIDS
    that supports a trait to represent the patient's spoken language and
    as a value I get the string "DNS:usmarc.omg.org/041/ENG" (par. 3.6)
    then according to 2.1.4 I should search LQS for the coding scheme
    "DNS:usmarc.omg.org" but I would probably find nothing because the
    ''correct'' coding scheme is "DNS:usmarc.omg.org/041" (par. 3.5). Thus
    I should be aware that when I see such codes, the coding scheme is the
    "DNS:usmarc.omg.org/041" and the rest is the concept code. But this
    forces me, as implementer of the translation library, to know all the
    possible coding schemes in order to parse them correctly.

    So my questions are:

    • Are the remarks mentioned above correct and well known?
    • If yes how the OMG is going to tackle this issue?
    • If the OMG considers it too costly to change all the examples in
      the spec. and the stringified coding schemes in the idls, what is
      the proposed way to implement the translation_library interface?
      (One solution might be to have the LQS expose a translation_library
      interface through the TerminologyService interface and let the LQS
      server do the "correct" transformation ...)

    [BTW, the paragraph 1.5.2.4 does not agree with 2.1.4: Firstly, it
    refers to "UniqueName" and "UniqueNameStr" which are unknown and it
    possibly means QualifiedName and QualifiedNameStr
    respectively. Secondly, it says that the character ':' should be the
    delimiter between NE and LN (!!).]

  • Reported: LQS 1.1 — Thu, 22 Jul 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT