This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Datatypes R2 Issue 72

From HL7Wiki
Jump to navigation Jump to search

Proposal

SpecializationType should be added as a property to DATAVALUE -- in order to provide a mechanism for conveying localized constraints on an HL7 RIM property. this is analogous to the use of profileId and templateId for messages and classes.

It's not a specialisation - it's a template. There is a number of technical reasons for this. It should be called templateId, with a type of UID --GrahameGrieve 18:27, 16 October 2006 (CDT)

Agree, and its should not be mapped to xsi:type, for that doesn't allow a receiver to ignore the templateId if circumstances allow this Rene spronk 22:48, 16 October 2006 (CDT).
What is the requirement?
  • what would I do with it?
  • what do I do if it's not there?
  • what do I gain by bothering with it?
I think that this is making implementation more complicated for little to no return on investment. So I want to see the case made. Gschadow 21:07, 11 January 2007 (CST)
Like with templates the useCase is very simple: This supports validation. This is the only use for it --GrahameGrieve 21:31, 11 January 2007 (CST)
But it makes no sense to require something in addition to the normal data for validation. Think of it this way: a validation thing is a policeman roaming the streets looking for bad guys. How do they know the bad guys? They compare what they do with what the law says. All they need is (a) the law, and (b) look at what the guys are doing. Saying that a template id assists in validation is like saying that the bad guys can just raise some flag which would excuse them from doing what they are doing. I believe every feature in the standard must answer to the 3 questions I just raised. Gschadow 21:37, 11 January 2007 (CST)

It's not like a bad guy raising a flag in order to get away with something. It's the opposite, by failing to declare what he's supposed to be doing, no one knows he's breaking the rules. It's like the "ring 555-* to report me if I'm a bad driver..."

what would I do with it? 

if you wanted to perform validation against a
datatype flavor, you can do that. If it's not there,
you may never know that the value should conform to
a particular flavor

what do I do if it's not there? 

Go on with your merry life, not knowing that the value
doesn't conform to the constraints. Of course, in this 
case, there's two reasons why your life may not be merry:
 * you discover that the data doesn't conform to your 
   expectations and are upset
 * you are a large project manager who expressed his 
   expectations of the datatypes, and you get very 
   upset indeed that you cannot get the validation engines
   to validate your expectations
Of course, in most cases, the model will define which flavor
applies. The main exception is only the very important
Observation.value attribute, where you will never know, unless
it is stated.

what do I gain by bothering with it? 

nothing, unless you are interoperating with a project
that expresses it's rules by defining data type flavors
and expects validation to reduce the implementation burden.

There you go, your 3 questions answered.--GrahameGrieve 21:36, 20 June 2007 (CDT)

Disposition

We decided elsewhere that we would add this property, but not as a semantic property of any - it's not a semantic property. This property is documented in the representation appendix as flavorId. And this proposal is closed. --GrahameGrieve 21:38, 20 June 2007 (CDT)

background

The following is an email thread discussion this proposal:

I agree with Rene -- though would add that we have in the abstract interactionId, profileId, typeId and templateId, -- giving us standard and localised type names for the entire content of the communication, and any class structure within it. In the abstract datatypes there is a property DataValue.type (ANY to those who use the XML ITS) to convey the type of an HL7 RIM attribute.

An ITS may of course chose to define how this type information is communicated in a way that suits the technology best, and in the XML ITS we use the xsi:type as a required part of the ITS to communicate the type of an HL7 RIM attribute.

It would make sense to rationalise these three different types of type -- and have a standard ITS-independent way to convey the type of the instance, class, and HL7 attribute. If we are happy with the three different sets of attributes for this -- then we should at least find a place in the documentation where the relationship between them can be described. I propose that that should be the RIM document, and that the outcome of this email thread should be a harmonisation proposal, as well as a clarification to the conformance document (and a change to the abstract datatypes -- see next para).


For the conformance document is suggest that "specializations attribute" should be rephrased as "DataValue.SpecialisationType", and there should be a change proposal into datatypeR2 to include this property as part of the abstract datatypes. There is a new draft of the datatypes in the next ballot cycle, and this should be included.

All the best

Charlie


Charlie McCay, charlie@RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay



> -----Original Message----- > From: owner-conf@lists.hl7.org > [1] On Behalf Of Rene Spronk (Ringholm) > Sent: 16 October 2006 06:44 > To: Lyons, John (MED US) > Cc: Conf@lists.hl7.org > Subject: Re: Concrete Data Types - Section 5.3.3.1 Refinement chapter > > John, > > If we regard a datatype specialization as a "templateId" > (http://informatics.mayo.edu/wiki/index.php/TemplateId) at the data > type level -and the analogy makes sense to me-, then the data type > specialization should be conveyed in an abstract manner. > > So should there be an option for a sender to convey what > specialization it has used: yes, see templateId as a precedent. > > Should that be done in an ITS specific way: I don't think so. > One of the key things with templateId is that a receiver may ignore it > and use its own facilities to parse it anyway. > Using an xsi:type to identify a constrained datatype may result in the > receiver not knowing that datatype specialization name and its > inability to process the message. > > We have InteractionId, typeId, templateId, all of which are abstract > in nature. Why should a datatype spezialization be any different? > > TTYL, > > -Rene > > > Lyons, John (MED US) wrote: > > We had an affirmative-suggestion ballot item (in the ballot > > reconciliation spreadsheet it is Excel row number 149 - Item number > > 149) which talked concrete data types and the idea that > they represent > > an ITS specific attribute giving the specialization name. > The text in > > the Refinement chapter is: > > > > A concrete data type specialization identifies a model that can be > > used to validate instance of a localized model. A concrete > data type > > is a refinement of a single HL7 data type. A concrete data type may > > be, but need not be, a refinement of an abstract data type > > specialization. Where a concrete data type specialization is a > > refinement of an abstract data type specialization it > identifies which > > member of the set of choices permitted by the abstract data > type has > > been/should be used to validate the component. Only concrete data > > types can be referenced in the specializations attribute of > an instance. > > > > The comment by the balloter was: > > > > I still have REAL problems with this notion of an ITS > spefic "attribute" > > that gives the specialization name. I don't think it is > EVER required > > for the sender to tell the receiver what specialization was used on > > the sending side...after all, the requirements to be able to process

> > only a subset of the data type spec is on the receiving side...and > > hence, it is the receiver who SHOULD decide which specialization is > > used to validate any given element. Plus, this section > should give a > > forward pointer to > > 5.3.3.2 #1, if you insist on having these. > > > > I wanted to get other peoples opinion on this item so that we might > > decide if really do need to make a change or the text is > fine as is. > > If you could reply with your opinion on this we can discuss > this item > > at this weeks conference call and make a decision. Also > the text for > > 5.3.3.2 #1 is: > > > > > > 1. It must be possible to express in a message instance > that a named > > data type specialization MAY be used by the receiver > to validate > > the contents of the RIM attribute. To ensure international > > interoperability the names of specializations which are not > > defined in the abstract data types specification SHOULD NOT > > replace the base data type for a RIM attribute where this is > > communicated in an instance, but may be sent in > addition to this. > > The base data type is communicated in a way that is > determined by > > the ITS , and for the XML ITS , this is achieved using the XML > > attribute "xsi:type". > > > > > > > > John Lyons > > *_______________________________________* > > > > *SIEMENS **Medical Solutions - Health Services* > > > > *John C. Lyons* > > > > *Technical Operations & Integration Support - Siemens OPENLink* > > > > *51 Valley Stream Parkway**, Malvern, PA, 19355-1406*** > > > > *Phone: +1 610 219 4792* > > > > *Fax: +1 610 219 5849* > > > > *E-Mail: > **_John.Lyons@siemens.com_*** > > > > *SCD > **http://scd.siemens.com/db4/lookUp?scdid=R3880000544809* > > > > _______________________________________________________ > > > > > > ************************************************ > > You are currently subscribed to conf@lists.hl7.org as > > rene.spronk@ringholm.com To unsubscribe from this list, > send a blank > > email to leave-conf-5121W@lists.hl7.org To access the > Archives of this > > list, go to: > > http://lists.hl7.org/read/?forum=conf > > To access your List Server profile and subscriptions, go to: > > http://%%site.domainname%%/read/login > > > ---------------------------------------------------------------------- > > --------- This message and any included attachments are > from Siemens > > Medical Solutions USA, Inc. and are intended only for the > > addressee(s). > > The information contained herein may include trade secrets or > > privileged or otherwise confidential information. > Unauthorized review, > > forwarding, printing, copying, distributing, or using such > information > > is strictly prohibited and may be unlawful. If you received this > > message in error, or have reason to believe you are not > authorized to > > receive it, please promptly delete this message and notify > the sender > > by e-mail with a copy to Central.SecurityOffice@siemens.com > > > > Thank you > > > > > -- > ------------------------------------------------------------ > Rene Spronk Phone: +31(0)655 363 446 > Senior Consultant Fax: +31(0)30 695 6915 > Ringholm GmbH The Netherlands > http://www.ringholm.com mailto:Rene.Spronk@ringholm.nl > ------------------------------------------------------------ > Ringholm GmbH Integration Consulting - Making Standards Work > > ************************************************ > You are currently subscribed to conf@lists.hl7.org as > charlie@ramseysystems.co.uk To unsubscribe from this list, send a > blank email to leave-conf-5121W@lists.hl7.org To access the Archives > of this list, go to: > http://lists.hl7.org/read/?forum=conf > To access your List Server profile and subscriptions, go to: > http://lists.hl7.org/read/login > >

You are currently subscribed to inm@lists.hl7.org as charlie@ramseysystems.co.uk To unsubscribe from this list, send a blank email to leave-inm-5283A@lists.hl7.org To access the Archives of this list, go to: http://lists.hl7.org/read/?forum=inm To access your List Server profile and subscriptions, go to: http://%%site.domainname%%/read/login

Retrieved from "https://wiki.hl7.org/w/index.php?title=Datatypes_R2_Issue_72&oldid=13387"