[New-ITS] Compactness of style (was: RE: Element content vs attributes)
Smithies Rik
rik.smithies at cfh.nhs.uk
Fri Jul 21 13:56:43 BST 2006
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
>
More information about the New-ITS
mailing list