[New-ITS] Compactness of style (was: RE: Element content vsattributes)
Jewell,Gaby
GJEWELL at CERNER.COM
Fri Jul 21 16:18:00 BST 2006
CWE also allows freetext, which is not allowed in the CFH messages.
I had never heard this specific interpretation of CWE before. A SNOMED
code is a SNOMED code. Unless I'm using code system version (which
we're not in the CFH messages), how does someone know it's a "new" code?
And if we are using code system version, why not just state which
version of SNOMED the code came from?
My understanding of extensions was more for HL7 or User-defined code
systems, where the vocabulary can be extended in a local implementation.
Gaby Jewell | Strategist | Cerner Corporation | office: 816.201.3290 |
fax: 816.571.3290 | gjewell at cerner.com | www.cerner.com
-----Original Message-----
From: new-its-bounces at lists.hl7.org.uk
[mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve
Sent: Friday, July 21, 2006 7:59 AM
To: Smithies Rik
Cc: new-its at lists.hl7.org.uk
Subject: Re: [New-ITS] Compactness of style (was: RE: Element content
vsattributes)
CWE says extensions are allowed. The most common case for extensions is
when new codes are added for a new version of the codeSystem. CNE means
they can't be adopted seamlessly whereas CWE says that they can.
For this reason there is agreement at HL7 that snomed is always CWE. But
I am not acquainted with CfH thinking on this issue, nor have I looked
at the models to see how it's done.
Grahame
Smithies Rik wrote:
> I may have missed the point, but I was expecting the codeSystem to be
> only suppressible in cases of CNE.
>
> I realised that some models need to be generic and future proof, and
> in those cases where any codeSystem can come along, you surely do need
> to say the codeSystem.
>
> I'd like to think that serious used of CWE was rare though. Certainly
> in CFH it isn't used much if at all.
>
> Is CWE meant for "send anything you like" or is it where multiple
> codeSystem are sanctioned, but not all codeSystem, and you just cant
> narrow it down to one for the diagram ? Or is that the point where
> valueSets come into play ? What if you allow any code from 2
> codeSystem, is that CWE ?
>
> Rik
>
>> -----Original Message-----
>> From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame
>> Grieve
>> Sent: 21 July 2006 13:22
>> To: Smithies Rik
>> Cc: Tim Benson; grahame at jivamedical.com; new-its at lists.hl7.org.uk;
>> ann.wrightson at bt.com
>> Subject: Re: [New-ITS] Compactness of style (was: RE: Element content
>> vs attributes)
>>
>> that's right, the ruids are just token replacements for oids, so oids
>> are still there in the background.
>>
>> I'm a little pessimistic that we can remove the codeSystem from the
>> instance. The reason is the difference between valueSet and
>> codeSystem - is there good machinery to infer that valueSet X with
>> CWE means that the implementable model can regard the codeSystem as
>> fixed?
>>
>> Grahame
>>
>>
>> Smithies Rik wrote:
>>> Hi Tim, Grahame
>>>
>>>
>>>> Can we can do what we want without using OIDs?
>>>>
>>>> If OIDs did not already exist today, is there is a real user
>>>> requirement to invent them?
>>>>
>>>> I think that the answers to the last 2 questions are
>> probably YES and
>>>> NO respectively
>>> I would have suggested NO and YES, so what are the
>> alternatives ? You
>>> seem to need a namespacing method for codes and ids, hierarchical
>>> ideally, to ease sub-allocation, so OIDs work pretty well
>> imho. They
>>> are verbose unfortunately. They also don't cover the requirement to
>>> say what type of ID something is.
>>>
>>> UUIDs are also very verbose. You could certainly shrink
>> messages a few
>>> percent by using a more compressed UUID format (eg base 36). They
>>> stick out like a sore thumb in flattened versions of current ITS
>>> examples. I once looked for an alternative and nothing came up.
>>>
>>> I like the idea of RUIDs, which I have also never seen
>> before. But if
>>> in a given model a certain attribute is always, say, SCT,
>> then there
>>> is no theoretical need to send the codeSystem all, hence no great
>>> advantage in shortening it.
>>>
>>> There is also the CodeSystemName if you want readability.
>> The casual
>>> reader of XML will just see it's a code and read the
>> displayName. It
>>> don't believe it help readability to the non-expert to have the OID
>>> shown in "english" as an RUID, it would be best to just
>> have code and
>>> text.
>>>
>>> If the OID must be carried for some other reason, then if
>> the RUID is
>>> shorter so much the better, but two formats are harder to
>> support than
>>> one and OIDs aren't likely to disappear totally.
>>>
>>> Rik
>>>
>>>> -----Original Message-----
>>>> From: new-its-bounces at lists.hl7.org.uk
>>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Tim Benson
>>>> Sent: 20 July 2006 12:49
>>>> To: grahame at jivamedical.com; ann.wrightson at bt.com
>>>> Cc: new-its at lists.hl7.org.uk
>>>> Subject: Re: [New-ITS] Compactness of style (was: RE:
>> Element content
>>>> vs attributes)
>>>>
>>>> The question is whether getting rid of OIDs would be
>> friendly? This
>>>> raises several related questions.
>>>>
>>>> Are people so familiar with oids that they would miss them?
>>>> In teaching HL7 I have not met anyone who was familiar with OIDs
>>>> outside of HL7.
>>>>
>>>> Can we can do what we want without using OIDs?
>>>>
>>>> If OIDs did not already exist today, is there is a real user
>>>> requirement to invent them?
>>>>
>>>> I think that the answers to the last 2 questions are
>> probably YES and
>>>> NO respectively
>>>>
>>>> Tim
>>>>
>>>> On 20/7/06 10:27 Grahame Grieve wrote:
>>>>
>>>>> I will respond to this several times in different ways.
>> One of the
>>>>> things that this makes think is that we should dust off
>>>> RUIDs. The HL7
>>>>> type UID is either UUID, OID, or RUID. We've never defined
>>>> any RUIDs,
>>>>> so no one really talks about them. But we (HL7) could - we could
>>>>> define
>>>>>
>>>>> snomed-CT = [some long oid]
>>>>> loinc = (some long oid)
>>>>> [all HL7 codesets names] = (hl7 oids) other common candidates as
>>>>> required
>>>>>
>>>>> then you could have <code codeSystem="snomed-CT" code="23123".../>
>>>>>
>>>>> (This doesn't address the xml issues - I Will take them up
>>>>> separately.)
>>>>>
>>>>> But is this change something that would make the messages
>>>> more friendly?
>>>>> Actually, it's possible that the UK realm could just define these
>>>>> without lengthy consultation with HL7 under realm
>> localisation. The
>>>>> comments in the abstract data types say:
>>>>>
>>>>> "A globally unique string defined exclusively by HL7.
>>>> Identifiers in
>>>>> this scheme are only defined by balloted HL7
>>>> specifications. Local
>>>>> communities or systems must never use such reserved identifiers
>>>>> based on bilateral negotiations"
>>>>>
>>>>> ambiguous where a realm sits here. We could seek
>> clarification. But
>>>>> this is only worthwhile if getting rid of the oids would be
>>>> friendly.
>>>>> comments?
>>>>>
>>>>> Grahame
>>>>>
>>>>>
>>>>> ann.wrightson at bt.com wrote:
>>>>>> A fork on the previous discussion:
>>>>>>
>>>>>> GG> I am left with a simple view: attributes are better
>> cause they
>>>>>> GG> use
>>>>>> less space, so use them when you can.
>>>>>>
>>>>>> If you package a non-XML data structure into XML in two
>>>> ways, first
>>>>>> using a general rule of
>>>> put-data-attributes-into-XML-attributes, then
>>>>>> using a general rule of
>>>> put-data-attributes-into-XML-child-elements,
>>>>>> then yes XML attributes do use less space.
>>>>>>
>>>>>> However, if you allow translations that are more
>> intelligent with
>>>>>> respect to the nature of XML (for example, removing the
>> constraint
>>>>>> that all names and values in the abstractly-modelled
>> non-XML data
>>>>>> have to appear unchanged in the XML, including a short readable
>>>>>> code-system-name in the implementable model, and thus
>>>> allowing an OID
>>>>>> to yield a readable tagname), an element-based style is
>> able to be
>>>>>> both readable and compact
>>>>>> - and could still be generated from the non-XML model. Such
>>>>>> intelligence does have some cost; I would justify that by
>>>> saying it's
>>>>>> for the same reason as terminologies don't just use
>> code-numbers -
>>>>>> people, developers no less than clinicians, need clear-text
>>>>>> linguistic forms of reasonable reliability and not just
>>>> formally-unambiguous gobbledegook.
>>>>>> For example (from MIM 4.1.02):
>>>>>>
>>>>>> <code codeSystem="2.16.840.1.113883.2.1.3.2.4.15"
>> code="371534008"
>>>>>> displayName="summary report" />
>>>>>>
>>>>>> can become:
>>>>>>
>>>>>> <SnCT code="371534008">summary report</SnCT>
>>>>>>
>>>>>> without the total loss of signal in the XML regarding the
>>>> terminology
>>>>>> being used that happens if you instead go to this kind of
>>>> style (MIM
>>>>>> 4.1.03):
>>>>>>
>>>>>> <code code="163171000000105" displayName="Care Professional
>>>>>> Documentation" />
>>>>>>
>>>>>> The "loss of signal" for implementers has emerged as the main
>>>>>> practical issue here, IMO. However, assuming that all the names
>>>>>> involved are about the same length, there is also some
>>>> difference in
>>>>>> the right direction in overall length. At its simplest
>> this is eg:
>>>>>> <aaaa bbbb="zzzz" cccc="xxxx" dddd="yyyy" />
>>>>>>
>>>>>> becoming:
>>>>>>
>>>>>> <zzzz dddd="yyyy" >xxxx</zzzz>
>>>>>>
>>>>>> The second also shortens by one step the XPath required
>> to select
>>>>>> this specific kind of element (and may reduce the size of an
>>>>>> intermediate nodeset considerably). Of course, that also
>> means it
>>>>>> lengthens the XPath required to find all the XML elements
>>>>>> corresponding to type "aaaa" in the underlying model... So
>>>> as usual
>>>>>> we are in a trade-off & need to judge which weighs heavier
>>>> for our "market".
>>>>>> Ann W.
>>>>>>
>>>> _______________________________________________
>>>> New-ITS mailing list
>>>> New-ITS at lists.hl7.org.uk
>>>> http://lists.hl7.org.uk/mailman/listinfo/new-its
>>>>
>>> This e-mail is confidential and privileged. If you are not
>> the intended recipient please accept our apologies; please do not
>> disclose, copy or distribute information in this e-mail or take any
>> action in reliance on its contents: to do so is strictly prohibited
>> and may be unlawful. Please inform us that this message has gone
>> astray before deleting it. Thank you for your co-operation.
>>>
>>>
>> --
>> Grahame Grieve
>> CTO, Jiva Medical Software Integration Tools
>> CTO, Kestral Computing Healthcare Applications
>>
>
--
Grahame Grieve
CTO, Jiva Medical Software Integration Tools
CTO, Kestral Computing Healthcare Applications
_______________________________________________
New-ITS mailing list
New-ITS at lists.hl7.org.uk
http://lists.hl7.org.uk/mailman/listinfo/new-its
-----------------------------------------
CONFIDENTIALITY NOTICE This message and any included attachments
are from Cerner Corporation and are intended only for the
addressee. The information contained in this message is
confidential and may constitute inside or non-public information
under international, federal, or state securities laws.
Unauthorized forwarding, printing, copying, distribution, or use of
such information is strictly prohibited and may be unlawful. If you
are not the addressee, please promptly delete this message and
notify the sender of the delivery error by e-mail or you may call
Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1)
(816)221-1024. -------------------------------------------
More information about the New-ITS
mailing list