From grahame at kestral.com.au Wed Aug 2 10:08:35 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 2 Aug 2006 19:08:35 +1000 Subject: [New-ITS] updates to wiki Message-ID: Hi Some updates to the wiki site, we will be discussing these tomorrow. I will have printouts for these tomorrow. 1. http://b2international.com/umlits/index.php/How_do_we_make_the_instance_more_user-friendly%3F This is a nice document now. It may well be suitable for wider release soon. 2. http://b2international.com/umlits/index.php/How_is_the_Implementable_Model_formed 3. http://b2international.com/umlits/index.php/Serialisation_and_XML_rules 4. http://b2international.com/umlits/index.php/Proposed_modeling_changes_to_the_HL7_model_diagrams 5. http://b2international.com/umlits/index.php/Data_Types_Package it'd be nice if someone could contribute to this today or tomorrow: http://b2international.com/umlits/index.php/What_semantic_processing_is_currently_done_in_existing_or_planned_in_near_future_applications%3F Grahame From Robert.Worden at Charteris.com Thu Aug 10 18:17:57 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Thu, 10 Aug 2006 18:17:57 +0100 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM Message-ID: Not sure about 'optimised' because: - Optimised implies the best in some sense; but it may not yet be the best, just better - The acronym 'OM' somehow is not very snappy - hard to read as a word (or a bit Buddhist?). I have two other suggestions: - Transmission Model, or TM (still a bit Buddhist?) - Semantically Equivalent Model, or SEM I like the last because it tells people we are not messing with RIM semantics. Anyway, the acronym is now a variable in the tools, and I can change it daily. We could put it to a vote at the WGM. Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. -----Original Message----- From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] Sent: 09 August 2006 17:44 To: Lloyd McKenzie Cc: grahame at jivamedical.com; Robert Worden Subject: RE: Steering RMIM reshaping Well -- we were trying to avoid C words -- so "optimized" seems the best offering so far All the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay > -----Original Message----- > From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > Sent: 09 August 2006 17:08 > To: Charlie McCay > Cc: grahame at jivamedical.com; Robert Worden > Subject: Re: Steering RMIM reshaping > > Hi Charlie, > > Calling it a "practical" model sends the wrong message about > the existing structure. Executable model suggests that it's > an internal object model, which it isn't. > > What this is is a "collapsed" or "compressed" or "optimized" > or some other transformation type word. > > > Lloyd > > Charlie McCay wrote: > > So how about practical model or exchange model or executable model > > > > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > > Dogpole, Shrewsbury, Shropshire SY1 1ES > > > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > > > > > > > > >> -----Original Message----- > >> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >> Sent: 09 August 2006 16:22 > >> To: Charlie McCay > >> Cc: grahame at jivamedical.com; Robert Worden > >> Subject: Re: Steering RMIM reshaping > >> > >> Hi Charlie, > >> > >> The challenge is that many will read "physical model" in its > >> usual sense, which is persistence model, which we definitely > >> shouldn't be suggesting, let alone imposing. > >> > >> > >> Lloyd > >> > >> Charlie McCay wrote: > >> > >>> Hi > >>> > >>> Why not? -- the intent is to provide the model for the physical > >>> exchange (subject to ITS realisation, but that is the > >>> > >> model-reality > >> > >>> mapping) -- it is this practical model that is exactly what > >>> > >> we do want > >> > >>> from HL7, and that we have been using the logical > >>> > >> information model > >> > >>> as a proxy for until now > >>> > >>> Alternative that I do not like as much: > >>> > >>> EM exchange model / executable model > >>> > >>> charlie > >>> > >>> > >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > Ltd, 23D > >>> Dogpole, Shrewsbury, Shropshire SY1 1ES > >>> > >>> tel 01743 232278 / 07808 570172 skype: charliemccay > >>> > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >>>> Sent: 09 August 2006 16:02 > >>>> To: Charlie McCay > >>>> Cc: grahame at jivamedical.com; Robert Worden > >>>> Subject: Re: Steering RMIM reshaping > >>>> > >>>> Hi Charlie, > >>>> > >>>> I don't want to imply that HL7 defines actual physical > models . . . > >>>> > >>>> > >>>> Lloyd > >>>> > >>>> Charlie McCay wrote: > >>>> > >>>> > >>>>> How about > >>>>> > >>>>> PM -- Physical/(?Practical?) Model ? > >>>>> PM / PSM (Platform model (Platform Specific Model) > >>>>> > >>>>> All the best > >>>>> > >>>>> Charlie > >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > >>>>> > >> Ltd, 23D > >> > >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES > >>>>> > >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >>>>>> Sent: 08 August 2006 05:45 > >>>>>> To: grahame at jivamedical.com > >>>>>> Cc: Robert Worden; Charlie McCay > >>>>>> Subject: Re: Steering RMIM reshaping > >>>>>> > >>>>>> Except CM is used for CMET. Not sure we need a different > >>>>>> > >>>>>> > >>>> id if the > >>>> > >>>> > >>>>>> models are just transforms of each other. > >>>>>> > >>>>>> Grahame Grieve wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> CM = collapsed model or computable model > >>>>>>> > >>>>>>> we could go with that > >>>>>>> > >>>>>>> Grahame > >>>>>>> > >>>>>>> > >>>>>>> Lloyd McKenzie wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> We can't use the word "Message" because we'll presumably > >>>>>>>> > >>>>>>>> > >>>> be using > >>>> > >>>> > >>>>>>>> this stuff for documents too. How about just > >>>>>>>> > >> "collapsed model", > >> > >>>>>>>> seeing as that's what it is . . . > >>>>>>>> > >>>>>>>> Grahame Grieve wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> we've been using the term implementable model. IM, > I know.... > >>>>>>>>> > >>>>>>>>> maybe you could go for "message design"? it's not > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>> strictly a model, > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>> so we can get away from the "M" part and reduce confusion? > >>>>>>>>> > >>>>>>>>> cc: Charlie for an opinion > >>>>>>>>> > >>>>>>>>> Grahame > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Robert Worden wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Grahame - > >>>>>>>>>> > >>>>>>>>>> I agree that DAM is not the right name, and will tend > >>>>>>>>>> > >>>>>>>>>> > >>>> to confuse > >>>> > >>>> > >>>>>>>>>> people; we are making something strictly derived from > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> the RMIM and > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> suitable for implementation, which may have DAM-like > >>>>>>>>>> > >> names and > >> > >>>>>>>>>> structure. > >>>>>>>>>> > >>>>>>>>>> I'll stop calling it a DAM, and make the tools stop > >>>>>>>>>> > >>>>>>>>>> > >>>> calling it a > >>>> > >>>> > >>>>>>>>>> DAM; but I would like a shorter name than 'reshaped > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> RMIM'. Any suggestions? > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped > >>>>>>>>>> > >>>>>>>>>> > >>>> Implementation > >>>> > >>>> > >>>>>>>>>> Model? > >>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. > >>>>>>>>>> > >>>>>>>>>> Give me an acronym and I will do a global edit... > >>>>>>>>>> > >>>>>>>>>> Robert > >>>>>>>>>> > >>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> Close, London > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> EC1A 7JN > >>>>>>>>>> > >>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> mobile: 44 7970 > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> 197968 > >>>>>>>>>> > >>>>>>>>>> *************************** E-mail confidentiality notice > >>>>>>>>>> ******************************* > >>>>>>>>>> > >>>>>>>>>> This message is intended for the addressee only. It is > >>>>>>>>>> > >>>>>>>>>> > >>>> private, > >>>> > >>>> > >>>>>>>>>> confidential and may contain information of a > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> proprietary nature. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> If you have received this message in error, please > >>>>>>>>>> > >>>>>>>>>> > >>>> notify us and > >>>> > >>>> > >>>>>>>>>> remove it from your system. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On > >>>>>>>>>> > >> Behalf Of > >> > >>>>>>>>>> Grahame Grieve > >>>>>>>>>> Sent: 07 August 2006 22:18 > >>>>>>>>>> To: Robert Worden > >>>>>>>>>> Cc: Lloyd McKenzie > >>>>>>>>>> Subject: Re: Steering RMIM reshaping > >>>>>>>>>> > >>>>>>>>>> I'm way behind on email. but spotted this. > >>>>>>>>>> > >>>>>>>>>> Robert, we need to stop talking about DAM. There is no > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> correlation > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> between what we are trying to achieve and a real DAM. > >>>>>>>>>> > >>>>>>>>>> What we want is to do implementation modelling on > >>>>>>>>>> > >> the RMIM. We > >> > >>>>>>>>>> recognise - particularly after talking to Simon Withey > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> last week - > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> that this has nothing to do with the DAM process, > >>>>>>>>>> > >>>>>>>>>> > >>>> except for the > >>>> > >>>> > >>>>>>>>>> naming question. > >>>>>>>>>> (Where by names in the instance should allow > >>>>>>>>>> > >>>>>>>>>> > >>>> identification back > >>>> > >>>> > >>>>>>>>>> against the DAM, rather than against the RIM. Except > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> unless you are > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> concerned about naming stability, but that's a much > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> harder question > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> indeed) > >>>>>>>>>> > >>>>>>>>>> will come back to this thread later when I catch up > >>>>>>>>>> > >>>>>>>>>> Grahame > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Robert Worden wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Hi Lloyd - > >>>>>>>>>>> > >>>>>>>>>>> I was thinking that since people should really > >>>>>>>>>>> > >>>>>>>>>>> > >>>> produce a DAM on > >>>> > >>>> > >>>>>>>>>>> the > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> way > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> to their RMIM, rather than the other way round, in some > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> sense the > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> RMIM should be derived from the DAM. But as it is not > >>>>>>>>>>> > >>>>>>>>>>> > >>>> a formal > >>>> > >>>> > >>>>>>>>>>> derivation, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> it > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> may be that the route is not > >>>>>>>>>>> > >> appropriate. > >> > >>>>>>>>>>> What then is the approved mechanism for adding > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> annotations to a MIF? > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> I'm > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> sure I could find it in the schemas, but it's easier to > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> ask you... > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> :-) > >>>>>>>>>>> > >>>>>>>>>>> Robert > >>>>>>>>>>> > >>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> Close, London > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> EC1A 7JN > >>>>>>>>>>> > >>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> mobile: 44 7970 > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> 197968 > >>>>>>>>>>> > >>>>>>>>>>> *************************** E-mail confidentiality notice > >>>>>>>>>>> ******************************* > >>>>>>>>>>> > >>>>>>>>>>> This message is intended for the addressee only. It > >>>>>>>>>>> > >>>>>>>>>>> > >>>> is private, > >>>> > >>>> > >>>>>>>>>>> confidential and may contain information of a > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> proprietary nature. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> If you have received this message in error, please > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> notify us and > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> remove it from your system. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> 07 August > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> 2006 19:43 > >>>>>>>>>>> To: Robert Worden > >>>>>>>>>>> Cc: grahame at kestral.com.au > >>>>>>>>>>> Subject: Re: Steering RMIM reshaping > >>>>>>>>>>> > >>>>>>>>>>> Hi Robert, > >>>>>>>>>>> > >>>>>>>>>>> Relationships between a static model and a DAM would be > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> mappings, > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> not derivations. StaticModelDerivationId is not a > >>>>>>>>>>> > >>>>>>>>>>> > >>>> spare. In the > >>>> > >>>> > >>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> and HMD but > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> in theory we could derive from 20 different models. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> (And there's > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> no ordering > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> either, > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> the RIM could be the first one listed or the seventh.) > >>>>>>>>>>> > >>>>>>>>>>> The basic question is whether you construct your > DAM from a > >>>>>>>>>>> collapsed static model (as we do in Canada), or whether > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> you want > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> to create your DAMs and DIMs separately and map > >>>>>>>>>>> > >> them. If the > >> > >>>>>>>>>>> latter, I don't think > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> you > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> could do this in an automated way. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Lloyd > >>>>>>>>>>> > >>>>>>>>>>> Robert Worden wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Grahame - > >>>>>>>>>>>> > >>>>>>>>>>>> You asked the other day for suggestions as to how > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> the current > >>>> > >>>> > >>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be steered by > >>>>>>>>>>>> annotations in the RMIM MIF, rather than by user > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> input. Here is a > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> first punt to get thinking going. > >>>>>>>>>>>> > >>>>>>>>>>>> The simplest suggestion I can make is to add to the > >>>>>>>>>>>> elements another one which says > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> how this > >>>> > >>>> > >>>>>>>>>>>> RMIM > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> was > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>> derived (or might have been derived) from a DAM. These > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> would look > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> like: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> > >>>>>>>>>>>> > >>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> but choose > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> one > >>>>>>>>>>>> > >>>>>>>>>>>> that is). These can go on elements for classes, > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> associations, and > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> properties to say in effect > >>>>>>>>>>>> > >>>>>>>>>>>> * Rename this class to a DAM class name > >>>>>>>>>>>> * Rename this association (with perhaps other > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> attributes saying > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> 'collapse it' or 'leave it out') > >>>>>>>>>>>> * Rename this property to a DAM property name (or > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> some value > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> meaning 'leave it out') > >>>>>>>>>>>> > >>>>>>>>>>>> If you wanted, you would not even have to say explicitly > >>>>>>>>>>>> 'collapse an > >>>>>>>>>>>> > >>>>>>>>>>>> association' - because if the DAM class names are > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> the same on > >>>> > >>>> > >>>>>>>>>>>> either side of it, that means collapse it. > >>>>>>>>>>>> > >>>>>>>>>>>> This proposal would not yet address a combination of > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> restricting > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> and reshaping an RMIM. > >>>>>>>>>>>> > >>>>>>>>>>>> It would imply you cannot collapse across a CMET > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> boundary, which > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> I gather from our discussion the other day you would > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> like to do. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> Or maybe you can, by telling the association to > >>>>>>>>>>>> > >> the CMET to > >> > >>>>>>>>>>>> collapse itself? Have not thought it through yet. I > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> know there > >>>> > >>>> > >>>>>>>>>>>> are issues > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> about > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>> CMETs with a choice at the top - any chance you > >>>>>>>>>>>> > >> could send a > >> > >>>>>>>>>>>> simple diagram to illustrate the problem as you see it? > >>>>>>>>>>>> > >>>>>>>>>>>> Anyway, if we come up with any scheme like the above, > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> it should > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> be straightforward to implement in the tool. > >>>>>>>>>>>> > >>>>>>>>>>>> Robert > >>>>>>>>>>>> > >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> Close, London > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> EC1A > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> 7JN > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> 7970 197968 > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> *************************** E-mail confidentiality notice > >>>>>>>>>>>> ******************************* > >>>>>>>>>>>> > >>>>>>>>>>>> This message is intended for the addressee only. It is > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> private, > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> confidential and may contain information of a > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> proprietary nature. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> If you have received this > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> message > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>> in error, please notify > >>>>>>>>>>>> us and remove it from your system. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> > _________________________________________________________________ > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> This message from Charteris plc has been checked > >>>>>>>>>>>> > >> for viruses > >> > >>>>>>>>>>>> http://www.charteris.com/ > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > _________________________________________________________________ > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> This message to Charteris plc has been checked > for viruses > >>>>>>>>>>> http://www.charteris.com/ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > _________________________________________________________________ > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> This message from Charteris plc has been checked > >>>>>>>>>>> > >> for viruses > >> > >>>>>>>>>>> http://www.charteris.com/ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > > > _________________________________________________________________ This message to Charteris plc has been checked for viruses http://www.charteris.com/ _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ From Laura.Sato at cfh.nhs.uk Fri Aug 11 09:36:22 2006 From: Laura.Sato at cfh.nhs.uk (Sato Laura) Date: Fri, 11 Aug 2006 09:36:22 +0100 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM Message-ID: <1A3D105C334EAE49BDDD93D8767573F5041FB301@EXCHAQ2.nhsia.nhs.uk> I realise that I'm a little late into this conversation, but... what was wrong with Implementable Model - is it the acronym, IM, that's too like something else? What I liked about 'implementable' was that it gave the sense of the view for which the model was designed for (i.e. implementers). It gave a focus for what it was supposed to accomplish. Scanning through the other terms, I don't mind Platform-Specific Model, if that's truly what it is (is it?). Transmission Model might be okay. Semantically Equivalent Model doesn't say anything to me about what it's for, so I'm not crazy about this one. Just my 2p... Regards, Laura _________________________ Laura Sato Informatics Standards Lead Communications & Messaging NHS Connecting for Health Mobile: (44) (0)7733 324 338 Email: laura.sato at cfh.nhs.uk www.connectingforhealth.nhs.uk -----Original Message----- From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden Sent: 10 August 2006 18:18 To: charlie at ramseysystems.co.uk; Lloyd McKenzie Cc: new-its at lists.hl7.org.uk Subject: [New-ITS] Name for a flattened,association-collapsed model derived from an RMIM Not sure about 'optimised' because: - Optimised implies the best in some sense; but it may not yet be the best, just better - The acronym 'OM' somehow is not very snappy - hard to read as a word (or a bit Buddhist?). I have two other suggestions: - Transmission Model, or TM (still a bit Buddhist?) - Semantically Equivalent Model, or SEM I like the last because it tells people we are not messing with RIM semantics. Anyway, the acronym is now a variable in the tools, and I can change it daily. We could put it to a vote at the WGM. Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. -----Original Message----- From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] Sent: 09 August 2006 17:44 To: Lloyd McKenzie Cc: grahame at jivamedical.com; Robert Worden Subject: RE: Steering RMIM reshaping Well -- we were trying to avoid C words -- so "optimized" seems the best offering so far All the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay > -----Original Message----- > From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > Sent: 09 August 2006 17:08 > To: Charlie McCay > Cc: grahame at jivamedical.com; Robert Worden > Subject: Re: Steering RMIM reshaping > > Hi Charlie, > > Calling it a "practical" model sends the wrong message about > the existing structure. Executable model suggests that it's > an internal object model, which it isn't. > > What this is is a "collapsed" or "compressed" or "optimized" > or some other transformation type word. > > > Lloyd > > Charlie McCay wrote: > > So how about practical model or exchange model or executable model > > > > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > > Dogpole, Shrewsbury, Shropshire SY1 1ES > > > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > > > > > > > > >> -----Original Message----- > >> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >> Sent: 09 August 2006 16:22 > >> To: Charlie McCay > >> Cc: grahame at jivamedical.com; Robert Worden > >> Subject: Re: Steering RMIM reshaping > >> > >> Hi Charlie, > >> > >> The challenge is that many will read "physical model" in its > >> usual sense, which is persistence model, which we definitely > >> shouldn't be suggesting, let alone imposing. > >> > >> > >> Lloyd > >> > >> Charlie McCay wrote: > >> > >>> Hi > >>> > >>> Why not? -- the intent is to provide the model for the physical > >>> exchange (subject to ITS realisation, but that is the > >>> > >> model-reality > >> > >>> mapping) -- it is this practical model that is exactly what > >>> > >> we do want > >> > >>> from HL7, and that we have been using the logical > >>> > >> information model > >> > >>> as a proxy for until now > >>> > >>> Alternative that I do not like as much: > >>> > >>> EM exchange model / executable model > >>> > >>> charlie > >>> > >>> > >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > Ltd, 23D > >>> Dogpole, Shrewsbury, Shropshire SY1 1ES > >>> > >>> tel 01743 232278 / 07808 570172 skype: charliemccay > >>> > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >>>> Sent: 09 August 2006 16:02 > >>>> To: Charlie McCay > >>>> Cc: grahame at jivamedical.com; Robert Worden > >>>> Subject: Re: Steering RMIM reshaping > >>>> > >>>> Hi Charlie, > >>>> > >>>> I don't want to imply that HL7 defines actual physical > models . . . > >>>> > >>>> > >>>> Lloyd > >>>> > >>>> Charlie McCay wrote: > >>>> > >>>> > >>>>> How about > >>>>> > >>>>> PM -- Physical/(?Practical?) Model ? > >>>>> PM / PSM (Platform model (Platform Specific Model) > >>>>> > >>>>> All the best > >>>>> > >>>>> Charlie > >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > >>>>> > >> Ltd, 23D > >> > >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES > >>>>> > >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >>>>>> Sent: 08 August 2006 05:45 > >>>>>> To: grahame at jivamedical.com > >>>>>> Cc: Robert Worden; Charlie McCay > >>>>>> Subject: Re: Steering RMIM reshaping > >>>>>> > >>>>>> Except CM is used for CMET. Not sure we need a different > >>>>>> > >>>>>> > >>>> id if the > >>>> > >>>> > >>>>>> models are just transforms of each other. > >>>>>> > >>>>>> Grahame Grieve wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> CM = collapsed model or computable model > >>>>>>> > >>>>>>> we could go with that > >>>>>>> > >>>>>>> Grahame > >>>>>>> > >>>>>>> > >>>>>>> Lloyd McKenzie wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> We can't use the word "Message" because we'll presumably > >>>>>>>> > >>>>>>>> > >>>> be using > >>>> > >>>> > >>>>>>>> this stuff for documents too. How about just > >>>>>>>> > >> "collapsed model", > >> > >>>>>>>> seeing as that's what it is . . . > >>>>>>>> > >>>>>>>> Grahame Grieve wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> we've been using the term implementable model. IM, > I know.... > >>>>>>>>> > >>>>>>>>> maybe you could go for "message design"? it's not > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>> strictly a model, > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>> so we can get away from the "M" part and reduce confusion? > >>>>>>>>> > >>>>>>>>> cc: Charlie for an opinion > >>>>>>>>> > >>>>>>>>> Grahame > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Robert Worden wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Grahame - > >>>>>>>>>> > >>>>>>>>>> I agree that DAM is not the right name, and will tend > >>>>>>>>>> > >>>>>>>>>> > >>>> to confuse > >>>> > >>>> > >>>>>>>>>> people; we are making something strictly derived from > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> the RMIM and > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> suitable for implementation, which may have DAM-like > >>>>>>>>>> > >> names and > >> > >>>>>>>>>> structure. > >>>>>>>>>> > >>>>>>>>>> I'll stop calling it a DAM, and make the tools stop > >>>>>>>>>> > >>>>>>>>>> > >>>> calling it a > >>>> > >>>> > >>>>>>>>>> DAM; but I would like a shorter name than 'reshaped > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> RMIM'. Any suggestions? > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped > >>>>>>>>>> > >>>>>>>>>> > >>>> Implementation > >>>> > >>>> > >>>>>>>>>> Model? > >>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. > >>>>>>>>>> > >>>>>>>>>> Give me an acronym and I will do a global edit... > >>>>>>>>>> > >>>>>>>>>> Robert > >>>>>>>>>> > >>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> Close, London > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> EC1A 7JN > >>>>>>>>>> > >>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> mobile: 44 7970 > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> 197968 > >>>>>>>>>> > >>>>>>>>>> *************************** E-mail confidentiality notice > >>>>>>>>>> ******************************* > >>>>>>>>>> > >>>>>>>>>> This message is intended for the addressee only. It is > >>>>>>>>>> > >>>>>>>>>> > >>>> private, > >>>> > >>>> > >>>>>>>>>> confidential and may contain information of a > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> proprietary nature. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> If you have received this message in error, please > >>>>>>>>>> > >>>>>>>>>> > >>>> notify us and > >>>> > >>>> > >>>>>>>>>> remove it from your system. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On > >>>>>>>>>> > >> Behalf Of > >> > >>>>>>>>>> Grahame Grieve > >>>>>>>>>> Sent: 07 August 2006 22:18 > >>>>>>>>>> To: Robert Worden > >>>>>>>>>> Cc: Lloyd McKenzie > >>>>>>>>>> Subject: Re: Steering RMIM reshaping > >>>>>>>>>> > >>>>>>>>>> I'm way behind on email. but spotted this. > >>>>>>>>>> > >>>>>>>>>> Robert, we need to stop talking about DAM. There is no > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> correlation > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> between what we are trying to achieve and a real DAM. > >>>>>>>>>> > >>>>>>>>>> What we want is to do implementation modelling on > >>>>>>>>>> > >> the RMIM. We > >> > >>>>>>>>>> recognise - particularly after talking to Simon Withey > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> last week - > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> that this has nothing to do with the DAM process, > >>>>>>>>>> > >>>>>>>>>> > >>>> except for the > >>>> > >>>> > >>>>>>>>>> naming question. > >>>>>>>>>> (Where by names in the instance should allow > >>>>>>>>>> > >>>>>>>>>> > >>>> identification back > >>>> > >>>> > >>>>>>>>>> against the DAM, rather than against the RIM. Except > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> unless you are > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> concerned about naming stability, but that's a much > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> harder question > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> indeed) > >>>>>>>>>> > >>>>>>>>>> will come back to this thread later when I catch up > >>>>>>>>>> > >>>>>>>>>> Grahame > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Robert Worden wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Hi Lloyd - > >>>>>>>>>>> > >>>>>>>>>>> I was thinking that since people should really > >>>>>>>>>>> > >>>>>>>>>>> > >>>> produce a DAM on > >>>> > >>>> > >>>>>>>>>>> the > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> way > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> to their RMIM, rather than the other way round, in some > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> sense the > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> RMIM should be derived from the DAM. But as it is not > >>>>>>>>>>> > >>>>>>>>>>> > >>>> a formal > >>>> > >>>> > >>>>>>>>>>> derivation, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> it > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> may be that the route is not > >>>>>>>>>>> > >> appropriate. > >> > >>>>>>>>>>> What then is the approved mechanism for adding > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> annotations to a MIF? > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> I'm > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> sure I could find it in the schemas, but it's easier to > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> ask you... > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> :-) > >>>>>>>>>>> > >>>>>>>>>>> Robert > >>>>>>>>>>> > >>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> Close, London > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> EC1A 7JN > >>>>>>>>>>> > >>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> mobile: 44 7970 > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> 197968 > >>>>>>>>>>> > >>>>>>>>>>> *************************** E-mail confidentiality notice > >>>>>>>>>>> ******************************* > >>>>>>>>>>> > >>>>>>>>>>> This message is intended for the addressee only. It > >>>>>>>>>>> > >>>>>>>>>>> > >>>> is private, > >>>> > >>>> > >>>>>>>>>>> confidential and may contain information of a > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> proprietary nature. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> If you have received this message in error, please > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> notify us and > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> remove it from your system. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> 07 August > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> 2006 19:43 > >>>>>>>>>>> To: Robert Worden > >>>>>>>>>>> Cc: grahame at kestral.com.au > >>>>>>>>>>> Subject: Re: Steering RMIM reshaping > >>>>>>>>>>> > >>>>>>>>>>> Hi Robert, > >>>>>>>>>>> > >>>>>>>>>>> Relationships between a static model and a DAM would be > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> mappings, > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> not derivations. StaticModelDerivationId is not a > >>>>>>>>>>> > >>>>>>>>>>> > >>>> spare. In the > >>>> > >>>> > >>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> and HMD but > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> in theory we could derive from 20 different models. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> (And there's > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> no ordering > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> either, > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> the RIM could be the first one listed or the seventh.) > >>>>>>>>>>> > >>>>>>>>>>> The basic question is whether you construct your > DAM from a > >>>>>>>>>>> collapsed static model (as we do in Canada), or whether > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> you want > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> to create your DAMs and DIMs separately and map > >>>>>>>>>>> > >> them. If the > >> > >>>>>>>>>>> latter, I don't think > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> you > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> could do this in an automated way. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Lloyd > >>>>>>>>>>> > >>>>>>>>>>> Robert Worden wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Grahame - > >>>>>>>>>>>> > >>>>>>>>>>>> You asked the other day for suggestions as to how > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> the current > >>>> > >>>> > >>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be steered by > >>>>>>>>>>>> annotations in the RMIM MIF, rather than by user > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> input. Here is a > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> first punt to get thinking going. > >>>>>>>>>>>> > >>>>>>>>>>>> The simplest suggestion I can make is to add to the > >>>>>>>>>>>> elements another one which says > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> how this > >>>> > >>>> > >>>>>>>>>>>> RMIM > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> was > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>> derived (or might have been derived) from a DAM. These > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> would look > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> like: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> > >>>>>>>>>>>> > >>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> but choose > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> one > >>>>>>>>>>>> > >>>>>>>>>>>> that is). These can go on elements for classes, > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> associations, and > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> properties to say in effect > >>>>>>>>>>>> > >>>>>>>>>>>> * Rename this class to a DAM class name > >>>>>>>>>>>> * Rename this association (with perhaps other > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> attributes saying > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> 'collapse it' or 'leave it out') > >>>>>>>>>>>> * Rename this property to a DAM property name (or > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> some value > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> meaning 'leave it out') > >>>>>>>>>>>> > >>>>>>>>>>>> If you wanted, you would not even have to say explicitly > >>>>>>>>>>>> 'collapse an > >>>>>>>>>>>> > >>>>>>>>>>>> association' - because if the DAM class names are > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> the same on > >>>> > >>>> > >>>>>>>>>>>> either side of it, that means collapse it. > >>>>>>>>>>>> > >>>>>>>>>>>> This proposal would not yet address a combination of > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> restricting > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> and reshaping an RMIM. > >>>>>>>>>>>> > >>>>>>>>>>>> It would imply you cannot collapse across a CMET > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> boundary, which > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> I gather from our discussion the other day you would > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> like to do. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> Or maybe you can, by telling the association to > >>>>>>>>>>>> > >> the CMET to > >> > >>>>>>>>>>>> collapse itself? Have not thought it through yet. I > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> know there > >>>> > >>>> > >>>>>>>>>>>> are issues > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> about > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>> CMETs with a choice at the top - any chance you > >>>>>>>>>>>> > >> could send a > >> > >>>>>>>>>>>> simple diagram to illustrate the problem as you see it? > >>>>>>>>>>>> > >>>>>>>>>>>> Anyway, if we come up with any scheme like the above, > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> it should > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> be straightforward to implement in the tool. > >>>>>>>>>>>> > >>>>>>>>>>>> Robert > >>>>>>>>>>>> > >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> Close, London > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> EC1A > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> 7JN > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> 7970 197968 > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> *************************** E-mail confidentiality notice > >>>>>>>>>>>> ******************************* > >>>>>>>>>>>> > >>>>>>>>>>>> This message is intended for the addressee only. It is > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> private, > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> confidential and may contain information of a > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> proprietary nature. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> If you have received this > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> message > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>> in error, please notify > >>>>>>>>>>>> us and remove it from your system. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> > _________________________________________________________________ > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> This message from Charteris plc has been checked > >>>>>>>>>>>> > >> for viruses > >> > >>>>>>>>>>>> http://www.charteris.com/ > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > _________________________________________________________________ > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> This message to Charteris plc has been checked > for viruses > >>>>>>>>>>> http://www.charteris.com/ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > _________________________________________________________________ > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>> This message from Charteris plc has been checked > >>>>>>>>>>> > >> for viruses > >> > >>>>>>>>>>> http://www.charteris.com/ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > > > _________________________________________________________________ This message to Charteris plc has been checked for viruses http://www.charteris.com/ _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ _______________________________________________ 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. From rik.smithies at cfh.nhs.uk Fri Aug 11 10:30:37 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Fri, 11 Aug 2006 10:30:37 +0100 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM Message-ID: <1A3D105C334EAE49BDDD93D8767573F5041FB363@EXCHAQ2.nhsia.nhs.uk> Rather than Implementable Model, which all models are hopefully, how about "Implementation Model", which stresses that it is modelled specifically to account for implementation issues. "Optimised" isn't too bad but as Robert says in which direction is it optimised ? maybe OIM Optimised Implementation Model If you say it quick, it's only one syllable! > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Sato Laura > Sent: 11 August 2006 09:36 > To: Robert Worden; charlie at ramseysystems.co.uk; Lloyd McKenzie > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Name for a > flattened,association-collapsed model derived from an RMIM > > I realise that I'm a little late into this conversation, > but... what was wrong with Implementable Model - is it the > acronym, IM, that's too like something else? What I liked > about 'implementable' was that it gave the sense of the view > for which the model was designed for (i.e. > implementers). It gave a focus for what it was supposed to > accomplish. > > Scanning through the other terms, I don't mind > Platform-Specific Model, if that's truly what it is (is it?). > Transmission Model might be okay. > > Semantically Equivalent Model doesn't say anything to me > about what it's for, so I'm not crazy about this one. > > Just my 2p... > > Regards, > Laura > _________________________ > Laura Sato > Informatics Standards Lead > > Communications & Messaging > NHS Connecting for Health > Mobile: (44) (0)7733 324 338 > Email: laura.sato at cfh.nhs.uk > www.connectingforhealth.nhs.uk > > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden > Sent: 10 August 2006 18:18 > To: charlie at ramseysystems.co.uk; Lloyd McKenzie > Cc: new-its at lists.hl7.org.uk > Subject: [New-ITS] Name for a flattened,association-collapsed > model derived from an RMIM > > Not sure about 'optimised' because: > > - Optimised implies the best in some sense; but it may not > yet be the best, just better > - The acronym 'OM' somehow is not very snappy - hard to read > as a word (or a bit Buddhist?). > > I have two other suggestions: > > - Transmission Model, or TM (still a bit Buddhist?) > - Semantically Equivalent Model, or SEM > > I like the last because it tells people we are not messing > with RIM semantics. > > Anyway, the acronym is now a variable in the tools, and I can > change it daily. We could put it to a vote at the WGM. > > Robert > > Charteris plc, Charteris House, 39/40 Bartholomew Close, London > EC1A 7JN > > phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 > 197968 > > *************************** E-mail confidentiality notice > ******************************* > > This message is intended for the addressee only. It is > private, confidential and may contain information of a > proprietary nature. If you have received this message in > error, please notify us and remove it from your system. > > -----Original Message----- > From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] > Sent: 09 August 2006 17:44 > To: Lloyd McKenzie > Cc: grahame at jivamedical.com; Robert Worden > Subject: RE: Steering RMIM reshaping > > Well -- we were trying to avoid C words -- so "optimized" > seems the best offering so far All the best Charlie > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > > > -----Original Message----- > > From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > > Sent: 09 August 2006 17:08 > > To: Charlie McCay > > Cc: grahame at jivamedical.com; Robert Worden > > Subject: Re: Steering RMIM reshaping > > > > Hi Charlie, > > > > Calling it a "practical" model sends the wrong message about the > > existing structure. Executable model suggests that it's an > internal > > object model, which it isn't. > > > > What this is is a "collapsed" or "compressed" or "optimized" > > or some other transformation type word. > > > > > > Lloyd > > > > Charlie McCay wrote: > > > So how about practical model or exchange model or executable model > > > > > > > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > Ltd, 23D > > > Dogpole, Shrewsbury, Shropshire SY1 1ES > > > > > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > > >> Sent: 09 August 2006 16:22 > > >> To: Charlie McCay > > >> Cc: grahame at jivamedical.com; Robert Worden > > >> Subject: Re: Steering RMIM reshaping > > >> > > >> Hi Charlie, > > >> > > >> The challenge is that many will read "physical model" in > its usual > > >> sense, which is persistence model, which we definitely > shouldn't be > > >> suggesting, let alone imposing. > > >> > > >> > > >> Lloyd > > >> > > >> Charlie McCay wrote: > > >> > > >>> Hi > > >>> > > >>> Why not? -- the intent is to provide the model for the physical > > >>> exchange (subject to ITS realisation, but that is the > > >>> > > >> model-reality > > >> > > >>> mapping) -- it is this practical model that is exactly what > > >>> > > >> we do want > > >> > > >>> from HL7, and that we have been using the logical > > >>> > > >> information model > > >> > > >>> as a proxy for until now > > >>> > > >>> Alternative that I do not like as much: > > >>> > > >>> EM exchange model / executable model > > >>> > > >>> charlie > > >>> > > >>> > > >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > > Ltd, 23D > > >>> Dogpole, Shrewsbury, Shropshire SY1 1ES > > >>> > > >>> tel 01743 232278 / 07808 570172 skype: charliemccay > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > > >>>> Sent: 09 August 2006 16:02 > > >>>> To: Charlie McCay > > >>>> Cc: grahame at jivamedical.com; Robert Worden > > >>>> Subject: Re: Steering RMIM reshaping > > >>>> > > >>>> Hi Charlie, > > >>>> > > >>>> I don't want to imply that HL7 defines actual physical > > models . . . > > >>>> > > >>>> > > >>>> Lloyd > > >>>> > > >>>> Charlie McCay wrote: > > >>>> > > >>>> > > >>>>> How about > > >>>>> > > >>>>> PM -- Physical/(?Practical?) Model ? > > >>>>> PM / PSM (Platform model (Platform Specific Model) > > >>>>> > > >>>>> All the best > > >>>>> > > >>>>> Charlie > > >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > > >>>>> > > >> Ltd, 23D > > >> > > >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES > > >>>>> > > >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > > >>>>>> Sent: 08 August 2006 05:45 > > >>>>>> To: grahame at jivamedical.com > > >>>>>> Cc: Robert Worden; Charlie McCay > > >>>>>> Subject: Re: Steering RMIM reshaping > > >>>>>> > > >>>>>> Except CM is used for CMET. Not sure we need a different > > >>>>>> > > >>>>>> > > >>>> id if the > > >>>> > > >>>> > > >>>>>> models are just transforms of each other. > > >>>>>> > > >>>>>> Grahame Grieve wrote: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> CM = collapsed model or computable model > > >>>>>>> > > >>>>>>> we could go with that > > >>>>>>> > > >>>>>>> Grahame > > >>>>>>> > > >>>>>>> > > >>>>>>> Lloyd McKenzie wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>> We can't use the word "Message" because we'll presumably > > >>>>>>>> > > >>>>>>>> > > >>>> be using > > >>>> > > >>>> > > >>>>>>>> this stuff for documents too. How about just > > >>>>>>>> > > >> "collapsed model", > > >> > > >>>>>>>> seeing as that's what it is . . . > > >>>>>>>> > > >>>>>>>> Grahame Grieve wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> we've been using the term implementable model. IM, > > I know.... > > >>>>>>>>> > > >>>>>>>>> maybe you could go for "message design"? it's not > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>> strictly a model, > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>> so we can get away from the "M" part and reduce confusion? > > >>>>>>>>> > > >>>>>>>>> cc: Charlie for an opinion > > >>>>>>>>> > > >>>>>>>>> Grahame > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Robert Worden wrote: > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> Grahame - > > >>>>>>>>>> > > >>>>>>>>>> I agree that DAM is not the right name, and will tend > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> to confuse > > >>>> > > >>>> > > >>>>>>>>>> people; we are making something strictly derived from > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> the RMIM and > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> suitable for implementation, which may have DAM-like > > >>>>>>>>>> > > >> names and > > >> > > >>>>>>>>>> structure. > > >>>>>>>>>> > > >>>>>>>>>> I'll stop calling it a DAM, and make the tools stop > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> calling it a > > >>>> > > >>>> > > >>>>>>>>>> DAM; but I would like a shorter name than 'reshaped > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> RMIM'. Any suggestions? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> Implementation > > >>>> > > >>>> > > >>>>>>>>>> Model? > > >>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. > > >>>>>>>>>> > > >>>>>>>>>> Give me an acronym and I will do a global edit... > > >>>>>>>>>> > > >>>>>>>>>> Robert > > >>>>>>>>>> > > >>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> Close, London > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> EC1A 7JN > > >>>>>>>>>> > > >>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> mobile: 44 7970 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> 197968 > > >>>>>>>>>> > > >>>>>>>>>> *************************** E-mail confidentiality notice > > >>>>>>>>>> ******************************* > > >>>>>>>>>> > > >>>>>>>>>> This message is intended for the addressee only. It is > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> private, > > >>>> > > >>>> > > >>>>>>>>>> confidential and may contain information of a > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> proprietary nature. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> If you have received this message in error, please > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> notify us and > > >>>> > > >>>> > > >>>>>>>>>> remove it from your system. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> -----Original Message----- > > >>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On > > >>>>>>>>>> > > >> Behalf Of > > >> > > >>>>>>>>>> Grahame Grieve > > >>>>>>>>>> Sent: 07 August 2006 22:18 > > >>>>>>>>>> To: Robert Worden > > >>>>>>>>>> Cc: Lloyd McKenzie > > >>>>>>>>>> Subject: Re: Steering RMIM reshaping > > >>>>>>>>>> > > >>>>>>>>>> I'm way behind on email. but spotted this. > > >>>>>>>>>> > > >>>>>>>>>> Robert, we need to stop talking about DAM. There is no > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> correlation > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> between what we are trying to achieve and a real DAM. > > >>>>>>>>>> > > >>>>>>>>>> What we want is to do implementation modelling on > > >>>>>>>>>> > > >> the RMIM. We > > >> > > >>>>>>>>>> recognise - particularly after talking to Simon Withey > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> last week - > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> that this has nothing to do with the DAM process, > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> except for the > > >>>> > > >>>> > > >>>>>>>>>> naming question. > > >>>>>>>>>> (Where by names in the instance should allow > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> identification back > > >>>> > > >>>> > > >>>>>>>>>> against the DAM, rather than against the RIM. Except > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> unless you are > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> concerned about naming stability, but that's a much > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> harder question > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> indeed) > > >>>>>>>>>> > > >>>>>>>>>> will come back to this thread later when I catch up > > >>>>>>>>>> > > >>>>>>>>>> Grahame > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Robert Worden wrote: > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> Hi Lloyd - > > >>>>>>>>>>> > > >>>>>>>>>>> I was thinking that since people should really > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>> produce a DAM on > > >>>> > > >>>> > > >>>>>>>>>>> the > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> way > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> to their RMIM, rather than the other way round, in some > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> sense the > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> RMIM should be derived from the DAM. But as it is not > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>> a formal > > >>>> > > >>>> > > >>>>>>>>>>> derivation, > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> it > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> may be that the route is not > > >>>>>>>>>>> > > >> appropriate. > > >> > > >>>>>>>>>>> What then is the approved mechanism for adding > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> annotations to a MIF? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> I'm > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> sure I could find it in the schemas, but it's easier to > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> ask you... > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> :-) > > >>>>>>>>>>> > > >>>>>>>>>>> Robert > > >>>>>>>>>>> > > >>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> Close, London > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> EC1A 7JN > > >>>>>>>>>>> > > >>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> mobile: 44 7970 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> 197968 > > >>>>>>>>>>> > > >>>>>>>>>>> *************************** E-mail > confidentiality notice > > >>>>>>>>>>> ******************************* > > >>>>>>>>>>> > > >>>>>>>>>>> This message is intended for the addressee only. It > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>> is private, > > >>>> > > >>>> > > >>>>>>>>>>> confidential and may contain information of a > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> proprietary nature. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> If you have received this message in error, please > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> notify us and > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> remove it from your system. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> -----Original Message----- > > >>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> 07 August > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> 2006 19:43 > > >>>>>>>>>>> To: Robert Worden > > >>>>>>>>>>> Cc: grahame at kestral.com.au > > >>>>>>>>>>> Subject: Re: Steering RMIM reshaping > > >>>>>>>>>>> > > >>>>>>>>>>> Hi Robert, > > >>>>>>>>>>> > > >>>>>>>>>>> Relationships between a static model and a DAM would be > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> mappings, > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> not derivations. StaticModelDerivationId is not a > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>> spare. In the > > >>>> > > >>>> > > >>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> and HMD but > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> in theory we could derive from 20 different models. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> (And there's > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> no ordering > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> either, > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> the RIM could be the first one listed or the seventh.) > > >>>>>>>>>>> > > >>>>>>>>>>> The basic question is whether you construct your > > DAM from a > > >>>>>>>>>>> collapsed static model (as we do in Canada), or whether > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> you want > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> to create your DAMs and DIMs separately and map > > >>>>>>>>>>> > > >> them. If the > > >> > > >>>>>>>>>>> latter, I don't think > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> you > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> could do this in an automated way. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> Lloyd > > >>>>>>>>>>> > > >>>>>>>>>>> Robert Worden wrote: > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>>> Grahame - > > >>>>>>>>>>>> > > >>>>>>>>>>>> You asked the other day for suggestions as to how > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>> the current > > >>>> > > >>>> > > >>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be > steered by > > >>>>>>>>>>>> annotations in the RMIM MIF, rather than by user > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> input. Here is a > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> first punt to get thinking going. > > >>>>>>>>>>>> > > >>>>>>>>>>>> The simplest suggestion I can make is to add to the > > >>>>>>>>>>>> elements another one which says > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>> how this > > >>>> > > >>>> > > >>>>>>>>>>>> RMIM > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>> was > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>>> derived (or might have been derived) from a DAM. These > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> would look > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> like: > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>>> > >>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> > > >>>>>>>>>>>> > > >>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> but choose > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> one > > >>>>>>>>>>>> > > >>>>>>>>>>>> that is). These can go on elements for classes, > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> associations, and > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> properties to say in effect > > >>>>>>>>>>>> > > >>>>>>>>>>>> * Rename this class to a DAM class name > > >>>>>>>>>>>> * Rename this association (with perhaps other > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> attributes saying > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> 'collapse it' or 'leave it out') > > >>>>>>>>>>>> * Rename this property to a DAM property name (or > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> some value > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> meaning 'leave it out') > > >>>>>>>>>>>> > > >>>>>>>>>>>> If you wanted, you would not even have to say > explicitly > > >>>>>>>>>>>> 'collapse an > > >>>>>>>>>>>> > > >>>>>>>>>>>> association' - because if the DAM class names are > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>> the same on > > >>>> > > >>>> > > >>>>>>>>>>>> either side of it, that means collapse it. > > >>>>>>>>>>>> > > >>>>>>>>>>>> This proposal would not yet address a combination of > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> restricting > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> and reshaping an RMIM. > > >>>>>>>>>>>> > > >>>>>>>>>>>> It would imply you cannot collapse across a CMET > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> boundary, which > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> I gather from our discussion the other day you would > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> like to do. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> Or maybe you can, by telling the association to > > >>>>>>>>>>>> > > >> the CMET to > > >> > > >>>>>>>>>>>> collapse itself? Have not thought it through yet. I > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>> know there > > >>>> > > >>>> > > >>>>>>>>>>>> are issues > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>> about > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>>> CMETs with a choice at the top - any chance you > > >>>>>>>>>>>> > > >> could send a > > >> > > >>>>>>>>>>>> simple diagram to illustrate the problem as you see it? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Anyway, if we come up with any scheme like the above, > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> it should > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> be straightforward to implement in the tool. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Robert > > >>>>>>>>>>>> > > >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> Close, London > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> EC1A > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> 7JN > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> 7970 197968 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> *************************** E-mail > confidentiality notice > > >>>>>>>>>>>> ******************************* > > >>>>>>>>>>>> > > >>>>>>>>>>>> This message is intended for the addressee only. It is > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> private, > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> confidential and may contain information of a > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> proprietary nature. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> If you have received this > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>> message > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>>> in error, please notify > > >>>>>>>>>>>> us and remove it from your system. > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> > > _________________________________________________________________ > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> This message from Charteris plc has been checked > > >>>>>>>>>>>> > > >> for viruses > > >> > > >>>>>>>>>>>> http://www.charteris.com/ > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> > > _________________________________________________________________ > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> This message to Charteris plc has been checked > > for viruses > > >>>>>>>>>>> http://www.charteris.com/ > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> > > _________________________________________________________________ > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> This message from Charteris plc has been checked > > >>>>>>>>>>> > > >> for viruses > > >> > > >>>>>>>>>>> http://www.charteris.com/ > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>> > > >>>> > > >> > > >> > > > > > > > > _________________________________________________________________ > This message to Charteris plc has been checked for viruses > http://www.charteris.com/ > > _________________________________________________________________ > This message from Charteris plc has been checked for viruses > http://www.charteris.com/ > _______________________________________________ > 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. > > > _______________________________________________ > 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. From Robert.Worden at Charteris.com Fri Aug 11 12:07:31 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Fri, 11 Aug 2006 12:07:31 +0100 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM Message-ID: OIM not sure about that - sounds a bit west country... Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. -----Original Message----- From: Smithies Rik [mailto:rik.smithies at cfh.nhs.uk] Sent: 11 August 2006 10:31 To: Sato Laura; Robert Worden; charlie at ramseysystems.co.uk; Lloyd McKenzie Cc: new-its at lists.hl7.org.uk Subject: RE: [New-ITS] Name for a flattened,association-collapsed model derived from an RMIM Rather than Implementable Model, which all models are hopefully, how about "Implementation Model", which stresses that it is modelled specifically to account for implementation issues. "Optimised" isn't too bad but as Robert says in which direction is it optimised ? maybe OIM Optimised Implementation Model If you say it quick, it's only one syllable! > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Sato Laura > Sent: 11 August 2006 09:36 > To: Robert Worden; charlie at ramseysystems.co.uk; Lloyd McKenzie > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Name for a > flattened,association-collapsed model derived from an RMIM > > I realise that I'm a little late into this conversation, > but... what was wrong with Implementable Model - is it the > acronym, IM, that's too like something else? What I liked > about 'implementable' was that it gave the sense of the view > for which the model was designed for (i.e. > implementers). It gave a focus for what it was supposed to > accomplish. > > Scanning through the other terms, I don't mind > Platform-Specific Model, if that's truly what it is (is it?). > Transmission Model might be okay. > > Semantically Equivalent Model doesn't say anything to me > about what it's for, so I'm not crazy about this one. > > Just my 2p... > > Regards, > Laura > _________________________ > Laura Sato > Informatics Standards Lead > > Communications & Messaging > NHS Connecting for Health > Mobile: (44) (0)7733 324 338 > Email: laura.sato at cfh.nhs.uk > www.connectingforhealth.nhs.uk > > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden > Sent: 10 August 2006 18:18 > To: charlie at ramseysystems.co.uk; Lloyd McKenzie > Cc: new-its at lists.hl7.org.uk > Subject: [New-ITS] Name for a flattened,association-collapsed > model derived from an RMIM > > Not sure about 'optimised' because: > > - Optimised implies the best in some sense; but it may not > yet be the best, just better > - The acronym 'OM' somehow is not very snappy - hard to read > as a word (or a bit Buddhist?). > > I have two other suggestions: > > - Transmission Model, or TM (still a bit Buddhist?) > - Semantically Equivalent Model, or SEM > > I like the last because it tells people we are not messing > with RIM semantics. > > Anyway, the acronym is now a variable in the tools, and I can > change it daily. We could put it to a vote at the WGM. > > Robert > > Charteris plc, Charteris House, 39/40 Bartholomew Close, London > EC1A 7JN > > phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 > 197968 > > *************************** E-mail confidentiality notice > ******************************* > > This message is intended for the addressee only. It is > private, confidential and may contain information of a > proprietary nature. If you have received this message in > error, please notify us and remove it from your system. > > -----Original Message----- > From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] > Sent: 09 August 2006 17:44 > To: Lloyd McKenzie > Cc: grahame at jivamedical.com; Robert Worden > Subject: RE: Steering RMIM reshaping > > Well -- we were trying to avoid C words -- so "optimized" > seems the best offering so far All the best Charlie > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > > > -----Original Message----- > > From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > > Sent: 09 August 2006 17:08 > > To: Charlie McCay > > Cc: grahame at jivamedical.com; Robert Worden > > Subject: Re: Steering RMIM reshaping > > > > Hi Charlie, > > > > Calling it a "practical" model sends the wrong message about the > > existing structure. Executable model suggests that it's an > internal > > object model, which it isn't. > > > > What this is is a "collapsed" or "compressed" or "optimized" > > or some other transformation type word. > > > > > > Lloyd > > > > Charlie McCay wrote: > > > So how about practical model or exchange model or executable model > > > > > > > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > Ltd, 23D > > > Dogpole, Shrewsbury, Shropshire SY1 1ES > > > > > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > > >> Sent: 09 August 2006 16:22 > > >> To: Charlie McCay > > >> Cc: grahame at jivamedical.com; Robert Worden > > >> Subject: Re: Steering RMIM reshaping > > >> > > >> Hi Charlie, > > >> > > >> The challenge is that many will read "physical model" in > its usual > > >> sense, which is persistence model, which we definitely > shouldn't be > > >> suggesting, let alone imposing. > > >> > > >> > > >> Lloyd > > >> > > >> Charlie McCay wrote: > > >> > > >>> Hi > > >>> > > >>> Why not? -- the intent is to provide the model for the physical > > >>> exchange (subject to ITS realisation, but that is the > > >>> > > >> model-reality > > >> > > >>> mapping) -- it is this practical model that is exactly what > > >>> > > >> we do want > > >> > > >>> from HL7, and that we have been using the logical > > >>> > > >> information model > > >> > > >>> as a proxy for until now > > >>> > > >>> Alternative that I do not like as much: > > >>> > > >>> EM exchange model / executable model > > >>> > > >>> charlie > > >>> > > >>> > > >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > > Ltd, 23D > > >>> Dogpole, Shrewsbury, Shropshire SY1 1ES > > >>> > > >>> tel 01743 232278 / 07808 570172 skype: charliemccay > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > > >>>> Sent: 09 August 2006 16:02 > > >>>> To: Charlie McCay > > >>>> Cc: grahame at jivamedical.com; Robert Worden > > >>>> Subject: Re: Steering RMIM reshaping > > >>>> > > >>>> Hi Charlie, > > >>>> > > >>>> I don't want to imply that HL7 defines actual physical > > models . . . > > >>>> > > >>>> > > >>>> Lloyd > > >>>> > > >>>> Charlie McCay wrote: > > >>>> > > >>>> > > >>>>> How about > > >>>>> > > >>>>> PM -- Physical/(?Practical?) Model ? > > >>>>> PM / PSM (Platform model (Platform Specific Model) > > >>>>> > > >>>>> All the best > > >>>>> > > >>>>> Charlie > > >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > > >>>>> > > >> Ltd, 23D > > >> > > >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES > > >>>>> > > >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > > >>>>>> Sent: 08 August 2006 05:45 > > >>>>>> To: grahame at jivamedical.com > > >>>>>> Cc: Robert Worden; Charlie McCay > > >>>>>> Subject: Re: Steering RMIM reshaping > > >>>>>> > > >>>>>> Except CM is used for CMET. Not sure we need a different > > >>>>>> > > >>>>>> > > >>>> id if the > > >>>> > > >>>> > > >>>>>> models are just transforms of each other. > > >>>>>> > > >>>>>> Grahame Grieve wrote: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> CM = collapsed model or computable model > > >>>>>>> > > >>>>>>> we could go with that > > >>>>>>> > > >>>>>>> Grahame > > >>>>>>> > > >>>>>>> > > >>>>>>> Lloyd McKenzie wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>> We can't use the word "Message" because we'll presumably > > >>>>>>>> > > >>>>>>>> > > >>>> be using > > >>>> > > >>>> > > >>>>>>>> this stuff for documents too. How about just > > >>>>>>>> > > >> "collapsed model", > > >> > > >>>>>>>> seeing as that's what it is . . . > > >>>>>>>> > > >>>>>>>> Grahame Grieve wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> we've been using the term implementable model. IM, > > I know.... > > >>>>>>>>> > > >>>>>>>>> maybe you could go for "message design"? it's not > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>> strictly a model, > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>> so we can get away from the "M" part and reduce confusion? > > >>>>>>>>> > > >>>>>>>>> cc: Charlie for an opinion > > >>>>>>>>> > > >>>>>>>>> Grahame > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Robert Worden wrote: > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> Grahame - > > >>>>>>>>>> > > >>>>>>>>>> I agree that DAM is not the right name, and will tend > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> to confuse > > >>>> > > >>>> > > >>>>>>>>>> people; we are making something strictly derived from > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> the RMIM and > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> suitable for implementation, which may have DAM-like > > >>>>>>>>>> > > >> names and > > >> > > >>>>>>>>>> structure. > > >>>>>>>>>> > > >>>>>>>>>> I'll stop calling it a DAM, and make the tools stop > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> calling it a > > >>>> > > >>>> > > >>>>>>>>>> DAM; but I would like a shorter name than 'reshaped > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> RMIM'. Any suggestions? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> Implementation > > >>>> > > >>>> > > >>>>>>>>>> Model? > > >>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. > > >>>>>>>>>> > > >>>>>>>>>> Give me an acronym and I will do a global edit... > > >>>>>>>>>> > > >>>>>>>>>> Robert > > >>>>>>>>>> > > >>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> Close, London > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> EC1A 7JN > > >>>>>>>>>> > > >>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> mobile: 44 7970 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> 197968 > > >>>>>>>>>> > > >>>>>>>>>> *************************** E-mail confidentiality notice > > >>>>>>>>>> ******************************* > > >>>>>>>>>> > > >>>>>>>>>> This message is intended for the addressee only. It is > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> private, > > >>>> > > >>>> > > >>>>>>>>>> confidential and may contain information of a > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> proprietary nature. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> If you have received this message in error, please > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> notify us and > > >>>> > > >>>> > > >>>>>>>>>> remove it from your system. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> -----Original Message----- > > >>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On > > >>>>>>>>>> > > >> Behalf Of > > >> > > >>>>>>>>>> Grahame Grieve > > >>>>>>>>>> Sent: 07 August 2006 22:18 > > >>>>>>>>>> To: Robert Worden > > >>>>>>>>>> Cc: Lloyd McKenzie > > >>>>>>>>>> Subject: Re: Steering RMIM reshaping > > >>>>>>>>>> > > >>>>>>>>>> I'm way behind on email. but spotted this. > > >>>>>>>>>> > > >>>>>>>>>> Robert, we need to stop talking about DAM. There is no > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> correlation > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> between what we are trying to achieve and a real DAM. > > >>>>>>>>>> > > >>>>>>>>>> What we want is to do implementation modelling on > > >>>>>>>>>> > > >> the RMIM. We > > >> > > >>>>>>>>>> recognise - particularly after talking to Simon Withey > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> last week - > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> that this has nothing to do with the DAM process, > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> except for the > > >>>> > > >>>> > > >>>>>>>>>> naming question. > > >>>>>>>>>> (Where by names in the instance should allow > > >>>>>>>>>> > > >>>>>>>>>> > > >>>> identification back > > >>>> > > >>>> > > >>>>>>>>>> against the DAM, rather than against the RIM. Except > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> unless you are > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> concerned about naming stability, but that's a much > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>> harder question > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> indeed) > > >>>>>>>>>> > > >>>>>>>>>> will come back to this thread later when I catch up > > >>>>>>>>>> > > >>>>>>>>>> Grahame > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Robert Worden wrote: > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> Hi Lloyd - > > >>>>>>>>>>> > > >>>>>>>>>>> I was thinking that since people should really > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>> produce a DAM on > > >>>> > > >>>> > > >>>>>>>>>>> the > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> way > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> to their RMIM, rather than the other way round, in some > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> sense the > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> RMIM should be derived from the DAM. But as it is not > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>> a formal > > >>>> > > >>>> > > >>>>>>>>>>> derivation, > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> it > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> may be that the route is not > > >>>>>>>>>>> > > >> appropriate. > > >> > > >>>>>>>>>>> What then is the approved mechanism for adding > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> annotations to a MIF? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>> I'm > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> sure I could find it in the schemas, but it's easier to > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> ask you... > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> :-) > > >>>>>>>>>>> > > >>>>>>>>>>> Robert > > >>>>>>>>>>> > > >>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> Close, London > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> EC1A 7JN > > >>>>>>>>>>> > > >>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> mobile: 44 7970 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> 197968 > > >>>>>>>>>>> > > >>>>>>>>>>> *************************** E-mail > confidentiality notice > > >>>>>>>>>>> ******************************* > > >>>>>>>>>>> > > >>>>>>>>>>> This message is intended for the addressee only. It > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>> is private, > > >>>> > > >>>> > > >>>>>>>>>>> confidential and may contain information of a > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> proprietary nature. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> If you have received this message in error, please > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> notify us and > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> remove it from your system. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> -----Original Message----- > > >>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> 07 August > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> 2006 19:43 > > >>>>>>>>>>> To: Robert Worden > > >>>>>>>>>>> Cc: grahame at kestral.com.au > > >>>>>>>>>>> Subject: Re: Steering RMIM reshaping > > >>>>>>>>>>> > > >>>>>>>>>>> Hi Robert, > > >>>>>>>>>>> > > >>>>>>>>>>> Relationships between a static model and a DAM would be > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> mappings, > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> not derivations. StaticModelDerivationId is not a > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>> spare. In the > > >>>> > > >>>> > > >>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> and HMD but > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> in theory we could derive from 20 different models. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> (And there's > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> no ordering > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> either, > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> the RIM could be the first one listed or the seventh.) > > >>>>>>>>>>> > > >>>>>>>>>>> The basic question is whether you construct your > > DAM from a > > >>>>>>>>>>> collapsed static model (as we do in Canada), or whether > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> you want > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> to create your DAMs and DIMs separately and map > > >>>>>>>>>>> > > >> them. If the > > >> > > >>>>>>>>>>> latter, I don't think > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> you > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> could do this in an automated way. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> Lloyd > > >>>>>>>>>>> > > >>>>>>>>>>> Robert Worden wrote: > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>>> Grahame - > > >>>>>>>>>>>> > > >>>>>>>>>>>> You asked the other day for suggestions as to how > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>> the current > > >>>> > > >>>> > > >>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be > steered by > > >>>>>>>>>>>> annotations in the RMIM MIF, rather than by user > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> input. Here is a > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> first punt to get thinking going. > > >>>>>>>>>>>> > > >>>>>>>>>>>> The simplest suggestion I can make is to add to the > > >>>>>>>>>>>> elements another one which says > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>> how this > > >>>> > > >>>> > > >>>>>>>>>>>> RMIM > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>> was > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>>> derived (or might have been derived) from a DAM. These > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> would look > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> like: > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>>> > >>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> > > >>>>>>>>>>>> > > >>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> but choose > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> one > > >>>>>>>>>>>> > > >>>>>>>>>>>> that is). These can go on elements for classes, > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> associations, and > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> properties to say in effect > > >>>>>>>>>>>> > > >>>>>>>>>>>> * Rename this class to a DAM class name > > >>>>>>>>>>>> * Rename this association (with perhaps other > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> attributes saying > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> 'collapse it' or 'leave it out') > > >>>>>>>>>>>> * Rename this property to a DAM property name (or > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> some value > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> meaning 'leave it out') > > >>>>>>>>>>>> > > >>>>>>>>>>>> If you wanted, you would not even have to say > explicitly > > >>>>>>>>>>>> 'collapse an > > >>>>>>>>>>>> > > >>>>>>>>>>>> association' - because if the DAM class names are > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>> the same on > > >>>> > > >>>> > > >>>>>>>>>>>> either side of it, that means collapse it. > > >>>>>>>>>>>> > > >>>>>>>>>>>> This proposal would not yet address a combination of > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> restricting > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> and reshaping an RMIM. > > >>>>>>>>>>>> > > >>>>>>>>>>>> It would imply you cannot collapse across a CMET > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> boundary, which > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> I gather from our discussion the other day you would > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> like to do. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> Or maybe you can, by telling the association to > > >>>>>>>>>>>> > > >> the CMET to > > >> > > >>>>>>>>>>>> collapse itself? Have not thought it through yet. I > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>> know there > > >>>> > > >>>> > > >>>>>>>>>>>> are issues > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>> about > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>>> CMETs with a choice at the top - any chance you > > >>>>>>>>>>>> > > >> could send a > > >> > > >>>>>>>>>>>> simple diagram to illustrate the problem as you see it? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Anyway, if we come up with any scheme like the above, > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> it should > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> be straightforward to implement in the tool. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Robert > > >>>>>>>>>>>> > > >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> Close, London > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> EC1A > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> 7JN > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> 7970 197968 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> *************************** E-mail > confidentiality notice > > >>>>>>>>>>>> ******************************* > > >>>>>>>>>>>> > > >>>>>>>>>>>> This message is intended for the addressee only. It is > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> private, > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> confidential and may contain information of a > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> proprietary nature. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> If you have received this > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>> message > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>>> in error, please notify > > >>>>>>>>>>>> us and remove it from your system. > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>> > > _________________________________________________________________ > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>>> This message from Charteris plc has been checked > > >>>>>>>>>>>> > > >> for viruses > > >> > > >>>>>>>>>>>> http://www.charteris.com/ > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> > > _________________________________________________________________ > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> This message to Charteris plc has been checked > > for viruses > > >>>>>>>>>>> http://www.charteris.com/ > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>> > > _________________________________________________________________ > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>>>>> This message from Charteris plc has been checked > > >>>>>>>>>>> > > >> for viruses > > >> > > >>>>>>>>>>> http://www.charteris.com/ > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>> > > >>>> > > >> > > >> > > > > > > > > _________________________________________________________________ > This message to Charteris plc has been checked for viruses > http://www.charteris.com/ > > _________________________________________________________________ > This message from Charteris plc has been checked for viruses > http://www.charteris.com/ > _______________________________________________ > 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. > > > _______________________________________________ > 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. _________________________________________________________________ This message to Charteris plc has been checked for viruses http://www.charteris.com/ _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ From Charlie at ramseysystems.co.uk Fri Aug 11 17:38:44 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Fri, 11 Aug 2006 17:38:44 +0100 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FBFD@ramseysc1420.RamseyNet.local> Lloyd I understood that IM was rejected because we already have lots of Information Models. It is yet to be established whether the collapsed model approach, if endorsed, would be an alternative to or replacement for, the current ITS. There was a view expressed in INM that maintaining both may not be the best way to go forwards. Every model is platform independent to some degree. One take on the collapsing process would be to say that it was intended to generate models that were appropriate for implementation using XML, and as such would be platform specific. Another would be that it was to produce models that were appropriate for any generic implementation technology (ie an Abstract Implementation Model), in this case I would agree that it would be inappropriate to say that the models were platform specific. One of the issues that we need to explore is whether targeting just XML for the implementation models makes a significant difference. There are differing expectations as to what the outcome of that will be. All the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay > -----Original Message----- > From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > Sent: 11 August 2006 17:17 > To: Sato Laura > Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Name for a > flattened,association-collapsed model derived from an RMIM > > Hi Laura, > > The issue is that HL7 can be implemented in both collapsed > and non-collapsed manners. The model is also platform-independent. > > > Lloyd > > Sato Laura wrote: > > I realise that I'm a little late into this conversation, > but... what > > was wrong with Implementable Model - is it the acronym, IM, > that's too > > like something else? What I liked about 'implementable' was that it > > gave the sense of the view for which the model was designed > for (i.e. > > implementers). It gave a focus for what it was supposed to > accomplish. > > > > Scanning through the other terms, I don't mind > Platform-Specific Model, > > if that's truly what it is (is it?). Transmission Model > might be okay. > > > > Semantically Equivalent Model doesn't say anything to me > about what it's > > for, so I'm not crazy about this one. > > > > Just my 2p... > > > > Regards, > > Laura > > _________________________ > > Laura Sato > > Informatics Standards Lead > > > > Communications & Messaging > > NHS Connecting for Health > > Mobile: (44) (0)7733 324 338 > > Email: laura.sato at cfh.nhs.uk > > www.connectingforhealth.nhs.uk > > > > -----Original Message----- > > From: new-its-bounces at lists.hl7.org.uk > > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden > > Sent: 10 August 2006 18:18 > > To: charlie at ramseysystems.co.uk; Lloyd McKenzie > > Cc: new-its at lists.hl7.org.uk > > Subject: [New-ITS] Name for a flattened,association-collapsed model > > derived from an RMIM > > > > Not sure about 'optimised' because: > > > > - Optimised implies the best in some sense; but it may not > yet be the > > best, just better > > - The acronym 'OM' somehow is not very snappy - hard to > read as a word > > (or a bit Buddhist?). > > > > I have two other suggestions: > > > > - Transmission Model, or TM (still a bit Buddhist?) > > - Semantically Equivalent Model, or SEM > > > > I like the last because it tells people we are not messing with RIM > > semantics. > > > > Anyway, the acronym is now a variable in the tools, and I > can change it > > daily. We could put it to a vote at the WGM. > > > > Robert > > > > Charteris plc, Charteris House, 39/40 Bartholomew Close, London > > EC1A 7JN > > > > phone: 44 1353 777668; Fax 44 1353 777394; > mobile: 44 7970 > > 197968 > > > > *************************** E-mail confidentiality notice > > ******************************* > > > > This message is intended for the addressee only. It is private, > > confidential and may contain > > information of a proprietary nature. If you have received > this message > > in error, please notify > > us and remove it from your system. > > > > -----Original Message----- > > From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] > > Sent: 09 August 2006 17:44 > > To: Lloyd McKenzie > > Cc: grahame at jivamedical.com; Robert Worden > > Subject: RE: Steering RMIM reshaping > > > > Well -- we were trying to avoid C words -- so "optimized" > seems the best > > offering so far > > All the best > > Charlie > > > > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > > Dogpole, Shrewsbury, Shropshire SY1 1ES > > > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > > > > > > > > >> -----Original Message----- > >> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >> Sent: 09 August 2006 17:08 > >> To: Charlie McCay > >> Cc: grahame at jivamedical.com; Robert Worden > >> Subject: Re: Steering RMIM reshaping > >> > >> Hi Charlie, > >> > >> Calling it a "practical" model sends the wrong message about > >> the existing structure. Executable model suggests that it's > >> an internal object model, which it isn't. > >> > >> What this is is a "collapsed" or "compressed" or "optimized" > >> or some other transformation type word. > >> > >> > >> Lloyd > >> > >> Charlie McCay wrote: > >> > >>> So how about practical model or exchange model or executable model > >>> > >>> > >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > >>> Dogpole, Shrewsbury, Shropshire SY1 1ES > >>> > >>> tel 01743 232278 / 07808 570172 skype: charliemccay > >>> > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >>>> Sent: 09 August 2006 16:22 > >>>> To: Charlie McCay > >>>> Cc: grahame at jivamedical.com; Robert Worden > >>>> Subject: Re: Steering RMIM reshaping > >>>> > >>>> Hi Charlie, > >>>> > >>>> The challenge is that many will read "physical model" in its > >>>> usual sense, which is persistence model, which we definitely > >>>> shouldn't be suggesting, let alone imposing. > >>>> > >>>> > >>>> Lloyd > >>>> > >>>> Charlie McCay wrote: > >>>> > >>>> > >>>>> Hi > >>>>> > >>>>> Why not? -- the intent is to provide the model for the physical > >>>>> exchange (subject to ITS realisation, but that is the > >>>>> > >>>>> > >>>> model-reality > >>>> > >>>> > >>>>> mapping) -- it is this practical model that is exactly what > >>>>> > >>>>> > >>>> we do want > >>>> > >>>> > >>>>> from HL7, and that we have been using the logical > >>>>> > >>>>> > >>>> information model > >>>> > >>>> > >>>>> as a proxy for until now > >>>>> > >>>>> Alternative that I do not like as much: > >>>>> > >>>>> EM exchange model / executable model > >>>>> > >>>>> charlie > >>>>> > >>>>> > >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > >>>>> > >> Ltd, 23D > >> > >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES > >>>>> > >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >>>>>> Sent: 09 August 2006 16:02 > >>>>>> To: Charlie McCay > >>>>>> Cc: grahame at jivamedical.com; Robert Worden > >>>>>> Subject: Re: Steering RMIM reshaping > >>>>>> > >>>>>> Hi Charlie, > >>>>>> > >>>>>> I don't want to imply that HL7 defines actual physical > >>>>>> > >> models . . . > >> > >>>>>> Lloyd > >>>>>> > >>>>>> Charlie McCay wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> How about > >>>>>>> > >>>>>>> PM -- Physical/(?Practical?) Model ? > >>>>>>> PM / PSM (Platform model (Platform Specific Model) > >>>>>>> > >>>>>>> All the best > >>>>>>> > >>>>>>> Charlie > >>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > >>>>>>> > >>>>>>> > >>>> Ltd, 23D > >>>> > >>>> > >>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES > >>>>>>> > >>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >>>>>>>> Sent: 08 August 2006 05:45 > >>>>>>>> To: grahame at jivamedical.com > >>>>>>>> Cc: Robert Worden; Charlie McCay > >>>>>>>> Subject: Re: Steering RMIM reshaping > >>>>>>>> > >>>>>>>> Except CM is used for CMET. Not sure we need a different > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> id if the > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> models are just transforms of each other. > >>>>>>>> > >>>>>>>> Grahame Grieve wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> CM = collapsed model or computable model > >>>>>>>>> > >>>>>>>>> we could go with that > >>>>>>>>> > >>>>>>>>> Grahame > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Lloyd McKenzie wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> We can't use the word "Message" because we'll presumably > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>> be using > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>> this stuff for documents too. How about just > >>>>>>>>>> > >>>>>>>>>> > >>>> "collapsed model", > >>>> > >>>> > >>>>>>>>>> seeing as that's what it is . . . > >>>>>>>>>> > >>>>>>>>>> Grahame Grieve wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> we've been using the term implementable model. IM, > >>>>>>>>>>> > >> I know.... > >> > >>>>>>>>>>> maybe you could go for "message design"? it's not > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>> strictly a model, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> so we can get away from the "M" part and reduce confusion? > >>>>>>>>>>> > >>>>>>>>>>> cc: Charlie for an opinion > >>>>>>>>>>> > >>>>>>>>>>> Grahame > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Robert Worden wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Grahame - > >>>>>>>>>>>> > >>>>>>>>>>>> I agree that DAM is not the right name, and will tend > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> to confuse > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> people; we are making something strictly derived from > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> the RMIM and > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> suitable for implementation, which may have DAM-like > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> names and > >>>> > >>>> > >>>>>>>>>>>> structure. > >>>>>>>>>>>> > >>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> calling it a > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> RMIM'. Any suggestions? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> Implementation > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> Model? > >>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. > >>>>>>>>>>>> > >>>>>>>>>>>> Give me an acronym and I will do a global edit... > >>>>>>>>>>>> > >>>>>>>>>>>> Robert > >>>>>>>>>>>> > >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> Close, London > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> EC1A 7JN > >>>>>>>>>>>> > >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> mobile: 44 7970 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> 197968 > >>>>>>>>>>>> > >>>>>>>>>>>> *************************** E-mail confidentiality notice > >>>>>>>>>>>> ******************************* > >>>>>>>>>>>> > >>>>>>>>>>>> This message is intended for the addressee only. It is > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> private, > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> confidential and may contain information of a > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> proprietary nature. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> If you have received this message in error, please > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> notify us and > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> remove it from your system. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> Behalf Of > >>>> > >>>> > >>>>>>>>>>>> Grahame Grieve > >>>>>>>>>>>> Sent: 07 August 2006 22:18 > >>>>>>>>>>>> To: Robert Worden > >>>>>>>>>>>> Cc: Lloyd McKenzie > >>>>>>>>>>>> Subject: Re: Steering RMIM reshaping > >>>>>>>>>>>> > >>>>>>>>>>>> I'm way behind on email. but spotted this. > >>>>>>>>>>>> > >>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> correlation > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> between what we are trying to achieve and a real DAM. > >>>>>>>>>>>> > >>>>>>>>>>>> What we want is to do implementation modelling on > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> the RMIM. We > >>>> > >>>> > >>>>>>>>>>>> recognise - particularly after talking to Simon Withey > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> last week - > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> that this has nothing to do with the DAM process, > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> except for the > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> naming question. > >>>>>>>>>>>> (Where by names in the instance should allow > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> identification back > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>> against the DAM, rather than against the RIM. Except > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> unless you are > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> concerned about naming stability, but that's a much > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> harder question > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> indeed) > >>>>>>>>>>>> > >>>>>>>>>>>> will come back to this thread later when I catch up > >>>>>>>>>>>> > >>>>>>>>>>>> Grahame > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Robert Worden wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi Lloyd - > >>>>>>>>>>>>> > >>>>>>>>>>>>> I was thinking that since people should really > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>> produce a DAM on > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>>> the > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> way > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> to their RMIM, rather than the other way round, in some > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> sense the > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>> a formal > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>>> derivation, > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> it > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> may be that the route is not > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>> appropriate. > >>>> > >>>> > >>>>>>>>>>>>> What then is the approved mechanism for adding > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> annotations to a MIF? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> I'm > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> sure I could find it in the schemas, but it's easier to > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> ask you... > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> :-) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Robert > >>>>>>>>>>>>> > >>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> Close, London > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> EC1A 7JN > >>>>>>>>>>>>> > >>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> mobile: 44 7970 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> 197968 > >>>>>>>>>>>>> > >>>>>>>>>>>>> *************************** E-mail > confidentiality notice > >>>>>>>>>>>>> ******************************* > >>>>>>>>>>>>> > >>>>>>>>>>>>> This message is intended for the addressee only. It > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>> is private, > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>>> confidential and may contain information of a > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> proprietary nature. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> If you have received this message in error, please > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> notify us and > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> remove it from your system. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> 07 August > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> 2006 19:43 > >>>>>>>>>>>>> To: Robert Worden > >>>>>>>>>>>>> Cc: grahame at kestral.com.au > >>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hi Robert, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Relationships between a static model and a DAM would be > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> mappings, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> not derivations. StaticModelDerivationId is not a > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>> spare. In the > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> and HMD but > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> in theory we could derive from 20 different models. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> (And there's > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> no ordering > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> either, > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> the RIM could be the first one listed or the seventh.) > >>>>>>>>>>>>> > >>>>>>>>>>>>> The basic question is whether you construct your > >>>>>>>>>>>>> > >> DAM from a > >> > >>>>>>>>>>>>> collapsed static model (as we do in Canada), or whether > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> you want > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> to create your DAMs and DIMs separately and map > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>> them. If the > >>>> > >>>> > >>>>>>>>>>>>> latter, I don't think > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> you > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> could do this in an automated way. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Lloyd > >>>>>>>>>>>>> > >>>>>>>>>>>>> Robert Worden wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Grahame - > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> You asked the other day for suggestions as to how > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>> the current > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be > steered by > >>>>>>>>>>>>>> annotations in the RMIM MIF, rather than by user > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> input. Here is a > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> first punt to get thinking going. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The simplest suggestion I can make is to add to the > >>>>>>>>>>>>>> elements another one which says > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>> how this > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>>>> RMIM > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> was > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>> derived (or might have been derived) from a DAM. These > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> would look > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> like: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> but choose > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> one > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> that is). These can go on elements for classes, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> associations, and > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> properties to say in effect > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> * Rename this class to a DAM class name > >>>>>>>>>>>>>> * Rename this association (with perhaps other > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> attributes saying > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> 'collapse it' or 'leave it out') > >>>>>>>>>>>>>> * Rename this property to a DAM property name (or > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> some value > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> meaning 'leave it out') > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> If you wanted, you would not even have to say > explicitly > >>>>>>>>>>>>>> 'collapse an > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> association' - because if the DAM class names are > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>> the same on > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>>>> either side of it, that means collapse it. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This proposal would not yet address a combination of > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> restricting > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> and reshaping an RMIM. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> It would imply you cannot collapse across a CMET > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> boundary, which > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> I gather from our discussion the other day you would > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> like to do. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> Or maybe you can, by telling the association to > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>> the CMET to > >>>> > >>>> > >>>>>>>>>>>>>> collapse itself? Have not thought it through yet. I > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>> know there > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>>>>>>> are issues > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> about > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>> CMETs with a choice at the top - any chance you > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>> could send a > >>>> > >>>> > >>>>>>>>>>>>>> simple diagram to illustrate the problem as you see it? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Anyway, if we come up with any scheme like the above, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> it should > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> be straightforward to implement in the tool. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Robert > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> Close, London > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> EC1A > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> 7JN > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> 7970 197968 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> *************************** E-mail > confidentiality notice > >>>>>>>>>>>>>> ******************************* > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This message is intended for the addressee only. It is > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> private, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> confidential and may contain information of a > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> proprietary nature. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> If you have received this > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> message > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>> in error, please notify > >>>>>>>>>>>>>> us and remove it from your system. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >> _________________________________________________________________ > >> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> This message from Charteris plc has been checked > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>> for viruses > >>>> > >>>> > >>>>>>>>>>>>>> http://www.charteris.com/ > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >> _________________________________________________________________ > >> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> This message to Charteris plc has been checked > >>>>>>>>>>>>> > >> for viruses > >> > >>>>>>>>>>>>> http://www.charteris.com/ > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >> _________________________________________________________________ > >> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>> This message from Charteris plc has been checked > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>> for viruses > >>>> > >>>> > >>>>>>>>>>>>> http://www.charteris.com/ > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > > > > _________________________________________________________________ > > This message to Charteris plc has been checked for viruses > > http://www.charteris.com/ > > > > _________________________________________________________________ > > This message from Charteris plc has been checked for viruses > > http://www.charteris.com/ > > _______________________________________________ > > 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. > > > > > > > > > From lloyd at lmckenzie.com Fri Aug 11 17:17:29 2006 From: lloyd at lmckenzie.com (Lloyd McKenzie) Date: Fri, 11 Aug 2006 10:17:29 -0600 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM In-Reply-To: <1A3D105C334EAE49BDDD93D8767573F5041FB301@EXCHAQ2.nhsia.nhs.uk> References: <1A3D105C334EAE49BDDD93D8767573F5041FB301@EXCHAQ2.nhsia.nhs.uk> Message-ID: <44DCAD99.1060108@lmckenzie.com> Hi Laura, The issue is that HL7 can be implemented in both collapsed and non-collapsed manners. The model is also platform-independent. Lloyd Sato Laura wrote: > I realise that I'm a little late into this conversation, but... what > was wrong with Implementable Model - is it the acronym, IM, that's too > like something else? What I liked about 'implementable' was that it > gave the sense of the view for which the model was designed for (i.e. > implementers). It gave a focus for what it was supposed to accomplish. > > Scanning through the other terms, I don't mind Platform-Specific Model, > if that's truly what it is (is it?). Transmission Model might be okay. > > Semantically Equivalent Model doesn't say anything to me about what it's > for, so I'm not crazy about this one. > > Just my 2p... > > Regards, > Laura > _________________________ > Laura Sato > Informatics Standards Lead > > Communications & Messaging > NHS Connecting for Health > Mobile: (44) (0)7733 324 338 > Email: laura.sato at cfh.nhs.uk > www.connectingforhealth.nhs.uk > > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden > Sent: 10 August 2006 18:18 > To: charlie at ramseysystems.co.uk; Lloyd McKenzie > Cc: new-its at lists.hl7.org.uk > Subject: [New-ITS] Name for a flattened,association-collapsed model > derived from an RMIM > > Not sure about 'optimised' because: > > - Optimised implies the best in some sense; but it may not yet be the > best, just better > - The acronym 'OM' somehow is not very snappy - hard to read as a word > (or a bit Buddhist?). > > I have two other suggestions: > > - Transmission Model, or TM (still a bit Buddhist?) > - Semantically Equivalent Model, or SEM > > I like the last because it tells people we are not messing with RIM > semantics. > > Anyway, the acronym is now a variable in the tools, and I can change it > daily. We could put it to a vote at the WGM. > > Robert > > Charteris plc, Charteris House, 39/40 Bartholomew Close, London > EC1A 7JN > > phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 > 197968 > > *************************** E-mail confidentiality notice > ******************************* > > This message is intended for the addressee only. It is private, > confidential and may contain > information of a proprietary nature. If you have received this message > in error, please notify > us and remove it from your system. > > -----Original Message----- > From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] > Sent: 09 August 2006 17:44 > To: Lloyd McKenzie > Cc: grahame at jivamedical.com; Robert Worden > Subject: RE: Steering RMIM reshaping > > Well -- we were trying to avoid C words -- so "optimized" seems the best > offering so far > All the best > Charlie > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > Dogpole, Shrewsbury, Shropshire SY1 1ES > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > > >> -----Original Message----- >> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >> Sent: 09 August 2006 17:08 >> To: Charlie McCay >> Cc: grahame at jivamedical.com; Robert Worden >> Subject: Re: Steering RMIM reshaping >> >> Hi Charlie, >> >> Calling it a "practical" model sends the wrong message about >> the existing structure. Executable model suggests that it's >> an internal object model, which it isn't. >> >> What this is is a "collapsed" or "compressed" or "optimized" >> or some other transformation type word. >> >> >> Lloyd >> >> Charlie McCay wrote: >> >>> So how about practical model or exchange model or executable model >>> >>> >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>> >>> tel 01743 232278 / 07808 570172 skype: charliemccay >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>> Sent: 09 August 2006 16:22 >>>> To: Charlie McCay >>>> Cc: grahame at jivamedical.com; Robert Worden >>>> Subject: Re: Steering RMIM reshaping >>>> >>>> Hi Charlie, >>>> >>>> The challenge is that many will read "physical model" in its >>>> usual sense, which is persistence model, which we definitely >>>> shouldn't be suggesting, let alone imposing. >>>> >>>> >>>> Lloyd >>>> >>>> Charlie McCay wrote: >>>> >>>> >>>>> Hi >>>>> >>>>> Why not? -- the intent is to provide the model for the physical >>>>> exchange (subject to ITS realisation, but that is the >>>>> >>>>> >>>> model-reality >>>> >>>> >>>>> mapping) -- it is this practical model that is exactly what >>>>> >>>>> >>>> we do want >>>> >>>> >>>>> from HL7, and that we have been using the logical >>>>> >>>>> >>>> information model >>>> >>>> >>>>> as a proxy for until now >>>>> >>>>> Alternative that I do not like as much: >>>>> >>>>> EM exchange model / executable model >>>>> >>>>> charlie >>>>> >>>>> >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>> >> Ltd, 23D >> >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>> >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>> Sent: 09 August 2006 16:02 >>>>>> To: Charlie McCay >>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>> Subject: Re: Steering RMIM reshaping >>>>>> >>>>>> Hi Charlie, >>>>>> >>>>>> I don't want to imply that HL7 defines actual physical >>>>>> >> models . . . >> >>>>>> Lloyd >>>>>> >>>>>> Charlie McCay wrote: >>>>>> >>>>>> >>>>>> >>>>>>> How about >>>>>>> >>>>>>> PM -- Physical/(?Practical?) Model ? >>>>>>> PM / PSM (Platform model (Platform Specific Model) >>>>>>> >>>>>>> All the best >>>>>>> >>>>>>> Charlie >>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>> >>>>>>> >>>> Ltd, 23D >>>> >>>> >>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>> >>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>> Sent: 08 August 2006 05:45 >>>>>>>> To: grahame at jivamedical.com >>>>>>>> Cc: Robert Worden; Charlie McCay >>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>> >>>>>>>> Except CM is used for CMET. Not sure we need a different >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> id if the >>>>>> >>>>>> >>>>>> >>>>>>>> models are just transforms of each other. >>>>>>>> >>>>>>>> Grahame Grieve wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> CM = collapsed model or computable model >>>>>>>>> >>>>>>>>> we could go with that >>>>>>>>> >>>>>>>>> Grahame >>>>>>>>> >>>>>>>>> >>>>>>>>> Lloyd McKenzie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> We can't use the word "Message" because we'll presumably >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> be using >>>>>> >>>>>> >>>>>> >>>>>>>>>> this stuff for documents too. How about just >>>>>>>>>> >>>>>>>>>> >>>> "collapsed model", >>>> >>>> >>>>>>>>>> seeing as that's what it is . . . >>>>>>>>>> >>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> we've been using the term implementable model. IM, >>>>>>>>>>> >> I know.... >> >>>>>>>>>>> maybe you could go for "message design"? it's not >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> strictly a model, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> so we can get away from the "M" part and reduce confusion? >>>>>>>>>>> >>>>>>>>>>> cc: Charlie for an opinion >>>>>>>>>>> >>>>>>>>>>> Grahame >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Grahame - >>>>>>>>>>>> >>>>>>>>>>>> I agree that DAM is not the right name, and will tend >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> to confuse >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> people; we are making something strictly derived from >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> the RMIM and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> suitable for implementation, which may have DAM-like >>>>>>>>>>>> >>>>>>>>>>>> >>>> names and >>>> >>>> >>>>>>>>>>>> structure. >>>>>>>>>>>> >>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> calling it a >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> RMIM'. Any suggestions? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> Implementation >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> Model? >>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. >>>>>>>>>>>> >>>>>>>>>>>> Give me an acronym and I will do a global edit... >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> Close, London >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>> >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> mobile: 44 7970 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> 197968 >>>>>>>>>>>> >>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>> ******************************* >>>>>>>>>>>> >>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> private, >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> proprietary nature. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> notify us and >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> remove it from your system. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On >>>>>>>>>>>> >>>>>>>>>>>> >>>> Behalf Of >>>> >>>> >>>>>>>>>>>> Grahame Grieve >>>>>>>>>>>> Sent: 07 August 2006 22:18 >>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>> Cc: Lloyd McKenzie >>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>> >>>>>>>>>>>> I'm way behind on email. but spotted this. >>>>>>>>>>>> >>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> correlation >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> between what we are trying to achieve and a real DAM. >>>>>>>>>>>> >>>>>>>>>>>> What we want is to do implementation modelling on >>>>>>>>>>>> >>>>>>>>>>>> >>>> the RMIM. We >>>> >>>> >>>>>>>>>>>> recognise - particularly after talking to Simon Withey >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> last week - >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> that this has nothing to do with the DAM process, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> except for the >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> naming question. >>>>>>>>>>>> (Where by names in the instance should allow >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> identification back >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> against the DAM, rather than against the RIM. Except >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> unless you are >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> concerned about naming stability, but that's a much >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> harder question >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> indeed) >>>>>>>>>>>> >>>>>>>>>>>> will come back to this thread later when I catch up >>>>>>>>>>>> >>>>>>>>>>>> Grahame >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi Lloyd - >>>>>>>>>>>>> >>>>>>>>>>>>> I was thinking that since people should really >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> produce a DAM on >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>> the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> way >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> to their RMIM, rather than the other way round, in some >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> sense the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> a formal >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>> derivation, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> it >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> may be that the route is not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> appropriate. >>>> >>>> >>>>>>>>>>>>> What then is the approved mechanism for adding >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> annotations to a MIF? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> I'm >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> sure I could find it in the schemas, but it's easier to >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> ask you... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> :-) >>>>>>>>>>>>> >>>>>>>>>>>>> Robert >>>>>>>>>>>>> >>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> Close, London >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>> >>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> mobile: 44 7970 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> 197968 >>>>>>>>>>>>> >>>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>>> ******************************* >>>>>>>>>>>>> >>>>>>>>>>>>> This message is intended for the addressee only. It >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> is private, >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> proprietary nature. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> notify us and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> 07 August >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> 2006 19:43 >>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>> Cc: grahame at kestral.com.au >>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>> >>>>>>>>>>>>> Relationships between a static model and a DAM would be >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> mappings, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> not derivations. StaticModelDerivationId is not a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> spare. In the >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> and HMD but >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> in theory we could derive from 20 different models. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> (And there's >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> no ordering >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> either, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> the RIM could be the first one listed or the seventh.) >>>>>>>>>>>>> >>>>>>>>>>>>> The basic question is whether you construct your >>>>>>>>>>>>> >> DAM from a >> >>>>>>>>>>>>> collapsed static model (as we do in Canada), or whether >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> you want >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> to create your DAMs and DIMs separately and map >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> them. If the >>>> >>>> >>>>>>>>>>>>> latter, I don't think >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> you >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> could do this in an automated way. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Lloyd >>>>>>>>>>>>> >>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame - >>>>>>>>>>>>>> >>>>>>>>>>>>>> You asked the other day for suggestions as to how >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> the current >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be steered by >>>>>>>>>>>>>> annotations in the RMIM MIF, rather than by user >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> input. Here is a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> first punt to get thinking going. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The simplest suggestion I can make is to add to the >>>>>>>>>>>>>> elements another one which says >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> how this >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>> RMIM >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> was >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> derived (or might have been derived) from a DAM. These >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> would look >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> like: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> but choose >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> one >>>>>>>>>>>>>> >>>>>>>>>>>>>> that is). These can go on elements for classes, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> associations, and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> properties to say in effect >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Rename this class to a DAM class name >>>>>>>>>>>>>> * Rename this association (with perhaps other >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> attributes saying >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> 'collapse it' or 'leave it out') >>>>>>>>>>>>>> * Rename this property to a DAM property name (or >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> some value >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> meaning 'leave it out') >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you wanted, you would not even have to say explicitly >>>>>>>>>>>>>> 'collapse an >>>>>>>>>>>>>> >>>>>>>>>>>>>> association' - because if the DAM class names are >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> the same on >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>> either side of it, that means collapse it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This proposal would not yet address a combination of >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> restricting >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> and reshaping an RMIM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It would imply you cannot collapse across a CMET >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> boundary, which >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> I gather from our discussion the other day you would >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> like to do. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> Or maybe you can, by telling the association to >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>> the CMET to >>>> >>>> >>>>>>>>>>>>>> collapse itself? Have not thought it through yet. I >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> know there >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>> are issues >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> about >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> CMETs with a choice at the top - any chance you >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>> could send a >>>> >>>> >>>>>>>>>>>>>> simple diagram to illustrate the problem as you see it? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Anyway, if we come up with any scheme like the above, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> it should >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> be straightforward to implement in the tool. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> Close, London >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> EC1A >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> 7JN >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> 7970 197968 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>> >>>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> private, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> proprietary nature. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> If you have received this >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> message >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> in error, please notify >>>>>>>>>>>>>> us and remove it from your system. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> _________________________________________________________________ >> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>> for viruses >>>> >>>> >>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >> _________________________________________________________________ >> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> This message to Charteris plc has been checked >>>>>>>>>>>>> >> for viruses >> >>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >> _________________________________________________________________ >> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> for viruses >>>> >>>> >>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >> >> > > _________________________________________________________________ > This message to Charteris plc has been checked for viruses > http://www.charteris.com/ > > _________________________________________________________________ > This message from Charteris plc has been checked for viruses > http://www.charteris.com/ > _______________________________________________ > 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. > > > From lloyd at lmckenzie.com Sat Aug 12 01:20:02 2006 From: lloyd at lmckenzie.com (Lloyd McKenzie) Date: Fri, 11 Aug 2006 18:20:02 -0600 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A04FBFD@ramseysc1420.RamseyNet.local> References: <7A55F2E13F53E749A4C13A8E53B7424A04FBFD@ramseysc1420.RamseyNet.local> Message-ID: <44DD1EB2.4050205@lmckenzie.com> Hi Charlie, I, for one, would like the existing ITS to continue to exist, perhaps evolving to force all structural attributes to be exposed. That way there remains a neutral, specification-independent layer that more sophisticated applications can use. Lloyd Charlie McCay wrote: > Lloyd > > I understood that IM was rejected because we already have lots of > Information Models. > > It is yet to be established whether the collapsed model approach, if > endorsed, would be an alternative to or replacement for, the current > ITS. There was a view expressed in INM that maintaining both may not be > the best way to go forwards. > > Every model is platform independent to some degree. One take on the > collapsing process would be to say that it was intended to generate > models that were appropriate for implementation using XML, and as such > would be platform specific. Another would be that it was to produce > models that were appropriate for any generic implementation technology > (ie an Abstract Implementation Model), in this case I would agree that > it would be inappropriate to say that the models were platform specific. > One of the issues that we need to explore is whether targeting just XML > for the implementation models makes a significant difference. There are > differing expectations as to what the outcome of that will be. > > All the best > > Charlie > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > Dogpole, Shrewsbury, Shropshire SY1 1ES > tel 01743 232278 / 07808 570172 skype: charliemccay > > > >> -----Original Message----- >> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >> Sent: 11 August 2006 17:17 >> To: Sato Laura >> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk >> Subject: Re: [New-ITS] Name for a >> flattened,association-collapsed model derived from an RMIM >> >> Hi Laura, >> >> The issue is that HL7 can be implemented in both collapsed >> and non-collapsed manners. The model is also platform-independent. >> >> >> Lloyd >> >> Sato Laura wrote: >> >>> I realise that I'm a little late into this conversation, >>> >> but... what >> >>> was wrong with Implementable Model - is it the acronym, IM, >>> >> that's too >> >>> like something else? What I liked about 'implementable' was that it >>> gave the sense of the view for which the model was designed >>> >> for (i.e. >> >>> implementers). It gave a focus for what it was supposed to >>> >> accomplish. >> >>> Scanning through the other terms, I don't mind >>> >> Platform-Specific Model, >> >>> if that's truly what it is (is it?). Transmission Model >>> >> might be okay. >> >>> Semantically Equivalent Model doesn't say anything to me >>> >> about what it's >> >>> for, so I'm not crazy about this one. >>> >>> Just my 2p... >>> >>> Regards, >>> Laura >>> _________________________ >>> Laura Sato >>> Informatics Standards Lead >>> >>> Communications & Messaging >>> NHS Connecting for Health >>> Mobile: (44) (0)7733 324 338 >>> Email: laura.sato at cfh.nhs.uk >>> www.connectingforhealth.nhs.uk >>> >>> -----Original Message----- >>> From: new-its-bounces at lists.hl7.org.uk >>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden >>> Sent: 10 August 2006 18:18 >>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie >>> Cc: new-its at lists.hl7.org.uk >>> Subject: [New-ITS] Name for a flattened,association-collapsed model >>> derived from an RMIM >>> >>> Not sure about 'optimised' because: >>> >>> - Optimised implies the best in some sense; but it may not >>> >> yet be the >> >>> best, just better >>> - The acronym 'OM' somehow is not very snappy - hard to >>> >> read as a word >> >>> (or a bit Buddhist?). >>> >>> I have two other suggestions: >>> >>> - Transmission Model, or TM (still a bit Buddhist?) >>> - Semantically Equivalent Model, or SEM >>> >>> I like the last because it tells people we are not messing with RIM >>> semantics. >>> >>> Anyway, the acronym is now a variable in the tools, and I >>> >> can change it >> >>> daily. We could put it to a vote at the WGM. >>> >>> Robert >>> >>> Charteris plc, Charteris House, 39/40 Bartholomew Close, London >>> EC1A 7JN >>> >>> phone: 44 1353 777668; Fax 44 1353 777394; >>> >> mobile: 44 7970 >> >>> 197968 >>> >>> *************************** E-mail confidentiality notice >>> ******************************* >>> >>> This message is intended for the addressee only. It is private, >>> confidential and may contain >>> information of a proprietary nature. If you have received >>> >> this message >> >>> in error, please notify >>> us and remove it from your system. >>> >>> -----Original Message----- >>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] >>> Sent: 09 August 2006 17:44 >>> To: Lloyd McKenzie >>> Cc: grahame at jivamedical.com; Robert Worden >>> Subject: RE: Steering RMIM reshaping >>> >>> Well -- we were trying to avoid C words -- so "optimized" >>> >> seems the best >> >>> offering so far >>> All the best >>> Charlie >>> >>> >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>> >>> tel 01743 232278 / 07808 570172 skype: charliemccay >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>> Sent: 09 August 2006 17:08 >>>> To: Charlie McCay >>>> Cc: grahame at jivamedical.com; Robert Worden >>>> Subject: Re: Steering RMIM reshaping >>>> >>>> Hi Charlie, >>>> >>>> Calling it a "practical" model sends the wrong message about >>>> the existing structure. Executable model suggests that it's >>>> an internal object model, which it isn't. >>>> >>>> What this is is a "collapsed" or "compressed" or "optimized" >>>> or some other transformation type word. >>>> >>>> >>>> Lloyd >>>> >>>> Charlie McCay wrote: >>>> >>>> >>>>> So how about practical model or exchange model or executable model >>>>> >>>>> >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>> >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>> Sent: 09 August 2006 16:22 >>>>>> To: Charlie McCay >>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>> Subject: Re: Steering RMIM reshaping >>>>>> >>>>>> Hi Charlie, >>>>>> >>>>>> The challenge is that many will read "physical model" in its >>>>>> usual sense, which is persistence model, which we definitely >>>>>> shouldn't be suggesting, let alone imposing. >>>>>> >>>>>> >>>>>> Lloyd >>>>>> >>>>>> Charlie McCay wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> Why not? -- the intent is to provide the model for the physical >>>>>>> exchange (subject to ITS realisation, but that is the >>>>>>> >>>>>>> >>>>>>> >>>>>> model-reality >>>>>> >>>>>> >>>>>> >>>>>>> mapping) -- it is this practical model that is exactly what >>>>>>> >>>>>>> >>>>>>> >>>>>> we do want >>>>>> >>>>>> >>>>>> >>>>>>> from HL7, and that we have been using the logical >>>>>>> >>>>>>> >>>>>>> >>>>>> information model >>>>>> >>>>>> >>>>>> >>>>>>> as a proxy for until now >>>>>>> >>>>>>> Alternative that I do not like as much: >>>>>>> >>>>>>> EM exchange model / executable model >>>>>>> >>>>>>> charlie >>>>>>> >>>>>>> >>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>> >>>>>>> >>>> Ltd, 23D >>>> >>>> >>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>> >>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>> Sent: 09 August 2006 16:02 >>>>>>>> To: Charlie McCay >>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>> >>>>>>>> Hi Charlie, >>>>>>>> >>>>>>>> I don't want to imply that HL7 defines actual physical >>>>>>>> >>>>>>>> >>>> models . . . >>>> >>>> >>>>>>>> Lloyd >>>>>>>> >>>>>>>> Charlie McCay wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> How about >>>>>>>>> >>>>>>>>> PM -- Physical/(?Practical?) Model ? >>>>>>>>> PM / PSM (Platform model (Platform Specific Model) >>>>>>>>> >>>>>>>>> All the best >>>>>>>>> >>>>>>>>> Charlie >>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> Ltd, 23D >>>>>> >>>>>> >>>>>> >>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>> >>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>> Sent: 08 August 2006 05:45 >>>>>>>>>> To: grahame at jivamedical.com >>>>>>>>>> Cc: Robert Worden; Charlie McCay >>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>> >>>>>>>>>> Except CM is used for CMET. Not sure we need a different >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> id if the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> models are just transforms of each other. >>>>>>>>>> >>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> CM = collapsed model or computable model >>>>>>>>>>> >>>>>>>>>>> we could go with that >>>>>>>>>>> >>>>>>>>>>> Grahame >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Lloyd McKenzie wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> We can't use the word "Message" because we'll presumably >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> be using >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> this stuff for documents too. How about just >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> "collapsed model", >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> seeing as that's what it is . . . >>>>>>>>>>>> >>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> we've been using the term implementable model. IM, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> I know.... >>>> >>>> >>>>>>>>>>>>> maybe you could go for "message design"? it's not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> strictly a model, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> so we can get away from the "M" part and reduce confusion? >>>>>>>>>>>>> >>>>>>>>>>>>> cc: Charlie for an opinion >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame - >>>>>>>>>>>>>> >>>>>>>>>>>>>> I agree that DAM is not the right name, and will tend >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> to confuse >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> people; we are making something strictly derived from >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> the RMIM and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> suitable for implementation, which may have DAM-like >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> names and >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>> structure. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> calling it a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> RMIM'. Any suggestions? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> Implementation >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> Model? >>>>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Give me an acronym and I will do a global edit... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> Close, London >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>>> >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> mobile: 44 7970 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> 197968 >>>>>>>>>>>>>> >>>>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>> >>>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> private, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> proprietary nature. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> notify us and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> Behalf Of >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>> Grahame Grieve >>>>>>>>>>>>>> Sent: 07 August 2006 22:18 >>>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>>> Cc: Lloyd McKenzie >>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm way behind on email. but spotted this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> correlation >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> between what we are trying to achieve and a real DAM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What we want is to do implementation modelling on >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> the RMIM. We >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>> recognise - particularly after talking to Simon Withey >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> last week - >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> that this has nothing to do with the DAM process, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> except for the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> naming question. >>>>>>>>>>>>>> (Where by names in the instance should allow >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> identification back >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> against the DAM, rather than against the RIM. Except >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> unless you are >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> concerned about naming stability, but that's a much >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> harder question >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> indeed) >>>>>>>>>>>>>> >>>>>>>>>>>>>> will come back to this thread later when I catch up >>>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Lloyd - >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I was thinking that since people should really >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> produce a DAM on >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> way >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> to their RMIM, rather than the other way round, in some >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> sense the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> a formal >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> derivation, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> it >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> may be that the route is not >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> appropriate. >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>> What then is the approved mechanism for adding >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> annotations to a MIF? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> I'm >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> sure I could find it in the schemas, but it's easier to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> ask you... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> :-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Robert >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> Close, London >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> mobile: 44 7970 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> 197968 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *************************** E-mail >>>>>>>>>>>>>>> >> confidentiality notice >> >>>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This message is intended for the addressee only. It >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> is private, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> proprietary nature. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> notify us and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> 07 August >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> 2006 19:43 >>>>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>>>> Cc: grahame at kestral.com.au >>>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Relationships between a static model and a DAM would be >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> mappings, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> not derivations. StaticModelDerivationId is not a >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> spare. In the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> and HMD but >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> in theory we could derive from 20 different models. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> (And there's >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> no ordering >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> either, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> the RIM could be the first one listed or the seventh.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The basic question is whether you construct your >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> DAM from a >>>> >>>> >>>>>>>>>>>>>>> collapsed static model (as we do in Canada), or whether >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> you want >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> to create your DAMs and DIMs separately and map >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> them. If the >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>> latter, I don't think >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> you >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> could do this in an automated way. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Lloyd >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Grahame - >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You asked the other day for suggestions as to how >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> the current >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be >>>>>>>>>>>>>>>> >> steered by >> >>>>>>>>>>>>>>>> annotations in the RMIM MIF, rather than by user >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> input. Here is a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> first punt to get thinking going. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The simplest suggestion I can make is to add to the >>>>>>>>>>>>>>>> elements another one which says >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> how this >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> RMIM >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> was >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> derived (or might have been derived) from a DAM. These >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> would look >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> but choose >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> that is). These can go on elements for classes, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> associations, and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> properties to say in effect >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Rename this class to a DAM class name >>>>>>>>>>>>>>>> * Rename this association (with perhaps other >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> attributes saying >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> 'collapse it' or 'leave it out') >>>>>>>>>>>>>>>> * Rename this property to a DAM property name (or >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> some value >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> meaning 'leave it out') >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If you wanted, you would not even have to say >>>>>>>>>>>>>>>> >> explicitly >> >>>>>>>>>>>>>>>> 'collapse an >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> association' - because if the DAM class names are >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> the same on >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> either side of it, that means collapse it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This proposal would not yet address a combination of >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> restricting >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> and reshaping an RMIM. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It would imply you cannot collapse across a CMET >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> boundary, which >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> I gather from our discussion the other day you would >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> like to do. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> Or maybe you can, by telling the association to >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>> the CMET to >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>>> collapse itself? Have not thought it through yet. I >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> know there >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> are issues >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> about >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> CMETs with a choice at the top - any chance you >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>> could send a >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>>> simple diagram to illustrate the problem as you see it? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Anyway, if we come up with any scheme like the above, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> it should >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> be straightforward to implement in the tool. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Robert >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> Close, London >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> EC1A >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 7JN >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> 7970 197968 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> *************************** E-mail >>>>>>>>>>>>>>>> >> confidentiality notice >> >>>>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> private, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> proprietary nature. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> If you have received this >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> message >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> in error, please notify >>>>>>>>>>>>>>>> us and remove it from your system. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> _________________________________________________________________ >>>> >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>> for viruses >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> _________________________________________________________________ >>>> >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> This message to Charteris plc has been checked >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> for viruses >>>> >>>> >>>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> _________________________________________________________________ >>>> >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> for viruses >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> _________________________________________________________________ >>> This message to Charteris plc has been checked for viruses >>> http://www.charteris.com/ >>> >>> _________________________________________________________________ >>> This message from Charteris plc has been checked for viruses >>> http://www.charteris.com/ >>> _______________________________________________ >>> 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. >> >>> >>> >> >> From Robert.Worden at Charteris.com Sun Aug 13 09:20:59 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Sun, 13 Aug 2006 09:20:59 +0100 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM Message-ID: Lloyd, Charlie - I support Lloyd's view for the reasons he gives, and because I think it is better for HL7 to offer its implementers a choice of implementation technologies, rather than pulling the rug out from under one technology just as they are getting going. The choice can be offered because translation between the two ITS can be done automatically and precisely. So there need not even be 'spheres of influence' dominated by one ITS or the other. Is there anybody out there who disagrees? Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. -----Original Message----- From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: 12 August 2006 01:20 To: Charlie McCay Cc: Sato Laura; Robert Worden; new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Name for a flattened,association-collapsed model derived from an RMIM Hi Charlie, I, for one, would like the existing ITS to continue to exist, perhaps evolving to force all structural attributes to be exposed. That way there remains a neutral, specification-independent layer that more sophisticated applications can use. Lloyd Charlie McCay wrote: > Lloyd > > I understood that IM was rejected because we already have lots of > Information Models. > > It is yet to be established whether the collapsed model approach, if > endorsed, would be an alternative to or replacement for, the current > ITS. There was a view expressed in INM that maintaining both may not be > the best way to go forwards. > > Every model is platform independent to some degree. One take on the > collapsing process would be to say that it was intended to generate > models that were appropriate for implementation using XML, and as such > would be platform specific. Another would be that it was to produce > models that were appropriate for any generic implementation technology > (ie an Abstract Implementation Model), in this case I would agree that > it would be inappropriate to say that the models were platform specific. > One of the issues that we need to explore is whether targeting just XML > for the implementation models makes a significant difference. There are > differing expectations as to what the outcome of that will be. > > All the best > > Charlie > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > Dogpole, Shrewsbury, Shropshire SY1 1ES > tel 01743 232278 / 07808 570172 skype: charliemccay > > > >> -----Original Message----- >> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >> Sent: 11 August 2006 17:17 >> To: Sato Laura >> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk >> Subject: Re: [New-ITS] Name for a >> flattened,association-collapsed model derived from an RMIM >> >> Hi Laura, >> >> The issue is that HL7 can be implemented in both collapsed >> and non-collapsed manners. The model is also platform-independent. >> >> >> Lloyd >> >> Sato Laura wrote: >> >>> I realise that I'm a little late into this conversation, >>> >> but... what >> >>> was wrong with Implementable Model - is it the acronym, IM, >>> >> that's too >> >>> like something else? What I liked about 'implementable' was that it >>> gave the sense of the view for which the model was designed >>> >> for (i.e. >> >>> implementers). It gave a focus for what it was supposed to >>> >> accomplish. >> >>> Scanning through the other terms, I don't mind >>> >> Platform-Specific Model, >> >>> if that's truly what it is (is it?). Transmission Model >>> >> might be okay. >> >>> Semantically Equivalent Model doesn't say anything to me >>> >> about what it's >> >>> for, so I'm not crazy about this one. >>> >>> Just my 2p... >>> >>> Regards, >>> Laura >>> _________________________ >>> Laura Sato >>> Informatics Standards Lead >>> >>> Communications & Messaging >>> NHS Connecting for Health >>> Mobile: (44) (0)7733 324 338 >>> Email: laura.sato at cfh.nhs.uk >>> www.connectingforhealth.nhs.uk >>> >>> -----Original Message----- >>> From: new-its-bounces at lists.hl7.org.uk >>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden >>> Sent: 10 August 2006 18:18 >>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie >>> Cc: new-its at lists.hl7.org.uk >>> Subject: [New-ITS] Name for a flattened,association-collapsed model >>> derived from an RMIM >>> >>> Not sure about 'optimised' because: >>> >>> - Optimised implies the best in some sense; but it may not >>> >> yet be the >> >>> best, just better >>> - The acronym 'OM' somehow is not very snappy - hard to >>> >> read as a word >> >>> (or a bit Buddhist?). >>> >>> I have two other suggestions: >>> >>> - Transmission Model, or TM (still a bit Buddhist?) >>> - Semantically Equivalent Model, or SEM >>> >>> I like the last because it tells people we are not messing with RIM >>> semantics. >>> >>> Anyway, the acronym is now a variable in the tools, and I >>> >> can change it >> >>> daily. We could put it to a vote at the WGM. >>> >>> Robert >>> >>> Charteris plc, Charteris House, 39/40 Bartholomew Close, London >>> EC1A 7JN >>> >>> phone: 44 1353 777668; Fax 44 1353 777394; >>> >> mobile: 44 7970 >> >>> 197968 >>> >>> *************************** E-mail confidentiality notice >>> ******************************* >>> >>> This message is intended for the addressee only. It is private, >>> confidential and may contain >>> information of a proprietary nature. If you have received >>> >> this message >> >>> in error, please notify >>> us and remove it from your system. >>> >>> -----Original Message----- >>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] >>> Sent: 09 August 2006 17:44 >>> To: Lloyd McKenzie >>> Cc: grahame at jivamedical.com; Robert Worden >>> Subject: RE: Steering RMIM reshaping >>> >>> Well -- we were trying to avoid C words -- so "optimized" >>> >> seems the best >> >>> offering so far >>> All the best >>> Charlie >>> >>> >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>> >>> tel 01743 232278 / 07808 570172 skype: charliemccay >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>> Sent: 09 August 2006 17:08 >>>> To: Charlie McCay >>>> Cc: grahame at jivamedical.com; Robert Worden >>>> Subject: Re: Steering RMIM reshaping >>>> >>>> Hi Charlie, >>>> >>>> Calling it a "practical" model sends the wrong message about >>>> the existing structure. Executable model suggests that it's >>>> an internal object model, which it isn't. >>>> >>>> What this is is a "collapsed" or "compressed" or "optimized" >>>> or some other transformation type word. >>>> >>>> >>>> Lloyd >>>> >>>> Charlie McCay wrote: >>>> >>>> >>>>> So how about practical model or exchange model or executable model >>>>> >>>>> >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>> >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>> Sent: 09 August 2006 16:22 >>>>>> To: Charlie McCay >>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>> Subject: Re: Steering RMIM reshaping >>>>>> >>>>>> Hi Charlie, >>>>>> >>>>>> The challenge is that many will read "physical model" in its >>>>>> usual sense, which is persistence model, which we definitely >>>>>> shouldn't be suggesting, let alone imposing. >>>>>> >>>>>> >>>>>> Lloyd >>>>>> >>>>>> Charlie McCay wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> Why not? -- the intent is to provide the model for the physical >>>>>>> exchange (subject to ITS realisation, but that is the >>>>>>> >>>>>>> >>>>>>> >>>>>> model-reality >>>>>> >>>>>> >>>>>> >>>>>>> mapping) -- it is this practical model that is exactly what >>>>>>> >>>>>>> >>>>>>> >>>>>> we do want >>>>>> >>>>>> >>>>>> >>>>>>> from HL7, and that we have been using the logical >>>>>>> >>>>>>> >>>>>>> >>>>>> information model >>>>>> >>>>>> >>>>>> >>>>>>> as a proxy for until now >>>>>>> >>>>>>> Alternative that I do not like as much: >>>>>>> >>>>>>> EM exchange model / executable model >>>>>>> >>>>>>> charlie >>>>>>> >>>>>>> >>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>> >>>>>>> >>>> Ltd, 23D >>>> >>>> >>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>> >>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>> Sent: 09 August 2006 16:02 >>>>>>>> To: Charlie McCay >>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>> >>>>>>>> Hi Charlie, >>>>>>>> >>>>>>>> I don't want to imply that HL7 defines actual physical >>>>>>>> >>>>>>>> >>>> models . . . >>>> >>>> >>>>>>>> Lloyd >>>>>>>> >>>>>>>> Charlie McCay wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> How about >>>>>>>>> >>>>>>>>> PM -- Physical/(?Practical?) Model ? >>>>>>>>> PM / PSM (Platform model (Platform Specific Model) >>>>>>>>> >>>>>>>>> All the best >>>>>>>>> >>>>>>>>> Charlie >>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> Ltd, 23D >>>>>> >>>>>> >>>>>> >>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>> >>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>> Sent: 08 August 2006 05:45 >>>>>>>>>> To: grahame at jivamedical.com >>>>>>>>>> Cc: Robert Worden; Charlie McCay >>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>> >>>>>>>>>> Except CM is used for CMET. Not sure we need a different >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> id if the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> models are just transforms of each other. >>>>>>>>>> >>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> CM = collapsed model or computable model >>>>>>>>>>> >>>>>>>>>>> we could go with that >>>>>>>>>>> >>>>>>>>>>> Grahame >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Lloyd McKenzie wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> We can't use the word "Message" because we'll presumably >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> be using >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> this stuff for documents too. How about just >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> "collapsed model", >>>>>> >>>>>> >>>>>> >>>>>>>>>>>> seeing as that's what it is . . . >>>>>>>>>>>> >>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> we've been using the term implementable model. IM, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> I know.... >>>> >>>> >>>>>>>>>>>>> maybe you could go for "message design"? it's not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> strictly a model, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> so we can get away from the "M" part and reduce confusion? >>>>>>>>>>>>> >>>>>>>>>>>>> cc: Charlie for an opinion >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame - >>>>>>>>>>>>>> >>>>>>>>>>>>>> I agree that DAM is not the right name, and will tend >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> to confuse >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> people; we are making something strictly derived from >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> the RMIM and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> suitable for implementation, which may have DAM-like >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> names and >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>> structure. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> calling it a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> RMIM'. Any suggestions? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> Implementation >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> Model? >>>>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Give me an acronym and I will do a global edit... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> Close, London >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>>> >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> mobile: 44 7970 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> 197968 >>>>>>>>>>>>>> >>>>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>> >>>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> private, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> proprietary nature. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> notify us and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> Behalf Of >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>> Grahame Grieve >>>>>>>>>>>>>> Sent: 07 August 2006 22:18 >>>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>>> Cc: Lloyd McKenzie >>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm way behind on email. but spotted this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> correlation >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> between what we are trying to achieve and a real DAM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What we want is to do implementation modelling on >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> the RMIM. We >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>> recognise - particularly after talking to Simon Withey >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> last week - >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> that this has nothing to do with the DAM process, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> except for the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> naming question. >>>>>>>>>>>>>> (Where by names in the instance should allow >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> identification back >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> against the DAM, rather than against the RIM. Except >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> unless you are >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> concerned about naming stability, but that's a much >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> harder question >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> indeed) >>>>>>>>>>>>>> >>>>>>>>>>>>>> will come back to this thread later when I catch up >>>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Lloyd - >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I was thinking that since people should really >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> produce a DAM on >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> way >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> to their RMIM, rather than the other way round, in some >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> sense the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> a formal >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> derivation, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> it >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> may be that the route is not >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> appropriate. >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>> What then is the approved mechanism for adding >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> annotations to a MIF? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> I'm >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> sure I could find it in the schemas, but it's easier to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> ask you... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> :-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Robert >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> Close, London >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> mobile: 44 7970 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> 197968 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *************************** E-mail >>>>>>>>>>>>>>> >> confidentiality notice >> >>>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This message is intended for the addressee only. It >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> is private, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> proprietary nature. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> notify us and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> 07 August >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> 2006 19:43 >>>>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>>>> Cc: grahame at kestral.com.au >>>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Relationships between a static model and a DAM would be >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> mappings, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> not derivations. StaticModelDerivationId is not a >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> spare. In the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> and HMD but >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> in theory we could derive from 20 different models. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> (And there's >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> no ordering >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> either, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> the RIM could be the first one listed or the seventh.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The basic question is whether you construct your >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> DAM from a >>>> >>>> >>>>>>>>>>>>>>> collapsed static model (as we do in Canada), or whether >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> you want >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> to create your DAMs and DIMs separately and map >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> them. If the >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>> latter, I don't think >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> you >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> could do this in an automated way. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Lloyd >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Grahame - >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You asked the other day for suggestions as to how >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> the current >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be >>>>>>>>>>>>>>>> >> steered by >> >>>>>>>>>>>>>>>> annotations in the RMIM MIF, rather than by user >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> input. Here is a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> first punt to get thinking going. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The simplest suggestion I can make is to add to the >>>>>>>>>>>>>>>> elements another one which says >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> how this >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> RMIM >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> was >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> derived (or might have been derived) from a DAM. These >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> would look >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> but choose >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> that is). These can go on elements for classes, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> associations, and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> properties to say in effect >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Rename this class to a DAM class name >>>>>>>>>>>>>>>> * Rename this association (with perhaps other >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> attributes saying >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> 'collapse it' or 'leave it out') >>>>>>>>>>>>>>>> * Rename this property to a DAM property name (or >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> some value >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> meaning 'leave it out') >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If you wanted, you would not even have to say >>>>>>>>>>>>>>>> >> explicitly >> >>>>>>>>>>>>>>>> 'collapse an >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> association' - because if the DAM class names are >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> the same on >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> either side of it, that means collapse it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This proposal would not yet address a combination of >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> restricting >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> and reshaping an RMIM. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It would imply you cannot collapse across a CMET >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> boundary, which >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> I gather from our discussion the other day you would >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> like to do. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> Or maybe you can, by telling the association to >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>> the CMET to >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>>> collapse itself? Have not thought it through yet. I >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> know there >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> are issues >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> about >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> CMETs with a choice at the top - any chance you >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>> could send a >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>>> simple diagram to illustrate the problem as you see it? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Anyway, if we come up with any scheme like the above, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> it should >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> be straightforward to implement in the tool. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Robert >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> Close, London >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> EC1A >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 7JN >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> 7970 197968 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> *************************** E-mail >>>>>>>>>>>>>>>> >> confidentiality notice >> >>>>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> private, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> proprietary nature. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> If you have received this >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> message >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> in error, please notify >>>>>>>>>>>>>>>> us and remove it from your system. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> _________________________________________________________________ >>>> >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>> for viruses >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> _________________________________________________________________ >>>> >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> This message to Charteris plc has been checked >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> for viruses >>>> >>>> >>>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> _________________________________________________________________ >>>> >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> for viruses >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> _________________________________________________________________ >>> This message to Charteris plc has been checked for viruses >>> http://www.charteris.com/ >>> >>> _________________________________________________________________ >>> This message from Charteris plc has been checked for viruses >>> http://www.charteris.com/ >>> _______________________________________________ >>> 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. >> >>> >>> >> >> _________________________________________________________________ This message to Charteris plc has been checked for viruses http://www.charteris.com/ _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ From tim.benson at abies.co.uk Sun Aug 13 10:58:27 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Sun, 13 Aug 2006 10:58:27 +0100 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM In-Reply-To: Message-ID: The ITS is what is implemented. Once it is implemented and working, no-one will want to change it - in the same way that no-one updates a V2.2 interface to V2.5. It is inevitable that there will be a wide range of different ITS developed over time. We have to live with this. Tim On 13/8/06 09:20 Robert Worden wrote: > Lloyd, Charlie - > > I support Lloyd's view for the reasons he gives, and because I think it > is better for HL7 to offer its implementers a choice of implementation > technologies, rather than pulling the rug out from under one technology > just as they are getting going. > > The choice can be offered because translation between the two ITS can be > done automatically and precisely. So there need not even be 'spheres of > influence' dominated by one ITS or the other. > > Is there anybody out there who disagrees? > > Robert > > Charteris plc, Charteris House, 39/40 Bartholomew Close, London > EC1A 7JN > > phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 > 197968 > > *************************** E-mail confidentiality notice > ******************************* > > This message is intended for the addressee only. It is private, > confidential and may contain > information of a proprietary nature. If you have received this message > in error, please notify > us and remove it from your system. > > -----Original Message----- > From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > Sent: 12 August 2006 01:20 > To: Charlie McCay > Cc: Sato Laura; Robert Worden; new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Name for a flattened,association-collapsed model > derived from an RMIM > > Hi Charlie, > > I, for one, would like the existing ITS to continue to exist, perhaps > evolving to force all structural attributes to be exposed. That way > there remains a neutral, specification-independent layer that more > sophisticated applications can use. > > > Lloyd > > Charlie McCay wrote: >> Lloyd >> >> I understood that IM was rejected because we already have lots of >> Information Models. >> >> It is yet to be established whether the collapsed model approach, if >> endorsed, would be an alternative to or replacement for, the current >> ITS. There was a view expressed in INM that maintaining both may not > be >> the best way to go forwards. >> >> Every model is platform independent to some degree. One take on the >> collapsing process would be to say that it was intended to generate >> models that were appropriate for implementation using XML, and as such >> would be platform specific. Another would be that it was to produce >> models that were appropriate for any generic implementation technology >> (ie an Abstract Implementation Model), in this case I would agree that >> it would be inappropriate to say that the models were platform > specific. >> One of the issues that we need to explore is whether targeting just > XML >> for the implementation models makes a significant difference. There > are >> differing expectations as to what the outcome of that will be. >> >> All the best >> >> Charlie >> >> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >> Dogpole, Shrewsbury, Shropshire SY1 1ES >> tel 01743 232278 / 07808 570172 skype: charliemccay >> >> >> >>> -----Original Message----- >>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>> Sent: 11 August 2006 17:17 >>> To: Sato Laura >>> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk >>> Subject: Re: [New-ITS] Name for a >>> flattened,association-collapsed model derived from an RMIM >>> >>> Hi Laura, >>> >>> The issue is that HL7 can be implemented in both collapsed >>> and non-collapsed manners. The model is also platform-independent. >>> >>> >>> Lloyd >>> >>> Sato Laura wrote: >>> >>>> I realise that I'm a little late into this conversation, >>>> >>> but... what >>> >>>> was wrong with Implementable Model - is it the acronym, IM, >>>> >>> that's too >>> >>>> like something else? What I liked about 'implementable' was that it >>>> gave the sense of the view for which the model was designed >>>> >>> for (i.e. >>> >>>> implementers). It gave a focus for what it was supposed to >>>> >>> accomplish. >>> >>>> Scanning through the other terms, I don't mind >>>> >>> Platform-Specific Model, >>> >>>> if that's truly what it is (is it?). Transmission Model >>>> >>> might be okay. >>> >>>> Semantically Equivalent Model doesn't say anything to me >>>> >>> about what it's >>> >>>> for, so I'm not crazy about this one. >>>> >>>> Just my 2p... >>>> >>>> Regards, >>>> Laura >>>> _________________________ >>>> Laura Sato >>>> Informatics Standards Lead >>>> >>>> Communications & Messaging >>>> NHS Connecting for Health >>>> Mobile: (44) (0)7733 324 338 >>>> Email: laura.sato at cfh.nhs.uk >>>> www.connectingforhealth.nhs.uk >>>> >>>> -----Original Message----- >>>> From: new-its-bounces at lists.hl7.org.uk >>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden >>>> Sent: 10 August 2006 18:18 >>>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie >>>> Cc: new-its at lists.hl7.org.uk >>>> Subject: [New-ITS] Name for a flattened,association-collapsed model >>>> derived from an RMIM >>>> >>>> Not sure about 'optimised' because: >>>> >>>> - Optimised implies the best in some sense; but it may not >>>> >>> yet be the >>> >>>> best, just better >>>> - The acronym 'OM' somehow is not very snappy - hard to >>>> >>> read as a word >>> >>>> (or a bit Buddhist?). >>>> >>>> I have two other suggestions: >>>> >>>> - Transmission Model, or TM (still a bit Buddhist?) >>>> - Semantically Equivalent Model, or SEM >>>> >>>> I like the last because it tells people we are not messing with RIM >>>> semantics. >>>> >>>> Anyway, the acronym is now a variable in the tools, and I >>>> >>> can change it >>> >>>> daily. We could put it to a vote at the WGM. >>>> >>>> Robert >>>> >>>> Charteris plc, Charteris House, 39/40 Bartholomew Close, London >>>> EC1A 7JN >>>> >>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>> >>> mobile: 44 7970 >>> >>>> 197968 >>>> >>>> *************************** E-mail confidentiality notice >>>> ******************************* >>>> >>>> This message is intended for the addressee only. It is private, >>>> confidential and may contain >>>> information of a proprietary nature. If you have received >>>> >>> this message >>> >>>> in error, please notify >>>> us and remove it from your system. >>>> >>>> -----Original Message----- >>>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] >>>> Sent: 09 August 2006 17:44 >>>> To: Lloyd McKenzie >>>> Cc: grahame at jivamedical.com; Robert Worden >>>> Subject: RE: Steering RMIM reshaping >>>> >>>> Well -- we were trying to avoid C words -- so "optimized" >>>> >>> seems the best >>> >>>> offering so far >>>> All the best >>>> Charlie >>>> >>>> >>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>> >>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>> Sent: 09 August 2006 17:08 >>>>> To: Charlie McCay >>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>> Subject: Re: Steering RMIM reshaping >>>>> >>>>> Hi Charlie, >>>>> >>>>> Calling it a "practical" model sends the wrong message about >>>>> the existing structure. Executable model suggests that it's >>>>> an internal object model, which it isn't. >>>>> >>>>> What this is is a "collapsed" or "compressed" or "optimized" >>>>> or some other transformation type word. >>>>> >>>>> >>>>> Lloyd >>>>> >>>>> Charlie McCay wrote: >>>>> >>>>> >>>>>> So how about practical model or exchange model or executable model >>>>>> >>>>>> >>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>> >>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>> Sent: 09 August 2006 16:22 >>>>>>> To: Charlie McCay >>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>> >>>>>>> Hi Charlie, >>>>>>> >>>>>>> The challenge is that many will read "physical model" in its >>>>>>> usual sense, which is persistence model, which we definitely >>>>>>> shouldn't be suggesting, let alone imposing. >>>>>>> >>>>>>> >>>>>>> Lloyd >>>>>>> >>>>>>> Charlie McCay wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> Why not? -- the intent is to provide the model for the physical >>>>>>>> exchange (subject to ITS realisation, but that is the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> model-reality >>>>>>> >>>>>>> >>>>>>> >>>>>>>> mapping) -- it is this practical model that is exactly what >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> we do want >>>>>>> >>>>>>> >>>>>>> >>>>>>>> from HL7, and that we have been using the logical >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> information model >>>>>>> >>>>>>> >>>>>>> >>>>>>>> as a proxy for until now >>>>>>>> >>>>>>>> Alternative that I do not like as much: >>>>>>>> >>>>>>>> EM exchange model / executable model >>>>>>>> >>>>>>>> charlie >>>>>>>> >>>>>>>> >>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>> >>>>>>>> >>>>> Ltd, 23D >>>>> >>>>> >>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>> >>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>> Sent: 09 August 2006 16:02 >>>>>>>>> To: Charlie McCay >>>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>> >>>>>>>>> Hi Charlie, >>>>>>>>> >>>>>>>>> I don't want to imply that HL7 defines actual physical >>>>>>>>> >>>>>>>>> >>>>> models . . . >>>>> >>>>> >>>>>>>>> Lloyd >>>>>>>>> >>>>>>>>> Charlie McCay wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> How about >>>>>>>>>> >>>>>>>>>> PM -- Physical/(?Practical?) Model ? >>>>>>>>>> PM / PSM (Platform model (Platform Specific Model) >>>>>>>>>> >>>>>>>>>> All the best >>>>>>>>>> >>>>>>>>>> Charlie >>>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> Ltd, 23D >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>>> >>>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>>> Sent: 08 August 2006 05:45 >>>>>>>>>>> To: grahame at jivamedical.com >>>>>>>>>>> Cc: Robert Worden; Charlie McCay >>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>> >>>>>>>>>>> Except CM is used for CMET. Not sure we need a different >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> id if the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> models are just transforms of each other. >>>>>>>>>>> >>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> CM = collapsed model or computable model >>>>>>>>>>>> >>>>>>>>>>>> we could go with that >>>>>>>>>>>> >>>>>>>>>>>> Grahame >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Lloyd McKenzie wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We can't use the word "Message" because we'll presumably >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> be using >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> this stuff for documents too. How about just >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> "collapsed model", >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> seeing as that's what it is . . . >>>>>>>>>>>> >>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> we've been using the term implementable model. IM, >>>>>>>>>>>> >>>>>>>>>>>> >>>>> I know.... >>>>> >>>>> >>>>>>>>>>>> maybe you could go for "message design"? it's not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> strictly a model, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> so we can get away from the "M" part and reduce confusion? >>>>>>>>>>>> >>>>>>>>>>>> cc: Charlie for an opinion >>>>>>>>>>>> >>>>>>>>>>>> Grahame >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Grahame - >>>>>>>>>>>> >>>>>>>>>>>> I agree that DAM is not the right name, and will tend >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> to confuse >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> people; we are making something strictly derived from >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> the RMIM and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> suitable for implementation, which may have DAM-like >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> names and >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> structure. >>>>>>>>>>>> >>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> calling it a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> RMIM'. Any suggestions? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> Implementation >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> Model? >>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. >>>>>>>>>>>> >>>>>>>>>>>> Give me an acronym and I will do a global edit... >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Close, London >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>> >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 197968 >>>>>>>>>>>> >>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>> ******************************* >>>>>>>>>>>> >>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> private, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> proprietary nature. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> notify us and >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> remove it from your system. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> Behalf Of >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> Grahame Grieve >>>>>>>>>>>> Sent: 07 August 2006 22:18 >>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>> Cc: Lloyd McKenzie >>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>> >>>>>>>>>>>> I'm way behind on email. but spotted this. >>>>>>>>>>>> >>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> correlation >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> between what we are trying to achieve and a real DAM. >>>>>>>>>>>> >>>>>>>>>>>> What we want is to do implementation modelling on >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> the RMIM. We >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> recognise - particularly after talking to Simon Withey >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> last week - >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> that this has nothing to do with the DAM process, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> except for the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> naming question. >>>>>>>>>>>> (Where by names in the instance should allow >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> identification back >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> against the DAM, rather than against the RIM. Except >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> unless you are >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> concerned about naming stability, but that's a much >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> harder question >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> indeed) >>>>>>>>>>>> >>>>>>>>>>>> will come back to this thread later when I catch up >>>>>>>>>>>> >>>>>>>>>>>> Grahame >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Lloyd - >>>>>>>>>>>> >>>>>>>>>>>> I was thinking that since people should really >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> produce a DAM on >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> way >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> to their RMIM, rather than the other way round, in some >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> sense the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> a formal >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> derivation, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> it >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> may be that the route is not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> appropriate. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> What then is the approved mechanism for adding >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> annotations to a MIF? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I'm >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> sure I could find it in the schemas, but it's easier to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> ask you... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> :-) >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Close, London >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>> >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 197968 >>>>>>>>>>>> >>>>>>>>>>>> *************************** E-mail >>>>>>>>>>>> >>> confidentiality notice >>> >>>>>>>>>>>> ******************************* >>>>>>>>>>>> >>>>>>>>>>>> This message is intended for the addressee only. It >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> is private, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> proprietary nature. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> notify us and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> remove it from your system. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> 07 August >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 2006 19:43 >>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>> Cc: grahame at kestral.com.au >>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>> >>>>>>>>>>>> Hi Robert, >>>>>>>>>>>> >>>>>>>>>>>> Relationships between a static model and a DAM would be >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> mappings, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> not derivations. StaticModelDerivationId is not a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> spare. In the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> and HMD but >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> in theory we could derive from 20 different models. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> (And there's >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> no ordering >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> either, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> the RIM could be the first one listed or the seventh.) >>>>>>>>>>>> >>>>>>>>>>>> The basic question is whether you construct your >>>>>>>>>>>> >>>>>>>>>>>> >>>>> DAM from a >>>>> >>>>> >>>>>>>>>>>> collapsed static model (as we do in Canada), or whether >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> you want >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> to create your DAMs and DIMs separately and map >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> them. If the >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> latter, I don't think >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> you >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> could do this in an automated way. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Lloyd >>>>>>>>>>>> >>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Grahame - >>>>>>>>>>>> >>>>>>>>>>>> You asked the other day for suggestions as to how >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> the current >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be >>>>>>>>>>>> >>> steered by >>> >>>>>>>>>>>> annotations in the RMIM MIF, rather than by user >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> input. Here is a >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> first punt to get thinking going. >>>>>>>>>>>> >>>>>>>>>>>> The simplest suggestion I can make is to add to the >>>>>>>>>>>> elements another one which says >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> how this >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> RMIM >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> was >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> derived (or might have been derived) from a DAM. These >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> would look >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> like: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> >>>>>>>>>>>> >>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> but choose >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> one >>>>>>>>>>>> >>>>>>>>>>>> that is). These can go on elements for classes, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> associations, and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> properties to say in effect >>>>>>>>>>>> >>>>>>>>>>>> * Rename this class to a DAM class name >>>>>>>>>>>> * Rename this association (with perhaps other >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> attributes saying >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 'collapse it' or 'leave it out') >>>>>>>>>>>> * Rename this property to a DAM property name (or >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> some value >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> meaning 'leave it out') >>>>>>>>>>>> >>>>>>>>>>>> If you wanted, you would not even have to say >>>>>>>>>>>> >>> explicitly >>> >>>>>>>>>>>> 'collapse an >>>>>>>>>>>> >>>>>>>>>>>> association' - because if the DAM class names are >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> the same on >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> either side of it, that means collapse it. >>>>>>>>>>>> >>>>>>>>>>>> This proposal would not yet address a combination of >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> restricting >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> and reshaping an RMIM. >>>>>>>>>>>> >>>>>>>>>>>> It would imply you cannot collapse across a CMET >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> boundary, which >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I gather from our discussion the other day you would >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> like to do. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Or maybe you can, by telling the association to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> the CMET to >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> collapse itself? Have not thought it through yet. I >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> know there >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> are issues >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> about >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> CMETs with a choice at the top - any chance you >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> could send a >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> simple diagram to illustrate the problem as you see it? >>>>>>>>>>>> >>>>>>>>>>>> Anyway, if we come up with any scheme like the above, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> it should >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> be straightforward to implement in the tool. >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Close, London >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> EC1A >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 7JN >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> 7970 197968 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> *************************** E-mail >>>>>>>>>>>> >>> confidentiality notice >>> >>>>>>>>>>>> ******************************* >>>>>>>>>>>> >>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> private, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> proprietary nature. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> If you have received this >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> message >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> in error, please notify >>>>>>>>>>>> us and remove it from your system. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>> _________________________________________________________________ >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> for viruses >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>> _________________________________________________________________ >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> This message to Charteris plc has been checked >>>>>>>>>>>> >>>>>>>>>>>> >>>>> for viruses >>>>> >>>>> >>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>> _________________________________________________________________ >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> for viruses >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> _________________________________________________________________ >>>> This message to Charteris plc has been checked for viruses >>>> http://www.charteris.com/ >>>> >>>> _________________________________________________________________ >>>> This message from Charteris plc has been checked for viruses >>>> http://www.charteris.com/ >>>> _______________________________________________ >>>> 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. >>> >>>> >>>> >>> >>> > > > > _________________________________________________________________ > This message to Charteris plc has been checked for viruses > http://www.charteris.com/ > > _________________________________________________________________ > This message from Charteris plc has been checked for viruses > http://www.charteris.com/ > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > From webmaster at hl7.org.uk Mon Aug 14 11:53:37 2006 From: webmaster at hl7.org.uk (HL7 UK Webmaster) Date: Mon, 14 Aug 2006 11:53:37 +0100 Subject: [New-ITS] HL7 UK Pre-WGM Consultation Session, including New-ITS - 23 August 2006 Message-ID: <000d01c6bf8f$e9ac2780$01bc2a50@HL7UKWebmaster> Dear HL7 UK Members & New-ITS Mailing List Members HL7 UK are holding a HL7 UK Pre-WGM Consultation Session, including New-ITS, at the Union Jack Club on 23 August 2006. For further information please see the HL7 UK Web Site or follow this link . Kindest regards Mary Pritchard HL7 UK Webmaster www.hl7.org.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060814/22adb253/attachment.htm From ann.wrightson at bt.com Tue Aug 15 15:00:46 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Tue, 15 Aug 2006 15:00:46 +0100 Subject: [New-ITS] What were the outputs of the 3/8 meeting? Message-ID: <849288029444F74899F8C8E3D479FF6DDBC38C@E03MVZ3-UKDY.domain1.systemhost.net> I'm back - and would like to catch up properly before I jump in. Is there output material from the 3/8 meeting? Thanks Ann W. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060815/b63d77e5/attachment.htm From Laura.Sato at cfh.nhs.uk Tue Aug 15 15:22:59 2006 From: Laura.Sato at cfh.nhs.uk (Sato Laura) Date: Tue, 15 Aug 2006 15:22:59 +0100 Subject: [New-ITS] What were the outputs of the 3/8 meeting? Message-ID: <1A3D105C334EAE49BDDD93D8767573F50425529A@EXCHAQ2.nhsia.nhs.uk> Thanks for the reminder, Ann. There was much discussion about orientation and scope of the ITS, but the only substantive documented output is attached which is mainly a possible update to the original overview graphic. My apologies that it's in rough form and may be a bit cryptic. Fyi, we hope to have substantive updates on the wiki by the end of this week. Best regards, Laura _________________________ Laura Sato Informatics Standards Lead Communications & Messaging NHS Connecting for Health Mobile: (44) (0)7733 324 338 Email: laura.sato at cfh.nhs.uk www.connectingforhealth.nhs.uk ________________________________ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of ann.wrightson at bt.com Sent: 15 August 2006 15:01 To: new-its at lists.hl7.org.uk Subject: [New-ITS] What were the outputs of the 3/8 meeting? I'm back - and would like to catch up properly before I jump in. Is there output material from the 3/8 meeting? Thanks Ann W. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060815/6da140c5/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: NewView_v0-2.doc Type: application/msword Size: 56832 bytes Desc: NewView_v0-2.doc Url : http://lists.hl7.org.uk/pipermail/new-its/attachments/20060815/6da140c5/NewView_v0-2-0001.doc From grahame at kestral.com.au Wed Aug 16 09:06:43 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 16 Aug 2006 18:06:43 +1000 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A04FBFD@ramseysc1420.RamseyNet.local> References: <7A55F2E13F53E749A4C13A8E53B7424A04FBFD@ramseysc1420.RamseyNet.local> Message-ID: <44E2D213.5060403@kestral.com.au> how about MMM for Mere Mortals Model The rationale for replacing the existing XML ITS with a new UML ITS: * the xml its is broken in a couple of small places. fixing it won't be backwards compatible * the uml its will be easier to implement (we hope) * though it's easy to say that you can convert between the models, this takes time and resources, both at development and run time, and this will force people to choose. But there will be no choice. Offering 3rd party conversion tools, whether free or commercial, will not be a solution (might be a problem in it's own right) * it will be extra work to maintain 2 ITS specifications Rationale for not replacing it * people are already implementing XML ITS * we explicitly allowed for multiple ITS's. Indeed, they both already exist. I am not at sure which is a better approach. I believe that further investigation will be required, including actual implementation, before we get a feel for the answer. Grahame Charlie McCay wrote: > Lloyd > > I understood that IM was rejected because we already have lots of > Information Models. > > It is yet to be established whether the collapsed model approach, if > endorsed, would be an alternative to or replacement for, the current > ITS. There was a view expressed in INM that maintaining both may not be > the best way to go forwards. > > Every model is platform independent to some degree. One take on the > collapsing process would be to say that it was intended to generate > models that were appropriate for implementation using XML, and as such > would be platform specific. Another would be that it was to produce > models that were appropriate for any generic implementation technology > (ie an Abstract Implementation Model), in this case I would agree that > it would be inappropriate to say that the models were platform specific. > One of the issues that we need to explore is whether targeting just XML > for the implementation models makes a significant difference. There are > differing expectations as to what the outcome of that will be. > > All the best > > Charlie > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > Dogpole, Shrewsbury, Shropshire SY1 1ES > tel 01743 232278 / 07808 570172 skype: charliemccay > > >> -----Original Message----- >> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >> Sent: 11 August 2006 17:17 >> To: Sato Laura >> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk >> Subject: Re: [New-ITS] Name for a >> flattened,association-collapsed model derived from an RMIM >> >> Hi Laura, >> >> The issue is that HL7 can be implemented in both collapsed >> and non-collapsed manners. The model is also platform-independent. >> >> >> Lloyd >> >> Sato Laura wrote: >>> I realise that I'm a little late into this conversation, >> but... what >>> was wrong with Implementable Model - is it the acronym, IM, >> that's too >>> like something else? What I liked about 'implementable' was that it >>> gave the sense of the view for which the model was designed >> for (i.e. >>> implementers). It gave a focus for what it was supposed to >> accomplish. >>> Scanning through the other terms, I don't mind >> Platform-Specific Model, >>> if that's truly what it is (is it?). Transmission Model >> might be okay. >>> Semantically Equivalent Model doesn't say anything to me >> about what it's >>> for, so I'm not crazy about this one. >>> >>> Just my 2p... >>> >>> Regards, >>> Laura >>> _________________________ >>> Laura Sato >>> Informatics Standards Lead >>> >>> Communications & Messaging >>> NHS Connecting for Health >>> Mobile: (44) (0)7733 324 338 >>> Email: laura.sato at cfh.nhs.uk >>> www.connectingforhealth.nhs.uk >>> >>> -----Original Message----- >>> From: new-its-bounces at lists.hl7.org.uk >>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden >>> Sent: 10 August 2006 18:18 >>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie >>> Cc: new-its at lists.hl7.org.uk >>> Subject: [New-ITS] Name for a flattened,association-collapsed model >>> derived from an RMIM >>> >>> Not sure about 'optimised' because: >>> >>> - Optimised implies the best in some sense; but it may not >> yet be the >>> best, just better >>> - The acronym 'OM' somehow is not very snappy - hard to >> read as a word >>> (or a bit Buddhist?). >>> >>> I have two other suggestions: >>> >>> - Transmission Model, or TM (still a bit Buddhist?) >>> - Semantically Equivalent Model, or SEM >>> >>> I like the last because it tells people we are not messing with RIM >>> semantics. >>> >>> Anyway, the acronym is now a variable in the tools, and I >> can change it >>> daily. We could put it to a vote at the WGM. >>> >>> Robert >>> >>> Charteris plc, Charteris House, 39/40 Bartholomew Close, London >>> EC1A 7JN >>> >>> phone: 44 1353 777668; Fax 44 1353 777394; >> mobile: 44 7970 >>> 197968 >>> >>> *************************** E-mail confidentiality notice >>> ******************************* >>> >>> This message is intended for the addressee only. It is private, >>> confidential and may contain >>> information of a proprietary nature. If you have received >> this message >>> in error, please notify >>> us and remove it from your system. >>> >>> -----Original Message----- >>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] >>> Sent: 09 August 2006 17:44 >>> To: Lloyd McKenzie >>> Cc: grahame at jivamedical.com; Robert Worden >>> Subject: RE: Steering RMIM reshaping >>> >>> Well -- we were trying to avoid C words -- so "optimized" >> seems the best >>> offering so far >>> All the best >>> Charlie >>> >>> >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>> >>> tel 01743 232278 / 07808 570172 skype: charliemccay >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>> Sent: 09 August 2006 17:08 >>>> To: Charlie McCay >>>> Cc: grahame at jivamedical.com; Robert Worden >>>> Subject: Re: Steering RMIM reshaping >>>> >>>> Hi Charlie, >>>> >>>> Calling it a "practical" model sends the wrong message about >>>> the existing structure. Executable model suggests that it's >>>> an internal object model, which it isn't. >>>> >>>> What this is is a "collapsed" or "compressed" or "optimized" >>>> or some other transformation type word. >>>> >>>> >>>> Lloyd >>>> >>>> Charlie McCay wrote: >>>> >>>>> So how about practical model or exchange model or executable model >>>>> >>>>> >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>> >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>> Sent: 09 August 2006 16:22 >>>>>> To: Charlie McCay >>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>> Subject: Re: Steering RMIM reshaping >>>>>> >>>>>> Hi Charlie, >>>>>> >>>>>> The challenge is that many will read "physical model" in its >>>>>> usual sense, which is persistence model, which we definitely >>>>>> shouldn't be suggesting, let alone imposing. >>>>>> >>>>>> >>>>>> Lloyd >>>>>> >>>>>> Charlie McCay wrote: >>>>>> >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> Why not? -- the intent is to provide the model for the physical >>>>>>> exchange (subject to ITS realisation, but that is the >>>>>>> >>>>>>> >>>>>> model-reality >>>>>> >>>>>> >>>>>>> mapping) -- it is this practical model that is exactly what >>>>>>> >>>>>>> >>>>>> we do want >>>>>> >>>>>> >>>>>>> from HL7, and that we have been using the logical >>>>>>> >>>>>>> >>>>>> information model >>>>>> >>>>>> >>>>>>> as a proxy for until now >>>>>>> >>>>>>> Alternative that I do not like as much: >>>>>>> >>>>>>> EM exchange model / executable model >>>>>>> >>>>>>> charlie >>>>>>> >>>>>>> >>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>> >>>> Ltd, 23D >>>> >>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>> >>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>> Sent: 09 August 2006 16:02 >>>>>>>> To: Charlie McCay >>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>> >>>>>>>> Hi Charlie, >>>>>>>> >>>>>>>> I don't want to imply that HL7 defines actual physical >>>>>>>> >>>> models . . . >>>> >>>>>>>> Lloyd >>>>>>>> >>>>>>>> Charlie McCay wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> How about >>>>>>>>> >>>>>>>>> PM -- Physical/(?Practical?) Model ? >>>>>>>>> PM / PSM (Platform model (Platform Specific Model) >>>>>>>>> >>>>>>>>> All the best >>>>>>>>> >>>>>>>>> Charlie >>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>> >>>>>>>>> >>>>>> Ltd, 23D >>>>>> >>>>>> >>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>> >>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>> Sent: 08 August 2006 05:45 >>>>>>>>>> To: grahame at jivamedical.com >>>>>>>>>> Cc: Robert Worden; Charlie McCay >>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>> >>>>>>>>>> Except CM is used for CMET. Not sure we need a different >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> id if the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> models are just transforms of each other. >>>>>>>>>> >>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> CM = collapsed model or computable model >>>>>>>>>>> >>>>>>>>>>> we could go with that >>>>>>>>>>> >>>>>>>>>>> Grahame >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Lloyd McKenzie wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> We can't use the word "Message" because we'll presumably >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> be using >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> this stuff for documents too. How about just >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> "collapsed model", >>>>>> >>>>>> >>>>>>>>>>>> seeing as that's what it is . . . >>>>>>>>>>>> >>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> we've been using the term implementable model. IM, >>>>>>>>>>>>> >>>> I know.... >>>> >>>>>>>>>>>>> maybe you could go for "message design"? it's not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> strictly a model, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> so we can get away from the "M" part and reduce confusion? >>>>>>>>>>>>> >>>>>>>>>>>>> cc: Charlie for an opinion >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame - >>>>>>>>>>>>>> >>>>>>>>>>>>>> I agree that DAM is not the right name, and will tend >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> to confuse >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> people; we are making something strictly derived from >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> the RMIM and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> suitable for implementation, which may have DAM-like >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> names and >>>>>> >>>>>> >>>>>>>>>>>>>> structure. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> calling it a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> RMIM'. Any suggestions? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> Implementation >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> Model? >>>>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Give me an acronym and I will do a global edit... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> Close, London >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>>> >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> mobile: 44 7970 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> 197968 >>>>>>>>>>>>>> >>>>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>> >>>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> private, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> proprietary nature. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> notify us and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> Behalf Of >>>>>> >>>>>> >>>>>>>>>>>>>> Grahame Grieve >>>>>>>>>>>>>> Sent: 07 August 2006 22:18 >>>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>>> Cc: Lloyd McKenzie >>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm way behind on email. but spotted this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> correlation >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> between what we are trying to achieve and a real DAM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What we want is to do implementation modelling on >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> the RMIM. We >>>>>> >>>>>> >>>>>>>>>>>>>> recognise - particularly after talking to Simon Withey >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> last week - >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> that this has nothing to do with the DAM process, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> except for the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> naming question. >>>>>>>>>>>>>> (Where by names in the instance should allow >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> identification back >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>> against the DAM, rather than against the RIM. Except >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> unless you are >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> concerned about naming stability, but that's a much >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> harder question >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> indeed) >>>>>>>>>>>>>> >>>>>>>>>>>>>> will come back to this thread later when I catch up >>>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Lloyd - >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I was thinking that since people should really >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> produce a DAM on >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> way >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> to their RMIM, rather than the other way round, in some >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> sense the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> a formal >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> derivation, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> it >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> may be that the route is not >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> appropriate. >>>>>> >>>>>> >>>>>>>>>>>>>>> What then is the approved mechanism for adding >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> annotations to a MIF? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> I'm >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> sure I could find it in the schemas, but it's easier to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> ask you... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> :-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Robert >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> Close, London >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> mobile: 44 7970 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> 197968 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *************************** E-mail >> confidentiality notice >>>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This message is intended for the addressee only. It >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> is private, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> proprietary nature. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> notify us and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> 07 August >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> 2006 19:43 >>>>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>>>> Cc: grahame at kestral.com.au >>>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Relationships between a static model and a DAM would be >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> mappings, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> not derivations. StaticModelDerivationId is not a >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> spare. In the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> and HMD but >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> in theory we could derive from 20 different models. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> (And there's >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> no ordering >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> either, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> the RIM could be the first one listed or the seventh.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The basic question is whether you construct your >>>>>>>>>>>>>>> >>>> DAM from a >>>> >>>>>>>>>>>>>>> collapsed static model (as we do in Canada), or whether >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> you want >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> to create your DAMs and DIMs separately and map >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> them. If the >>>>>> >>>>>> >>>>>>>>>>>>>>> latter, I don't think >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> you >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> could do this in an automated way. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Lloyd >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Grahame - >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You asked the other day for suggestions as to how >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> the current >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be >> steered by >>>>>>>>>>>>>>>> annotations in the RMIM MIF, rather than by user >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> input. Here is a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> first punt to get thinking going. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The simplest suggestion I can make is to add to the >>>>>>>>>>>>>>>> elements another one which says >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> how this >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> RMIM >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> was >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> derived (or might have been derived) from a DAM. These >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> would look >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> but choose >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> that is). These can go on elements for classes, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> associations, and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> properties to say in effect >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Rename this class to a DAM class name >>>>>>>>>>>>>>>> * Rename this association (with perhaps other >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> attributes saying >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> 'collapse it' or 'leave it out') >>>>>>>>>>>>>>>> * Rename this property to a DAM property name (or >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> some value >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> meaning 'leave it out') >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If you wanted, you would not even have to say >> explicitly >>>>>>>>>>>>>>>> 'collapse an >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> association' - because if the DAM class names are >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> the same on >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> either side of it, that means collapse it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This proposal would not yet address a combination of >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> restricting >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> and reshaping an RMIM. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It would imply you cannot collapse across a CMET >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> boundary, which >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> I gather from our discussion the other day you would >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> like to do. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> Or maybe you can, by telling the association to >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>> the CMET to >>>>>> >>>>>> >>>>>>>>>>>>>>>> collapse itself? Have not thought it through yet. I >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> know there >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> are issues >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> about >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> CMETs with a choice at the top - any chance you >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>> could send a >>>>>> >>>>>> >>>>>>>>>>>>>>>> simple diagram to illustrate the problem as you see it? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Anyway, if we come up with any scheme like the above, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> it should >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> be straightforward to implement in the tool. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Robert >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> Close, London >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> EC1A >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 7JN >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> 7970 197968 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> *************************** E-mail >> confidentiality notice >>>>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> private, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> proprietary nature. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> If you have received this >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> message >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> in error, please notify >>>>>>>>>>>>>>>> us and remove it from your system. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> _________________________________________________________________ >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>> for viruses >>>>>> >>>>>> >>>>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> _________________________________________________________________ >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> This message to Charteris plc has been checked >>>>>>>>>>>>>>> >>>> for viruses >>>> >>>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>> _________________________________________________________________ >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>> for viruses >>>>>> >>>>>> >>>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>> _________________________________________________________________ >>> This message to Charteris plc has been checked for viruses >>> http://www.charteris.com/ >>> >>> _________________________________________________________________ >>> This message from Charteris plc has been checked for viruses >>> http://www.charteris.com/ >>> _______________________________________________ >>> 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. >>> >>> >> >> > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From tim.benson at abies.co.uk Wed Aug 16 09:50:15 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Wed, 16 Aug 2006 09:50:15 +0100 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM In-Reply-To: <44E2D213.5060403@kestral.com.au> Message-ID: Grahame, It really does not matter what it is called as long as it is not easily confused with another TLA. For this reason I would not suggest MMM which will inevitably be referred to as 3M, which is a well-known trademark, with large healthcare interests. I would also prefer not to see the word model, unless it is a model in the UML sense of the word. CEN CR 12587 defined an IMS as an Implementable Message Specification, which might be revived. It is always good to reuse existing terms and meanings and avoid the temptation of neologism, otherwise known as humpty-dumptyism. Tim On 16/8/06 09:06 Grahame Grieve wrote: > how about MMM for Mere Mortals Model > > The rationale for replacing the existing XML ITS > with a new UML ITS: > * the xml its is broken in a couple of small places. fixing it > won't be backwards compatible > * the uml its will be easier to implement (we hope) > * though it's easy to say that you can convert between the models, > this takes time and resources, both at development and run time, > and this will force people to choose. But there will be no choice. > Offering 3rd party conversion tools, whether free or commercial, > will not be a solution (might be a problem in it's own right) > * it will be extra work to maintain 2 ITS specifications > > Rationale for not replacing it > * people are already implementing XML ITS > * we explicitly allowed for multiple ITS's. Indeed, they both > already exist. > > I am not at sure which is a better approach. I believe that further > investigation will be required, including actual implementation, > before we get a feel for the answer. > > Grahame > > > Charlie McCay wrote: >> Lloyd >> >> I understood that IM was rejected because we already have lots of >> Information Models. >> >> It is yet to be established whether the collapsed model approach, if >> endorsed, would be an alternative to or replacement for, the current >> ITS. There was a view expressed in INM that maintaining both may not be >> the best way to go forwards. >> >> Every model is platform independent to some degree. One take on the >> collapsing process would be to say that it was intended to generate >> models that were appropriate for implementation using XML, and as such >> would be platform specific. Another would be that it was to produce >> models that were appropriate for any generic implementation technology >> (ie an Abstract Implementation Model), in this case I would agree that >> it would be inappropriate to say that the models were platform specific. >> One of the issues that we need to explore is whether targeting just XML >> for the implementation models makes a significant difference. There are >> differing expectations as to what the outcome of that will be. >> >> All the best >> >> Charlie >> >> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >> Dogpole, Shrewsbury, Shropshire SY1 1ES >> tel 01743 232278 / 07808 570172 skype: charliemccay >> >> >>> -----Original Message----- >>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>> Sent: 11 August 2006 17:17 >>> To: Sato Laura >>> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk >>> Subject: Re: [New-ITS] Name for a >>> flattened,association-collapsed model derived from an RMIM >>> >>> Hi Laura, >>> >>> The issue is that HL7 can be implemented in both collapsed >>> and non-collapsed manners. The model is also platform-independent. >>> >>> >>> Lloyd >>> >>> Sato Laura wrote: >>>> I realise that I'm a little late into this conversation, >>> but... what >>>> was wrong with Implementable Model - is it the acronym, IM, >>> that's too >>>> like something else? What I liked about 'implementable' was that it >>>> gave the sense of the view for which the model was designed >>> for (i.e. >>>> implementers). It gave a focus for what it was supposed to >>> accomplish. >>>> Scanning through the other terms, I don't mind >>> Platform-Specific Model, >>>> if that's truly what it is (is it?). Transmission Model >>> might be okay. >>>> Semantically Equivalent Model doesn't say anything to me >>> about what it's >>>> for, so I'm not crazy about this one. >>>> >>>> Just my 2p... >>>> >>>> Regards, >>>> Laura >>>> _________________________ >>>> Laura Sato >>>> Informatics Standards Lead >>>> >>>> Communications & Messaging >>>> NHS Connecting for Health >>>> Mobile: (44) (0)7733 324 338 >>>> Email: laura.sato at cfh.nhs.uk >>>> www.connectingforhealth.nhs.uk >>>> >>>> -----Original Message----- >>>> From: new-its-bounces at lists.hl7.org.uk >>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden >>>> Sent: 10 August 2006 18:18 >>>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie >>>> Cc: new-its at lists.hl7.org.uk >>>> Subject: [New-ITS] Name for a flattened,association-collapsed model >>>> derived from an RMIM >>>> >>>> Not sure about 'optimised' because: >>>> >>>> - Optimised implies the best in some sense; but it may not >>> yet be the >>>> best, just better >>>> - The acronym 'OM' somehow is not very snappy - hard to >>> read as a word >>>> (or a bit Buddhist?). >>>> >>>> I have two other suggestions: >>>> >>>> - Transmission Model, or TM (still a bit Buddhist?) >>>> - Semantically Equivalent Model, or SEM >>>> >>>> I like the last because it tells people we are not messing with RIM >>>> semantics. >>>> >>>> Anyway, the acronym is now a variable in the tools, and I >>> can change it >>>> daily. We could put it to a vote at the WGM. >>>> >>>> Robert >>>> >>>> Charteris plc, Charteris House, 39/40 Bartholomew Close, London >>>> EC1A 7JN >>>> >>>> phone: 44 1353 777668; Fax 44 1353 777394; >>> mobile: 44 7970 >>>> 197968 >>>> >>>> *************************** E-mail confidentiality notice >>>> ******************************* >>>> >>>> This message is intended for the addressee only. It is private, >>>> confidential and may contain >>>> information of a proprietary nature. If you have received >>> this message >>>> in error, please notify >>>> us and remove it from your system. >>>> >>>> -----Original Message----- >>>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] >>>> Sent: 09 August 2006 17:44 >>>> To: Lloyd McKenzie >>>> Cc: grahame at jivamedical.com; Robert Worden >>>> Subject: RE: Steering RMIM reshaping >>>> >>>> Well -- we were trying to avoid C words -- so "optimized" >>> seems the best >>>> offering so far >>>> All the best >>>> Charlie >>>> >>>> >>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>> >>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>> Sent: 09 August 2006 17:08 >>>>> To: Charlie McCay >>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>> Subject: Re: Steering RMIM reshaping >>>>> >>>>> Hi Charlie, >>>>> >>>>> Calling it a "practical" model sends the wrong message about >>>>> the existing structure. Executable model suggests that it's >>>>> an internal object model, which it isn't. >>>>> >>>>> What this is is a "collapsed" or "compressed" or "optimized" >>>>> or some other transformation type word. >>>>> >>>>> >>>>> Lloyd >>>>> >>>>> Charlie McCay wrote: >>>>> >>>>>> So how about practical model or exchange model or executable model >>>>>> >>>>>> >>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>> >>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>> Sent: 09 August 2006 16:22 >>>>>>> To: Charlie McCay >>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>> >>>>>>> Hi Charlie, >>>>>>> >>>>>>> The challenge is that many will read "physical model" in its >>>>>>> usual sense, which is persistence model, which we definitely >>>>>>> shouldn't be suggesting, let alone imposing. >>>>>>> >>>>>>> >>>>>>> Lloyd >>>>>>> >>>>>>> Charlie McCay wrote: >>>>>>> >>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> Why not? -- the intent is to provide the model for the physical >>>>>>>> exchange (subject to ITS realisation, but that is the >>>>>>>> >>>>>>>> >>>>>>> model-reality >>>>>>> >>>>>>> >>>>>>>> mapping) -- it is this practical model that is exactly what >>>>>>>> >>>>>>>> >>>>>>> we do want >>>>>>> >>>>>>> >>>>>>>> from HL7, and that we have been using the logical >>>>>>>> >>>>>>>> >>>>>>> information model >>>>>>> >>>>>>> >>>>>>>> as a proxy for until now >>>>>>>> >>>>>>>> Alternative that I do not like as much: >>>>>>>> >>>>>>>> EM exchange model / executable model >>>>>>>> >>>>>>>> charlie >>>>>>>> >>>>>>>> >>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>> >>>>> Ltd, 23D >>>>> >>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>> >>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>> Sent: 09 August 2006 16:02 >>>>>>>>> To: Charlie McCay >>>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>> >>>>>>>>> Hi Charlie, >>>>>>>>> >>>>>>>>> I don't want to imply that HL7 defines actual physical >>>>>>>>> >>>>> models . . . >>>>> >>>>>>>>> Lloyd >>>>>>>>> >>>>>>>>> Charlie McCay wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> How about >>>>>>>>>> >>>>>>>>>> PM -- Physical/(?Practical?) Model ? >>>>>>>>>> PM / PSM (Platform model (Platform Specific Model) >>>>>>>>>> >>>>>>>>>> All the best >>>>>>>>>> >>>>>>>>>> Charlie >>>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>>> >>>>>>>>>> >>>>>>> Ltd, 23D >>>>>>> >>>>>>> >>>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>>> >>>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>>> Sent: 08 August 2006 05:45 >>>>>>>>>>> To: grahame at jivamedical.com >>>>>>>>>>> Cc: Robert Worden; Charlie McCay >>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>> >>>>>>>>>>> Except CM is used for CMET. Not sure we need a different >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> id if the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> models are just transforms of each other. >>>>>>>>>>> >>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> CM = collapsed model or computable model >>>>>>>>>>>> >>>>>>>>>>>> we could go with that >>>>>>>>>>>> >>>>>>>>>>>> Grahame >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Lloyd McKenzie wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We can't use the word "Message" because we'll presumably >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> be using >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> this stuff for documents too. How about just >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> "collapsed model", >>>>>>> >>>>>>> >>>>>>>>>>>> seeing as that's what it is . . . >>>>>>>>>>>> >>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> we've been using the term implementable model. IM, >>>>>>>>>>>> >>>>> I know.... >>>>> >>>>>>>>>>>> maybe you could go for "message design"? it's not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> strictly a model, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> so we can get away from the "M" part and reduce confusion? >>>>>>>>>>>> >>>>>>>>>>>> cc: Charlie for an opinion >>>>>>>>>>>> >>>>>>>>>>>> Grahame >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Grahame - >>>>>>>>>>>> >>>>>>>>>>>> I agree that DAM is not the right name, and will tend >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> to confuse >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> people; we are making something strictly derived from >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> the RMIM and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> suitable for implementation, which may have DAM-like >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> names and >>>>>>> >>>>>>> >>>>>>>>>>>> structure. >>>>>>>>>>>> >>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> calling it a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> RMIM'. Any suggestions? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> Implementation >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> Model? >>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. >>>>>>>>>>>> >>>>>>>>>>>> Give me an acronym and I will do a global edit... >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Close, London >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>> >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 197968 >>>>>>>>>>>> >>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>> ******************************* >>>>>>>>>>>> >>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> private, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> proprietary nature. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> notify us and >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> remove it from your system. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> Behalf Of >>>>>>> >>>>>>> >>>>>>>>>>>> Grahame Grieve >>>>>>>>>>>> Sent: 07 August 2006 22:18 >>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>> Cc: Lloyd McKenzie >>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>> >>>>>>>>>>>> I'm way behind on email. but spotted this. >>>>>>>>>>>> >>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> correlation >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> between what we are trying to achieve and a real DAM. >>>>>>>>>>>> >>>>>>>>>>>> What we want is to do implementation modelling on >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> the RMIM. We >>>>>>> >>>>>>> >>>>>>>>>>>> recognise - particularly after talking to Simon Withey >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> last week - >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> that this has nothing to do with the DAM process, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> except for the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> naming question. >>>>>>>>>>>> (Where by names in the instance should allow >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> identification back >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> against the DAM, rather than against the RIM. Except >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> unless you are >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> concerned about naming stability, but that's a much >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> harder question >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> indeed) >>>>>>>>>>>> >>>>>>>>>>>> will come back to this thread later when I catch up >>>>>>>>>>>> >>>>>>>>>>>> Grahame >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Lloyd - >>>>>>>>>>>> >>>>>>>>>>>> I was thinking that since people should really >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> produce a DAM on >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> way >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> to their RMIM, rather than the other way round, in some >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> sense the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> a formal >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> derivation, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> it >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> may be that the route is not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> appropriate. >>>>>>> >>>>>>> >>>>>>>>>>>> What then is the approved mechanism for adding >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> annotations to a MIF? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I'm >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> sure I could find it in the schemas, but it's easier to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> ask you... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> :-) >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Close, London >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>> >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 197968 >>>>>>>>>>>> >>>>>>>>>>>> *************************** E-mail >>> confidentiality notice >>>>>>>>>>>> ******************************* >>>>>>>>>>>> >>>>>>>>>>>> This message is intended for the addressee only. It >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> is private, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> proprietary nature. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> notify us and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> remove it from your system. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> 07 August >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 2006 19:43 >>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>> Cc: grahame at kestral.com.au >>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>> >>>>>>>>>>>> Hi Robert, >>>>>>>>>>>> >>>>>>>>>>>> Relationships between a static model and a DAM would be >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> mappings, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> not derivations. StaticModelDerivationId is not a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> spare. In the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> and HMD but >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> in theory we could derive from 20 different models. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> (And there's >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> no ordering >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> either, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> the RIM could be the first one listed or the seventh.) >>>>>>>>>>>> >>>>>>>>>>>> The basic question is whether you construct your >>>>>>>>>>>> >>>>> DAM from a >>>>> >>>>>>>>>>>> collapsed static model (as we do in Canada), or whether >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> you want >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> to create your DAMs and DIMs separately and map >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> them. If the >>>>>>> >>>>>>> >>>>>>>>>>>> latter, I don't think >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> you >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> could do this in an automated way. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Lloyd >>>>>>>>>>>> >>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Grahame - >>>>>>>>>>>> >>>>>>>>>>>> You asked the other day for suggestions as to how >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> the current >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be >>> steered by >>>>>>>>>>>> annotations in the RMIM MIF, rather than by user >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> input. Here is a >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> first punt to get thinking going. >>>>>>>>>>>> >>>>>>>>>>>> The simplest suggestion I can make is to add to the >>>>>>>>>>>> elements another one which says >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> how this >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> RMIM >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> was >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> derived (or might have been derived) from a DAM. These >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> would look >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> like: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> >>>>>>>>>>>> >>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> but choose >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> one >>>>>>>>>>>> >>>>>>>>>>>> that is). These can go on elements for classes, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> associations, and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> properties to say in effect >>>>>>>>>>>> >>>>>>>>>>>> * Rename this class to a DAM class name >>>>>>>>>>>> * Rename this association (with perhaps other >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> attributes saying >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 'collapse it' or 'leave it out') >>>>>>>>>>>> * Rename this property to a DAM property name (or >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> some value >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> meaning 'leave it out') >>>>>>>>>>>> >>>>>>>>>>>> If you wanted, you would not even have to say >>> explicitly >>>>>>>>>>>> 'collapse an >>>>>>>>>>>> >>>>>>>>>>>> association' - because if the DAM class names are >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> the same on >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> either side of it, that means collapse it. >>>>>>>>>>>> >>>>>>>>>>>> This proposal would not yet address a combination of >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> restricting >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> and reshaping an RMIM. >>>>>>>>>>>> >>>>>>>>>>>> It would imply you cannot collapse across a CMET >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> boundary, which >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I gather from our discussion the other day you would >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> like to do. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Or maybe you can, by telling the association to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> the CMET to >>>>>>> >>>>>>> >>>>>>>>>>>> collapse itself? Have not thought it through yet. I >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> know there >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> are issues >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> about >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> CMETs with a choice at the top - any chance you >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> could send a >>>>>>> >>>>>>> >>>>>>>>>>>> simple diagram to illustrate the problem as you see it? >>>>>>>>>>>> >>>>>>>>>>>> Anyway, if we come up with any scheme like the above, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> it should >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> be straightforward to implement in the tool. >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Close, London >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> EC1A >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 7JN >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> 7970 197968 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> *************************** E-mail >>> confidentiality notice >>>>>>>>>>>> ******************************* >>>>>>>>>>>> >>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> private, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> proprietary nature. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> If you have received this >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> message >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> in error, please notify >>>>>>>>>>>> us and remove it from your system. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>> _________________________________________________________________ >>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> for viruses >>>>>>> >>>>>>> >>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>> _________________________________________________________________ >>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> This message to Charteris plc has been checked >>>>>>>>>>>> >>>>> for viruses >>>>> >>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>> _________________________________________________________________ >>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> for viruses >>>>>>> >>>>>>> >>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>> _________________________________________________________________ >>>> This message to Charteris plc has been checked for viruses >>>> http://www.charteris.com/ >>>> >>>> _________________________________________________________________ >>>> This message from Charteris plc has been checked for viruses >>>> http://www.charteris.com/ >>>> _______________________________________________ >>>> 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. >>>> >>>> >>> >>> >> _______________________________________________ >> New-ITS mailing list >> New-ITS at lists.hl7.org.uk >> http://lists.hl7.org.uk/mailman/listinfo/new-its >> From grahame at kestral.com.au Wed Aug 16 10:02:26 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 16 Aug 2006 19:02:26 +1000 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM In-Reply-To: References: Message-ID: <44E2DF22.2050308@kestral.com.au> Tim, that wasn't supposed to be serious! but your comment about model might be interesting. Of course we can switch [M]odel for [M]essage and get everyone even more confused, especially since only some of what we are dealing with is messages. Why not model? anyway, it is model in the UML sense of the word Can you use the words "UML model"? ;-) Grahame Tim Benson wrote: > Grahame, > > It really does not matter what it is called as long as it is not easily > confused with another TLA. For this reason I would not suggest MMM which > will inevitably be referred to as 3M, which is a well-known trademark, with > large healthcare interests. I would also prefer not to see the word model, > unless it is a model in the UML sense of the word. > > CEN CR 12587 defined an IMS as an Implementable Message Specification, which > might be revived. > > It is always good to reuse existing terms and meanings and avoid the > temptation of neologism, otherwise known as humpty-dumptyism. > > Tim > > On 16/8/06 09:06 Grahame Grieve wrote: > >> how about MMM for Mere Mortals Model >> >> The rationale for replacing the existing XML ITS >> with a new UML ITS: >> * the xml its is broken in a couple of small places. fixing it >> won't be backwards compatible >> * the uml its will be easier to implement (we hope) >> * though it's easy to say that you can convert between the models, >> this takes time and resources, both at development and run time, >> and this will force people to choose. But there will be no choice. >> Offering 3rd party conversion tools, whether free or commercial, >> will not be a solution (might be a problem in it's own right) >> * it will be extra work to maintain 2 ITS specifications >> >> Rationale for not replacing it >> * people are already implementing XML ITS >> * we explicitly allowed for multiple ITS's. Indeed, they both >> already exist. >> >> I am not at sure which is a better approach. I believe that further >> investigation will be required, including actual implementation, >> before we get a feel for the answer. >> >> Grahame >> >> >> Charlie McCay wrote: >>> Lloyd >>> >>> I understood that IM was rejected because we already have lots of >>> Information Models. >>> >>> It is yet to be established whether the collapsed model approach, if >>> endorsed, would be an alternative to or replacement for, the current >>> ITS. There was a view expressed in INM that maintaining both may not be >>> the best way to go forwards. >>> >>> Every model is platform independent to some degree. One take on the >>> collapsing process would be to say that it was intended to generate >>> models that were appropriate for implementation using XML, and as such >>> would be platform specific. Another would be that it was to produce >>> models that were appropriate for any generic implementation technology >>> (ie an Abstract Implementation Model), in this case I would agree that >>> it would be inappropriate to say that the models were platform specific. >>> One of the issues that we need to explore is whether targeting just XML >>> for the implementation models makes a significant difference. There are >>> differing expectations as to what the outcome of that will be. >>> >>> All the best >>> >>> Charlie >>> >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>> tel 01743 232278 / 07808 570172 skype: charliemccay >>> >>> >>>> -----Original Message----- >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>> Sent: 11 August 2006 17:17 >>>> To: Sato Laura >>>> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk >>>> Subject: Re: [New-ITS] Name for a >>>> flattened,association-collapsed model derived from an RMIM >>>> >>>> Hi Laura, >>>> >>>> The issue is that HL7 can be implemented in both collapsed >>>> and non-collapsed manners. The model is also platform-independent. >>>> >>>> >>>> Lloyd >>>> >>>> Sato Laura wrote: >>>>> I realise that I'm a little late into this conversation, >>>> but... what >>>>> was wrong with Implementable Model - is it the acronym, IM, >>>> that's too >>>>> like something else? What I liked about 'implementable' was that it >>>>> gave the sense of the view for which the model was designed >>>> for (i.e. >>>>> implementers). It gave a focus for what it was supposed to >>>> accomplish. >>>>> Scanning through the other terms, I don't mind >>>> Platform-Specific Model, >>>>> if that's truly what it is (is it?). Transmission Model >>>> might be okay. >>>>> Semantically Equivalent Model doesn't say anything to me >>>> about what it's >>>>> for, so I'm not crazy about this one. >>>>> >>>>> Just my 2p... >>>>> >>>>> Regards, >>>>> Laura >>>>> _________________________ >>>>> Laura Sato >>>>> Informatics Standards Lead >>>>> >>>>> Communications & Messaging >>>>> NHS Connecting for Health >>>>> Mobile: (44) (0)7733 324 338 >>>>> Email: laura.sato at cfh.nhs.uk >>>>> www.connectingforhealth.nhs.uk >>>>> >>>>> -----Original Message----- >>>>> From: new-its-bounces at lists.hl7.org.uk >>>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden >>>>> Sent: 10 August 2006 18:18 >>>>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie >>>>> Cc: new-its at lists.hl7.org.uk >>>>> Subject: [New-ITS] Name for a flattened,association-collapsed model >>>>> derived from an RMIM >>>>> >>>>> Not sure about 'optimised' because: >>>>> >>>>> - Optimised implies the best in some sense; but it may not >>>> yet be the >>>>> best, just better >>>>> - The acronym 'OM' somehow is not very snappy - hard to >>>> read as a word >>>>> (or a bit Buddhist?). >>>>> >>>>> I have two other suggestions: >>>>> >>>>> - Transmission Model, or TM (still a bit Buddhist?) >>>>> - Semantically Equivalent Model, or SEM >>>>> >>>>> I like the last because it tells people we are not messing with RIM >>>>> semantics. >>>>> >>>>> Anyway, the acronym is now a variable in the tools, and I >>>> can change it >>>>> daily. We could put it to a vote at the WGM. >>>>> >>>>> Robert >>>>> >>>>> Charteris plc, Charteris House, 39/40 Bartholomew Close, London >>>>> EC1A 7JN >>>>> >>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>> mobile: 44 7970 >>>>> 197968 >>>>> >>>>> *************************** E-mail confidentiality notice >>>>> ******************************* >>>>> >>>>> This message is intended for the addressee only. It is private, >>>>> confidential and may contain >>>>> information of a proprietary nature. If you have received >>>> this message >>>>> in error, please notify >>>>> us and remove it from your system. >>>>> >>>>> -----Original Message----- >>>>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] >>>>> Sent: 09 August 2006 17:44 >>>>> To: Lloyd McKenzie >>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>> Subject: RE: Steering RMIM reshaping >>>>> >>>>> Well -- we were trying to avoid C words -- so "optimized" >>>> seems the best >>>>> offering so far >>>>> All the best >>>>> Charlie >>>>> >>>>> >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>> >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>> Sent: 09 August 2006 17:08 >>>>>> To: Charlie McCay >>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>> Subject: Re: Steering RMIM reshaping >>>>>> >>>>>> Hi Charlie, >>>>>> >>>>>> Calling it a "practical" model sends the wrong message about >>>>>> the existing structure. Executable model suggests that it's >>>>>> an internal object model, which it isn't. >>>>>> >>>>>> What this is is a "collapsed" or "compressed" or "optimized" >>>>>> or some other transformation type word. >>>>>> >>>>>> >>>>>> Lloyd >>>>>> >>>>>> Charlie McCay wrote: >>>>>> >>>>>>> So how about practical model or exchange model or executable model >>>>>>> >>>>>>> >>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>> >>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>> Sent: 09 August 2006 16:22 >>>>>>>> To: Charlie McCay >>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>> >>>>>>>> Hi Charlie, >>>>>>>> >>>>>>>> The challenge is that many will read "physical model" in its >>>>>>>> usual sense, which is persistence model, which we definitely >>>>>>>> shouldn't be suggesting, let alone imposing. >>>>>>>> >>>>>>>> >>>>>>>> Lloyd >>>>>>>> >>>>>>>> Charlie McCay wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> Why not? -- the intent is to provide the model for the physical >>>>>>>>> exchange (subject to ITS realisation, but that is the >>>>>>>>> >>>>>>>>> >>>>>>>> model-reality >>>>>>>> >>>>>>>> >>>>>>>>> mapping) -- it is this practical model that is exactly what >>>>>>>>> >>>>>>>>> >>>>>>>> we do want >>>>>>>> >>>>>>>> >>>>>>>>> from HL7, and that we have been using the logical >>>>>>>>> >>>>>>>>> >>>>>>>> information model >>>>>>>> >>>>>>>> >>>>>>>>> as a proxy for until now >>>>>>>>> >>>>>>>>> Alternative that I do not like as much: >>>>>>>>> >>>>>>>>> EM exchange model / executable model >>>>>>>>> >>>>>>>>> charlie >>>>>>>>> >>>>>>>>> >>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>> >>>>>> Ltd, 23D >>>>>> >>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>> >>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>> Sent: 09 August 2006 16:02 >>>>>>>>>> To: Charlie McCay >>>>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>> >>>>>>>>>> Hi Charlie, >>>>>>>>>> >>>>>>>>>> I don't want to imply that HL7 defines actual physical >>>>>>>>>> >>>>>> models . . . >>>>>> >>>>>>>>>> Lloyd >>>>>>>>>> >>>>>>>>>> Charlie McCay wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> How about >>>>>>>>>>> >>>>>>>>>>> PM -- Physical/(?Practical?) Model ? >>>>>>>>>>> PM / PSM (Platform model (Platform Specific Model) >>>>>>>>>>> >>>>>>>>>>> All the best >>>>>>>>>>> >>>>>>>>>>> Charlie >>>>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> Ltd, 23D >>>>>>>> >>>>>>>> >>>>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>>>> >>>>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>>>> Sent: 08 August 2006 05:45 >>>>>>>>>>>> To: grahame at jivamedical.com >>>>>>>>>>>> Cc: Robert Worden; Charlie McCay >>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>> >>>>>>>>>>>> Except CM is used for CMET. Not sure we need a different >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> id if the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> models are just transforms of each other. >>>>>>>>>>>> >>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> CM = collapsed model or computable model >>>>>>>>>>>>> >>>>>>>>>>>>> we could go with that >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Lloyd McKenzie wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> We can't use the word "Message" because we'll presumably >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> be using >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> this stuff for documents too. How about just >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> "collapsed model", >>>>>>>> >>>>>>>> >>>>>>>>>>>>> seeing as that's what it is . . . >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> we've been using the term implementable model. IM, >>>>>>>>>>>>> >>>>>> I know.... >>>>>> >>>>>>>>>>>>> maybe you could go for "message design"? it's not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> strictly a model, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> so we can get away from the "M" part and reduce confusion? >>>>>>>>>>>>> >>>>>>>>>>>>> cc: Charlie for an opinion >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame - >>>>>>>>>>>>> >>>>>>>>>>>>> I agree that DAM is not the right name, and will tend >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> to confuse >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> people; we are making something strictly derived from >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> the RMIM and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> suitable for implementation, which may have DAM-like >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> names and >>>>>>>> >>>>>>>> >>>>>>>>>>>>> structure. >>>>>>>>>>>>> >>>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> calling it a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> RMIM'. Any suggestions? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> Implementation >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> Model? >>>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. >>>>>>>>>>>>> >>>>>>>>>>>>> Give me an acronym and I will do a global edit... >>>>>>>>>>>>> >>>>>>>>>>>>> Robert >>>>>>>>>>>>> >>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Close, London >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>> >>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 197968 >>>>>>>>>>>>> >>>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>>> ******************************* >>>>>>>>>>>>> >>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> private, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> proprietary nature. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> notify us and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> Behalf Of >>>>>>>> >>>>>>>> >>>>>>>>>>>>> Grahame Grieve >>>>>>>>>>>>> Sent: 07 August 2006 22:18 >>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>> Cc: Lloyd McKenzie >>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>> >>>>>>>>>>>>> I'm way behind on email. but spotted this. >>>>>>>>>>>>> >>>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> correlation >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> between what we are trying to achieve and a real DAM. >>>>>>>>>>>>> >>>>>>>>>>>>> What we want is to do implementation modelling on >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> the RMIM. We >>>>>>>> >>>>>>>> >>>>>>>>>>>>> recognise - particularly after talking to Simon Withey >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> last week - >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> that this has nothing to do with the DAM process, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> except for the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> naming question. >>>>>>>>>>>>> (Where by names in the instance should allow >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> identification back >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> against the DAM, rather than against the RIM. Except >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> unless you are >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> concerned about naming stability, but that's a much >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> harder question >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> indeed) >>>>>>>>>>>>> >>>>>>>>>>>>> will come back to this thread later when I catch up >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Lloyd - >>>>>>>>>>>>> >>>>>>>>>>>>> I was thinking that since people should really >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> produce a DAM on >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> way >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> to their RMIM, rather than the other way round, in some >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> sense the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> a formal >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> derivation, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> it >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> may be that the route is not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> appropriate. >>>>>>>> >>>>>>>> >>>>>>>>>>>>> What then is the approved mechanism for adding >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> annotations to a MIF? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I'm >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> sure I could find it in the schemas, but it's easier to >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> ask you... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> :-) >>>>>>>>>>>>> >>>>>>>>>>>>> Robert >>>>>>>>>>>>> >>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Close, London >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>> >>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 197968 >>>>>>>>>>>>> >>>>>>>>>>>>> *************************** E-mail >>>> confidentiality notice >>>>>>>>>>>>> ******************************* >>>>>>>>>>>>> >>>>>>>>>>>>> This message is intended for the addressee only. It >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> is private, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> proprietary nature. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> notify us and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> 07 August >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 2006 19:43 >>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>> Cc: grahame at kestral.com.au >>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>> >>>>>>>>>>>>> Relationships between a static model and a DAM would be >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> mappings, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> not derivations. StaticModelDerivationId is not a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> spare. In the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> and HMD but >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> in theory we could derive from 20 different models. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> (And there's >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> no ordering >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> either, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> the RIM could be the first one listed or the seventh.) >>>>>>>>>>>>> >>>>>>>>>>>>> The basic question is whether you construct your >>>>>>>>>>>>> >>>>>> DAM from a >>>>>> >>>>>>>>>>>>> collapsed static model (as we do in Canada), or whether >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> you want >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> to create your DAMs and DIMs separately and map >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> them. If the >>>>>>>> >>>>>>>> >>>>>>>>>>>>> latter, I don't think >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> you >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> could do this in an automated way. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Lloyd >>>>>>>>>>>>> >>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame - >>>>>>>>>>>>> >>>>>>>>>>>>> You asked the other day for suggestions as to how >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> the current >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be >>>> steered by >>>>>>>>>>>>> annotations in the RMIM MIF, rather than by user >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> input. Here is a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> first punt to get thinking going. >>>>>>>>>>>>> >>>>>>>>>>>>> The simplest suggestion I can make is to add to the >>>>>>>>>>>>> elements another one which says >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> how this >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> RMIM >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> was >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> derived (or might have been derived) from a DAM. These >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> would look >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> like: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> >>>>>>>>>>>>> >>>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> but choose >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> one >>>>>>>>>>>>> >>>>>>>>>>>>> that is). These can go on elements for classes, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> associations, and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> properties to say in effect >>>>>>>>>>>>> >>>>>>>>>>>>> * Rename this class to a DAM class name >>>>>>>>>>>>> * Rename this association (with perhaps other >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> attributes saying >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 'collapse it' or 'leave it out') >>>>>>>>>>>>> * Rename this property to a DAM property name (or >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> some value >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> meaning 'leave it out') >>>>>>>>>>>>> >>>>>>>>>>>>> If you wanted, you would not even have to say >>>> explicitly >>>>>>>>>>>>> 'collapse an >>>>>>>>>>>>> >>>>>>>>>>>>> association' - because if the DAM class names are >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> the same on >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> either side of it, that means collapse it. >>>>>>>>>>>>> >>>>>>>>>>>>> This proposal would not yet address a combination of >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> restricting >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> and reshaping an RMIM. >>>>>>>>>>>>> >>>>>>>>>>>>> It would imply you cannot collapse across a CMET >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> boundary, which >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I gather from our discussion the other day you would >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> like to do. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Or maybe you can, by telling the association to >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> the CMET to >>>>>>>> >>>>>>>> >>>>>>>>>>>>> collapse itself? Have not thought it through yet. I >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> know there >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> are issues >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> about >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> CMETs with a choice at the top - any chance you >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> could send a >>>>>>>> >>>>>>>> >>>>>>>>>>>>> simple diagram to illustrate the problem as you see it? >>>>>>>>>>>>> >>>>>>>>>>>>> Anyway, if we come up with any scheme like the above, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> it should >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> be straightforward to implement in the tool. >>>>>>>>>>>>> >>>>>>>>>>>>> Robert >>>>>>>>>>>>> >>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Close, London >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> EC1A >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 7JN >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> 7970 197968 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> *************************** E-mail >>>> confidentiality notice >>>>>>>>>>>>> ******************************* >>>>>>>>>>>>> >>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> private, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> proprietary nature. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> If you have received this >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> message >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> in error, please notify >>>>>>>>>>>>> us and remove it from your system. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> _________________________________________________________________ >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> for viruses >>>>>>>> >>>>>>>> >>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> _________________________________________________________________ >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> This message to Charteris plc has been checked >>>>>>>>>>>>> >>>>>> for viruses >>>>>> >>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> _________________________________________________________________ >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> for viruses >>>>>>>> >>>>>>>> >>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> _________________________________________________________________ >>>>> This message to Charteris plc has been checked for viruses >>>>> http://www.charteris.com/ >>>>> >>>>> _________________________________________________________________ >>>>> This message from Charteris plc has been checked for viruses >>>>> http://www.charteris.com/ >>>>> _______________________________________________ >>>>> 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. >>>>> >>>> >>> _______________________________________________ >>> New-ITS mailing list >>> New-ITS at lists.hl7.org.uk >>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>> > > > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From tim.benson at abies.co.uk Wed Aug 16 10:30:37 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Wed, 16 Aug 2006 10:30:37 +0100 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM In-Reply-To: <44E2DF22.2050308@kestral.com.au> Message-ID: The UML Reference Manual - Encyclopedia of Terms (page 342) defines model as: "A semantically complete abstraction of a system". A model may comprise a containment hierarchy of packages in which the top level package corresponds to the entire system. Elements in different models do not directly affect each other, but they often represent the same concepts at different levels of detail or stages of development. Therefore relationships between them, such as trace and refinement, are important to the development process itself and often capture important design decisions. HL7 has traditionally used a much broader definition of model (e.g. DMIMs, RMIMs etc), but if we using UML explicitly, we should at least use the term model in the precise technical way defined by UML. Tim On 16/8/06 10:02 Grahame Grieve wrote: > Tim, that wasn't supposed to be serious! > > but your comment about model might be interesting. > Of course we can switch [M]odel for [M]essage > and get everyone even more confused, especially > since only some of what we are dealing with is > messages. > > Why not model? anyway, it is model in the UML sense of > the word > > Can you use the words "UML model"? ;-) > > Grahame > > > Tim Benson wrote: >> Grahame, >> >> It really does not matter what it is called as long as it is not easily >> confused with another TLA. For this reason I would not suggest MMM which >> will inevitably be referred to as 3M, which is a well-known trademark, with >> large healthcare interests. I would also prefer not to see the word model, >> unless it is a model in the UML sense of the word. >> >> CEN CR 12587 defined an IMS as an Implementable Message Specification, which >> might be revived. >> >> It is always good to reuse existing terms and meanings and avoid the >> temptation of neologism, otherwise known as humpty-dumptyism. >> >> Tim >> >> On 16/8/06 09:06 Grahame Grieve wrote: >> >>> how about MMM for Mere Mortals Model >>> >>> The rationale for replacing the existing XML ITS >>> with a new UML ITS: >>> * the xml its is broken in a couple of small places. fixing it >>> won't be backwards compatible >>> * the uml its will be easier to implement (we hope) >>> * though it's easy to say that you can convert between the models, >>> this takes time and resources, both at development and run time, >>> and this will force people to choose. But there will be no choice. >>> Offering 3rd party conversion tools, whether free or commercial, >>> will not be a solution (might be a problem in it's own right) >>> * it will be extra work to maintain 2 ITS specifications >>> >>> Rationale for not replacing it >>> * people are already implementing XML ITS >>> * we explicitly allowed for multiple ITS's. Indeed, they both >>> already exist. >>> >>> I am not at sure which is a better approach. I believe that further >>> investigation will be required, including actual implementation, >>> before we get a feel for the answer. >>> >>> Grahame >>> >>> >>> Charlie McCay wrote: >>>> Lloyd >>>> >>>> I understood that IM was rejected because we already have lots of >>>> Information Models. >>>> >>>> It is yet to be established whether the collapsed model approach, if >>>> endorsed, would be an alternative to or replacement for, the current >>>> ITS. There was a view expressed in INM that maintaining both may not be >>>> the best way to go forwards. >>>> >>>> Every model is platform independent to some degree. One take on the >>>> collapsing process would be to say that it was intended to generate >>>> models that were appropriate for implementation using XML, and as such >>>> would be platform specific. Another would be that it was to produce >>>> models that were appropriate for any generic implementation technology >>>> (ie an Abstract Implementation Model), in this case I would agree that >>>> it would be inappropriate to say that the models were platform specific. >>>> One of the issues that we need to explore is whether targeting just XML >>>> for the implementation models makes a significant difference. There are >>>> differing expectations as to what the outcome of that will be. >>>> >>>> All the best >>>> >>>> Charlie >>>> >>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>> >>>> >>>>> -----Original Message----- >>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>> Sent: 11 August 2006 17:17 >>>>> To: Sato Laura >>>>> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk >>>>> Subject: Re: [New-ITS] Name for a >>>>> flattened,association-collapsed model derived from an RMIM >>>>> >>>>> Hi Laura, >>>>> >>>>> The issue is that HL7 can be implemented in both collapsed >>>>> and non-collapsed manners. The model is also platform-independent. >>>>> >>>>> >>>>> Lloyd >>>>> >>>>> Sato Laura wrote: >>>>>> I realise that I'm a little late into this conversation, >>>>> but... what >>>>>> was wrong with Implementable Model - is it the acronym, IM, >>>>> that's too >>>>>> like something else? What I liked about 'implementable' was that it >>>>>> gave the sense of the view for which the model was designed >>>>> for (i.e. >>>>>> implementers). It gave a focus for what it was supposed to >>>>> accomplish. >>>>>> Scanning through the other terms, I don't mind >>>>> Platform-Specific Model, >>>>>> if that's truly what it is (is it?). Transmission Model >>>>> might be okay. >>>>>> Semantically Equivalent Model doesn't say anything to me >>>>> about what it's >>>>>> for, so I'm not crazy about this one. >>>>>> >>>>>> Just my 2p... >>>>>> >>>>>> Regards, >>>>>> Laura >>>>>> _________________________ >>>>>> Laura Sato >>>>>> Informatics Standards Lead >>>>>> >>>>>> Communications & Messaging >>>>>> NHS Connecting for Health >>>>>> Mobile: (44) (0)7733 324 338 >>>>>> Email: laura.sato at cfh.nhs.uk >>>>>> www.connectingforhealth.nhs.uk >>>>>> >>>>>> -----Original Message----- >>>>>> From: new-its-bounces at lists.hl7.org.uk >>>>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden >>>>>> Sent: 10 August 2006 18:18 >>>>>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie >>>>>> Cc: new-its at lists.hl7.org.uk >>>>>> Subject: [New-ITS] Name for a flattened,association-collapsed model >>>>>> derived from an RMIM >>>>>> >>>>>> Not sure about 'optimised' because: >>>>>> >>>>>> - Optimised implies the best in some sense; but it may not >>>>> yet be the >>>>>> best, just better >>>>>> - The acronym 'OM' somehow is not very snappy - hard to >>>>> read as a word >>>>>> (or a bit Buddhist?). >>>>>> >>>>>> I have two other suggestions: >>>>>> >>>>>> - Transmission Model, or TM (still a bit Buddhist?) >>>>>> - Semantically Equivalent Model, or SEM >>>>>> >>>>>> I like the last because it tells people we are not messing with RIM >>>>>> semantics. >>>>>> >>>>>> Anyway, the acronym is now a variable in the tools, and I >>>>> can change it >>>>>> daily. We could put it to a vote at the WGM. >>>>>> >>>>>> Robert >>>>>> >>>>>> Charteris plc, Charteris House, 39/40 Bartholomew Close, London >>>>>> EC1A 7JN >>>>>> >>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>> mobile: 44 7970 >>>>>> 197968 >>>>>> >>>>>> *************************** E-mail confidentiality notice >>>>>> ******************************* >>>>>> >>>>>> This message is intended for the addressee only. It is private, >>>>>> confidential and may contain >>>>>> information of a proprietary nature. If you have received >>>>> this message >>>>>> in error, please notify >>>>>> us and remove it from your system. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] >>>>>> Sent: 09 August 2006 17:44 >>>>>> To: Lloyd McKenzie >>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>> Subject: RE: Steering RMIM reshaping >>>>>> >>>>>> Well -- we were trying to avoid C words -- so "optimized" >>>>> seems the best >>>>>> offering so far >>>>>> All the best >>>>>> Charlie >>>>>> >>>>>> >>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>> >>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>> Sent: 09 August 2006 17:08 >>>>>>> To: Charlie McCay >>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>> >>>>>>> Hi Charlie, >>>>>>> >>>>>>> Calling it a "practical" model sends the wrong message about >>>>>>> the existing structure. Executable model suggests that it's >>>>>>> an internal object model, which it isn't. >>>>>>> >>>>>>> What this is is a "collapsed" or "compressed" or "optimized" >>>>>>> or some other transformation type word. >>>>>>> >>>>>>> >>>>>>> Lloyd >>>>>>> >>>>>>> Charlie McCay wrote: >>>>>>> >>>>>>>> So how about practical model or exchange model or executable model >>>>>>>> >>>>>>>> >>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>> >>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>> Sent: 09 August 2006 16:22 >>>>>>>>> To: Charlie McCay >>>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>> >>>>>>>>> Hi Charlie, >>>>>>>>> >>>>>>>>> The challenge is that many will read "physical model" in its >>>>>>>>> usual sense, which is persistence model, which we definitely >>>>>>>>> shouldn't be suggesting, let alone imposing. >>>>>>>>> >>>>>>>>> >>>>>>>>> Lloyd >>>>>>>>> >>>>>>>>> Charlie McCay wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> Why not? -- the intent is to provide the model for the physical >>>>>>>>>> exchange (subject to ITS realisation, but that is the >>>>>>>>>> >>>>>>>>>> >>>>>>>>> model-reality >>>>>>>>> >>>>>>>>> >>>>>>>>>> mapping) -- it is this practical model that is exactly what >>>>>>>>>> >>>>>>>>>> >>>>>>>>> we do want >>>>>>>>> >>>>>>>>> >>>>>>>>>> from HL7, and that we have been using the logical >>>>>>>>>> >>>>>>>>>> >>>>>>>>> information model >>>>>>>>> >>>>>>>>> >>>>>>>>>> as a proxy for until now >>>>>>>>>> >>>>>>>>>> Alternative that I do not like as much: >>>>>>>>>> >>>>>>>>>> EM exchange model / executable model >>>>>>>>>> >>>>>>>>>> charlie >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>>> >>>>>>> Ltd, 23D >>>>>>> >>>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>>> >>>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>>> Sent: 09 August 2006 16:02 >>>>>>>>>>> To: Charlie McCay >>>>>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>> >>>>>>>>>>> Hi Charlie, >>>>>>>>>>> >>>>>>>>>>> I don't want to imply that HL7 defines actual physical >>>>>>>>>>> >>>>>>> models . . . >>>>>>> >>>>>>>>>>> Lloyd >>>>>>>>>>> >>>>>>>>>>> Charlie McCay wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> How about >>>>>>>>>>>> >>>>>>>>>>>> PM -- Physical/(?Practical?) Model ? >>>>>>>>>>>> PM / PSM (Platform model (Platform Specific Model) >>>>>>>>>>>> >>>>>>>>>>>> All the best >>>>>>>>>>>> >>>>>>>>>>>> Charlie >>>>>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> Ltd, 23D >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>>>>> >>>>>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>>>> Sent: 08 August 2006 05:45 >>>>>>>>>>>> To: grahame at jivamedical.com >>>>>>>>>>>> Cc: Robert Worden; Charlie McCay >>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>> >>>>>>>>>>>> Except CM is used for CMET. Not sure we need a different >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> id if the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> models are just transforms of each other. >>>>>>>>>>>> >>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> CM = collapsed model or computable model >>>>>>>>>>>> >>>>>>>>>>>> we could go with that >>>>>>>>>>>> >>>>>>>>>>>> Grahame >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Lloyd McKenzie wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We can't use the word "Message" because we'll presumably >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> be using >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> this stuff for documents too. How about just >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> "collapsed model", >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> seeing as that's what it is . . . >>>>>>>>>>>> >>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> we've been using the term implementable model. IM, >>>>>>>>>>>> >>>>>>> I know.... >>>>>>> >>>>>>>>>>>> maybe you could go for "message design"? it's not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> strictly a model, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> so we can get away from the "M" part and reduce confusion? >>>>>>>>>>>> >>>>>>>>>>>> cc: Charlie for an opinion >>>>>>>>>>>> >>>>>>>>>>>> Grahame >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Grahame - >>>>>>>>>>>> >>>>>>>>>>>> I agree that DAM is not the right name, and will tend >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> to confuse >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> people; we are making something strictly derived from >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> the RMIM and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> suitable for implementation, which may have DAM-like >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> names and >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> structure. >>>>>>>>>>>> >>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> calling it a >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> RMIM'. Any suggestions? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Implementation >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Model? >>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. >>>>>>>>>>>> >>>>>>>>>>>> Give me an acronym and I will do a global edit... >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Close, London >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>> >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 197968 >>>>>>>>>>>> >>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>> ******************************* >>>>>>>>>>>> >>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> private, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> proprietary nature. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> notify us and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> remove it from your system. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> Behalf Of >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> Grahame Grieve >>>>>>>>>>>> Sent: 07 August 2006 22:18 >>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>> Cc: Lloyd McKenzie >>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>> >>>>>>>>>>>> I'm way behind on email. but spotted this. >>>>>>>>>>>> >>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> correlation >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> between what we are trying to achieve and a real DAM. >>>>>>>>>>>> >>>>>>>>>>>> What we want is to do implementation modelling on >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> the RMIM. We >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> recognise - particularly after talking to Simon Withey >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> last week - >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> that this has nothing to do with the DAM process, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> except for the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> naming question. >>>>>>>>>>>> (Where by names in the instance should allow >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> identification back >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> against the DAM, rather than against the RIM. Except >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> unless you are >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> concerned about naming stability, but that's a much >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> harder question >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> indeed) >>>>>>>>>>>> >>>>>>>>>>>> will come back to this thread later when I catch up >>>>>>>>>>>> >>>>>>>>>>>> Grahame >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Lloyd - >>>>>>>>>>>> >>>>>>>>>>>> I was thinking that since people should really >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> produce a DAM on >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> way >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> to their RMIM, rather than the other way round, in some >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> sense the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> a formal >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> derivation, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> it >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> may be that the route is not >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> appropriate. >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> What then is the approved mechanism for adding >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> annotations to a MIF? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'm >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> sure I could find it in the schemas, but it's easier to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ask you... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> :-) >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Close, London >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>> >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 197968 >>>>>>>>>>>> >>>>>>>>>>>> *************************** E-mail >>>>> confidentiality notice >>>>>>>>>>>> ******************************* >>>>>>>>>>>> >>>>>>>>>>>> This message is intended for the addressee only. It >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> is private, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> proprietary nature. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> notify us and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> remove it from your system. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 07 August >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2006 19:43 >>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>> Cc: grahame at kestral.com.au >>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>> >>>>>>>>>>>> Hi Robert, >>>>>>>>>>>> >>>>>>>>>>>> Relationships between a static model and a DAM would be >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mappings, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> not derivations. StaticModelDerivationId is not a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> spare. In the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> and HMD but >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> in theory we could derive from 20 different models. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (And there's >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> no ordering >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> either, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> the RIM could be the first one listed or the seventh.) >>>>>>>>>>>> >>>>>>>>>>>> The basic question is whether you construct your >>>>>>>>>>>> >>>>>>> DAM from a >>>>>>> >>>>>>>>>>>> collapsed static model (as we do in Canada), or whether >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> you want >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> to create your DAMs and DIMs separately and map >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> them. If the >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> latter, I don't think >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> you >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> could do this in an automated way. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Lloyd >>>>>>>>>>>> >>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Grahame - >>>>>>>>>>>> >>>>>>>>>>>> You asked the other day for suggestions as to how >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> the current >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be >>>>> steered by >>>>>>>>>>>> annotations in the RMIM MIF, rather than by user >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> input. Here is a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> first punt to get thinking going. >>>>>>>>>>>> >>>>>>>>>>>> The simplest suggestion I can make is to add to the >>>>>>>>>>>> elements another one which says >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> how this >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> RMIM >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> was >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> derived (or might have been derived) from a DAM. These >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> would look >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> like: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> >>>>>>>>>>>> >>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> but choose >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> one >>>>>>>>>>>> >>>>>>>>>>>> that is). These can go on elements for classes, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> associations, and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> properties to say in effect >>>>>>>>>>>> >>>>>>>>>>>> * Rename this class to a DAM class name >>>>>>>>>>>> * Rename this association (with perhaps other >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> attributes saying >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 'collapse it' or 'leave it out') >>>>>>>>>>>> * Rename this property to a DAM property name (or >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> some value >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> meaning 'leave it out') >>>>>>>>>>>> >>>>>>>>>>>> If you wanted, you would not even have to say >>>>> explicitly >>>>>>>>>>>> 'collapse an >>>>>>>>>>>> >>>>>>>>>>>> association' - because if the DAM class names are >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> the same on >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> either side of it, that means collapse it. >>>>>>>>>>>> >>>>>>>>>>>> This proposal would not yet address a combination of >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> restricting >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> and reshaping an RMIM. >>>>>>>>>>>> >>>>>>>>>>>> It would imply you cannot collapse across a CMET >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> boundary, which >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I gather from our discussion the other day you would >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> like to do. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Or maybe you can, by telling the association to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> the CMET to >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> collapse itself? Have not thought it through yet. I >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> know there >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> are issues >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> about >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> CMETs with a choice at the top - any chance you >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> could send a >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> simple diagram to illustrate the problem as you see it? >>>>>>>>>>>> >>>>>>>>>>>> Anyway, if we come up with any scheme like the above, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> it should >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> be straightforward to implement in the tool. >>>>>>>>>>>> >>>>>>>>>>>> Robert >>>>>>>>>>>> >>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Close, London >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> EC1A >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 7JN >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 7970 197968 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *************************** E-mail >>>>> confidentiality notice >>>>>>>>>>>> ******************************* >>>>>>>>>>>> >>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> private, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> proprietary nature. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If you have received this >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> message >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> in error, please notify >>>>>>>>>>>> us and remove it from your system. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> for viruses >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This message to Charteris plc has been checked >>>>>>>>>>>> >>>>>>> for viruses >>>>>>> >>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> for viruses >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> _________________________________________________________________ >>>>>> This message to Charteris plc has been checked for viruses >>>>>> http://www.charteris.com/ >>>>>> >>>>>> _________________________________________________________________ >>>>>> This message from Charteris plc has been checked for viruses >>>>>> http://www.charteris.com/ >>>>>> _______________________________________________ >>>>>> 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. >>>>>> >>>>> >>>> _______________________________________________ >>>> New-ITS mailing list >>>> New-ITS at lists.hl7.org.uk >>>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>>> >> >> >> From rik.smithies at cfh.nhs.uk Wed Aug 16 12:15:05 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Wed, 16 Aug 2006 12:15:05 +0100 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM Message-ID: <1A3D105C334EAE49BDDD93D8767573F504255615@EXCHAQ2.nhsia.nhs.uk> Another rationale for not replacing it is that people with vested interests tend not to like revolutions that they feel may threaten their investment and expertise. So you may come up against more resistance if you say the comfortable old ITS is going to go away. Others may welcome the change, but it seems this is a smaller group. This resistance might be a large blocker on the project, raising the bar for its acceptance significantly higher, or creating factions. I would suggest a more stealthy approach : a deliberate co-existence, followed by survival of the fittest. May the best ITS win ;-) Rik > -----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: 16 August 2006 09:07 > To: charlie at ramseysystems.co.uk > Cc: Robert Worden; new-its at lists.hl7.org.uk; Lloyd McKenzie; > Sato Laura > Subject: Re: [New-ITS] Name for a flattened, > association-collapsed model derived from an RMIM > > how about MMM for Mere Mortals Model > > The rationale for replacing the existing XML ITS with a new UML ITS: > * the xml its is broken in a couple of small places. fixing it > won't be backwards compatible > * the uml its will be easier to implement (we hope) > * though it's easy to say that you can convert between the models, > this takes time and resources, both at development and run time, > and this will force people to choose. But there will be no choice. > Offering 3rd party conversion tools, whether free or commercial, > will not be a solution (might be a problem in it's own right) > * it will be extra work to maintain 2 ITS specifications > > Rationale for not replacing it > * people are already implementing XML ITS > * we explicitly allowed for multiple ITS's. Indeed, they both > already exist. > > I am not at sure which is a better approach. I believe that > further investigation will be required, including actual > implementation, before we get a feel for the answer. > > Grahame > > > Charlie McCay wrote: > > Lloyd > > > > I understood that IM was rejected because we already have lots of > > Information Models. > > > > It is yet to be established whether the collapsed model > approach, if > > endorsed, would be an alternative to or replacement for, > the current > > ITS. There was a view expressed in INM that maintaining > both may not > > be the best way to go forwards. > > > > Every model is platform independent to some degree. One > take on the > > collapsing process would be to say that it was intended to generate > > models that were appropriate for implementation using XML, > and as such > > would be platform specific. Another would be that it was > to produce > > models that were appropriate for any generic implementation > technology > > (ie an Abstract Implementation Model), in this case I would > agree that > > it would be inappropriate to say that the models were > platform specific. > > One of the issues that we need to explore is whether targeting just > > XML for the implementation models makes a significant difference. > > There are differing expectations as to what the outcome of > that will be. > > > > All the best > > > > Charlie > > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > > Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 > > 570172 skype: charliemccay > > > > > >> -----Original Message----- > >> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >> Sent: 11 August 2006 17:17 > >> To: Sato Laura > >> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk > >> Subject: Re: [New-ITS] Name for a > >> flattened,association-collapsed model derived from an RMIM > >> > >> Hi Laura, > >> > >> The issue is that HL7 can be implemented in both collapsed and > >> non-collapsed manners. The model is also platform-independent. > >> > >> > >> Lloyd > >> > >> Sato Laura wrote: > >>> I realise that I'm a little late into this conversation, > >> but... what > >>> was wrong with Implementable Model - is it the acronym, IM, > >> that's too > >>> like something else? What I liked about 'implementable' > was that it > >>> gave the sense of the view for which the model was designed > >> for (i.e. > >>> implementers). It gave a focus for what it was supposed to > >> accomplish. > >>> Scanning through the other terms, I don't mind > >> Platform-Specific Model, > >>> if that's truly what it is (is it?). Transmission Model > >> might be okay. > >>> Semantically Equivalent Model doesn't say anything to me > >> about what it's > >>> for, so I'm not crazy about this one. > >>> > >>> Just my 2p... > >>> > >>> Regards, > >>> Laura > >>> _________________________ > >>> Laura Sato > >>> Informatics Standards Lead > >>> > >>> Communications & Messaging > >>> NHS Connecting for Health > >>> Mobile: (44) (0)7733 324 338 > >>> Email: laura.sato at cfh.nhs.uk > >>> www.connectingforhealth.nhs.uk > >>> > >>> -----Original Message----- > >>> From: new-its-bounces at lists.hl7.org.uk > >>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of > Robert Worden > >>> Sent: 10 August 2006 18:18 > >>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie > >>> Cc: new-its at lists.hl7.org.uk > >>> Subject: [New-ITS] Name for a > flattened,association-collapsed model > >>> derived from an RMIM > >>> > >>> Not sure about 'optimised' because: > >>> > >>> - Optimised implies the best in some sense; but it may not > >> yet be the > >>> best, just better > >>> - The acronym 'OM' somehow is not very snappy - hard to > >> read as a word > >>> (or a bit Buddhist?). > >>> > >>> I have two other suggestions: > >>> > >>> - Transmission Model, or TM (still a bit Buddhist?) > >>> - Semantically Equivalent Model, or SEM > >>> > >>> I like the last because it tells people we are not > messing with RIM > >>> semantics. > >>> > >>> Anyway, the acronym is now a variable in the tools, and I > >> can change it > >>> daily. We could put it to a vote at the WGM. > >>> > >>> Robert > >>> > >>> Charteris plc, Charteris House, 39/40 Bartholomew > Close, London > >>> EC1A 7JN > >>> > >>> phone: 44 1353 777668; Fax 44 1353 777394; > >> mobile: 44 7970 > >>> 197968 > >>> > >>> *************************** E-mail confidentiality notice > >>> ******************************* > >>> > >>> This message is intended for the addressee only. It is private, > >>> confidential and may contain information of a proprietary > nature. If > >>> you have received > >> this message > >>> in error, please notify > >>> us and remove it from your system. > >>> > >>> -----Original Message----- > >>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] > >>> Sent: 09 August 2006 17:44 > >>> To: Lloyd McKenzie > >>> Cc: grahame at jivamedical.com; Robert Worden > >>> Subject: RE: Steering RMIM reshaping > >>> > >>> Well -- we were trying to avoid C words -- so "optimized" > >> seems the best > >>> offering so far > >>> All the best > >>> Charlie > >>> > >>> > >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > Ltd, 23D > >>> Dogpole, Shrewsbury, Shropshire SY1 1ES > >>> > >>> tel 01743 232278 / 07808 570172 skype: charliemccay > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >>>> Sent: 09 August 2006 17:08 > >>>> To: Charlie McCay > >>>> Cc: grahame at jivamedical.com; Robert Worden > >>>> Subject: Re: Steering RMIM reshaping > >>>> > >>>> Hi Charlie, > >>>> > >>>> Calling it a "practical" model sends the wrong message about the > >>>> existing structure. Executable model suggests that it's an > >>>> internal object model, which it isn't. > >>>> > >>>> What this is is a "collapsed" or "compressed" or "optimized" > >>>> or some other transformation type word. > >>>> > >>>> > >>>> Lloyd > >>>> > >>>> Charlie McCay wrote: > >>>> > >>>>> So how about practical model or exchange model or > executable model > >>>>> > >>>>> > >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey > Systems Ltd, 23D > >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES > >>>>> > >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >>>>>> Sent: 09 August 2006 16:22 > >>>>>> To: Charlie McCay > >>>>>> Cc: grahame at jivamedical.com; Robert Worden > >>>>>> Subject: Re: Steering RMIM reshaping > >>>>>> > >>>>>> Hi Charlie, > >>>>>> > >>>>>> The challenge is that many will read "physical model" in its > >>>>>> usual sense, which is persistence model, which we definitely > >>>>>> shouldn't be suggesting, let alone imposing. > >>>>>> > >>>>>> > >>>>>> Lloyd > >>>>>> > >>>>>> Charlie McCay wrote: > >>>>>> > >>>>>> > >>>>>>> Hi > >>>>>>> > >>>>>>> Why not? -- the intent is to provide the model for > the physical > >>>>>>> exchange (subject to ITS realisation, but that is the > >>>>>>> > >>>>>>> > >>>>>> model-reality > >>>>>> > >>>>>> > >>>>>>> mapping) -- it is this practical model that is exactly what > >>>>>>> > >>>>>>> > >>>>>> we do want > >>>>>> > >>>>>> > >>>>>>> from HL7, and that we have been using the logical > >>>>>>> > >>>>>>> > >>>>>> information model > >>>>>> > >>>>>> > >>>>>>> as a proxy for until now > >>>>>>> > >>>>>>> Alternative that I do not like as much: > >>>>>>> > >>>>>>> EM exchange model / executable model > >>>>>>> > >>>>>>> charlie > >>>>>>> > >>>>>>> > >>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > >>>>>>> > >>>> Ltd, 23D > >>>> > >>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES > >>>>>>> > >>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >>>>>>>> Sent: 09 August 2006 16:02 > >>>>>>>> To: Charlie McCay > >>>>>>>> Cc: grahame at jivamedical.com; Robert Worden > >>>>>>>> Subject: Re: Steering RMIM reshaping > >>>>>>>> > >>>>>>>> Hi Charlie, > >>>>>>>> > >>>>>>>> I don't want to imply that HL7 defines actual physical > >>>>>>>> > >>>> models . . . > >>>> > >>>>>>>> Lloyd > >>>>>>>> > >>>>>>>> Charlie McCay wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> How about > >>>>>>>>> > >>>>>>>>> PM -- Physical/(?Practical?) Model ? > >>>>>>>>> PM / PSM (Platform model (Platform Specific Model) > >>>>>>>>> > >>>>>>>>> All the best > >>>>>>>>> > >>>>>>>>> Charlie > >>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems > >>>>>>>>> > >>>>>>>>> > >>>>>> Ltd, 23D > >>>>>> > >>>>>> > >>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES > >>>>>>>>> > >>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] > >>>>>>>>>> Sent: 08 August 2006 05:45 > >>>>>>>>>> To: grahame at jivamedical.com > >>>>>>>>>> Cc: Robert Worden; Charlie McCay > >>>>>>>>>> Subject: Re: Steering RMIM reshaping > >>>>>>>>>> > >>>>>>>>>> Except CM is used for CMET. Not sure we need a different > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> id if the > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>> models are just transforms of each other. > >>>>>>>>>> > >>>>>>>>>> Grahame Grieve wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> CM = collapsed model or computable model > >>>>>>>>>>> > >>>>>>>>>>> we could go with that > >>>>>>>>>>> > >>>>>>>>>>> Grahame > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Lloyd McKenzie wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> We can't use the word "Message" because we'll presumably > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> be using > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>> this stuff for documents too. How about just > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>> "collapsed model", > >>>>>> > >>>>>> > >>>>>>>>>>>> seeing as that's what it is . . . > >>>>>>>>>>>> > >>>>>>>>>>>> Grahame Grieve wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> we've been using the term implementable model. IM, > >>>>>>>>>>>>> > >>>> I know.... > >>>> > >>>>>>>>>>>>> maybe you could go for "message design"? it's not > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>> strictly a model, > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>> so we can get away from the "M" part and reduce > confusion? > >>>>>>>>>>>>> > >>>>>>>>>>>>> cc: Charlie for an opinion > >>>>>>>>>>>>> > >>>>>>>>>>>>> Grahame > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Robert Worden wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Grahame - > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I agree that DAM is not the right name, and will tend > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> to confuse > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> people; we are making something strictly derived from > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>> the RMIM and > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>> suitable for implementation, which may have DAM-like > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>> names and > >>>>>> > >>>>>> > >>>>>>>>>>>>>> structure. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> calling it a > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>> RMIM'. Any suggestions? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> Implementation > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> Model? > >>>>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Give me an acronym and I will do a global edit... > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Robert > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>> Close, London > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>> EC1A 7JN > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>> mobile: 44 7970 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>> 197968 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> *************************** E-mail > confidentiality notice > >>>>>>>>>>>>>> ******************************* > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This message is intended for the addressee only. It is > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> private, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> confidential and may contain information of a > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>> proprietary nature. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>> If you have received this message in error, please > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> notify us and > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> remove it from your system. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>> Behalf Of > >>>>>> > >>>>>> > >>>>>>>>>>>>>> Grahame Grieve > >>>>>>>>>>>>>> Sent: 07 August 2006 22:18 > >>>>>>>>>>>>>> To: Robert Worden > >>>>>>>>>>>>>> Cc: Lloyd McKenzie > >>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'm way behind on email. but spotted this. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>> correlation > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>> between what we are trying to achieve and a real DAM. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> What we want is to do implementation modelling on > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>> the RMIM. We > >>>>>> > >>>>>> > >>>>>>>>>>>>>> recognise - particularly after talking to Simon Withey > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>> last week - > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>> that this has nothing to do with the DAM process, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> except for the > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> naming question. > >>>>>>>>>>>>>> (Where by names in the instance should allow > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>> identification back > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>> against the DAM, rather than against the RIM. Except > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>> unless you are > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>> concerned about naming stability, but that's a much > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>> harder question > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>> indeed) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> will come back to this thread later when I catch up > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Grahame > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Robert Worden wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi Lloyd - > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I was thinking that since people should really > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>> produce a DAM on > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> way > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> to their RMIM, rather than the other way > round, in some > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> sense the > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>> a formal > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>>> derivation, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> it > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> may be that the route is not > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>> appropriate. > >>>>>> > >>>>>> > >>>>>>>>>>>>>>> What then is the approved mechanism for adding > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> annotations to a MIF? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>> I'm > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> sure I could find it in the schemas, but it's > easier to > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> ask you... > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> :-) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Robert > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> Close, London > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> EC1A 7JN > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> mobile: 44 7970 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> 197968 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> *************************** E-mail > >> confidentiality notice > >>>>>>>>>>>>>>> ******************************* > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> This message is intended for the addressee only. It > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>> is private, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>>> confidential and may contain information of a > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> proprietary nature. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> If you have received this message in error, please > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> notify us and > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> remove it from your system. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: Lloyd McKenzie > [mailto:lloyd at lmckenzie.com] Sent: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> 07 August > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> 2006 19:43 > >>>>>>>>>>>>>>> To: Robert Worden > >>>>>>>>>>>>>>> Cc: grahame at kestral.com.au > >>>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi Robert, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Relationships between a static model and a > DAM would be > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> mappings, > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> not derivations. StaticModelDerivationId is not a > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>> spare. In the > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> and HMD but > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> in theory we could derive from 20 different models. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> (And there's > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> no ordering > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> either, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> the RIM could be the first one listed or the seventh.) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The basic question is whether you construct your > >>>>>>>>>>>>>>> > >>>> DAM from a > >>>> > >>>>>>>>>>>>>>> collapsed static model (as we do in Canada), > or whether > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> you want > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> to create your DAMs and DIMs separately and map > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>> them. If the > >>>>>> > >>>>>> > >>>>>>>>>>>>>>> latter, I don't think > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> you > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> could do this in an automated way. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Lloyd > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Robert Worden wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Grahame - > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> You asked the other day for suggestions as to how > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>> the current > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be > >> steered by > >>>>>>>>>>>>>>>> annotations in the RMIM MIF, rather than by user > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> input. Here is a > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> first punt to get thinking going. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The simplest suggestion I can make is to add to the > >>>>>>>>>>>>>>>> elements another one which says > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>> how this > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>>>> RMIM > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> was > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> derived (or might have been derived) from a > DAM. These > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> would look > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> like: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> (I don't know if staticModelDerivationId="4" > is spare; > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> but choose > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> one > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> that is). These can go on elements for classes, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> associations, and > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> properties to say in effect > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> * Rename this class to a DAM class name > >>>>>>>>>>>>>>>> * Rename this association (with perhaps other > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> attributes saying > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> 'collapse it' or 'leave it out') > >>>>>>>>>>>>>>>> * Rename this property to a DAM property name (or > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> some value > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> meaning 'leave it out') > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> If you wanted, you would not even have to say > >> explicitly > >>>>>>>>>>>>>>>> 'collapse an > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> association' - because if the DAM class names are > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>> the same on > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>>>> either side of it, that means collapse it. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> This proposal would not yet address a combination of > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> restricting > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> and reshaping an RMIM. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> It would imply you cannot collapse across a CMET > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> boundary, which > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> I gather from our discussion the other day you would > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> like to do. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> Or maybe you can, by telling the association to > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>> the CMET to > >>>>>> > >>>>>> > >>>>>>>>>>>>>>>> collapse itself? Have not thought it through yet. I > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>> know there > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>>>> are issues > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> about > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> CMETs with a choice at the top - any chance you > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>> could send a > >>>>>> > >>>>>> > >>>>>>>>>>>>>>>> simple diagram to illustrate the problem as > you see it? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Anyway, if we come up with any scheme like the above, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> it should > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> be straightforward to implement in the tool. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Robert > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> Close, London > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> EC1A > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 7JN > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> 7970 197968 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> *************************** E-mail > >> confidentiality notice > >>>>>>>>>>>>>>>> ******************************* > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> This message is intended for the addressee > only. It is > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> private, > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> confidential and may contain information of a > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>> proprietary nature. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> If you have received this > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> message > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> in error, please notify us and remove it from your > >>>>>>>>>>>>>>>> system. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>> _________________________________________________________________ > >>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>>> This message from Charteris plc has been checked > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>> for viruses > >>>>>> > >>>>>> > >>>>>>>>>>>>>>>> http://www.charteris.com/ > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> _________________________________________________________________ > >>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> This message to Charteris plc has been checked > >>>>>>>>>>>>>>> > >>>> for viruses > >>>> > >>>>>>>>>>>>>>> http://www.charteris.com/ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> _________________________________________________________________ > >>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>>>> This message from Charteris plc has been checked > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>> for viruses > >>>>>> > >>>>>> > >>>>>>>>>>>>>>> http://www.charteris.com/ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>>> > >>> _________________________________________________________________ > >>> This message to Charteris plc has been checked for viruses > >>> http://www.charteris.com/ > >>> > >>> _________________________________________________________________ > >>> This message from Charteris plc has been checked for viruses > >>> http://www.charteris.com/ > >>> _______________________________________________ > >>> 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. > >>> > >>> > >> > >> > > _______________________________________________ > > New-ITS mailing list > > New-ITS at lists.hl7.org.uk > > http://lists.hl7.org.uk/mailman/listinfo/new-its > > > > -- > 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 > 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. From MelvinR at AMS-Consulting.co.uk Wed Aug 16 12:52:30 2006 From: MelvinR at AMS-Consulting.co.uk (Melvin Reynolds) Date: Wed, 16 Aug 2006 12:52:30 +0100 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM In-Reply-To: <1A3D105C334EAE49BDDD93D8767573F504255615@EXCHAQ2.nhsia.nhs.uk> References: <1A3D105C334EAE49BDDD93D8767573F504255615@EXCHAQ2.nhsia.nhs.uk> Message-ID: Rik, I tend to agree. But it still, I think, leaves Robert with his original question! Melvin. In mail of Wed, 16 Aug 2006 12:15:05, Smithies Rik wrote: > >Another rationale for not replacing it is that people with vested >interests tend not to like revolutions that they feel may threaten their >investment and expertise. > >So you may come up against more resistance if you say the comfortable >old ITS is going to go away. Others may welcome the change, but it seems >this is a smaller group. > >This resistance might be a large blocker on the project, raising the bar >for its acceptance significantly higher, or creating factions. > >I would suggest a more stealthy approach : a deliberate co-existence, >followed by survival of the fittest. > >May the best ITS win ;-) > >Rik > >> -----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: 16 August 2006 09:07 >> To: charlie at ramseysystems.co.uk >> Cc: Robert Worden; new-its at lists.hl7.org.uk; Lloyd McKenzie; >> Sato Laura >> Subject: Re: [New-ITS] Name for a flattened, >> association-collapsed model derived from an RMIM >> >> how about MMM for Mere Mortals Model >> >> The rationale for replacing the existing XML ITS with a new UML ITS: >> * the xml its is broken in a couple of small places. fixing it >> won't be backwards compatible >> * the uml its will be easier to implement (we hope) >> * though it's easy to say that you can convert between the models, >> this takes time and resources, both at development and run time, >> and this will force people to choose. But there will be no choice. >> Offering 3rd party conversion tools, whether free or commercial, >> will not be a solution (might be a problem in it's own right) >> * it will be extra work to maintain 2 ITS specifications >> >> Rationale for not replacing it >> * people are already implementing XML ITS >> * we explicitly allowed for multiple ITS's. Indeed, they both >> already exist. >> >> I am not at sure which is a better approach. I believe that >> further investigation will be required, including actual >> implementation, before we get a feel for the answer. >> >> Grahame >> >> >> Charlie McCay wrote: >> > Lloyd >> > >> > I understood that IM was rejected because we already have lots of >> > Information Models. >> > >> > It is yet to be established whether the collapsed model >> approach, if >> > endorsed, would be an alternative to or replacement for, >> the current >> > ITS. There was a view expressed in INM that maintaining >> both may not >> > be the best way to go forwards. >> > >> > Every model is platform independent to some degree. One >> take on the >> > collapsing process would be to say that it was intended to generate >> > models that were appropriate for implementation using XML, >> and as such >> > would be platform specific. Another would be that it was >> to produce >> > models that were appropriate for any generic implementation >> technology >> > (ie an Abstract Implementation Model), in this case I would >> agree that >> > it would be inappropriate to say that the models were >> platform specific. >> > One of the issues that we need to explore is whether targeting just >> > XML for the implementation models makes a significant difference. >> > There are differing expectations as to what the outcome of >> that will be. >> > >> > All the best >> > >> > Charlie >> > >> > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >> > Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 >> > 570172 skype: charliemccay >> > >> > >> >> -----Original Message----- >> >> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >> >> Sent: 11 August 2006 17:17 >> >> To: Sato Laura >> >> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk >> >> Subject: Re: [New-ITS] Name for a >> >> flattened,association-collapsed model derived from an RMIM >> >> >> >> Hi Laura, >> >> >> >> The issue is that HL7 can be implemented in both collapsed and >> >> non-collapsed manners. The model is also platform-independent. >> >> >> >> >> >> Lloyd >> >> >> >> Sato Laura wrote: >> >>> I realise that I'm a little late into this conversation, >> >> but... what >> >>> was wrong with Implementable Model - is it the acronym, IM, >> >> that's too >> >>> like something else? What I liked about 'implementable' >> was that it >> >>> gave the sense of the view for which the model was designed >> >> for (i.e. >> >>> implementers). It gave a focus for what it was supposed to >> >> accomplish. >> >>> Scanning through the other terms, I don't mind >> >> Platform-Specific Model, >> >>> if that's truly what it is (is it?). Transmission Model >> >> might be okay. >> >>> Semantically Equivalent Model doesn't say anything to me >> >> about what it's >> >>> for, so I'm not crazy about this one. >> >>> >> >>> Just my 2p... >> >>> >> >>> Regards, >> >>> Laura >> >>> _________________________ >> >>> Laura Sato >> >>> Informatics Standards Lead >> >>> >> >>> Communications & Messaging >> >>> NHS Connecting for Health >> >>> Mobile: (44) (0)7733 324 338 >> >>> Email: laura.sato at cfh.nhs.uk >> >>> www.connectingforhealth.nhs.uk >> >>> >> >>> -----Original Message----- >> >>> From: new-its-bounces at lists.hl7.org.uk >> >>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of >> Robert Worden >> >>> Sent: 10 August 2006 18:18 >> >>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie >> >>> Cc: new-its at lists.hl7.org.uk >> >>> Subject: [New-ITS] Name for a >> flattened,association-collapsed model >> >>> derived from an RMIM >> >>> >> >>> Not sure about 'optimised' because: >> >>> >> >>> - Optimised implies the best in some sense; but it may not >> >> yet be the >> >>> best, just better >> >>> - The acronym 'OM' somehow is not very snappy - hard to >> >> read as a word >> >>> (or a bit Buddhist?). >> >>> >> >>> I have two other suggestions: >> >>> >> >>> - Transmission Model, or TM (still a bit Buddhist?) >> >>> - Semantically Equivalent Model, or SEM >> >>> >> >>> I like the last because it tells people we are not >> messing with RIM >> >>> semantics. >> >>> >> >>> Anyway, the acronym is now a variable in the tools, and I >> >> can change it >> >>> daily. We could put it to a vote at the WGM. >> >>> >> >>> Robert >> >>> >> >>> Charteris plc, Charteris House, 39/40 Bartholomew >> Close, London >> >>> EC1A 7JN >> >>> >> >>> phone: 44 1353 777668; Fax 44 1353 777394; >> >> mobile: 44 7970 >> >>> 197968 >> >>> >> >>> *************************** E-mail confidentiality notice >> >>> ******************************* >> >>> >> >>> This message is intended for the addressee only. It is private, >> >>> confidential and may contain information of a proprietary >> nature. If >> >>> you have received >> >> this message >> >>> in error, please notify >> >>> us and remove it from your system. >> >>> >> >>> -----Original Message----- >> >>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] >> >>> Sent: 09 August 2006 17:44 >> >>> To: Lloyd McKenzie >> >>> Cc: grahame at jivamedical.com; Robert Worden >> >>> Subject: RE: Steering RMIM reshaping >> >>> >> >>> Well -- we were trying to avoid C words -- so "optimized" >> >> seems the best >> >>> offering so far >> >>> All the best >> >>> Charlie >> >>> >> >>> >> >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >> Ltd, 23D >> >>> Dogpole, Shrewsbury, Shropshire SY1 1ES >> >>> >> >>> tel 01743 232278 / 07808 570172 skype: charliemccay >> >>> >> >>> >> >>> >> >>> >> >>> >> >>>> -----Original Message----- >> >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >> >>>> Sent: 09 August 2006 17:08 >> >>>> To: Charlie McCay >> >>>> Cc: grahame at jivamedical.com; Robert Worden >> >>>> Subject: Re: Steering RMIM reshaping >> >>>> >> >>>> Hi Charlie, >> >>>> >> >>>> Calling it a "practical" model sends the wrong message about the >> >>>> existing structure. Executable model suggests that it's an >> >>>> internal object model, which it isn't. >> >>>> >> >>>> What this is is a "collapsed" or "compressed" or "optimized" >> >>>> or some other transformation type word. >> >>>> >> >>>> >> >>>> Lloyd >> >>>> >> >>>> Charlie McCay wrote: >> >>>> >> >>>>> So how about practical model or exchange model or >> executable model >> >>>>> >> >>>>> >> >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey >> Systems Ltd, 23D >> >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >> >>>>> >> >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >> >>>>>> Sent: 09 August 2006 16:22 >> >>>>>> To: Charlie McCay >> >>>>>> Cc: grahame at jivamedical.com; Robert Worden >> >>>>>> Subject: Re: Steering RMIM reshaping >> >>>>>> >> >>>>>> Hi Charlie, >> >>>>>> >> >>>>>> The challenge is that many will read "physical model" in its >> >>>>>> usual sense, which is persistence model, which we definitely >> >>>>>> shouldn't be suggesting, let alone imposing. >> >>>>>> >> >>>>>> >> >>>>>> Lloyd >> >>>>>> >> >>>>>> Charlie McCay wrote: >> >>>>>> >> >>>>>> >> >>>>>>> Hi >> >>>>>>> >> >>>>>>> Why not? -- the intent is to provide the model for >> the physical >> >>>>>>> exchange (subject to ITS realisation, but that is the >> >>>>>>> >> >>>>>>> >> >>>>>> model-reality >> >>>>>> >> >>>>>> >> >>>>>>> mapping) -- it is this practical model that is exactly what >> >>>>>>> >> >>>>>>> >> >>>>>> we do want >> >>>>>> >> >>>>>> >> >>>>>>> from HL7, and that we have been using the logical >> >>>>>>> >> >>>>>>> >> >>>>>> information model >> >>>>>> >> >>>>>> >> >>>>>>> as a proxy for until now >> >>>>>>> >> >>>>>>> Alternative that I do not like as much: >> >>>>>>> >> >>>>>>> EM exchange model / executable model >> >>>>>>> >> >>>>>>> charlie >> >>>>>>> >> >>>>>>> >> >>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >> >>>>>>> >> >>>> Ltd, 23D >> >>>> >> >>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >> >>>>>>> >> >>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>>> -----Original Message----- >> >>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >> >>>>>>>> Sent: 09 August 2006 16:02 >> >>>>>>>> To: Charlie McCay >> >>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >> >>>>>>>> Subject: Re: Steering RMIM reshaping >> >>>>>>>> >> >>>>>>>> Hi Charlie, >> >>>>>>>> >> >>>>>>>> I don't want to imply that HL7 defines actual physical >> >>>>>>>> >> >>>> models . . . >> >>>> >> >>>>>>>> Lloyd >> >>>>>>>> >> >>>>>>>> Charlie McCay wrote: >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>> How about >> >>>>>>>>> >> >>>>>>>>> PM -- Physical/(?Practical?) Model ? >> >>>>>>>>> PM / PSM (Platform model (Platform Specific Model) >> >>>>>>>>> >> >>>>>>>>> All the best >> >>>>>>>>> >> >>>>>>>>> Charlie >> >>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >> >>>>>>>>> >> >>>>>>>>> >> >>>>>> Ltd, 23D >> >>>>>> >> >>>>>> >> >>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >> >>>>>>>>> >> >>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>> -----Original Message----- >> >>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >> >>>>>>>>>> Sent: 08 August 2006 05:45 >> >>>>>>>>>> To: grahame at jivamedical.com >> >>>>>>>>>> Cc: Robert Worden; Charlie McCay >> >>>>>>>>>> Subject: Re: Steering RMIM reshaping >> >>>>>>>>>> >> >>>>>>>>>> Except CM is used for CMET. Not sure we need a different >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>> id if the >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>> models are just transforms of each other. >> >>>>>>>>>> >> >>>>>>>>>> Grahame Grieve wrote: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>> CM = collapsed model or computable model >> >>>>>>>>>>> >> >>>>>>>>>>> we could go with that >> >>>>>>>>>>> >> >>>>>>>>>>> Grahame >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> Lloyd McKenzie wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>>> We can't use the word "Message" because we'll presumably >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>> be using >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>> this stuff for documents too. How about just >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>> "collapsed model", >> >>>>>> >> >>>>>> >> >>>>>>>>>>>> seeing as that's what it is . . . >> >>>>>>>>>>>> >> >>>>>>>>>>>> Grahame Grieve wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>>> we've been using the term implementable model. IM, >> >>>>>>>>>>>>> >> >>>> I know.... >> >>>> >> >>>>>>>>>>>>> maybe you could go for "message design"? it's not >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>> strictly a model, >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>> so we can get away from the "M" part and reduce >> confusion? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> cc: Charlie for an opinion >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Grahame >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Robert Worden wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>>> Grahame - >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> I agree that DAM is not the right name, and will tend >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>> to confuse >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>> people; we are making something strictly derived from >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>> the RMIM and >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>> suitable for implementation, which may have DAM-like >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>> names and >> >>>>>> >> >>>>>> >> >>>>>>>>>>>>>> structure. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>> calling it a >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>> RMIM'. Any suggestions? >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>> Implementation >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>> Model? >> >>>>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Give me an acronym and I will do a global edit... >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Robert >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>> Close, London >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>> EC1A 7JN >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>> mobile: 44 7970 >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>> 197968 >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> *************************** E-mail >> confidentiality notice >> >>>>>>>>>>>>>> ******************************* >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> This message is intended for the addressee only. It is >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>> private, >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>> confidential and may contain information of a >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>> proprietary nature. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>> If you have received this message in error, please >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>> notify us and >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>> remove it from your system. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> -----Original Message----- >> >>>>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>> Behalf Of >> >>>>>> >> >>>>>> >> >>>>>>>>>>>>>> Grahame Grieve >> >>>>>>>>>>>>>> Sent: 07 August 2006 22:18 >> >>>>>>>>>>>>>> To: Robert Worden >> >>>>>>>>>>>>>> Cc: Lloyd McKenzie >> >>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> I'm way behind on email. but spotted this. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>> correlation >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>> between what we are trying to achieve and a real DAM. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> What we want is to do implementation modelling on >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>> the RMIM. We >> >>>>>> >> >>>>>> >> >>>>>>>>>>>>>> recognise - particularly after talking to Simon Withey >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>> last week - >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>> that this has nothing to do with the DAM process, >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>> except for the >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>> naming question. >> >>>>>>>>>>>>>> (Where by names in the instance should allow >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>> identification back >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>> against the DAM, rather than against the RIM. Except >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>> unless you are >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>> concerned about naming stability, but that's a much >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>> harder question >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>> indeed) >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> will come back to this thread later when I catch up >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Grahame >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Robert Worden wrote: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Hi Lloyd - >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> I was thinking that since people should really >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>> produce a DAM on >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> way >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> to their RMIM, rather than the other way >> round, in some >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>> sense the >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>> a formal >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>>> derivation, >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> it >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> may be that the route is not >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>> appropriate. >> >>>>>> >> >>>>>> >> >>>>>>>>>>>>>>> What then is the approved mechanism for adding >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>> annotations to a MIF? >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>> I'm >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> sure I could find it in the schemas, but it's >> easier to >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>> ask you... >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> :-) >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Robert >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>> Close, London >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> EC1A 7JN >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>> mobile: 44 7970 >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> 197968 >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> *************************** E-mail >> >> confidentiality notice >> >>>>>>>>>>>>>>> ******************************* >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> This message is intended for the addressee only. It >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>> is private, >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>>> confidential and may contain information of a >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>> proprietary nature. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> If you have received this message in error, please >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>> notify us and >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> remove it from your system. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> -----Original Message----- >> >>>>>>>>>>>>>>> From: Lloyd McKenzie >> [mailto:lloyd at lmckenzie.com] Sent: >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>> 07 August >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> 2006 19:43 >> >>>>>>>>>>>>>>> To: Robert Worden >> >>>>>>>>>>>>>>> Cc: grahame at kestral.com.au >> >>>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Hi Robert, >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Relationships between a static model and a >> DAM would be >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>> mappings, >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> not derivations. StaticModelDerivationId is not a >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>> spare. In the >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>> and HMD but >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> in theory we could derive from 20 different models. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>> (And there's >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> no ordering >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> either, >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> the RIM could be the first one listed or the seventh.) >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> The basic question is whether you construct your >> >>>>>>>>>>>>>>> >> >>>> DAM from a >> >>>> >> >>>>>>>>>>>>>>> collapsed static model (as we do in Canada), >> or whether >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>> you want >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> to create your DAMs and DIMs separately and map >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>> them. If the >> >>>>>> >> >>>>>> >> >>>>>>>>>>>>>>> latter, I don't think >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> you >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> could do this in an automated way. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Lloyd >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Robert Worden wrote: >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Grahame - >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> You asked the other day for suggestions as to how >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>> the current >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be >> >> steered by >> >>>>>>>>>>>>>>>> annotations in the RMIM MIF, rather than by user >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> input. Here is a >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> first punt to get thinking going. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> The simplest suggestion I can make is to add to the >> >>>>>>>>>>>>>>>> elements another one which says >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>> how this >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>>>> RMIM >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> was >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> derived (or might have been derived) from a >> DAM. These >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> would look >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> like: >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> (I don't know if staticModelDerivationId="4" >> is spare; >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> but choose >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> one >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> that is). These can go on elements for classes, >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> associations, and >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> properties to say in effect >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> * Rename this class to a DAM class name >> >>>>>>>>>>>>>>>> * Rename this association (with perhaps other >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> attributes saying >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> 'collapse it' or 'leave it out') >> >>>>>>>>>>>>>>>> * Rename this property to a DAM property name (or >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> some value >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> meaning 'leave it out') >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> If you wanted, you would not even have to say >> >> explicitly >> >>>>>>>>>>>>>>>> 'collapse an >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> association' - because if the DAM class names are >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>> the same on >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>>>> either side of it, that means collapse it. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> This proposal would not yet address a combination of >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> restricting >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> and reshaping an RMIM. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> It would imply you cannot collapse across a CMET >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> boundary, which >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> I gather from our discussion the other day you would >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> like to do. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> Or maybe you can, by telling the association to >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>> the CMET to >> >>>>>> >> >>>>>> >> >>>>>>>>>>>>>>>> collapse itself? Have not thought it through yet. I >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>> know there >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>>>>>>>> are issues >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> about >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> CMETs with a choice at the top - any chance you >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>> could send a >> >>>>>> >> >>>>>> >> >>>>>>>>>>>>>>>> simple diagram to illustrate the problem as >> you see it? >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Anyway, if we come up with any scheme like the above, >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> it should >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> be straightforward to implement in the tool. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Robert >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> Close, London >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> EC1A >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> 7JN >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> 7970 197968 >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> *************************** E-mail >> >> confidentiality notice >> >>>>>>>>>>>>>>>> ******************************* >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> This message is intended for the addressee >> only. It is >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> private, >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> confidential and may contain information of a >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>> proprietary nature. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> If you have received this >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> message >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> in error, please notify us and remove it from your >> >>>>>>>>>>>>>>>> system. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>> _________________________________________________________________ >> >>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>>> This message from Charteris plc has been checked >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>> for viruses >> >>>>>> >> >>>>>> >> >>>>>>>>>>>>>>>> http://www.charteris.com/ >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>> _________________________________________________________________ >> >>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> This message to Charteris plc has been checked >> >>>>>>>>>>>>>>> >> >>>> for viruses >> >>>> >> >>>>>>>>>>>>>>> http://www.charteris.com/ >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>> _________________________________________________________________ >> >>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>>>>>> This message from Charteris plc has been checked >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>> for viruses >> >>>>>> >> >>>>>> >> >>>>>>>>>>>>>>> http://www.charteris.com/ >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>> >> >>>>>> >> >>>> >> >>> _________________________________________________________________ >> >>> This message to Charteris plc has been checked for viruses >> >>> http://www.charteris.com/ >> >>> >> >>> _________________________________________________________________ >> >>> This message from Charteris plc has been checked for viruses >> >>> http://www.charteris.com/ >> >>> _______________________________________________ >> >>> 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. >> >>> >> >>> >> >> >> >> >> > _______________________________________________ >> > New-ITS mailing list >> > New-ITS at lists.hl7.org.uk >> > http://lists.hl7.org.uk/mailman/listinfo/new-its >> > >> >> -- >> 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 >> > >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. > > >_______________________________________________ >New-ITS mailing list >New-ITS at lists.hl7.org.uk >http://lists.hl7.org.uk/mailman/listinfo/new-its -- Melvin I REYNOLDS, ~ Setting Standards for Information, Management & Technology in Care ~ AMS Consulting ~ Ashcote ~ Walford Road ~ Ross-on-Wye ~ HR9 5PQ ~ UK email: melvinr at ams-consulting.co.uk . . . . fax: +44 (0)8700 547 303 phone: +44 (0)1989 763 120 . . . . . . mobile: +44 (0)7831 517 803 . . . . . . . VOIP - skypeID: melvinreynolds . . . . . . ----------------------------------------------------------------------- The information contained in this e-mail may be confidential and / or copyright, and intended only for named recipient(s). If you have received it indirectly or in error please do not copy, distribute, take any action on, or rely on, the content; check authority for use with postmaster at ams-consulting.co.uk From grahame at kestral.com.au Wed Aug 16 14:55:57 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 16 Aug 2006 23:55:57 +1000 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM In-Reply-To: References: Message-ID: <44E323ED.4030107@kestral.com.au> oh, btw, how about XUM? pronounced "zoom" in west country english ;-) XUM = XML UML Model Grahame Tim Benson wrote: > Grahame, > > It really does not matter what it is called as long as it is not easily > confused with another TLA. For this reason I would not suggest MMM which > will inevitably be referred to as 3M, which is a well-known trademark, with > large healthcare interests. I would also prefer not to see the word model, > unless it is a model in the UML sense of the word. > > CEN CR 12587 defined an IMS as an Implementable Message Specification, which > might be revived. > > It is always good to reuse existing terms and meanings and avoid the > temptation of neologism, otherwise known as humpty-dumptyism. > > Tim > > On 16/8/06 09:06 Grahame Grieve wrote: > >> how about MMM for Mere Mortals Model >> >> The rationale for replacing the existing XML ITS >> with a new UML ITS: >> * the xml its is broken in a couple of small places. fixing it >> won't be backwards compatible >> * the uml its will be easier to implement (we hope) >> * though it's easy to say that you can convert between the models, >> this takes time and resources, both at development and run time, >> and this will force people to choose. But there will be no choice. >> Offering 3rd party conversion tools, whether free or commercial, >> will not be a solution (might be a problem in it's own right) >> * it will be extra work to maintain 2 ITS specifications >> >> Rationale for not replacing it >> * people are already implementing XML ITS >> * we explicitly allowed for multiple ITS's. Indeed, they both >> already exist. >> >> I am not at sure which is a better approach. I believe that further >> investigation will be required, including actual implementation, >> before we get a feel for the answer. >> >> Grahame >> >> >> Charlie McCay wrote: >>> Lloyd >>> >>> I understood that IM was rejected because we already have lots of >>> Information Models. >>> >>> It is yet to be established whether the collapsed model approach, if >>> endorsed, would be an alternative to or replacement for, the current >>> ITS. There was a view expressed in INM that maintaining both may not be >>> the best way to go forwards. >>> >>> Every model is platform independent to some degree. One take on the >>> collapsing process would be to say that it was intended to generate >>> models that were appropriate for implementation using XML, and as such >>> would be platform specific. Another would be that it was to produce >>> models that were appropriate for any generic implementation technology >>> (ie an Abstract Implementation Model), in this case I would agree that >>> it would be inappropriate to say that the models were platform specific. >>> One of the issues that we need to explore is whether targeting just XML >>> for the implementation models makes a significant difference. There are >>> differing expectations as to what the outcome of that will be. >>> >>> All the best >>> >>> Charlie >>> >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>> tel 01743 232278 / 07808 570172 skype: charliemccay >>> >>> >>>> -----Original Message----- >>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>> Sent: 11 August 2006 17:17 >>>> To: Sato Laura >>>> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk >>>> Subject: Re: [New-ITS] Name for a >>>> flattened,association-collapsed model derived from an RMIM >>>> >>>> Hi Laura, >>>> >>>> The issue is that HL7 can be implemented in both collapsed >>>> and non-collapsed manners. The model is also platform-independent. >>>> >>>> >>>> Lloyd >>>> >>>> Sato Laura wrote: >>>>> I realise that I'm a little late into this conversation, >>>> but... what >>>>> was wrong with Implementable Model - is it the acronym, IM, >>>> that's too >>>>> like something else? What I liked about 'implementable' was that it >>>>> gave the sense of the view for which the model was designed >>>> for (i.e. >>>>> implementers). It gave a focus for what it was supposed to >>>> accomplish. >>>>> Scanning through the other terms, I don't mind >>>> Platform-Specific Model, >>>>> if that's truly what it is (is it?). Transmission Model >>>> might be okay. >>>>> Semantically Equivalent Model doesn't say anything to me >>>> about what it's >>>>> for, so I'm not crazy about this one. >>>>> >>>>> Just my 2p... >>>>> >>>>> Regards, >>>>> Laura >>>>> _________________________ >>>>> Laura Sato >>>>> Informatics Standards Lead >>>>> >>>>> Communications & Messaging >>>>> NHS Connecting for Health >>>>> Mobile: (44) (0)7733 324 338 >>>>> Email: laura.sato at cfh.nhs.uk >>>>> www.connectingforhealth.nhs.uk >>>>> >>>>> -----Original Message----- >>>>> From: new-its-bounces at lists.hl7.org.uk >>>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden >>>>> Sent: 10 August 2006 18:18 >>>>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie >>>>> Cc: new-its at lists.hl7.org.uk >>>>> Subject: [New-ITS] Name for a flattened,association-collapsed model >>>>> derived from an RMIM >>>>> >>>>> Not sure about 'optimised' because: >>>>> >>>>> - Optimised implies the best in some sense; but it may not >>>> yet be the >>>>> best, just better >>>>> - The acronym 'OM' somehow is not very snappy - hard to >>>> read as a word >>>>> (or a bit Buddhist?). >>>>> >>>>> I have two other suggestions: >>>>> >>>>> - Transmission Model, or TM (still a bit Buddhist?) >>>>> - Semantically Equivalent Model, or SEM >>>>> >>>>> I like the last because it tells people we are not messing with RIM >>>>> semantics. >>>>> >>>>> Anyway, the acronym is now a variable in the tools, and I >>>> can change it >>>>> daily. We could put it to a vote at the WGM. >>>>> >>>>> Robert >>>>> >>>>> Charteris plc, Charteris House, 39/40 Bartholomew Close, London >>>>> EC1A 7JN >>>>> >>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>> mobile: 44 7970 >>>>> 197968 >>>>> >>>>> *************************** E-mail confidentiality notice >>>>> ******************************* >>>>> >>>>> This message is intended for the addressee only. It is private, >>>>> confidential and may contain >>>>> information of a proprietary nature. If you have received >>>> this message >>>>> in error, please notify >>>>> us and remove it from your system. >>>>> >>>>> -----Original Message----- >>>>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] >>>>> Sent: 09 August 2006 17:44 >>>>> To: Lloyd McKenzie >>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>> Subject: RE: Steering RMIM reshaping >>>>> >>>>> Well -- we were trying to avoid C words -- so "optimized" >>>> seems the best >>>>> offering so far >>>>> All the best >>>>> Charlie >>>>> >>>>> >>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>> >>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>> Sent: 09 August 2006 17:08 >>>>>> To: Charlie McCay >>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>> Subject: Re: Steering RMIM reshaping >>>>>> >>>>>> Hi Charlie, >>>>>> >>>>>> Calling it a "practical" model sends the wrong message about >>>>>> the existing structure. Executable model suggests that it's >>>>>> an internal object model, which it isn't. >>>>>> >>>>>> What this is is a "collapsed" or "compressed" or "optimized" >>>>>> or some other transformation type word. >>>>>> >>>>>> >>>>>> Lloyd >>>>>> >>>>>> Charlie McCay wrote: >>>>>> >>>>>>> So how about practical model or exchange model or executable model >>>>>>> >>>>>>> >>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>> >>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>> Sent: 09 August 2006 16:22 >>>>>>>> To: Charlie McCay >>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>> >>>>>>>> Hi Charlie, >>>>>>>> >>>>>>>> The challenge is that many will read "physical model" in its >>>>>>>> usual sense, which is persistence model, which we definitely >>>>>>>> shouldn't be suggesting, let alone imposing. >>>>>>>> >>>>>>>> >>>>>>>> Lloyd >>>>>>>> >>>>>>>> Charlie McCay wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> Why not? -- the intent is to provide the model for the physical >>>>>>>>> exchange (subject to ITS realisation, but that is the >>>>>>>>> >>>>>>>>> >>>>>>>> model-reality >>>>>>>> >>>>>>>> >>>>>>>>> mapping) -- it is this practical model that is exactly what >>>>>>>>> >>>>>>>>> >>>>>>>> we do want >>>>>>>> >>>>>>>> >>>>>>>>> from HL7, and that we have been using the logical >>>>>>>>> >>>>>>>>> >>>>>>>> information model >>>>>>>> >>>>>>>> >>>>>>>>> as a proxy for until now >>>>>>>>> >>>>>>>>> Alternative that I do not like as much: >>>>>>>>> >>>>>>>>> EM exchange model / executable model >>>>>>>>> >>>>>>>>> charlie >>>>>>>>> >>>>>>>>> >>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>> >>>>>> Ltd, 23D >>>>>> >>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>> >>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>> Sent: 09 August 2006 16:02 >>>>>>>>>> To: Charlie McCay >>>>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>> >>>>>>>>>> Hi Charlie, >>>>>>>>>> >>>>>>>>>> I don't want to imply that HL7 defines actual physical >>>>>>>>>> >>>>>> models . . . >>>>>> >>>>>>>>>> Lloyd >>>>>>>>>> >>>>>>>>>> Charlie McCay wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> How about >>>>>>>>>>> >>>>>>>>>>> PM -- Physical/(?Practical?) Model ? >>>>>>>>>>> PM / PSM (Platform model (Platform Specific Model) >>>>>>>>>>> >>>>>>>>>>> All the best >>>>>>>>>>> >>>>>>>>>>> Charlie >>>>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> Ltd, 23D >>>>>>>> >>>>>>>> >>>>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>>>> >>>>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>>>> Sent: 08 August 2006 05:45 >>>>>>>>>>>> To: grahame at jivamedical.com >>>>>>>>>>>> Cc: Robert Worden; Charlie McCay >>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>> >>>>>>>>>>>> Except CM is used for CMET. Not sure we need a different >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> id if the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> models are just transforms of each other. >>>>>>>>>>>> >>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> CM = collapsed model or computable model >>>>>>>>>>>>> >>>>>>>>>>>>> we could go with that >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Lloyd McKenzie wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> We can't use the word "Message" because we'll presumably >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> be using >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> this stuff for documents too. How about just >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> "collapsed model", >>>>>>>> >>>>>>>> >>>>>>>>>>>>> seeing as that's what it is . . . >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> we've been using the term implementable model. IM, >>>>>>>>>>>>> >>>>>> I know.... >>>>>> >>>>>>>>>>>>> maybe you could go for "message design"? it's not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> strictly a model, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> so we can get away from the "M" part and reduce confusion? >>>>>>>>>>>>> >>>>>>>>>>>>> cc: Charlie for an opinion >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame - >>>>>>>>>>>>> >>>>>>>>>>>>> I agree that DAM is not the right name, and will tend >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> to confuse >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> people; we are making something strictly derived from >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> the RMIM and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> suitable for implementation, which may have DAM-like >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> names and >>>>>>>> >>>>>>>> >>>>>>>>>>>>> structure. >>>>>>>>>>>>> >>>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> calling it a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> RMIM'. Any suggestions? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> Implementation >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> Model? >>>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. >>>>>>>>>>>>> >>>>>>>>>>>>> Give me an acronym and I will do a global edit... >>>>>>>>>>>>> >>>>>>>>>>>>> Robert >>>>>>>>>>>>> >>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Close, London >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>> >>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 197968 >>>>>>>>>>>>> >>>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>>> ******************************* >>>>>>>>>>>>> >>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> private, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> proprietary nature. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> notify us and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> Behalf Of >>>>>>>> >>>>>>>> >>>>>>>>>>>>> Grahame Grieve >>>>>>>>>>>>> Sent: 07 August 2006 22:18 >>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>> Cc: Lloyd McKenzie >>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>> >>>>>>>>>>>>> I'm way behind on email. but spotted this. >>>>>>>>>>>>> >>>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> correlation >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> between what we are trying to achieve and a real DAM. >>>>>>>>>>>>> >>>>>>>>>>>>> What we want is to do implementation modelling on >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> the RMIM. We >>>>>>>> >>>>>>>> >>>>>>>>>>>>> recognise - particularly after talking to Simon Withey >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> last week - >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> that this has nothing to do with the DAM process, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> except for the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> naming question. >>>>>>>>>>>>> (Where by names in the instance should allow >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> identification back >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> against the DAM, rather than against the RIM. Except >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> unless you are >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> concerned about naming stability, but that's a much >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> harder question >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> indeed) >>>>>>>>>>>>> >>>>>>>>>>>>> will come back to this thread later when I catch up >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Lloyd - >>>>>>>>>>>>> >>>>>>>>>>>>> I was thinking that since people should really >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> produce a DAM on >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> way >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> to their RMIM, rather than the other way round, in some >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> sense the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> a formal >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> derivation, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> it >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> may be that the route is not >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> appropriate. >>>>>>>> >>>>>>>> >>>>>>>>>>>>> What then is the approved mechanism for adding >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> annotations to a MIF? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I'm >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> sure I could find it in the schemas, but it's easier to >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> ask you... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> :-) >>>>>>>>>>>>> >>>>>>>>>>>>> Robert >>>>>>>>>>>>> >>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Close, London >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>> >>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 197968 >>>>>>>>>>>>> >>>>>>>>>>>>> *************************** E-mail >>>> confidentiality notice >>>>>>>>>>>>> ******************************* >>>>>>>>>>>>> >>>>>>>>>>>>> This message is intended for the addressee only. It >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> is private, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> proprietary nature. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> notify us and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> 07 August >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 2006 19:43 >>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>> Cc: grahame at kestral.com.au >>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>> >>>>>>>>>>>>> Relationships between a static model and a DAM would be >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> mappings, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> not derivations. StaticModelDerivationId is not a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> spare. In the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> and HMD but >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> in theory we could derive from 20 different models. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> (And there's >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> no ordering >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> either, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> the RIM could be the first one listed or the seventh.) >>>>>>>>>>>>> >>>>>>>>>>>>> The basic question is whether you construct your >>>>>>>>>>>>> >>>>>> DAM from a >>>>>> >>>>>>>>>>>>> collapsed static model (as we do in Canada), or whether >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> you want >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> to create your DAMs and DIMs separately and map >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> them. If the >>>>>>>> >>>>>>>> >>>>>>>>>>>>> latter, I don't think >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> you >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> could do this in an automated way. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Lloyd >>>>>>>>>>>>> >>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame - >>>>>>>>>>>>> >>>>>>>>>>>>> You asked the other day for suggestions as to how >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> the current >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be >>>> steered by >>>>>>>>>>>>> annotations in the RMIM MIF, rather than by user >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> input. Here is a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> first punt to get thinking going. >>>>>>>>>>>>> >>>>>>>>>>>>> The simplest suggestion I can make is to add to the >>>>>>>>>>>>> elements another one which says >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> how this >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> RMIM >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> was >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> derived (or might have been derived) from a DAM. These >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> would look >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> like: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> >>>>>>>>>>>>> >>>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> but choose >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> one >>>>>>>>>>>>> >>>>>>>>>>>>> that is). These can go on elements for classes, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> associations, and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> properties to say in effect >>>>>>>>>>>>> >>>>>>>>>>>>> * Rename this class to a DAM class name >>>>>>>>>>>>> * Rename this association (with perhaps other >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> attributes saying >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 'collapse it' or 'leave it out') >>>>>>>>>>>>> * Rename this property to a DAM property name (or >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> some value >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> meaning 'leave it out') >>>>>>>>>>>>> >>>>>>>>>>>>> If you wanted, you would not even have to say >>>> explicitly >>>>>>>>>>>>> 'collapse an >>>>>>>>>>>>> >>>>>>>>>>>>> association' - because if the DAM class names are >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> the same on >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> either side of it, that means collapse it. >>>>>>>>>>>>> >>>>>>>>>>>>> This proposal would not yet address a combination of >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> restricting >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> and reshaping an RMIM. >>>>>>>>>>>>> >>>>>>>>>>>>> It would imply you cannot collapse across a CMET >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> boundary, which >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I gather from our discussion the other day you would >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> like to do. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Or maybe you can, by telling the association to >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> the CMET to >>>>>>>> >>>>>>>> >>>>>>>>>>>>> collapse itself? Have not thought it through yet. I >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> know there >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> are issues >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> about >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> CMETs with a choice at the top - any chance you >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> could send a >>>>>>>> >>>>>>>> >>>>>>>>>>>>> simple diagram to illustrate the problem as you see it? >>>>>>>>>>>>> >>>>>>>>>>>>> Anyway, if we come up with any scheme like the above, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> it should >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> be straightforward to implement in the tool. >>>>>>>>>>>>> >>>>>>>>>>>>> Robert >>>>>>>>>>>>> >>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Close, London >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> EC1A >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 7JN >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> 7970 197968 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> *************************** E-mail >>>> confidentiality notice >>>>>>>>>>>>> ******************************* >>>>>>>>>>>>> >>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> private, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> proprietary nature. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> If you have received this >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> message >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> in error, please notify >>>>>>>>>>>>> us and remove it from your system. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> _________________________________________________________________ >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> for viruses >>>>>>>> >>>>>>>> >>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> _________________________________________________________________ >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> This message to Charteris plc has been checked >>>>>>>>>>>>> >>>>>> for viruses >>>>>> >>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> _________________________________________________________________ >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> for viruses >>>>>>>> >>>>>>>> >>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> _________________________________________________________________ >>>>> This message to Charteris plc has been checked for viruses >>>>> http://www.charteris.com/ >>>>> >>>>> _________________________________________________________________ >>>>> This message from Charteris plc has been checked for viruses >>>>> http://www.charteris.com/ >>>>> _______________________________________________ >>>>> 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. >>>>> >>>> >>> _______________________________________________ >>> New-ITS mailing list >>> New-ITS at lists.hl7.org.uk >>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>> > > > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From Laura.Sato at cfh.nhs.uk Wed Aug 16 15:38:14 2006 From: Laura.Sato at cfh.nhs.uk (Sato Laura) Date: Wed, 16 Aug 2006 15:38:14 +0100 Subject: [New-ITS] updates on semantic processing Message-ID: <1A3D105C334EAE49BDDD93D8767573F5042557AA@EXCHAQ2.nhsia.nhs.uk> Updates have been made to this wiki page - http://b2international.com/umlits/index.php/What_semantic_processing_is_ currently_done_in_existing_or_planned_in_near_future_applications%3F (wiki / wikiwiki) Best regards, Laura _________________________ Laura Sato Informatics Standards Lead Communications & Messaging NHS Connecting for Health Mobile: (44) (0)7733 324 338 Email: laura.sato at cfh.nhs.uk www.connectingforhealth.nhs.uk 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060816/907a082a/attachment.htm From ann.wrightson at bt.com Wed Aug 16 16:31:39 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Wed, 16 Aug 2006 16:31:39 +0100 Subject: [New-ITS] XML design principles Message-ID: <849288029444F74899F8C8E3D479FF6DDBCA1F@E03MVZ3-UKDY.domain1.systemhost.net> Thomas, Apologies for the delay in replying, I'm only just returned from leave. XML that at least some humans need to read (see my semantic processing contribution on the wiki for a real context) needs to be readable for the same reasons that terminologies need to have well-crafted linguistic expressions as well as formal identifiers of terms. In particular, users of terminologies, including information systems developers and integrators, are less likely to make mistakes concerning terminology usage and processing when the linguistic expressions of terms are well designed. Similarly, users of XML, including in particular information systems developers and integrators, are less likely to make mistakes concerning XML based processing when the XML is easy for a human to understand. In my experience XML that is designed for machines to read is indeed very difficult for humans, however it is also possible to design XML with the needs of legitimate human readers such as developers and system integrators in mind. To me this is (cognitive) ergonomics rather than aesthetics; just "looking nice" does not carry any weight with me either. I agree with you about the (relative lack of) readability of XSD and OWL, however this is a criticism of the design of XSD and OWL, not XML itself. Thanks for the pointer to dADL. Ann W. PS There is a principled analysis of human-readability of XML instances in the section called "Why is some XML so difficult to read?" in a paper I presented last year, see http://www.idealliance.org/papers/extreme/proceedings/html/2005/Wrightso n01/EML2005Wrightson01-toc.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060816/aed38fe4/attachment.htm From Charlie at ramseysystems.co.uk Wed Aug 16 17:09:43 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Wed, 16 Aug 2006 17:09:43 +0100 Subject: [New-ITS] Data Types Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FC2A@ramseysc1420.RamseyNet.local> Grahame The datatypes look good -- some initial (albeit slow) reaction 2 Conformance To conform to the specification applications must be able to appropriately produce and consume instances that conform to the schemas. To support conformance testing it may make sense to produce a test collection of instances that exercise some of these. In the past HL7 has not done this, but since conformance testing is a vital interest for HL7 users maybe it is something that should be done. 3.1 Null flavor There is a typo with QS and QC being mentioned, and I suspect that only one is needed (QS) - but since neither are in the normative edition I am not sure which I like the dropping of OTH (Other), and dealing with this in the coded types I can see that TRC and QS belong to QTY I do not see that PINF and NINF do -- these are values of the number, not of a measurement-- or is the argument that the only place where they make sense is in a measurement? 3.5 There are candidate descriptions for some IdentifierUse codes on the wiki at http://informatics.mayo.edu/wiki/index.php/Types_of_Identifiers 6.1.1 ANY HXIT -- HDF appendix A as distributed in the May ballot is about the HL7 UML profile, and does not describe audit. Where can the referenced version be found? 6.2.1 HXIT Second para "any" should be ANY 7.3.1 ED -- OpenEHR mapping UsagePeriod cannot be dropped as it may contain important information (like how long a reference will be available). I assume that this would have to be moved into the archetype during the mapping process 11.4.1 RTO This must be derived from QTY in the abstract so that it can get all the derivative properties (such as isZero, and GreaterThan etc which are relevant to Ratio (though one could argue not). The only reason for having QTY in the ITS was if it was needed to carry PINF and NINF. 13.3 GTS Seems to be a choice between sequences of intervals, or GTS expressed as a literal. Not clear why the XML/UML expression does not include the equivalent of SXCM to give the operator. If having the full GTS grammar in XML/UML was seen as too verbose/complex then will having it in a GTS literal be any easier. Also having two expressions means that implementations must support both literal and (item,period,event). It seems to me that you want a new datatype of STS (simpler timing specification) that just does (item*, period*,event*), and then full GTS can be expressed as a literal only. I do not know if STS would be usable to replace GTS in enough places to make this worthwhile. All the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay > -----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: 31 July 2006 12:30 > To: new-its at lists.hl7.org.uk > Subject: [New-ITS] Data Types > > Attached is a draft version of the Implementable Model for > Data types. Other implementable models will build on this package. > > This package may grow into more than just data types. > in particular, I expect it will acquire more structural > vocabulary items as enumerations. So it may end up not being > called the data types. > > There is a number of files in this package: > + Datatypes.doc - document presentation > + datatypes.eap - enterprise architecture source for > the UML diagrams > + datatypes.ocl - an internal UML representation I use to > compile check the OCL statements. The schemas are > generated from this source. > + datatypes.xsd - a generated schema where everything is > elements. Includes a single example schematron > + datatypes-attributes.xsd - a generated schema where > OCL Primitives are XML attributes. Includes a single > example schematron > > When we pick between elements and attributes, then I will > fill out the schematron assertions. I expect to have a > matching schematron assertion for every OCL constraint, > though some of them will be fairly difficult. > > Schematron experts: is there a way to do defines like the OCL does? > > Relax NG experts: I imagine it will also be easy to code > generate a Relax NG schema - if someone lays out the general > shape of it for ANY, QTY, TS, SET and IVL I could code > generate that too. > > comments are very welcome. Things you might want to check: > * current state of play in nullFlavors - I am still thinking about > how to rationalise them further. > * how ED works - no inline XML in this model. > * how GTS works - I don't know whether I've made things more > difficult or not.... > > Grahame > > > > From grahame at kestral.com.au Wed Aug 16 22:20:47 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Thu, 17 Aug 2006 07:20:47 +1000 Subject: [New-ITS] Data Types In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A04FC2A@ramseysc1420.RamseyNet.local> References: <7A55F2E13F53E749A4C13A8E53B7424A04FC2A@ramseysc1420.RamseyNet.local> Message-ID: <44E38C2F.7040702@kestral.com.au> > 2 Conformance > To conform to the specification applications must be able to > appropriately produce and consume instances that conform to the schemas. > > To support conformance testing it may make sense to produce a test > collection of instances that exercise some of these. In the past HL7 > has not done this, but since conformance testing is a vital interest for > HL7 users maybe it is something that should be done. yes, that was a placeholder. But if you provided samples - what, as an adjunct? - then what would you say? > 3.1 > Null flavor > There is a typo with QS and QC being mentioned, and I suspect that only > one is needed (QS) - but since neither are in the normative edition I am > not sure which > I like the dropping of OTH (Other), and dealing with this in the coded > types > I can see that TRC and QS belong to QTY > I do not see that PINF and NINF do -- these are values of the number, > not of a measurement-- or is the argument that the only place where they > make sense is in a measurement? agree they are properties of a number. But when do they arise in clinical medicine? As far as I can tell, they are there to model intervals. We say that >5 is 5 -> +infinity. This seems clumsy, especially since this nullFlavor has significance. I propose now to toast PINF and NINF altogether and have a bounded property on an interval actually TRC and QS belong to PQ - they are both related to the concept of measurement. > 3.5 > There are candidate descriptions for some IdentifierUse codes on the > wiki at http://informatics.mayo.edu/wiki/index.php/Types_of_Identifiers see also http://informatics.mayo.edu/wiki/index.php/Datatypes_R2_Issue_57 I have linked the pages > 6.1.1 ANY > HXIT -- HDF appendix A as distributed in the May ballot is about the HL7 > UML profile, and does not describe audit. Where can the referenced > version be found? October 2006. MnM are at least consistent. Have asked mnm > 6.2.1 HXIT > Second para "any" should be ANY thanks > 7.3.1 ED -- OpenEHR mapping > UsagePeriod cannot be dropped as it may contain important information > (like how long a reference will be available). I assume that this would > have to be moved into the archetype during the mapping process how important is this? Since the URL cannot be reused, it's useful but not exactly important. Have you seen it used in practice? If OpenEHR doesn't model the concept, why would you try to force it into an archetype? > 11.4.1 RTO > This must be derived from QTY in the abstract so that it can get all the > derivative properties (such as isZero, and GreaterThan etc which are > relevant to Ratio (though one could argue not). The only reason for > having QTY in the ITS was if it was needed to carry PINF and NINF. it would be wrong for RTO to carry PINF or NINF. The only circumstance where this could happen would be where the denominator was 0, and this is explicity prevented. So the numerator can carry it. But it doesn't arise anyway, since we ban NINF and PINF > > 13.3 GTS > Seems to be a choice between sequences of intervals, or GTS expressed as > a literal. Not clear why the XML/UML expression does not include the > equivalent of SXCM to give the operator. If having the full GTS grammar > in XML/UML was seen as too verbose/complex then will having it in a GTS > literal be any easier. Also having two expressions means that > implementations must support both literal and (item,period,event). > It seems to me that you want a new datatype of STS (simpler timing > specification) that just does (item*, period*,event*), and then full GTS > can be expressed as a literal only. I do not know if STS would be > usable to replace GTS in enough places to make this worthwhile. why is SXCM useful? How could you decide to use STS instead of GTS? no comment about ED & in-line XML? Grahame From Charlie at ramseysystems.co.uk Thu Aug 17 13:16:58 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Thu, 17 Aug 2006 13:16:58 +0100 Subject: [New-ITS] Data Types Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FC2E@ramseysc1420.RamseyNet.local> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of > Grahame Grieve > Sent: 16 August 2006 22:21 > To: Charlie McCay > Cc: grahame at jivamedical.com; new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Data Types > > > 2 Conformance > > To conform to the specification applications must be able to > > appropriately produce and consume instances that conform to > the schemas. > > > > To support conformance testing it may make sense to produce a test > > collection of instances that exercise some of these. In > the past HL7 > > has not done this, but since conformance testing is a vital > interest > > for > > HL7 users maybe it is something that should be done. > > yes, that was a placeholder. But if you provided samples - > what, as an adjunct? - then what would you say? Bigger topic than this email -- but happy there is a placeholder > > > 3.1 > > Null flavor > > There is a typo with QS and QC being mentioned, and I suspect that > > only one is needed (QS) - but since neither are in the normative > > edition I am not sure which I like the dropping of OTH (Other), and > > dealing with this in the coded types I can see that TRC and > QS belong > > to QTY I do not see that PINF and NINF do -- these are > values of the > > number, not of a measurement-- or is the argument that the > only place > > where they make sense is in a measurement? > > agree they are properties of a number. But when do they arise > in clinical medicine? As far as I can tell, they are there to > model intervals. We say that >5 is 5 -> +infinity. This seems > clumsy, especially since this nullFlavor has significance. I > propose now to toast PINF and NINF altogether and have a > bounded property on an interval Ok -- unless there are use cases I agree > > actually TRC and QS belong to PQ - they are both related to > the concept of measurement. Ok (I agreed before, just typed wrong) > > > 3.5 > > There are candidate descriptions for some IdentifierUse > codes on the > > wiki at > > http://informatics.mayo.edu/wiki/index.php/Types_of_Identifiers > > see also > http://informatics.mayo.edu/wiki/index.php/Datatypes_R2_Issue_57 > I have linked the pages > > > 6.1.1 ANY > > HXIT -- HDF appendix A as distributed in the May ballot is > about the > > HL7 UML profile, and does not describe audit. Where can the > > referenced version be found? > > October 2006. MnM are at least consistent. Have asked mnm You are getting ahead of yourself -- surely oct2005 > > > 6.2.1 HXIT > > Second para "any" should be ANY > > thanks > > > 7.3.1 ED -- OpenEHR mapping > > UsagePeriod cannot be dropped as it may contain important > information > > (like how long a reference will be available). I assume that this > > would have to be moved into the archetype during the mapping process > > how important is this? Since the URL cannot be reused, it's > useful but not exactly important. Have you seen it used in > practice? If OpenEHR doesn't model the concept, why would you > try to force it into an archetype? It is one of the options for conveying attachments -- to say that the image or whatever is available at a URI for a limited time -- I have not seen this used in practice, but have heard folk say that it could be useful. If it is dropped, then I suggest that implementation guidance should be provided as to how projects where it is populated should behave. Alternatively it should be dropped from HL7 on the basis that having been there for a while, no-one has used it, and any conceivable use case could be addressed by contractual agreement (which would be needed anyway to ensure that appropriate behaviour happened when a URI that was needed went out of date). The recommendation in the wrappers document was that the business ack should only be sent when all needed URIs had been dereferenced (where they were not persistent). There is still the issue of how the receiver knows that they are dealing with a persistent URI or not -- on balance I think that this is something that should be in openEHR > > > 11.4.1 RTO > > This must be derived from QTY in the abstract so that it > can get all > > the derivative properties (such as isZero, and GreaterThan > etc which > > are relevant to Ratio (though one could argue not). The > only reason > > for having QTY in the ITS was if it was needed to carry > PINF and NINF. > > it would be wrong for RTO to carry PINF or NINF. The only > circumstance where this could happen would be where the > denominator was 0, and this is explicity prevented. So the > numerator can carry it. But it doesn't arise anyway, since we > ban NINF and PINF > Ok > > > > 13.3 GTS > > Seems to be a choice between sequences of intervals, or GTS > expressed > > as a literal. Not clear why the XML/UML expression does > not include > > the equivalent of SXCM to give the operator. If having the > full GTS > > grammar in XML/UML was seen as too verbose/complex then > will having it > > in a GTS literal be any easier. Also having two expressions means > > that implementations must support both literal and > (item,period,event). > > It seems to me that you want a new datatype of STS (simpler timing > > specification) that just does (item*, period*,event*), and > then full > > GTS can be expressed as a literal only. I do not know if > STS would be > > usable to replace GTS in enough places to make this worthwhile. > > why is SXCM useful? It provides the set operator, allowing expressions such as "every Tuesday this year except in August". With it you have an XML grammer for GTS, and so do not need the literal form at all, without it you have a literal expression for everything, and an XML expression for the most common structures. One alternative that you have not taken up is the inclusion of originalText in GTS [1] - though maybe it should be text as an alternative rather than alongside the literal or XML expression. > How could you decide to use STS instead of GTS? So leave it to the sender to decide? -- when would the literal in this specification be used? Is it really useful to have an XML and a string-literal representation available in the specification. Maybe the decision should be made at the project level, with a datatype flavor of "just literal" and another of "structured interval" > > > no comment about ED & in-line XML? Ok -- you have data.data and st.value -- both will result in an extra level of nesting in the XML that is not nice, so why give them different names -- or is there something in the serialisation rules that says that value becomes the element content? I like having data as a separate element for ED, but not having value as an element in ST On a similar line I like that address type requiring address part elements for everything - however it does not really address the problem of having the structured and unstructured representation of the address overlapping -- in the CEN address datatypes you could send a structured address and the rendering of that as separate components, so that any truncating to fit the lines of the rendering did not affect the structured expression (that probably came from a postcode lookup). > > Grahame > > [1] http://informatics.mayo.edu/wiki/index.php/Datatypes_R2_Issue_13 From Thomas.Beale at OceanInformatics.biz Thu Aug 17 18:11:40 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Thu, 17 Aug 2006 18:11:40 +0100 Subject: [New-ITS] Data Types In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A04FC2E@ramseysc1420.RamseyNet.local> References: <7A55F2E13F53E749A4C13A8E53B7424A04FC2E@ramseysc1420.RamseyNet.local> Message-ID: <44E4A34C.8000703@OceanInformatics.biz> Charlie McCay wrote: > > >> agree they are properties of a number. But when do they arise >> in clinical medicine? As far as I can tell, they are there to >> model intervals. We say that >5 is 5 -> +infinity. This seems >> clumsy, especially since this nullFlavor has significance. I >> propose now to toast PINF and NINF altogether and have a >> bounded property on an interval >> which is what is done in openEHR as well, just as a point of reference. > > > >>> 7.3.1 ED -- OpenEHR mapping >>> UsagePeriod cannot be dropped as it may contain important >>> >> information >> >>> (like how long a reference will be available). I assume that this >>> would have to be moved into the archetype during the mapping process >>> >> how important is this? Since the URL cannot be reused, it's >> useful but not exactly important. Have you seen it used in >> practice? If OpenEHR doesn't model the concept, why would you >> try to force it into an archetype? >> > > It is one of the options for conveying attachments -- to say that the > image or whatever is available at a URI for a limited time -- I have not > seen this used in practice, but have heard folk say that it could be > useful. If it is dropped, then I suggest that implementation guidance > should be provided as to how projects where it is populated should > behave. Alternatively it should be dropped from HL7 on the basis that > having been there for a while, no-one has used it, and any conceivable > use case could be addressed by contractual agreement (which would be > needed anyway to ensure that appropriate behaviour happened when a URI > that was needed went out of date). The recommendation in the wrappers > document was that the business ack should only be sent when all needed > URIs had been dereferenced (where they were not persistent). There is > still the issue of how the receiver knows that they are dealing with a > persistent URI or not -- on balance I think that this is something that > should be in openEHR > I agree that there could be a need to say when a URL might be valid (in the future), but I don't think this is part of the URI model itself - it is likely to be highly contextual, since you could just as easily have no need to say such a thing. On the other hand, saying when when it _was_ valid (in the past), e.g. as is done in citations in papers, is something I had not thought of modelling, but could in theory always be a valid thing to say. If everyone agreed that all models of URI should have that, I would probably raise the CR in openEHR. re: GTS, sending in GTS syntax string format has to be better doesn' t it - it means the attribute is just a String and it allows the syntax definition to evolve (as long as it is backward compatible) without breaking the data, and possibly not harming older software too much. - thomas beale From Thomas.Beale at OceanInformatics.biz Thu Aug 17 21:38:42 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Thu, 17 Aug 2006 21:38:42 +0100 Subject: [New-ITS] XML design principles In-Reply-To: <849288029444F74899F8C8E3D479FF6DDBCA1F@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DDBCA1F@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44E4D3D2.90103@OceanInformatics.biz> An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060817/28c866cb/attachment.htm From ann.wrightson at bt.com Fri Aug 18 16:53:31 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Fri, 18 Aug 2006 16:53:31 +0100 Subject: [New-ITS] XML design principles References: <849288029444F74899F8C8E3D479FF6DDBCA1F@E03MVZ3-UKDY.domain1.systemhost.net> <44E4D3D2.90103@OceanInformatics.biz> Message-ID: <849288029444F74899F8C8E3D479FF6D529164@E03MVZ3-UKDY.domain1.systemhost.net> Thomas, Regarding llinguistic parseability, you may also be interested in the paper by Yves Marcoux at http://www.idealliance.org/papers/extreme/proceedings/html/2006/Marcoux01/EML2006Marcoux01.html Ann W. ________________________________ From: Thomas Beale [mailto:Thomas.Beale at OceanInformatics.biz] Sent: Thu 17/08/2006 21:38 To: Wrightson,A,Ann,JPGA8Y C Cc: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] XML design principles ann.wrightson at bt.com wrote: Thomas, Apologies for the delay in replying, I'm only just returned from leave. XML that at least some humans need to read (see my semantic processing contribution on the wiki for a real context) needs to be readable for the same reasons that terminologies need to have well-crafted linguistic expressions as well as formal identifiers of terms. In particular, users of terminologies, including information systems developers and integrators, are less likely to make mistakes concerning terminology usage and processing when the linguistic expressions of terms are well designed. Similarly, users of XML, including in particular information systems developers and integrators, are less likely to make mistakes concerning XML based processing when the XML is easy for a human to understand. In my experience XML that is designed for machines to read is indeed very difficult for humans, however it is also possible to design XML with the needs of legitimate human readers such as developers and system integrators in mind. To me this is (cognitive) ergonomics rather than aesthetics; just "looking nice" does not carry any weight with me either. I agree with you about the (relative lack of) readability of XSD and OWL, however this is a criticism of the design of XSD and OWL, not XML itself. Thanks for the pointer to dADL. Ann W. PS There is a principled analysis of human-readability of XML instances in the section called "Why is some XML so difficult to read?" in a paper I presented last year, see http://www.idealliance.org/papers/extreme/proceedings/html/2005/Wrightson01/EML2005Wrightson01-toc.html this looks very interesting - I will read it. Just noting an example from the first page: Jones John Male 9900112233 difficulty getting to sleep normal This is probably about as "easy-to-read" as XML ever gets, but to me it is still close to illegible, and that is because it doesn't parse - all the double tags in XML do two bad things: 1) they obscure the data with the labels to the data and b) they prevent it being read in a normal way. In dADL this would be: TeleMed = < Patient = < Surname = <"Jones"> Forename = <"John"> Gender = <"Male"> Identifier = <"9900112233"> > Result = < Time = < > SleepPattern = < code = <[401161007]> value = <"difficulty in getting to sleep"> > GlucoseTest = < code = <[401161007]> value = <"normal"> > > > Readable because it is half the size, and parses linguistically. This is just for academic interest of course - and unlikely to be of interest here! - thomas beale -- ___________________________________________________________________________________ CTO Ocean Informatics (http://www.OceanInformatics.biz) Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org) From grahame at kestral.com.au Sun Aug 20 02:27:10 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Sun, 20 Aug 2006 11:27:10 +1000 Subject: [New-ITS] Data Types In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A04FC2E@ramseysc1420.RamseyNet.local> References: <7A55F2E13F53E749A4C13A8E53B7424A04FC2E@ramseysc1420.RamseyNet.local> Message-ID: <44E7BA6E.1030704@kestral.com.au> >>> HL7 UML profile, and does not describe audit. Where can the >>> referenced version be found? >> October 2006. MnM are at least consistent. Have asked mnm > > You are getting ahead of yourself -- surely oct2005 ah, yes. >>> UsagePeriod cannot be dropped as it may contain important >> information >>> (like how long a reference will be available). I assume that this >>> would have to be moved into the archetype during the mapping process >> how important is this? Since the URL cannot be reused, it's >> useful but not exactly important. Have you seen it used in >> practice? If OpenEHR doesn't model the concept, why would you >> try to force it into an archetype? > > It is one of the options for conveying attachments -- to say that the > image or whatever is available at a URI for a limited time -- I have not > seen this used in practice, but have heard folk say that it could be > useful. If it is dropped, then I suggest that implementation guidance > should be provided as to how projects where it is populated should > behave. Alternatively it should be dropped from HL7 on the basis that > having been there for a while, no-one has used it, and any conceivable > use case could be addressed by contractual agreement (which would be > needed anyway to ensure that appropriate behaviour happened when a URI > that was needed went out of date). The recommendation in the wrappers > document was that the business ack should only be sent when all needed > URIs had been dereferenced (where they were not persistent). There is > still the issue of how the receiver knows that they are dealing with a > persistent URI or not -- on balance I think that this is something that > should be in openEHR note that I have not dropped it from the ITS, only noted that there is no place to map it. I don't think it's a great loss, since there's a rule that the url can never mean anything else. This kind of stuff is better managed as part of profiles and contracts. >> why is SXCM useful? > It provides the set operator, allowing expressions such as "every > Tuesday this year except in August". With it you have an XML grammer > for GTS, and so do not need the literal form at all, without it you have > a literal expression for everything, and an XML expression for the most > common structures. > > One alternative that you have not taken up is the inclusion of > originalText in GTS [1] - though maybe it should be text as an > alternative rather than alongside the literal or XML expression. well, I'm open to options on GTS. I haven't put originalText anywhere actually. I guess I should remove all the R2 things to be consistent >> no comment about ED & in-line XML? > Ok -- you have data.data and st.value -- both will result in an extra > level of nesting in the XML that is not nice, so why give them different > names -- or is there something in the serialisation rules that says that > value becomes the element content? I probably should make data.data to data.value for consistency > I like having data as a separate element for ED, but not having value as > an element in ST I don't like the idea that value becomes element content. It has a number of negative consequences for automatic processing of XML, and, so far as I can tell, only cosmetic advantages in the XML. > On a similar line I like that address type requiring address part > elements for everything - however it does not really address the problem > of having the structured and unstructured representation of the address > overlapping -- in the CEN address datatypes you could send a structured > address and the rendering of that as separate components, so that any > truncating to fit the lines of the rendering did not affect the > structured expression (that probably came from a postcode lookup). I think that this would require changes to the abstract. But I'll have another look Grahame From grahame at kestral.com.au Mon Aug 21 14:44:03 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 21 Aug 2006 23:44:03 +1000 Subject: [New-ITS] new its & related work: proposals for HL7 meeting Message-ID: <44E9B8A3.2010205@kestral.com.au> hi all Ok, I wish to propose a way forwards for this work, and specifically, what I think we should take to HL7 at Boca Raton. Apologies because I know that not everyone has seen all this stuff. glossary RBM - Rim Based Model Findings from investigation =========================== 1. Use of domain analysis models We find that the domain analysis models are - and should be - focused on domain analysis modeling. They may have constructs more suited to implementation concerns than the RBMs, but they might not either. The most useful thing that they contain is domain specific names for domain specific concepts that are lost in the RBM's. We firmly believe that these names are important, and that they should be carried into the process beyond domain analysis modelling. There is other more useful ways to introduce these names than mapping to the domain models. Nevertheless, mapping to domain analysis models and requirements analysis is a useful exercise in it's own right and the new eclipse RBM designer should include support for this. 2. Implementation Considerations We find that most implementers judge HL7 V3 purely on the strength of their implementation experience with the wire format. There is a wide variety of implementation paths, but few are prepared to make the kind of investment in basic V3 infrastructure that the javaSIG makes. Implementers mostly use the schema as a basis for their implementation, either directly or indirectly. There is a number of key problems: * that the XML is more deeply folded than the real world problems call for. Each element carries implicit and explicit processing requirements * the schemas do not support code generation well, and particularly reusability of the generated code. * The transformation from the real world problem to the instance is too hard to trace * Some specific implementation concerns such as reuse of parts of instances and easy to find and understand constraints on data type properties are not catered for We note that all of these have their roots in the way that the whole HL7 development process works, but there is a number of small things that we can do to palliate these concerns, and these things will most probably be acceptable to HL7 in the short term. These things form our short term strategy (see below). There will be other things that we propose in the long term (also see below). 3. Removal of fixed values We note that a significant portion of the message size is fixed values. Removing the fixed values will significantly reduce the message size (and "ugliness", though this is a nebulous concept). But the consequence of this is that you must consult the message definition to understand the messaging, and not all the implementers in UK are doing this or are even happy to wear the performance consequences of doing this. Should the fixed values be removed, then some other approach - perhaps based around name stability - needs to be found to allow for such generic processing (or sometimes known as semantic processing). We note that the relevance of such generic processing depends on the domain - in some highly transactional domains such as choose and book the concept of generic processing doesn't really apply, where as for clinical content, it is much more likely to apply. Some specific observations: - the longer a period of time data will persist for, the more likely semantic processing will be used - but this is out of scope for hl7 as an interchange format - the division isn't by message type - it's by the domain of the content. it would [probably] be wrong for clinical content in choose and book to be represented differently simply because choose and book messages are more transactional in nature. - there is no hard and fast division- generic and specific processing can be done on any content and there is a wide grey band in the middle. We still don't know whether we have to choose here, or if we have to choose, what to choose. Note: it's likely that semantic based processing would be better suited by simply serialising the RIM or the clinical statement and treating all the other models as templates on this. We are still giving this question further consideration. 4. CEN & HL7 harmonisation We find that broadly speaking, there is 3 areas of the model development process where CEN and HL7 are perceived to differ: * Reference Model * Constraint mechanisms * Wire format With regards to the reference model, we note that CEN are examining the UML ITS datatypes with regard to their suitability as a CEN standard in place of the currently proposed CEN data types. We also note that there is strong similarities between the CEN reference model and the HL7 clinical statement pattern. However we note that within this scope, there is also subtle but significant differences which lead to different implicit transformations of real world problems to the models, and these may make further alignment very difficult. Further investigation is needed. With regards to the Constraint mechanisms, we note that RBMs and Archetypes are the same beast. Though they present differently, the bulk of their content can be automatically converted from one form to the other. Small enhancements in each format could be proposed which would make the interconversion even easier. The new RBM designer could not only interconvert between the 2 formats, it can present both simultaneously much like an XML and a tree view in an XML editor. (note: Archetypes are reference model independent, and RMIM's could be made so. This equivalence does not involve changing reference models, but of converting from an RIM based Visio-like diagram to an RIM based ADL statement, or from a CEN RM based ADL to a CEN RM based visio-like diagram) [wire format still to be investigated]. This is the results of our findings. It leads to a number of recommendations, some of which are ITS specific, and some are proposed changes to the modeling methodology. Short Term changes - presented in detail at Boca Raton ====================================================== 1. UML ITS We will propose a new UML ITS. The UML ITS will be based on the following principles: * a UML Model and a schema will be produced from each RBM. these models will be known as the "XUM" (for XML & UML Model). * The "XUM" will be normative. We do not claim that these are the only schemas or UML diagrams that could describe the wire format, but that these are ones that will always be correct * The UML Model and the schema will be isomorphic as much as possible * The XUM will focus on a simple statement of the structure. More advanced validation concepts will be in OCL/Schematron statements. Full validation could only be provided by a specific software solution (as for the XML ITS) * The XUM will use a reference UML package/schema which defines common enumerations and data types. * the UML diagrams will have a secondary presentation with appropriate stereotypes to make the XML representation clear (using the XML for UML profile from http://www.xmlmodeling.com as VHA are). * the XUM will not represent any fixed or default values. These will be documented in the XUM but not part of the wire format * the XUM will collapse nested models to some degree (see further discussion below) * because there will be an XUM for every model - including the RIM itself - it will be possible to choose an XUM and serialise at any level of genericity. * XUM will not support schema or UML validation for templates. A specific software solution will be required for this. (any model will be able to be used as a template. A DIM is a template on the RIM, etc. A template is any model referenced as a constraint on the model being serialised. The template may be referenced in the instance, or in a profile - note that a profile is also a model, so it can be serialised directly) [Still to be resolved: * How do we handle model boundaries. Discussion in progress now * Should we use business names in instances. discussion to kick off shortly. * about different parts of the model being serialised at different levels. This is a core question that is related to support for semantic processing and the question of name stability otherwise] 1a. Does the New UML ITS replace the existing XML ITS We believe that it is too early to say whether this would be appropriate. We will propose that HL7 defers this decision. NHS should implement the UML ITS in practice and then take the outcomes of this back to HL7 for further consideration of whether the UML ITS should be a replacement for the XML ITS or an alternative. 2. Modifications to the RBM methodology. We propose 4 small modifications to the RBM methodology: 2.1: Business Names Most artifacts in the diagrams can be given Business names already - the MIF supports this, but support in the tooling is haphazard and the feature is rarely used. We propose explicity representing business names on the diagram. For instance, with attributes the current representation is something like name [: Type] [constraints] We could change it to business name ["name"] [:Type] [constraints] The presentation of business names on the diagrams would go a long way to help non-RIM-experienced mere mortals to navigate the RBMs. 2.2 Data Type property constraints Currently there is no support for fixing values of datatypes. As the models become more focused and less general, the importance of fixing particular values increases. Rather then using some constraint language, we will propose a syntax for making positive statements about the values of the datatype properties. The syntax will be derived from ADL as a simple intuitive way to make these constraints. 2.3 Infrastructure Root attributes Often the modeling process involves the creation of a number if RIM classes that do not have a useful real world equivalent, they are only required to meet the RIM grammar requirements. There is no useful point for these classes to carry Infrastructure root attributes such as nullFlavor. Often there is a cascade of classes where any one of them could carry a nullFlavor, but all the possible permutation of statements carries the same meaning in the domain models. We propose to introduce new flags on the RIM classes in a RBM that will mark these attributes as not appropriate for some classes, where appropriate. 2.4 We propose to introduce a flag to specify whether the class in question might be substituted by a reference to another class (and possibly what the scope of that reference might be). We can make everything referenceable in the ITS, but this is unpalatable to the implementors, we'd like to be selective about this. the new UML ITS would leverage all of these features to make the implementation process easier. Long Term changes ================= 1. Archetypes We note the relationship between archetypes and RBM's discussed above. Archetypes allow for more of the knowledge of a model to be expressed in a computational form, but do not necessarily offer a better path to implementation. We propose that HL7 investigate the use of archetypes as an alternative authoring approach for HL7 models as part of the new RBM designer. 2. Reference models - CEN & HL7 We propose to do further research ourselves (CFH) in association with the CEN/HL7 harmonisation group, and to investigate how to resolve the differences between the reference models through a combination of mapping, changes to the reference models and other techniques. We will bring our findings, and possibly change requests, forward to HL7 on an ongoing basis. 3. Implementable Models and UML We will continue to align the implementable model work with the ongoing research work with the intent that this implementation work will also form a basis for offering an implementation path for archetypes and CEN 13606 for vendors that do not wish or cannot adopt an entirely archetype based approach (we believe that for the next 1 or 2 decades this will be the bulk of healthcare application developers - if archetypes are the method of expression, then practical ways of implementing them in legacy systems must be found.) Grahame From lloyd at lmckenzie.com Wed Aug 16 15:07:19 2006 From: lloyd at lmckenzie.com (Lloyd McKenzie) Date: Wed, 16 Aug 2006 07:07:19 -0700 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM In-Reply-To: <44E323ED.4030107@kestral.com.au> References: <44E323ED.4030107@kestral.com.au> Message-ID: <44E32697.6040904@lmckenzie.com> There's nothing XML about the model. It could be used in a Java interface or anything else . . . (Though I do love the abbreviation :>) Grahame Grieve wrote: > oh, btw, how about XUM? pronounced "zoom" in west country > english ;-) > > XUM = XML UML Model > > Grahame > > > Tim Benson wrote: >> Grahame, >> >> It really does not matter what it is called as long as it is not easily >> confused with another TLA. For this reason I would not suggest MMM >> which >> will inevitably be referred to as 3M, which is a well-known >> trademark, with >> large healthcare interests. I would also prefer not to see the word >> model, >> unless it is a model in the UML sense of the word. >> >> CEN CR 12587 defined an IMS as an Implementable Message >> Specification, which >> might be revived. >> It is always good to reuse existing terms and meanings and avoid the >> temptation of neologism, otherwise known as humpty-dumptyism. >> >> Tim >> >> On 16/8/06 09:06 Grahame Grieve wrote: >> >>> how about MMM for Mere Mortals Model >>> >>> The rationale for replacing the existing XML ITS >>> with a new UML ITS: >>> * the xml its is broken in a couple of small places. fixing it >>> won't be backwards compatible >>> * the uml its will be easier to implement (we hope) >>> * though it's easy to say that you can convert between the models, >>> this takes time and resources, both at development and run time, >>> and this will force people to choose. But there will be no choice. >>> Offering 3rd party conversion tools, whether free or commercial, >>> will not be a solution (might be a problem in it's own right) >>> * it will be extra work to maintain 2 ITS specifications >>> >>> Rationale for not replacing it >>> * people are already implementing XML ITS >>> * we explicitly allowed for multiple ITS's. Indeed, they both >>> already exist. >>> >>> I am not at sure which is a better approach. I believe that further >>> investigation will be required, including actual implementation, >>> before we get a feel for the answer. >>> >>> Grahame >>> >>> >>> Charlie McCay wrote: >>>> Lloyd >>>> >>>> I understood that IM was rejected because we already have lots of >>>> Information Models. >>>> >>>> It is yet to be established whether the collapsed model approach, if >>>> endorsed, would be an alternative to or replacement for, the current >>>> ITS. There was a view expressed in INM that maintaining both may >>>> not be >>>> the best way to go forwards. >>>> >>>> Every model is platform independent to some degree. One take on the >>>> collapsing process would be to say that it was intended to generate >>>> models that were appropriate for implementation using XML, and as such >>>> would be platform specific. Another would be that it was to produce >>>> models that were appropriate for any generic implementation technology >>>> (ie an Abstract Implementation Model), in this case I would agree that >>>> it would be inappropriate to say that the models were platform >>>> specific. >>>> One of the issues that we need to explore is whether targeting just >>>> XML >>>> for the implementation models makes a significant difference. >>>> There are >>>> differing expectations as to what the outcome of that will be. >>>> >>>> All the best >>>> >>>> Charlie >>>> >>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>> >>>> >>>>> -----Original Message----- >>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>> Sent: 11 August 2006 17:17 >>>>> To: Sato Laura >>>>> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk >>>>> Subject: Re: [New-ITS] Name for a >>>>> flattened,association-collapsed model derived from an RMIM >>>>> >>>>> Hi Laura, >>>>> >>>>> The issue is that HL7 can be implemented in both collapsed >>>>> and non-collapsed manners. The model is also platform-independent. >>>>> >>>>> >>>>> Lloyd >>>>> >>>>> Sato Laura wrote: >>>>>> I realise that I'm a little late into this conversation, >>>>> but... what >>>>>> was wrong with Implementable Model - is it the acronym, IM, >>>>> that's too >>>>>> like something else? What I liked about 'implementable' was that it >>>>>> gave the sense of the view for which the model was designed >>>>> for (i.e. >>>>>> implementers). It gave a focus for what it was supposed to >>>>> accomplish. >>>>>> Scanning through the other terms, I don't mind >>>>> Platform-Specific Model, >>>>>> if that's truly what it is (is it?). Transmission Model >>>>> might be okay. >>>>>> Semantically Equivalent Model doesn't say anything to me >>>>> about what it's >>>>>> for, so I'm not crazy about this one. >>>>>> >>>>>> Just my 2p... >>>>>> >>>>>> Regards, >>>>>> Laura >>>>>> _________________________ >>>>>> Laura Sato >>>>>> Informatics Standards Lead >>>>>> >>>>>> Communications & Messaging >>>>>> NHS Connecting for Health >>>>>> Mobile: (44) (0)7733 324 338 >>>>>> Email: laura.sato at cfh.nhs.uk >>>>>> www.connectingforhealth.nhs.uk >>>>>> >>>>>> -----Original Message----- >>>>>> From: new-its-bounces at lists.hl7.org.uk >>>>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden >>>>>> Sent: 10 August 2006 18:18 >>>>>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie >>>>>> Cc: new-its at lists.hl7.org.uk >>>>>> Subject: [New-ITS] Name for a flattened,association-collapsed model >>>>>> derived from an RMIM >>>>>> >>>>>> Not sure about 'optimised' because: >>>>>> >>>>>> - Optimised implies the best in some sense; but it may not >>>>> yet be the >>>>>> best, just better >>>>>> - The acronym 'OM' somehow is not very snappy - hard to >>>>> read as a word >>>>>> (or a bit Buddhist?). >>>>>> >>>>>> I have two other suggestions: >>>>>> >>>>>> - Transmission Model, or TM (still a bit Buddhist?) >>>>>> - Semantically Equivalent Model, or SEM >>>>>> >>>>>> I like the last because it tells people we are not messing with RIM >>>>>> semantics. >>>>>> >>>>>> Anyway, the acronym is now a variable in the tools, and I >>>>> can change it >>>>>> daily. We could put it to a vote at the WGM. >>>>>> >>>>>> Robert >>>>>> >>>>>> Charteris plc, Charteris House, 39/40 Bartholomew Close, London >>>>>> EC1A 7JN >>>>>> >>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>> mobile: 44 7970 >>>>>> 197968 >>>>>> >>>>>> *************************** E-mail confidentiality notice >>>>>> ******************************* >>>>>> >>>>>> This message is intended for the addressee only. It is private, >>>>>> confidential and may contain >>>>>> information of a proprietary nature. If you have received >>>>> this message >>>>>> in error, please notify >>>>>> us and remove it from your system. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] >>>>>> Sent: 09 August 2006 17:44 >>>>>> To: Lloyd McKenzie >>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>> Subject: RE: Steering RMIM reshaping >>>>>> >>>>>> Well -- we were trying to avoid C words -- so "optimized" >>>>> seems the best >>>>>> offering so far >>>>>> All the best >>>>>> Charlie >>>>>> >>>>>> >>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>> >>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>> Sent: 09 August 2006 17:08 >>>>>>> To: Charlie McCay >>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>> >>>>>>> Hi Charlie, >>>>>>> >>>>>>> Calling it a "practical" model sends the wrong message about >>>>>>> the existing structure. Executable model suggests that it's >>>>>>> an internal object model, which it isn't. >>>>>>> >>>>>>> What this is is a "collapsed" or "compressed" or "optimized" >>>>>>> or some other transformation type word. >>>>>>> >>>>>>> >>>>>>> Lloyd >>>>>>> >>>>>>> Charlie McCay wrote: >>>>>>> >>>>>>>> So how about practical model or exchange model or executable model >>>>>>>> >>>>>>>> >>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>> >>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>> Sent: 09 August 2006 16:22 >>>>>>>>> To: Charlie McCay >>>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>> >>>>>>>>> Hi Charlie, >>>>>>>>> >>>>>>>>> The challenge is that many will read "physical model" in its >>>>>>>>> usual sense, which is persistence model, which we definitely >>>>>>>>> shouldn't be suggesting, let alone imposing. >>>>>>>>> >>>>>>>>> >>>>>>>>> Lloyd >>>>>>>>> >>>>>>>>> Charlie McCay wrote: >>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> Why not? -- the intent is to provide the model for the physical >>>>>>>>>> exchange (subject to ITS realisation, but that is the >>>>>>>>>> >>>>>>>>> model-reality >>>>>>>>> >>>>>>>>>> mapping) -- it is this practical model that is exactly what >>>>>>>>>> >>>>>>>>> we do want >>>>>>>>>> from HL7, and that we have been using the logical >>>>>>>>>> >>>>>>>>> information model >>>>>>>>> >>>>>>>>>> as a proxy for until now >>>>>>>>>> >>>>>>>>>> Alternative that I do not like as much: >>>>>>>>>> >>>>>>>>>> EM exchange model / executable model >>>>>>>>>> >>>>>>>>>> charlie >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>>> >>>>>>> Ltd, 23D >>>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>>> >>>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>>> Sent: 09 August 2006 16:02 >>>>>>>>>>> To: Charlie McCay >>>>>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>> >>>>>>>>>>> Hi Charlie, >>>>>>>>>>> >>>>>>>>>>> I don't want to imply that HL7 defines actual physical >>>>>>>>>>> >>>>>>> models . . . >>>>>>> >>>>>>>>>>> Lloyd >>>>>>>>>>> >>>>>>>>>>> Charlie McCay wrote: >>>>>>>>>>> >>>>>>>>>>>> How about >>>>>>>>>>>> >>>>>>>>>>>> PM -- Physical/(?Practical?) Model ? >>>>>>>>>>>> PM / PSM (Platform model (Platform Specific Model) >>>>>>>>>>>> >>>>>>>>>>>> All the best >>>>>>>>>>>> >>>>>>>>>>>> Charlie >>>>>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>>>>> >>>>>>>>> Ltd, 23D >>>>>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>>>>> >>>>>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>>>>> Sent: 08 August 2006 05:45 >>>>>>>>>>>>> To: grahame at jivamedical.com >>>>>>>>>>>>> Cc: Robert Worden; Charlie McCay >>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>> >>>>>>>>>>>>> Except CM is used for CMET. Not sure we need a different >>>>>>>>>>>>> >>>>>>>>>>> id if the >>>>>>>>>>> >>>>>>>>>>>>> models are just transforms of each other. >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> CM = collapsed model or computable model >>>>>>>>>>>>>> >>>>>>>>>>>>>> we could go with that >>>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Lloyd McKenzie wrote: >>>>>>>>>>>>>> We can't use the word "Message" >>>>>>>>>>>>>> because we'll presumably >>>>>>>>>>>>>> >>>>>>>>>>> be using >>>>>>>>>>> >>>>>>>>>>>>>> this stuff for documents too. How about just >>>>>>>>>>>>>> >>>>>>>>> "collapsed model", >>>>>>>>> >>>>>>>>>>>>>> seeing as that's what it is . . . >>>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>>>> we've been using the term >>>>>>>>>>>>>> implementable model. IM, >>>>>>>>>>>>>> >>>>>>> I know.... >>>>>>> >>>>>>>>>>>>>> maybe you could go for "message design"? it's not >>>>>>>>>>>>>> >>>>>>>>>>>>> strictly a model, >>>>>>>>>>>>> >>>>>>>>>>>>>> so we can get away from the "M" part and reduce confusion? >>>>>>>>>>>>>> >>>>>>>>>>>>>> cc: Charlie for an opinion >>>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>>> Grahame - >>>>>>>>>>>>>> >>>>>>>>>>>>>> I agree that DAM is not the right name, and will tend >>>>>>>>>>>>>> >>>>>>>>>>> to confuse >>>>>>>>>>> >>>>>>>>>>>>>> people; we are making something strictly derived from >>>>>>>>>>>>>> >>>>>>>>>>>>> the RMIM and >>>>>>>>>>>>> >>>>>>>>>>>>>> suitable for implementation, which may have DAM-like >>>>>>>>>>>>>> >>>>>>>>> names and >>>>>>>>>>>>>> structure. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop >>>>>>>>>>>>>> >>>>>>>>>>> calling it a >>>>>>>>>>> >>>>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped >>>>>>>>>>>>>> >>>>>>>>>>>>> RMIM'. Any suggestions? >>>>>>>>>>>>> >>>>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped >>>>>>>>>>>>>> >>>>>>>>>>> Implementation >>>>>>>>>>> >>>>>>>>>>>>>> Model? >>>>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Give me an acronym and I will do a global edit... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>> >>>>>>>>>>>>> Close, London >>>>>>>>>>>>> >>>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>>> >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>>> >>>>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>>>> >>>>>>>>>>>>>> 197968 >>>>>>>>>>>>>> >>>>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>> >>>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>>> >>>>>>>>>>> private, >>>>>>>>>>> >>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>> >>>>>>>>>>>>> proprietary nature. >>>>>>>>>>>>> >>>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>>> >>>>>>>>>>> notify us and >>>>>>>>>>> >>>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On >>>>>>>>>>>>>> >>>>>>>>> Behalf Of >>>>>>>>>>>>>> Grahame Grieve >>>>>>>>>>>>>> Sent: 07 August 2006 22:18 >>>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>>> Cc: Lloyd McKenzie >>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm way behind on email. but spotted this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no >>>>>>>>>>>>>> >>>>>>>>>>>>> correlation >>>>>>>>>>>>> >>>>>>>>>>>>>> between what we are trying to achieve and a real DAM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What we want is to do implementation modelling on >>>>>>>>>>>>>> >>>>>>>>> the RMIM. We >>>>>>>>> >>>>>>>>>>>>>> recognise - particularly after talking to Simon Withey >>>>>>>>>>>>>> >>>>>>>>>>>>> last week - >>>>>>>>>>>>> >>>>>>>>>>>>>> that this has nothing to do with the DAM process, >>>>>>>>>>>>>> >>>>>>>>>>> except for the >>>>>>>>>>> >>>>>>>>>>>>>> naming question. >>>>>>>>>>>>>> (Where by names in the instance should allow >>>>>>>>>>>>>> >>>>>>>>>>> identification back >>>>>>>>>>> >>>>>>>>>>>>>> against the DAM, rather than against the RIM. Except >>>>>>>>>>>>>> >>>>>>>>>>>>> unless you are >>>>>>>>>>>>> >>>>>>>>>>>>>> concerned about naming stability, but that's a much >>>>>>>>>>>>>> >>>>>>>>>>>>> harder question >>>>>>>>>>>>> >>>>>>>>>>>>>> indeed) >>>>>>>>>>>>>> >>>>>>>>>>>>>> will come back to this thread later when I catch up >>>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>>> Hi Lloyd - >>>>>>>>>>>>>> >>>>>>>>>>>>>> I was thinking that since people should really >>>>>>>>>>>>>> >>>>>>>>>>> produce a DAM on >>>>>>>>>>> >>>>>>>>>>>>>> the >>>>>>>>>>>>>> way >>>>>>>>>>>>>> to their RMIM, rather than the >>>>>>>>>>>>>> other way round, in some >>>>>>>>>>>>>> >>>>>>>>>>>>> sense the >>>>>>>>>>>>> >>>>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not >>>>>>>>>>>>>> >>>>>>>>>>> a formal >>>>>>>>>>> >>>>>>>>>>>>>> derivation, >>>>>>>>>>>>>> it >>>>>>>>>>>>>> may be that the >>>>>>>>>>>>>> route is not >>>>>>>>>>>>>> >>>>>>>>> appropriate. >>>>>>>>> >>>>>>>>>>>>>> What then is the approved mechanism for adding >>>>>>>>>>>>>> >>>>>>>>>>>>> annotations to a MIF? >>>>>>>>>>>>> >>>>>>>>>>>>>> I'm >>>>>>>>>>>>>> sure I could find it in the >>>>>>>>>>>>>> schemas, but it's easier to >>>>>>>>>>>>>> >>>>>>>>>>>>> ask you... >>>>>>>>>>>>> >>>>>>>>>>>>>> :-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>> >>>>>>>>>>>>> Close, London >>>>>>>>>>>>> >>>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>>> >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>>> >>>>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>>>> >>>>>>>>>>>>>> 197968 >>>>>>>>>>>>>> >>>>>>>>>>>>>> *************************** E-mail >>>>> confidentiality notice >>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>> >>>>>>>>>>>>>> This message is intended for the addressee only. It >>>>>>>>>>>>>> >>>>>>>>>>> is private, >>>>>>>>>>> >>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>> >>>>>>>>>>>>> proprietary nature. >>>>>>>>>>>>> >>>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>>> >>>>>>>>>>>>> notify us and >>>>>>>>>>>>> >>>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: >>>>>>>>>>>>>> >>>>>>>>>>>>> 07 August >>>>>>>>>>>>> >>>>>>>>>>>>>> 2006 19:43 >>>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>>> Cc: grahame at kestral.com.au >>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Relationships between a static model and a DAM would be >>>>>>>>>>>>>> >>>>>>>>>>>>> mappings, >>>>>>>>>>>>> >>>>>>>>>>>>>> not derivations. StaticModelDerivationId is not a >>>>>>>>>>>>>> >>>>>>>>>>> spare. In the >>>>>>>>>>> >>>>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM >>>>>>>>>>>>>> >>>>>>>>>>>>> and HMD but >>>>>>>>>>>>> >>>>>>>>>>>>>> in theory we could derive from 20 different models. >>>>>>>>>>>>>> >>>>>>>>>>>>> (And there's >>>>>>>>>>>>> >>>>>>>>>>>>>> no ordering >>>>>>>>>>>>>> either, >>>>>>>>>>>>>> the RIM could be the first one >>>>>>>>>>>>>> listed or the seventh.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> The basic question is whether you construct your >>>>>>>>>>>>>> >>>>>>> DAM from a >>>>>>>>>>>>>> collapsed static model (as we do in Canada), or whether >>>>>>>>>>>>>> >>>>>>>>>>>>> you want >>>>>>>>>>>>> >>>>>>>>>>>>>> to create your DAMs and DIMs separately and map >>>>>>>>>>>>>> >>>>>>>>> them. If the >>>>>>>>> >>>>>>>>>>>>>> latter, I don't think >>>>>>>>>>>>>> you >>>>>>>>>>>>>> could do this in an automated way. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Lloyd >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>>> Grahame - >>>>>>>>>>>>>> >>>>>>>>>>>>>> You asked the other day for suggestions as to how >>>>>>>>>>>>>> >>>>>>>>>>> the current >>>>>>>>>>> >>>>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be >>>>> steered by >>>>>>>>>>>>>> annotations in the RMIM MIF, rather than by user >>>>>>>>>>>>>> >>>>>>>>>>>>> input. Here is a >>>>>>>>>>>>> >>>>>>>>>>>>>> first punt to get thinking going. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The simplest suggestion I can make is to add to the >>>>>>>>>>>>>> elements another one which says >>>>>>>>>>>>>> >>>>>>>>>>> how this >>>>>>>>>>> >>>>>>>>>>>>>> RMIM >>>>>>>>>>>>>> was >>>>>>>>>>>>>> derived (or might have been >>>>>>>>>>>>>> derived) from a DAM. These >>>>>>>>>>>>>> >>>>>>>>>>>>> would look >>>>>>>>>>>>> >>>>>>>>>>>>>> like: >>>>>>>>>>>>>> >>>>>>>>>>>>> staticModelDerivationId="4" >>>>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; >>>>>>>>>>>>>> >>>>>>>>>>>>> but choose >>>>>>>>>>>>> >>>>>>>>>>>>>> one >>>>>>>>>>>>>> that is). These can go on elements for classes, >>>>>>>>>>>>>> >>>>>>>>>>>>> associations, and >>>>>>>>>>>>> >>>>>>>>>>>>>> properties to say in effect >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Rename this class to a DAM class name >>>>>>>>>>>>>> * Rename this association (with perhaps other >>>>>>>>>>>>>> >>>>>>>>>>>>> attributes saying >>>>>>>>>>>>> >>>>>>>>>>>>>> 'collapse it' or 'leave it out') >>>>>>>>>>>>>> * Rename this property to a DAM property name (or >>>>>>>>>>>>>> >>>>>>>>>>>>> some value >>>>>>>>>>>>> >>>>>>>>>>>>>> meaning 'leave it out') >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you wanted, you would not even have to say >>>>> explicitly >>>>>>>>>>>>>> 'collapse an >>>>>>>>>>>>>> association' - because if the DAM class names are >>>>>>>>>>>>>> >>>>>>>>>>> the same on >>>>>>>>>>> >>>>>>>>>>>>>> either side of it, that means collapse it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This proposal would not yet address a combination of >>>>>>>>>>>>>> >>>>>>>>>>>>> restricting >>>>>>>>>>>>> >>>>>>>>>>>>>> and reshaping an RMIM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It would imply you cannot collapse across a CMET >>>>>>>>>>>>>> >>>>>>>>>>>>> boundary, which >>>>>>>>>>>>> >>>>>>>>>>>>>> I gather from our discussion the other day you would >>>>>>>>>>>>>> >>>>>>>>>>>>> like to do. >>>>>>>>>>>>> >>>>>>>>>>>>>> Or maybe you can, by telling the association to >>>>>>>>>>>>>> >>>>>>>>> the CMET to >>>>>>>>> >>>>>>>>>>>>>> collapse itself? Have not thought it through yet. I >>>>>>>>>>>>>> >>>>>>>>>>> know there >>>>>>>>>>> >>>>>>>>>>>>>> are issues >>>>>>>>>>>>>> about >>>>>>>>>>>>>> CMETs with a choice at the top - >>>>>>>>>>>>>> any chance you >>>>>>>>>>>>>> >>>>>>>>> could send a >>>>>>>>> >>>>>>>>>>>>>> simple diagram to illustrate the problem as you see it? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Anyway, if we come up with any scheme like the above, >>>>>>>>>>>>>> >>>>>>>>>>>>> it should >>>>>>>>>>>>> >>>>>>>>>>>>>> be straightforward to implement in the tool. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>> >>>>>>>>>>>>> Close, London >>>>>>>>>>>>> >>>>>>>>>>>>>> EC1A >>>>>>>>>>>>>> 7JN >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 >>>>>>>>>>>>>> 1353 777394; mobile: 44 >>>>>>>>>>>>>> >>>>>>>>>>>>> 7970 197968 >>>>>>>>>>>>> >>>>>>>>>>>>>> *************************** E-mail >>>>> confidentiality notice >>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>> >>>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>>> >>>>>>>>>>>>> private, >>>>>>>>>>>>> >>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>> >>>>>>>>>>>>> proprietary nature. >>>>>>>>>>>>> >>>>>>>>>>>>>> If you have received this >>>>>>>>>>>>>> message >>>>>>>>>>>>>> in error, please notify >>>>>>>>>>>>>> us and remove it from your system. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>>> >>>>>>>>> for viruses >>>>>>>>> >>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> This message to Charteris plc has been checked >>>>>>>>>>>>>> >>>>>>> for viruses >>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>>> >>>>>>>>> for viruses >>>>>>>>> >>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> _________________________________________________________________ >>>>>> This message to Charteris plc has been checked for viruses >>>>>> http://www.charteris.com/ >>>>>> >>>>>> _________________________________________________________________ >>>>>> This message from Charteris plc has been checked for viruses >>>>>> http://www.charteris.com/ >>>>>> _______________________________________________ >>>>>> 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. >>>>>> >>>>> >>>> _______________________________________________ >>>> New-ITS mailing list >>>> New-ITS at lists.hl7.org.uk >>>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>>> >> >> >> > From lloyd at lmckenzie.com Wed Aug 16 16:35:23 2006 From: lloyd at lmckenzie.com (Lloyd McKenzie) Date: Wed, 16 Aug 2006 08:35:23 -0700 Subject: [New-ITS] Name for a flattened, association-collapsed model derived from an RMIM In-Reply-To: <44E2DF22.2050308@kestral.com.au> References: <44E2DF22.2050308@kestral.com.au> Message-ID: <44E33B3B.6080905@lmckenzie.com> The existing model is still UML. The new model merely collapses Grahame Grieve wrote: > Tim, that wasn't supposed to be serious! > > but your comment about model might be interesting. > Of course we can switch [M]odel for [M]essage > and get everyone even more confused, especially > since only some of what we are dealing with is > messages. > > Why not model? anyway, it is model in the UML sense of > the word > > Can you use the words "UML model"? ;-) > > Grahame > > > Tim Benson wrote: >> Grahame, >> >> It really does not matter what it is called as long as it is not easily >> confused with another TLA. For this reason I would not suggest MMM >> which >> will inevitably be referred to as 3M, which is a well-known >> trademark, with >> large healthcare interests. I would also prefer not to see the word >> model, >> unless it is a model in the UML sense of the word. >> >> CEN CR 12587 defined an IMS as an Implementable Message >> Specification, which >> might be revived. >> It is always good to reuse existing terms and meanings and avoid the >> temptation of neologism, otherwise known as humpty-dumptyism. >> >> Tim >> >> On 16/8/06 09:06 Grahame Grieve wrote: >> >>> how about MMM for Mere Mortals Model >>> >>> The rationale for replacing the existing XML ITS >>> with a new UML ITS: >>> * the xml its is broken in a couple of small places. fixing it >>> won't be backwards compatible >>> * the uml its will be easier to implement (we hope) >>> * though it's easy to say that you can convert between the models, >>> this takes time and resources, both at development and run time, >>> and this will force people to choose. But there will be no choice. >>> Offering 3rd party conversion tools, whether free or commercial, >>> will not be a solution (might be a problem in it's own right) >>> * it will be extra work to maintain 2 ITS specifications >>> >>> Rationale for not replacing it >>> * people are already implementing XML ITS >>> * we explicitly allowed for multiple ITS's. Indeed, they both >>> already exist. >>> >>> I am not at sure which is a better approach. I believe that further >>> investigation will be required, including actual implementation, >>> before we get a feel for the answer. >>> >>> Grahame >>> >>> >>> Charlie McCay wrote: >>>> Lloyd >>>> >>>> I understood that IM was rejected because we already have lots of >>>> Information Models. >>>> >>>> It is yet to be established whether the collapsed model approach, if >>>> endorsed, would be an alternative to or replacement for, the current >>>> ITS. There was a view expressed in INM that maintaining both may >>>> not be >>>> the best way to go forwards. >>>> >>>> Every model is platform independent to some degree. One take on the >>>> collapsing process would be to say that it was intended to generate >>>> models that were appropriate for implementation using XML, and as such >>>> would be platform specific. Another would be that it was to produce >>>> models that were appropriate for any generic implementation technology >>>> (ie an Abstract Implementation Model), in this case I would agree that >>>> it would be inappropriate to say that the models were platform >>>> specific. >>>> One of the issues that we need to explore is whether targeting just >>>> XML >>>> for the implementation models makes a significant difference. >>>> There are >>>> differing expectations as to what the outcome of that will be. >>>> >>>> All the best >>>> >>>> Charlie >>>> >>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>> >>>> >>>>> -----Original Message----- >>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>> Sent: 11 August 2006 17:17 >>>>> To: Sato Laura >>>>> Cc: Robert Worden; Charlie McCay; new-its at lists.hl7.org.uk >>>>> Subject: Re: [New-ITS] Name for a >>>>> flattened,association-collapsed model derived from an RMIM >>>>> >>>>> Hi Laura, >>>>> >>>>> The issue is that HL7 can be implemented in both collapsed >>>>> and non-collapsed manners. The model is also platform-independent. >>>>> >>>>> >>>>> Lloyd >>>>> >>>>> Sato Laura wrote: >>>>>> I realise that I'm a little late into this conversation, >>>>> but... what >>>>>> was wrong with Implementable Model - is it the acronym, IM, >>>>> that's too >>>>>> like something else? What I liked about 'implementable' was that it >>>>>> gave the sense of the view for which the model was designed >>>>> for (i.e. >>>>>> implementers). It gave a focus for what it was supposed to >>>>> accomplish. >>>>>> Scanning through the other terms, I don't mind >>>>> Platform-Specific Model, >>>>>> if that's truly what it is (is it?). Transmission Model >>>>> might be okay. >>>>>> Semantically Equivalent Model doesn't say anything to me >>>>> about what it's >>>>>> for, so I'm not crazy about this one. >>>>>> >>>>>> Just my 2p... >>>>>> >>>>>> Regards, >>>>>> Laura >>>>>> _________________________ >>>>>> Laura Sato >>>>>> Informatics Standards Lead >>>>>> >>>>>> Communications & Messaging >>>>>> NHS Connecting for Health >>>>>> Mobile: (44) (0)7733 324 338 >>>>>> Email: laura.sato at cfh.nhs.uk >>>>>> www.connectingforhealth.nhs.uk >>>>>> >>>>>> -----Original Message----- >>>>>> From: new-its-bounces at lists.hl7.org.uk >>>>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden >>>>>> Sent: 10 August 2006 18:18 >>>>>> To: charlie at ramseysystems.co.uk; Lloyd McKenzie >>>>>> Cc: new-its at lists.hl7.org.uk >>>>>> Subject: [New-ITS] Name for a flattened,association-collapsed model >>>>>> derived from an RMIM >>>>>> >>>>>> Not sure about 'optimised' because: >>>>>> >>>>>> - Optimised implies the best in some sense; but it may not >>>>> yet be the >>>>>> best, just better >>>>>> - The acronym 'OM' somehow is not very snappy - hard to >>>>> read as a word >>>>>> (or a bit Buddhist?). >>>>>> >>>>>> I have two other suggestions: >>>>>> >>>>>> - Transmission Model, or TM (still a bit Buddhist?) >>>>>> - Semantically Equivalent Model, or SEM >>>>>> >>>>>> I like the last because it tells people we are not messing with RIM >>>>>> semantics. >>>>>> >>>>>> Anyway, the acronym is now a variable in the tools, and I >>>>> can change it >>>>>> daily. We could put it to a vote at the WGM. >>>>>> >>>>>> Robert >>>>>> >>>>>> Charteris plc, Charteris House, 39/40 Bartholomew Close, London >>>>>> EC1A 7JN >>>>>> >>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>> mobile: 44 7970 >>>>>> 197968 >>>>>> >>>>>> *************************** E-mail confidentiality notice >>>>>> ******************************* >>>>>> >>>>>> This message is intended for the addressee only. It is private, >>>>>> confidential and may contain >>>>>> information of a proprietary nature. If you have received >>>>> this message >>>>>> in error, please notify >>>>>> us and remove it from your system. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] >>>>>> Sent: 09 August 2006 17:44 >>>>>> To: Lloyd McKenzie >>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>> Subject: RE: Steering RMIM reshaping >>>>>> >>>>>> Well -- we were trying to avoid C words -- so "optimized" >>>>> seems the best >>>>>> offering so far >>>>>> All the best >>>>>> Charlie >>>>>> >>>>>> >>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>> >>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>> Sent: 09 August 2006 17:08 >>>>>>> To: Charlie McCay >>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>> >>>>>>> Hi Charlie, >>>>>>> >>>>>>> Calling it a "practical" model sends the wrong message about >>>>>>> the existing structure. Executable model suggests that it's >>>>>>> an internal object model, which it isn't. >>>>>>> >>>>>>> What this is is a "collapsed" or "compressed" or "optimized" >>>>>>> or some other transformation type word. >>>>>>> >>>>>>> >>>>>>> Lloyd >>>>>>> >>>>>>> Charlie McCay wrote: >>>>>>> >>>>>>>> So how about practical model or exchange model or executable model >>>>>>>> >>>>>>>> >>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>> >>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>> Sent: 09 August 2006 16:22 >>>>>>>>> To: Charlie McCay >>>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>> >>>>>>>>> Hi Charlie, >>>>>>>>> >>>>>>>>> The challenge is that many will read "physical model" in its >>>>>>>>> usual sense, which is persistence model, which we definitely >>>>>>>>> shouldn't be suggesting, let alone imposing. >>>>>>>>> >>>>>>>>> >>>>>>>>> Lloyd >>>>>>>>> >>>>>>>>> Charlie McCay wrote: >>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> Why not? -- the intent is to provide the model for the physical >>>>>>>>>> exchange (subject to ITS realisation, but that is the >>>>>>>>>> >>>>>>>>> model-reality >>>>>>>>> >>>>>>>>>> mapping) -- it is this practical model that is exactly what >>>>>>>>>> >>>>>>>>> we do want >>>>>>>>>> from HL7, and that we have been using the logical >>>>>>>>>> >>>>>>>>> information model >>>>>>>>> >>>>>>>>>> as a proxy for until now >>>>>>>>>> >>>>>>>>>> Alternative that I do not like as much: >>>>>>>>>> >>>>>>>>>> EM exchange model / executable model >>>>>>>>>> >>>>>>>>>> charlie >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>>> >>>>>>> Ltd, 23D >>>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>>> >>>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>>> Sent: 09 August 2006 16:02 >>>>>>>>>>> To: Charlie McCay >>>>>>>>>>> Cc: grahame at jivamedical.com; Robert Worden >>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>> >>>>>>>>>>> Hi Charlie, >>>>>>>>>>> >>>>>>>>>>> I don't want to imply that HL7 defines actual physical >>>>>>>>>>> >>>>>>> models . . . >>>>>>> >>>>>>>>>>> Lloyd >>>>>>>>>>> >>>>>>>>>>> Charlie McCay wrote: >>>>>>>>>>> >>>>>>>>>>>> How about >>>>>>>>>>>> >>>>>>>>>>>> PM -- Physical/(?Practical?) Model ? >>>>>>>>>>>> PM / PSM (Platform model (Platform Specific Model) >>>>>>>>>>>> >>>>>>>>>>>> All the best >>>>>>>>>>>> >>>>>>>>>>>> Charlie >>>>>>>>>>>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems >>>>>>>>>>>> >>>>>>>>> Ltd, 23D >>>>>>>>>>>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>>>>>>>>>>> >>>>>>>>>>>> tel 01743 232278 / 07808 570172 skype: charliemccay >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] >>>>>>>>>>>>> Sent: 08 August 2006 05:45 >>>>>>>>>>>>> To: grahame at jivamedical.com >>>>>>>>>>>>> Cc: Robert Worden; Charlie McCay >>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>> >>>>>>>>>>>>> Except CM is used for CMET. Not sure we need a different >>>>>>>>>>>>> >>>>>>>>>>> id if the >>>>>>>>>>> >>>>>>>>>>>>> models are just transforms of each other. >>>>>>>>>>>>> >>>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> CM = collapsed model or computable model >>>>>>>>>>>>>> >>>>>>>>>>>>>> we could go with that >>>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Lloyd McKenzie wrote: >>>>>>>>>>>>>> We can't use the word "Message" >>>>>>>>>>>>>> because we'll presumably >>>>>>>>>>>>>> >>>>>>>>>>> be using >>>>>>>>>>> >>>>>>>>>>>>>> this stuff for documents too. How about just >>>>>>>>>>>>>> >>>>>>>>> "collapsed model", >>>>>>>>> >>>>>>>>>>>>>> seeing as that's what it is . . . >>>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame Grieve wrote: >>>>>>>>>>>>>> we've been using the term >>>>>>>>>>>>>> implementable model. IM, >>>>>>>>>>>>>> >>>>>>> I know.... >>>>>>> >>>>>>>>>>>>>> maybe you could go for "message design"? it's not >>>>>>>>>>>>>> >>>>>>>>>>>>> strictly a model, >>>>>>>>>>>>> >>>>>>>>>>>>>> so we can get away from the "M" part and reduce confusion? >>>>>>>>>>>>>> >>>>>>>>>>>>>> cc: Charlie for an opinion >>>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>>> Grahame - >>>>>>>>>>>>>> >>>>>>>>>>>>>> I agree that DAM is not the right name, and will tend >>>>>>>>>>>>>> >>>>>>>>>>> to confuse >>>>>>>>>>> >>>>>>>>>>>>>> people; we are making something strictly derived from >>>>>>>>>>>>>> >>>>>>>>>>>>> the RMIM and >>>>>>>>>>>>> >>>>>>>>>>>>>> suitable for implementation, which may have DAM-like >>>>>>>>>>>>>> >>>>>>>>> names and >>>>>>>>>>>>>> structure. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll stop calling it a DAM, and make the tools stop >>>>>>>>>>>>>> >>>>>>>>>>> calling it a >>>>>>>>>>> >>>>>>>>>>>>>> DAM; but I would like a shorter name than 'reshaped >>>>>>>>>>>>>> >>>>>>>>>>>>> RMIM'. Any suggestions? >>>>>>>>>>>>> >>>>>>>>>>>>>> FIM = Familiar Implementation Model? SIM = Shaped >>>>>>>>>>>>>> >>>>>>>>>>> Implementation >>>>>>>>>>> >>>>>>>>>>>>>> Model? >>>>>>>>>>>>>> As far as I am aware, HL7 doesn't over-use 'F'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Give me an acronym and I will do a global edit... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>> >>>>>>>>>>>>> Close, London >>>>>>>>>>>>> >>>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>>> >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>>> >>>>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>>>> >>>>>>>>>>>>>> 197968 >>>>>>>>>>>>>> >>>>>>>>>>>>>> *************************** E-mail confidentiality notice >>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>> >>>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>>> >>>>>>>>>>> private, >>>>>>>>>>> >>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>> >>>>>>>>>>>>> proprietary nature. >>>>>>>>>>>>> >>>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>>> >>>>>>>>>>> notify us and >>>>>>>>>>> >>>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On >>>>>>>>>>>>>> >>>>>>>>> Behalf Of >>>>>>>>>>>>>> Grahame Grieve >>>>>>>>>>>>>> Sent: 07 August 2006 22:18 >>>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>>> Cc: Lloyd McKenzie >>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm way behind on email. but spotted this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert, we need to stop talking about DAM. There is no >>>>>>>>>>>>>> >>>>>>>>>>>>> correlation >>>>>>>>>>>>> >>>>>>>>>>>>>> between what we are trying to achieve and a real DAM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What we want is to do implementation modelling on >>>>>>>>>>>>>> >>>>>>>>> the RMIM. We >>>>>>>>> >>>>>>>>>>>>>> recognise - particularly after talking to Simon Withey >>>>>>>>>>>>>> >>>>>>>>>>>>> last week - >>>>>>>>>>>>> >>>>>>>>>>>>>> that this has nothing to do with the DAM process, >>>>>>>>>>>>>> >>>>>>>>>>> except for the >>>>>>>>>>> >>>>>>>>>>>>>> naming question. >>>>>>>>>>>>>> (Where by names in the instance should allow >>>>>>>>>>>>>> >>>>>>>>>>> identification back >>>>>>>>>>> >>>>>>>>>>>>>> against the DAM, rather than against the RIM. Except >>>>>>>>>>>>>> >>>>>>>>>>>>> unless you are >>>>>>>>>>>>> >>>>>>>>>>>>>> concerned about naming stability, but that's a much >>>>>>>>>>>>>> >>>>>>>>>>>>> harder question >>>>>>>>>>>>> >>>>>>>>>>>>>> indeed) >>>>>>>>>>>>>> >>>>>>>>>>>>>> will come back to this thread later when I catch up >>>>>>>>>>>>>> >>>>>>>>>>>>>> Grahame >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>>> Hi Lloyd - >>>>>>>>>>>>>> >>>>>>>>>>>>>> I was thinking that since people should really >>>>>>>>>>>>>> >>>>>>>>>>> produce a DAM on >>>>>>>>>>> >>>>>>>>>>>>>> the >>>>>>>>>>>>>> way >>>>>>>>>>>>>> to their RMIM, rather than the >>>>>>>>>>>>>> other way round, in some >>>>>>>>>>>>>> >>>>>>>>>>>>> sense the >>>>>>>>>>>>> >>>>>>>>>>>>>> RMIM should be derived from the DAM. But as it is not >>>>>>>>>>>>>> >>>>>>>>>>> a formal >>>>>>>>>>> >>>>>>>>>>>>>> derivation, >>>>>>>>>>>>>> it >>>>>>>>>>>>>> may be that the >>>>>>>>>>>>>> route is not >>>>>>>>>>>>>> >>>>>>>>> appropriate. >>>>>>>>> >>>>>>>>>>>>>> What then is the approved mechanism for adding >>>>>>>>>>>>>> >>>>>>>>>>>>> annotations to a MIF? >>>>>>>>>>>>> >>>>>>>>>>>>>> I'm >>>>>>>>>>>>>> sure I could find it in the >>>>>>>>>>>>>> schemas, but it's easier to >>>>>>>>>>>>>> >>>>>>>>>>>>> ask you... >>>>>>>>>>>>> >>>>>>>>>>>>>> :-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>> >>>>>>>>>>>>> Close, London >>>>>>>>>>>>> >>>>>>>>>>>>>> EC1A 7JN >>>>>>>>>>>>>> >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 1353 777394; >>>>>>>>>>>>>> >>>>>>>>>>>>> mobile: 44 7970 >>>>>>>>>>>>> >>>>>>>>>>>>>> 197968 >>>>>>>>>>>>>> >>>>>>>>>>>>>> *************************** E-mail >>>>> confidentiality notice >>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>> >>>>>>>>>>>>>> This message is intended for the addressee only. It >>>>>>>>>>>>>> >>>>>>>>>>> is private, >>>>>>>>>>> >>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>> >>>>>>>>>>>>> proprietary nature. >>>>>>>>>>>>> >>>>>>>>>>>>>> If you have received this message in error, please >>>>>>>>>>>>>> >>>>>>>>>>>>> notify us and >>>>>>>>>>>>> >>>>>>>>>>>>>> remove it from your system. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Lloyd McKenzie [mailto:lloyd at lmckenzie.com] Sent: >>>>>>>>>>>>>> >>>>>>>>>>>>> 07 August >>>>>>>>>>>>> >>>>>>>>>>>>>> 2006 19:43 >>>>>>>>>>>>>> To: Robert Worden >>>>>>>>>>>>>> Cc: grahame at kestral.com.au >>>>>>>>>>>>>> Subject: Re: Steering RMIM reshaping >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Robert, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Relationships between a static model and a DAM would be >>>>>>>>>>>>>> >>>>>>>>>>>>> mappings, >>>>>>>>>>>>> >>>>>>>>>>>>>> not derivations. StaticModelDerivationId is not a >>>>>>>>>>>>>> >>>>>>>>>>> spare. In the >>>>>>>>>>> >>>>>>>>>>>>>> current hierarchy, we can derive from the RIM, R-MIM >>>>>>>>>>>>>> >>>>>>>>>>>>> and HMD but >>>>>>>>>>>>> >>>>>>>>>>>>>> in theory we could derive from 20 different models. >>>>>>>>>>>>>> >>>>>>>>>>>>> (And there's >>>>>>>>>>>>> >>>>>>>>>>>>>> no ordering >>>>>>>>>>>>>> either, >>>>>>>>>>>>>> the RIM could be the first one >>>>>>>>>>>>>> listed or the seventh.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> The basic question is whether you construct your >>>>>>>>>>>>>> >>>>>>> DAM from a >>>>>>>>>>>>>> collapsed static model (as we do in Canada), or whether >>>>>>>>>>>>>> >>>>>>>>>>>>> you want >>>>>>>>>>>>> >>>>>>>>>>>>>> to create your DAMs and DIMs separately and map >>>>>>>>>>>>>> >>>>>>>>> them. If the >>>>>>>>> >>>>>>>>>>>>>> latter, I don't think >>>>>>>>>>>>>> you >>>>>>>>>>>>>> could do this in an automated way. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Lloyd >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert Worden wrote: >>>>>>>>>>>>>> Grahame - >>>>>>>>>>>>>> >>>>>>>>>>>>>> You asked the other day for suggestions as to how >>>>>>>>>>>>>> >>>>>>>>>>> the current >>>>>>>>>>> >>>>>>>>>>>>>> proof-of-concept RMIM reshaping tool might be >>>>> steered by >>>>>>>>>>>>>> annotations in the RMIM MIF, rather than by user >>>>>>>>>>>>>> >>>>>>>>>>>>> input. Here is a >>>>>>>>>>>>> >>>>>>>>>>>>>> first punt to get thinking going. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The simplest suggestion I can make is to add to the >>>>>>>>>>>>>> elements another one which says >>>>>>>>>>>>>> >>>>>>>>>>> how this >>>>>>>>>>> >>>>>>>>>>>>>> RMIM >>>>>>>>>>>>>> was >>>>>>>>>>>>>> derived (or might have been >>>>>>>>>>>>>> derived) from a DAM. These >>>>>>>>>>>>>> >>>>>>>>>>>>> would look >>>>>>>>>>>>> >>>>>>>>>>>>>> like: >>>>>>>>>>>>>> >>>>>>>>>>>>> staticModelDerivationId="4" >>>>>>>>>>>>>> className="DAMClass" attributeName="DAMProperty"/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> (I don't know if staticModelDerivationId="4" is spare; >>>>>>>>>>>>>> >>>>>>>>>>>>> but choose >>>>>>>>>>>>> >>>>>>>>>>>>>> one >>>>>>>>>>>>>> that is). These can go on elements for classes, >>>>>>>>>>>>>> >>>>>>>>>>>>> associations, and >>>>>>>>>>>>> >>>>>>>>>>>>>> properties to say in effect >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Rename this class to a DAM class name >>>>>>>>>>>>>> * Rename this association (with perhaps other >>>>>>>>>>>>>> >>>>>>>>>>>>> attributes saying >>>>>>>>>>>>> >>>>>>>>>>>>>> 'collapse it' or 'leave it out') >>>>>>>>>>>>>> * Rename this property to a DAM property name (or >>>>>>>>>>>>>> >>>>>>>>>>>>> some value >>>>>>>>>>>>> >>>>>>>>>>>>>> meaning 'leave it out') >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you wanted, you would not even have to say >>>>> explicitly >>>>>>>>>>>>>> 'collapse an >>>>>>>>>>>>>> association' - because if the DAM class names are >>>>>>>>>>>>>> >>>>>>>>>>> the same on >>>>>>>>>>> >>>>>>>>>>>>>> either side of it, that means collapse it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This proposal would not yet address a combination of >>>>>>>>>>>>>> >>>>>>>>>>>>> restricting >>>>>>>>>>>>> >>>>>>>>>>>>>> and reshaping an RMIM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It would imply you cannot collapse across a CMET >>>>>>>>>>>>>> >>>>>>>>>>>>> boundary, which >>>>>>>>>>>>> >>>>>>>>>>>>>> I gather from our discussion the other day you would >>>>>>>>>>>>>> >>>>>>>>>>>>> like to do. >>>>>>>>>>>>> >>>>>>>>>>>>>> Or maybe you can, by telling the association to >>>>>>>>>>>>>> >>>>>>>>> the CMET to >>>>>>>>> >>>>>>>>>>>>>> collapse itself? Have not thought it through yet. I >>>>>>>>>>>>>> >>>>>>>>>>> know there >>>>>>>>>>> >>>>>>>>>>>>>> are issues >>>>>>>>>>>>>> about >>>>>>>>>>>>>> CMETs with a choice at the top - >>>>>>>>>>>>>> any chance you >>>>>>>>>>>>>> >>>>>>>>> could send a >>>>>>>>> >>>>>>>>>>>>>> simple diagram to illustrate the problem as you see it? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Anyway, if we come up with any scheme like the above, >>>>>>>>>>>>>> >>>>>>>>>>>>> it should >>>>>>>>>>>>> >>>>>>>>>>>>>> be straightforward to implement in the tool. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Robert >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charteris plc, Charteris House, 39/40 Bartholomew >>>>>>>>>>>>>> >>>>>>>>>>>>> Close, London >>>>>>>>>>>>> >>>>>>>>>>>>>> EC1A >>>>>>>>>>>>>> 7JN >>>>>>>>>>>>>> phone: 44 1353 777668; Fax 44 >>>>>>>>>>>>>> 1353 777394; mobile: 44 >>>>>>>>>>>>>> >>>>>>>>>>>>> 7970 197968 >>>>>>>>>>>>> >>>>>>>>>>>>>> *************************** E-mail >>>>> confidentiality notice >>>>>>>>>>>>>> ******************************* >>>>>>>>>>>>>> >>>>>>>>>>>>>> This message is intended for the addressee only. It is >>>>>>>>>>>>>> >>>>>>>>>>>>> private, >>>>>>>>>>>>> >>>>>>>>>>>>>> confidential and may contain information of a >>>>>>>>>>>>>> >>>>>>>>>>>>> proprietary nature. >>>>>>>>>>>>> >>>>>>>>>>>>>> If you have received this >>>>>>>>>>>>>> message >>>>>>>>>>>>>> in error, please notify >>>>>>>>>>>>>> us and remove it from your system. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>>> >>>>>>>>> for viruses >>>>>>>>> >>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> This message to Charteris plc has been checked >>>>>>>>>>>>>> >>>>>>> for viruses >>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> This message from Charteris plc has been checked >>>>>>>>>>>>>> >>>>>>>>> for viruses >>>>>>>>> >>>>>>>>>>>>>> http://www.charteris.com/ >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> _________________________________________________________________ >>>>>> This message to Charteris plc has been checked for viruses >>>>>> http://www.charteris.com/ >>>>>> >>>>>> _________________________________________________________________ >>>>>> This message from Charteris plc has been checked for viruses >>>>>> http://www.charteris.com/ >>>>>> _______________________________________________ >>>>>> 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. >>>>>> >>>>> >>>> _______________________________________________ >>>> New-ITS mailing list >>>> New-ITS at lists.hl7.org.uk >>>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>>> >> >> >> > From Thomas.Beale at OceanInformatics.biz Thu Aug 24 16:29:27 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Thu, 24 Aug 2006 16:29:27 +0100 Subject: [New-ITS] new its & related work: proposals for HL7 meeting In-Reply-To: <44E9B8A3.2010205@kestral.com.au> References: <44E9B8A3.2010205@kestral.com.au> Message-ID: <44EDC5D7.3030805@OceanInformatics.biz> Grahame Grieve wrote: > > 4. CEN & HL7 harmonisation > > We find that broadly speaking, there is 3 areas of the model > development process where CEN and HL7 are perceived to differ: > * Reference Model > * Constraint mechanisms > * Wire format > > With regards to the reference model, we note that CEN are examining > the UML ITS datatypes with regard to their suitability as a CEN > standard in place of the currently proposed CEN data types. We also > note that there is strong similarities between the CEN reference > model and the HL7 clinical statement pattern. However we note that > within this scope, there is also subtle but significant differences > which lead to different implicit transformations of real world > problems to the models, and these may make further alignment very > difficult. Further investigation is needed. > > With regards to the Constraint mechanisms, we note that RBMs and > Archetypes are the same beast. Though they present differently, > the bulk of their content can be automatically converted from one > form to the other. Small enhancements in each format could be proposed > which would make the interconversion even easier. The new RBM designer > could not only interconvert between the 2 formats, it can present both > simultaneously much like an XML and a tree view in an XML editor. > > (note: Archetypes are reference model independent, Need to be careful here: ADL is reference model-independent; any given archetype is reference model-dependent. > and RMIM's could > be made so. This equivalence does not involve changing reference models, > but of converting from an RIM based Visio-like diagram to an RIM > based ADL statement, or from a CEN RM based ADL to a CEN RM based > visio-like diagram) > how will this lead to shareable archetypes, given that archetypes are reference model-specific? The two kinds of archetypes now being used in openEHR are: * designed clinical archetypes, based on the openEHR reference model * integration archetypes, which are "mimics" of existing data sources, e.g. HL7v2 messages, and are 1:1 for each source definition they mimic; they are based on the CEN-like GenericEntry type in openEHR (a free hierarchy structure). Both kinds are shareable, but that's because the users all agree on the reference model concepts they are based on. In general, archetypes based on different reference models won't be shareable, although some complex transformation process might be doable. But we really have to ask why do that, when a less complex transformation is likely just to be at the data level; then at least the domain model space is clean comprehensible. > [wire format still to be investigated]. > > This is the results of our findings. It leads to a number of recommendations, > some of which are ITS specific, and some are proposed changes to the modeling > methodology. > > > Short Term changes - presented in detail at Boca Raton > ====================================================== > > ... > > 2. Modifications to the RBM methodology. > > We propose 4 small modifications to the RBM methodology: > > ... > > 2.3 Infrastructure Root attributes > Often the modeling process involves the creation of a number > if RIM classes that do not have a useful real world equivalent, > they are only required to meet the RIM grammar requirements. > There is no useful point for these classes to carry Infrastructure > root attributes such as nullFlavor. Often there is a cascade of > classes where any one of them could carry a nullFlavor, but all > the possible permutation of statements carries the same meaning > in the domain models. We propose to introduce new flags on the > RIM classes in a RBM that will mark these attributes as not appropriate > for some classes, where appropriate. > sounds tricky...there are already a lot of flags..... - thomas beale -- ___________________________________________________________________________________ CTO Ocean Informatics (http://www.OceanInformatics.biz) Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org) From rik.smithies at cfh.nhs.uk Thu Aug 24 18:36:51 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Thu, 24 Aug 2006 18:36:51 +0100 Subject: [New-ITS] Minutes from New ITS/Pre WGM meeeting 23/08/2006 Message-ID: <1A3D105C334EAE49BDDD93D8767573F50433A346@EXCHAQ2.nhsia.nhs.uk> Here are notes and minutes from yesterday, plus slides. Additions and corrections to me please. I will re-post to the members list in 24 hours. cheers Rik 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: HL7UK_PreWGM_ITS_Minutes_20060823.doc Type: application/msword Size: 74752 bytes Desc: HL7UK_PreWGM_ITS_Minutes_20060823.doc Url : http://lists.hl7.org.uk/pipermail/new-its/attachments/20060824/75995c5a/HL7UK_PreWGM_ITS_Minutes_20060823-0001.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: New ITS Investigationv0r2.ppt Type: application/vnd.ms-powerpoint Size: 41472 bytes Desc: New ITS Investigationv0r2.ppt Url : http://lists.hl7.org.uk/pipermail/new-its/attachments/20060824/75995c5a/NewITSInvestigationv0r2-0001.ppt From rik.smithies at cfh.nhs.uk Tue Aug 29 15:07:56 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Tue, 29 Aug 2006 15:07:56 +0100 Subject: [New-ITS] So, what's a XUM ? Message-ID: <1A3D105C334EAE49BDDD93D8767573F50433A960@EXCHAQ2.nhsia.nhs.uk> Is it 1 - a UML model of the whole message, that's an alternative to an RBM (RMIM) ? Is it 2 - a flattening profile (for instance the machine readable input script to a model flattening program eg. Robert's) ? I think we are intending 2, but that it is being confused with 1. XUM = "Name for a flattened, association-collapsed model derived from an RMIM" with "derived from" being the operative phrase. 2 could be generated from a marked-up RMIM in a modified designer. This wouldn't be a standalone model however, just a section of the RBM that dealt with what can be collapsed and what can't. Some more thoughts to stimulate discussion : Can you load in a XUM (type 2) to somewhere, perhaps an RMIM designer, to apply a standard flattening level to a compatible set of classes ? Does an un-flattened model eg CDA, have an implicit "null XUM" ? Could a slightly flattened model eg. a CFH GP Summary, have a CFH standard "flat clinical statement" XUM ? Could a UK PDS message have a highly flat XUM that is virtually what a hand crafted message would have come up with ? This is a bit like an ITS flavour generator, but with a model that describes it, so a way to get back to other flavours. cheers, Rik 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060829/82c74422/attachment.htm From Charlie at ramseysystems.co.uk Tue Aug 29 17:47:36 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Tue, 29 Aug 2006 17:47:36 +0100 Subject: [New-ITS] So, what's a XUM ? Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FC66@ramseysc1420.RamseyNet.local> Rik There is intended to be a XUM for every RBM, just as there is (or could be) a schema for every RBM in the XML ITS. The XUM for an RBM will be derived by a combination of rules and annotations on the RBM. I think that you are proposing naming different sets of rules for different degrees of flattening etc. This is going too far, and that if flattening is to happen we will have to agree on one set of rules+annotations that can be used. I would expect that the default behaviour would be no flattening without explicit annotations, so you could have unflattened CDA, mildly flattened GP summary, and strongly flattened PDS. Whether/why you would want to represent clinical statements in GP summary and clinical statements in CDA differently on the wire are questions that we do not have good answers to all the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay ________________________________ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Smithies Rik Sent: 29 August 2006 15:08 To: new-its at lists.hl7.org.uk Subject: [New-ITS] So, what's a XUM ? Is it 1 - a UML model of the whole message, that's an alternative to an RBM (RMIM) ? Is it 2 - a flattening profile (for instance the machine readable input script to a model flattening program eg. Robert's) ? I think we are intending 2, but that it is being confused with 1. XUM = "Name for a flattened, association-collapsed model derived from an RMIM" with "derived from" being the operative phrase. 2 could be generated from a marked-up RMIM in a modified designer. This wouldn't be a standalone model however, just a section of the RBM that dealt with what can be collapsed and what can't. Some more thoughts to stimulate discussion : Can you load in a XUM (type 2) to somewhere, perhaps an RMIM designer, to apply a standard flattening level to a compatible set of classes ? Does an un-flattened model eg CDA, have an implicit "null XUM" ? Could a slightly flattened model eg. a CFH GP Summary, have a CFH standard "flat clinical statement" XUM ? Could a UK PDS message have a highly flat XUM that is virtually what a hand crafted message would have come up with ? This is a bit like an ITS flavour generator, but with a model that describes it, so a way to get back to other flavours. cheers, Rik 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060829/eca9fb60/attachment.htm From rik.smithies at cfh.nhs.uk Wed Aug 30 15:31:52 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Wed, 30 Aug 2006 15:31:52 +0100 Subject: [New-ITS] So, what's a XUM ? Message-ID: <1A3D105C334EAE49BDDD93D8767573F5043C0EE3@EXCHAQ2.nhsia.nhs.uk> thanks Charlie, I think that clarifies things. >I think that you are proposing naming different sets of rules for different degrees of flattening etc. >This is going too far, and that if flattening is to happen we will have to agree on one set of rules+annotations that can be used. The rules would be fixed and would have all the possible flattenings in a given situation. But the annotations, unless they just follow the rules verbatim, will be ad hoc. In other words the same model could be annotated/flattened differently by different modellers, even if they all follow the basic rules for what can possibly be flattened. To avoid this, I was looking for a way to capture a set of annotations, in a model independent way (perhaps applicable to all clinical statement messages), so that you could more easily mandate the use of a given style of annotation. An "annotation template" perhaps. I suppose this is difficult to work through before we know what the rules are and what how the annotations affect them. cheers, Rik ________________________________ From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] Sent: 29 August 2006 17:48 To: Smithies Rik; new-its at lists.hl7.org.uk Subject: RE: [New-ITS] So, what's a XUM ? Rik There is intended to be a XUM for every RBM, just as there is (or could be) a schema for every RBM in the XML ITS. The XUM for an RBM will be derived by a combination of rules and annotations on the RBM. I think that you are proposing naming different sets of rules for different degrees of flattening etc. This is going too far, and that if flattening is to happen we will have to agree on one set of rules+annotations that can be used. I would expect that the default behaviour would be no flattening without explicit annotations, so you could have unflattened CDA, mildly flattened GP summary, and strongly flattened PDS. Whether/why you would want to represent clinical statements in GP summary and clinical statements in CDA differently on the wire are questions that we do not have good answers to all the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay ________________________________ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Smithies Rik Sent: 29 August 2006 15:08 To: new-its at lists.hl7.org.uk Subject: [New-ITS] So, what's a XUM ? Is it 1 - a UML model of the whole message, that's an alternative to an RBM (RMIM) ? Is it 2 - a flattening profile (for instance the machine readable input script to a model flattening program eg. Robert's) ? I think we are intending 2, but that it is being confused with 1. XUM = "Name for a flattened, association-collapsed model derived from an RMIM" with "derived from" being the operative phrase. 2 could be generated from a marked-up RMIM in a modified designer. This wouldn't be a standalone model however, just a section of the RBM that dealt with what can be collapsed and what can't. Some more thoughts to stimulate discussion : Can you load in a XUM (type 2) to somewhere, perhaps an RMIM designer, to apply a standard flattening level to a compatible set of classes ? Does an un-flattened model eg CDA, have an implicit "null XUM" ? Could a slightly flattened model eg. a CFH GP Summary, have a CFH standard "flat clinical statement" XUM ? Could a UK PDS message have a highly flat XUM that is virtually what a hand crafted message would have come up with ? This is a bit like an ITS flavour generator, but with a model that describes it, so a way to get back to other flavours. cheers, Rik 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060830/8a489cdb/attachment.htm From grahame at kestral.com.au Thu Aug 31 04:16:39 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Thu, 31 Aug 2006 13:16:39 +1000 Subject: [New-ITS] So, what's a XUM ? In-Reply-To: <1A3D105C334EAE49BDDD93D8767573F5043C0EE3@EXCHAQ2.nhsia.nhs.uk> References: <1A3D105C334EAE49BDDD93D8767573F5043C0EE3@EXCHAQ2.nhsia.nhs.uk> Message-ID: <44F65497.7020302@kestral.com.au> hi Rik I am hoping to propose a couple of modifications to the existing methodology that will allow us to, in your terms, "capture a set of annotations" The key question for whether things can and should be flattened is about the infrastructure root attributes. If they have meaning, then the concepts shouldn't really be flattened in the XML. If they don't, then the extra depth is appropriate. This is really a question of implementation decisions about the model. We could support the concept that different users could implement the model differently - and there is a powerful attraction to this. For me the outcome of the message simplification process is that one person's simplification is some one else's complication, unless we can come up with a new paradigm But it's also very obvious that allowing different implementers to implement the model differently is a very bad idea for interoperability. So we are still searching for the new paradigm.... Which brings me back to your question - what's a XUM? It's an *implementation view* of the RBM. This is not strictly an alternative, nor simply a flattening profile. Grahame Smithies Rik wrote: > thanks Charlie, I think that clarifies things. > >> I think that you are proposing naming different sets of rules for > different degrees of flattening etc. >> This is going too far, and that if flattening is to happen we will have > to agree on one set of rules+annotations that can be used. > > The rules would be fixed and would have all the possible flattenings in > a given situation. > > But the annotations, unless they just follow the rules verbatim, will be > ad hoc. In other words the same model could be annotated/flattened > differently by different modellers, even if they all follow the basic > rules for what can possibly be flattened. > > To avoid this, I was looking for a way to capture a set of annotations, > in a model independent way (perhaps applicable to all clinical statement > messages), so that you could more easily mandate the use of a given > style of annotation. An "annotation template" perhaps. > > I suppose this is difficult to work through before we know what the > rules are and what how the annotations affect them. > > cheers, > Rik > > > > > ________________________________ > > From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] > Sent: 29 August 2006 17:48 > To: Smithies Rik; new-its at lists.hl7.org.uk > Subject: RE: [New-ITS] So, what's a XUM ? > > > Rik > > There is intended to be a XUM for every RBM, just as there is > (or could be) a schema for every RBM in the XML ITS. The XUM for an RBM > will be derived by a combination of rules and annotations on the RBM. I > think that you are proposing naming different sets of rules for > different degrees of flattening etc. This is going too far, and that if > flattening is to happen we will have to agree on one set of > rules+annotations that can be used. > I would expect that the default behaviour would be no flattening > without explicit annotations, so you could have unflattened CDA, mildly > flattened GP summary, and strongly flattened PDS. Whether/why you would > want to represent clinical statements in GP summary and clinical > statements in CDA differently on the wire are questions that we do not > have good answers to > > all the best > > Charlie > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, > 23D Dogpole, Shrewsbury, Shropshire SY1 1ES > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > > > > > ________________________________ > > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Smithies Rik > Sent: 29 August 2006 15:08 > To: new-its at lists.hl7.org.uk > Subject: [New-ITS] So, what's a XUM ? > > > > Is it 1 > - a UML model of the whole message, that's an > alternative to an RBM (RMIM) ? > > > Is it 2 > - a flattening profile (for instance the machine > readable input script to a model flattening program eg. Robert's) ? > > I think we are intending 2, but that it is being > confused with 1. > > XUM = "Name for a flattened, association-collapsed model > derived from an RMIM" > with "derived from" being the operative phrase. > > 2 could be generated from a marked-up RMIM in a modified > designer. > This wouldn't be a standalone model however, just a > section of the RBM that dealt with what can be collapsed and what can't. > > Some more thoughts to stimulate discussion : > > Can you load in a XUM (type 2) to somewhere, perhaps > an RMIM designer, to apply a standard flattening level to a compatible > set of classes ? > > Does an un-flattened model eg CDA, have an implicit > "null XUM" ? > > Could a slightly flattened model eg. a CFH GP > Summary, have a CFH standard "flat clinical statement" XUM ? > > Could a UK PDS message have a highly flat XUM that > is virtually what a hand crafted message would have come up with ? > > This is a bit like an ITS flavour generator, but with a > model that describes it, so a way to get back to other flavours. > > cheers, > Rik > > 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. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From tim.benson at abies.co.uk Thu Aug 31 10:04:19 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Thu, 31 Aug 2006 10:04:19 +0100 Subject: [New-ITS] new its & related work: proposals for HL7 meeting In-Reply-To: <44F6527E.4090800@kestral.com.au> Message-ID: Hi Grahame, Thanks for this. I have only one substantive comment, which relates to your discussion about the use of domain analysis models. The term domain analysis model is not well defined in HL7 and has its own "baggage"; here I will use the term Functional Requirements Specification (FRS), which has a widely agreed understanding. The FRS should be stringently defined (strict, precise and exacting), and is a lot more than a glossary of business terms. Minimisation of implementation errors is paramount. Implementation errors are expensive to put right if identified during testing, and a threat to patient safety if not. RBMs, including XUMs, are only understandable by technical people, who have been trained in HL7, while the FRS should be understood by, or is capable of being explained to domain experts, who are not HL7-trained, with less risk of being mis-understood. The FRS should be an integral and normative part of the specification used in implementation, complementary to RBMs and XUMs. There is an element of chicken and egg. Logically, the FRS comes first and the RBMs and XUMs are derived from it. Others may argue that RBMs and XUMs can be described in implementation guides in such clarity and detail that anyone with a little technical knowledge can understand them without mis-understanding. This has been the approach up to now, as exemplified by the NHS CFH MIM. These may be improved by being even more careful and using improved ITS tools and models. My proposal is to use belt and braces ? all these good ideas together (i.e XUMs and tools and FRS). Best wishes Tim On 31/8/06 04:07 Grahame Grieve wrote: > hi all > > Ok, I wish to propose a way forwards for this work, and specifically, > what I think we should take to HL7 at Boca Raton. Apologies because I > know that not everyone has seen all this stuff. > > glossary > RBM - Rim Based Model > > Findings from investigation > =========================== > > 1. Use of domain analysis models > > We find that the domain analysis models are - and should > be - focused on domain analysis modeling. They may have > constructs more suited to implementation concerns than the > RBMs, but they might not either. The most useful thing that > they contain is domain specific names for domain specific > concepts that are lost in the RBM's. We firmly believe that > these names are important, and that they should be carried > into the process beyond domain analysis modelling. There is > other more useful ways to introduce these names than mapping > to the domain models. Nevertheless, mapping to domain analysis > models and requirements analysis is a useful exercise in it's > own right and the new eclipse RBM designer should include > support for this. > > 2. Implementation Considerations > > We find that most implementers judge HL7 V3 purely on the > strength of their implementation experience with the wire > format. There is a wide variety of implementation paths, but > few are prepared to make the kind of investment in basic V3 > infrastructure that the javaSIG makes. Implementers mostly > use the schema as a basis for their implementation, either > directly or indirectly. > > There is a number of key problems: > * that the XML is more deeply folded than the real world > problems call for. Each element carries implicit and > explicit processing requirements > * the schemas do not support code generation well, and particularly > reusability of the generated code. > * The transformation from the real world problem to the instance > is too hard to trace > * Some specific implementation concerns such as reuse of parts of > instances and easy to find and understand constraints on data type > properties are not catered for > > We note that all of these have their roots in the way that the > whole HL7 development process works, but there is a number of small > things that we can do to palliate these concerns, and these things > will most probably be acceptable to HL7 in the short term. These > things form our short term strategy (see below). There will be other > things that we propose in the long term (also see below). > > 3. Removal of fixed values > > We note that a significant portion of the message size is fixed > values. Removing the fixed values will significantly reduce the > message size (and "ugliness", though this is a nebulous concept). > But the consequence of this is that you must consult the message > definition to understand the messaging, and not all the implementers > in UK are doing this or are even happy to wear the performance > consequences of doing this. Should the fixed values be removed, > then some other approach - perhaps based around name stability - needs > to be found to allow for such generic processing (or sometimes known > as semantic processing). > > We note that the relevance of such generic processing depends on the > domain - in some highly transactional domains such as choose and book > the concept of generic processing doesn't really apply, where as for > clinical content, it is much more likely to apply. Some specific > observations: > - the longer a period of time data will persist for, the more > likely semantic processing will be used - but this is out of > scope for hl7 as an interchange format > - the division isn't by message type - it's by the domain of > the content. it would [probably] be wrong for clinical content > in choose and book to be represented differently simply because > choose and book messages are more transactional in nature. > - there is no hard and fast division- generic and specific processing > can be done on any content and there is a wide grey band in the middle. > > We still don't know whether we have to choose here, or if we have to > choose, what to choose. > > Note: it's likely that semantic based processing would be better suited > by simply serialising the RIM or the clinical statement and treating > all the other models as templates on this. We are still giving this question > further consideration. > > 4. CEN & HL7 harmonisation > > We find that broadly speaking, there is 3 areas of the model > development process where CEN and HL7 are perceived to differ: > * Reference Model > * Constraint mechanisms > * Wire format > > With regards to the reference model, we note that CEN are examining > the UML ITS datatypes with regard to their suitability as a CEN > standard in place of the currently proposed CEN data types. We also > note that there is strong similarities between the CEN reference > model and the HL7 clinical statement pattern. However we note that > within this scope, there is also subtle but significant differences > which lead to different implicit transformations of real world > problems to the models, and these may make further alignment very > difficult. Further investigation is needed. > > With regards to the Constraint mechanisms, we note that RBMs and > Archetypes are the same beast. Though they present differently, > the bulk of their content can be automatically converted from one > form to the other. Small enhancements in each format could be proposed > which would make the interconversion even easier. The new RBM designer > could not only interconvert between the 2 formats, it can present both > simultaneously much like an XML and a tree view in an XML editor. > > (note: Archetypes are reference model independent, and RMIM's could > be made so. This equivalence does not involve changing reference models, > but of converting from an RIM based Visio-like diagram to an RIM > based ADL statement, or from a CEN RM based ADL to a CEN RM based > visio-like diagram) > > [wire format still to be investigated]. > > This is the results of our findings. It leads to a number of recommendations, > some of which are ITS specific, and some are proposed changes to the modeling > methodology. > > > Short Term changes - presented in detail at Boca Raton > ====================================================== > > 1. UML ITS > > We will propose a new UML ITS. The UML ITS will be based on the following > principles: > * a UML Model and a schema will be produced from each RBM. these models > will be known as the "XUM" (for XML & UML Model). > * The "XUM" will be normative. We do not claim that these are the only schemas > or UML diagrams that could describe the wire format, but that these are > ones that will always be correct > * The UML Model and the schema will be isomorphic as much as possible > * The XUM will focus on a simple statement of the structure. More advanced > validation concepts will be in OCL/Schematron statements. Full > validation could only be provided by a specific software solution (as > for the XML ITS) > * The XUM will use a reference UML package/schema which defines common > enumerations > and data types. > * the UML diagrams will have a secondary presentation with appropriate > stereotypes to make the XML representation clear (using the XML for UML > profile from http://www.xmlmodeling.com as VHA are). > * the XUM will not represent any fixed or default values. These will be > documented > in the XUM but not part of the wire format > * the XUM will collapse nested models to some degree (see further discussion > below) > * because there will be an XUM for every model - including the RIM itself - it > will > be possible to choose an XUM and serialise at any level of genericity. > * XUM will not support schema or UML validation for templates. A specific > software > solution will be required for this. (any model will be able to be used as a > template. A DIM is a template on the RIM, etc. A template is any model > referenced > as a constraint on the model being serialised. The template may be > referenced in > the instance, or in a profile - note that a profile is also a model, so it > can be > serialised directly) > > [Still to be resolved: > * How do we handle model boundaries. Discussion in progress now > * Should we use business names in instances. discussion to kick off shortly. > * about different parts of the model being serialised at different levels. > This is a core question that is related to support for semantic processing > and > the question of name stability otherwise] > > 1a. Does the New UML ITS replace the existing XML ITS > > We believe that it is too early to say whether this would be appropriate. We > will propose that HL7 defers this decision. NHS should implement the UML ITS > in practice and then take the outcomes of this back to HL7 for further > consideration > of whether the UML ITS should be a replacement for the XML ITS or an > alternative. > > 2. Modifications to the RBM methodology. > > We propose 4 small modifications to the RBM methodology: > > 2.1: Business Names > Most artifacts in the diagrams can be given Business > names already - the MIF supports this, but support in > the tooling is haphazard and the feature is rarely used. > We propose explicity representing business names on the > diagram. For instance, with attributes the current > representation is something like > name [: Type] [constraints] > We could change it to > business name ["name"] [:Type] [constraints] > The presentation of business names on the diagrams would > go a long way to help non-RIM-experienced mere mortals > to navigate the RBMs. > > 2.2 Data Type property constraints > Currently there is no support for fixing values of datatypes. > As the models become more focused and less general, the > importance of fixing particular values increases. Rather then > using some constraint language, we will propose a syntax for > making positive statements about the values of the datatype > properties. The syntax will be derived from ADL as a simple > intuitive way to make these constraints. > > 2.3 Infrastructure Root attributes > Often the modeling process involves the creation of a number > if RIM classes that do not have a useful real world equivalent, > they are only required to meet the RIM grammar requirements. > There is no useful point for these classes to carry Infrastructure > root attributes such as nullFlavor. Often there is a cascade of > classes where any one of them could carry a nullFlavor, but all > the possible permutation of statements carries the same meaning > in the domain models. We propose to introduce new flags on the > RIM classes in a RBM that will mark these attributes as not appropriate > for some classes, where appropriate. > > 2.4 We propose to introduce a flag to specify whether the > class in question might be substituted by a reference to > another class (and possibly what the scope of that reference > might be). We can make everything referenceable in the ITS, > but this is unpalatable to the implementors, we'd like to be > selective about this. > > the new UML ITS would leverage all of these features to make the > implementation process easier. > > > Long Term changes > ================= > > 1. Archetypes > > We note the relationship between archetypes and RBM's discussed above. > Archetypes allow for more of the knowledge of a model to be expressed > in a computational form, but do not necessarily offer a better path to > implementation. We propose that HL7 investigate the use of archetypes > as an alternative authoring approach for HL7 models as part of the > new RBM designer. > > 2. Reference models - CEN & HL7 > > We propose to do further research ourselves (CFH) in association with > the CEN/HL7 harmonisation group, and to investigate how to resolve > the differences between the reference models through a combination of > mapping, changes to the reference models and other techniques. We will > bring our findings, and possibly change requests, forward to HL7 on an > ongoing basis. > > 3. Implementable Models and UML > > We will continue to align the implementable model work with the ongoing > research work with the intent that this implementation work will also form > a basis for offering an implementation path for archetypes and CEN 13606 > for vendors that do not wish or cannot adopt an entirely archetype based > approach (we believe that for the next 1 or 2 decades this will be the > bulk of healthcare application developers - if archetypes are the method > of expression, then practical ways of implementing them in legacy systems > must be found.) > > Grahame > > > From rik.smithies at cfh.nhs.uk Thu Aug 31 10:21:58 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Thu, 31 Aug 2006 10:21:58 +0100 Subject: [New-ITS] So, what's a XUM ? Message-ID: <1A3D105C334EAE49BDDD93D8767573F5043C1090@EXCHAQ2.nhsia.nhs.uk> Thanks Grahame I think the definition "an implementation view of a RIM based model" is a good one, and should allay some fears that this is all about circumventing the RIM. Rik > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of > Grahame Grieve > Sent: 31 August 2006 04:17 > To: Smithies Rik > Cc: charlie at ramseysystems.co.uk; new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] So, what's a XUM ? > > hi Rik > > I am hoping to propose a couple of modifications to the > existing methodology that will allow us to, in your terms, > "capture a set of annotations" > > The key question for whether things can and should be > flattened is about the infrastructure root attributes. If > they have meaning, then the concepts shouldn't really be > flattened in the XML. If they don't, then the extra depth is > appropriate. > > This is really a question of implementation decisions about > the model. We could support the concept that different users > could implement the model differently - and there is a > powerful attraction to this. For me the outcome of the > message simplification process is that one person's > simplification is some one else's complication, unless we can > come up with a new paradigm > > But it's also very obvious that allowing different > implementers to implement the model differently is a very bad > idea for interoperability. > So we are still searching for the new paradigm.... > > Which brings me back to your question - what's a XUM? It's an > *implementation view* of the RBM. This is not strictly an > alternative, nor simply a flattening profile. > > Grahame > > > Smithies Rik wrote: > > thanks Charlie, I think that clarifies things. > > > >> I think that you are proposing naming different sets of rules for > > different degrees of flattening etc. > >> This is going too far, and that if flattening is to happen we will > >> have > > to agree on one set of rules+annotations that can be used. > > > > The rules would be fixed and would have all the possible > flattenings > > in a given situation. > > > > But the annotations, unless they just follow the rules > verbatim, will > > be ad hoc. In other words the same model could be > annotated/flattened > > differently by different modellers, even if they all follow > the basic > > rules for what can possibly be flattened. > > > > To avoid this, I was looking for a way to capture a set of > > annotations, in a model independent way (perhaps applicable to all > > clinical statement messages), so that you could more easily mandate > > the use of a given style of annotation. An "annotation > template" perhaps. > > > > I suppose this is difficult to work through before we know what the > > rules are and what how the annotations affect them. > > > > cheers, > > Rik > > > > > > > > > > ________________________________ > > > > From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] > > Sent: 29 August 2006 17:48 > > To: Smithies Rik; new-its at lists.hl7.org.uk > > Subject: RE: [New-ITS] So, what's a XUM ? > > > > > > Rik > > > > There is intended to be a XUM for every RBM, just as > there is (or > > could be) a schema for every RBM in the XML ITS. The XUM > for an RBM > > will be derived by a combination of rules and annotations > on the RBM. > > I think that you are proposing naming different sets of rules for > > different degrees of flattening etc. This is going too > far, and that > > if flattening is to happen we will have to agree on one set of > > rules+annotations that can be used. > > I would expect that the default behaviour would be no > flattening > > without explicit annotations, so you could have unflattened CDA, > > mildly flattened GP summary, and strongly flattened PDS. > Whether/why > > you would want to represent clinical statements in GP summary and > > clinical statements in CDA differently on the wire are > questions that > > we do not have good answers to > > > > all the best > > > > Charlie > > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey > Systems Ltd, 23D > > Dogpole, Shrewsbury, Shropshire SY1 1ES > > > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > > > > > > > > > > > > > ________________________________ > > > > From: new-its-bounces at lists.hl7.org.uk > > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Smithies Rik > > Sent: 29 August 2006 15:08 > > To: new-its at lists.hl7.org.uk > > Subject: [New-ITS] So, what's a XUM ? > > > > > > > > Is it 1 > > - a UML model of the whole message, that's an > alternative to an RBM > > (RMIM) ? > > > > > > Is it 2 > > - a flattening profile (for instance the > machine readable input > > script to a model flattening program eg. Robert's) ? > > > > I think we are intending 2, but that it is > being confused with 1. > > > > XUM = "Name for a flattened, > association-collapsed model derived > > from an RMIM" > > with "derived from" being the operative phrase. > > > > 2 could be generated from a marked-up RMIM in a > modified designer. > > This wouldn't be a standalone model however, > just a section of the > > RBM that dealt with what can be collapsed and what can't. > > > > Some more thoughts to stimulate discussion : > > > > Can you load in a XUM (type 2) to > somewhere, perhaps an RMIM > > designer, to apply a standard flattening level to a > compatible set of > > classes ? > > > > Does an un-flattened model eg CDA, have an > implicit "null XUM" ? > > > > Could a slightly flattened model eg. a CFH > GP Summary, have a > > CFH standard "flat clinical statement" XUM ? > > > > Could a UK PDS message have a highly flat > XUM that is virtually > > what a hand crafted message would have come up with ? > > > > This is a bit like an ITS flavour generator, > but with a model that > > describes it, so a way to get back to other flavours. > > > > cheers, > > Rik > > > > 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. > > > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > New-ITS mailing list > > New-ITS at lists.hl7.org.uk > > http://lists.hl7.org.uk/mailman/listinfo/new-its > > -- > Grahame Grieve > CTO, Jiva Medical Software Integration Tools > CTO, Kestral Computing Healthcare Applications > From Robert.Worden at Charteris.com Thu Aug 31 11:57:23 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Thu, 31 Aug 2006 11:57:23 +0100 Subject: [New-ITS] Reshaping should be at the discretion of an implementor Message-ID: All - Allow me to dissent from a prevailing view about flattening/reshaping, as expressed by Charlie: >I think that you are proposing naming different sets of rules for different degrees of flattening etc. >This is going too far, and that if flattening is to happen we will have to agree on one set of rules+annotations that can be used. I think if we try to agree any set of rules that must be applied, then the reshaping will not achieve one of the main aims of the project - to reduce complexity for developers. As a crude measure of developer-perceived complexity, I use 'node count' - the number of distinct nodes in a message definition tree, allowing no repetitions or self-nesting. V3 node counts are very big. For a basic PA 'new Person' message, the node count is 1,129 (cutting off at V3 data types) or 77,550 (going to the leaves of the XML tree). For the lab 'Observation request' message the node count is 65,031 (going down to V3 data types) or 4,414,328 (going to leave of the tree). For a developer who wants to convey, say 100 data items in a message, he has to find the right V3 nodes amongst these thousands or millions to map onto - like a needle in a well-structured haystack. There is a huge impedance mismatch between his application and V3 (as between a domestic kettle and the national grid). That is why suppliers don't do it, unless someone pays them to. One of the main aims of flattening/reshaping is to reduce the impedance mismatch for developers. Flattening one association in a message definition will reduce the node count by precisely 1. Flattening on its own does nothing to reduce complexity as perceived by developers - it has no perceptible effect on node count, and it removes a lot of the tree structure which helps people find their way around (it makes the haystack less well structured, but does not reduce its size). Flattening and renaming is only effective when done in combination with restricting the RMIM, to reduce the node count. This cannot be done in any automatic way, or in a way decreed by HL7 committees - it has to be done by a super-implementor like CfH, knowing the applications they need to integrate. My proposal is to give implementers complete freedom to flatten, restrict and reshape as much as they like, to make messages which work for them and can be mapped to easily by their suppliers. These messages can always be reflated to fully compliant V3, using reliable automatic translation based on the mappings. Implementors can produce full V3 on demand, but don't need to send it always over the wire. Put another way: producing V3 via an intermediate XML is what HL7 already encourages implementers to do. A reshaped, flattened ITS is just such an intermediate form. We are just telling HL7 that an implementor, with a group of communicating applications, may choose to use the intermediate form over the wire between those applications, and only produce full V3 on demand, eg to prove conformance, or to communicate to other applications outside his group. HL7 should be constraining the semantics of what goes over the wire, not its physical form. (And if you are worried about performance costs of reflating to full XML ITS - performance is an implementor issue. Let implementors solve it as they think fit - not by decree from HL7) Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/b6522844/attachment.htm From rik.smithies at cfh.nhs.uk Thu Aug 31 12:26:28 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Thu, 31 Aug 2006 12:26:28 +0100 Subject: [New-ITS] Reshaping should be at the discretion of an implementor Message-ID: <1A3D105C334EAE49BDDD93D8767573F5043C118B@EXCHAQ2.nhsia.nhs.uk> hi Robert I would say that if there is a free for all on flattening and reshaping, then at the least we need a way to "can" certain profiles, to reduce the number of ways that are in active use, and prevent small incompatibilities creeping in. Allowing people to get back to "pure" XML ITS is one thing, but making this the only practical route to process several messages (all flattened slightly differently) isn't good. I think this transformation overhead is something we need to take into account. Software compression isn't popular, and has a similar overhead. If that was feasible then size issues, another of the main drivers for all this, would disappear at a stroke. >Flattening one association in a message definition will reduce the node count by precisely 1. Surely this will reduce the node count by more than 1 when the attributes and datatypes of that association are considered, as they presumably were in the numbers leading up to that statement. cheers, Rik ________________________________ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden Sent: 31 August 2006 11:57 To: new-its at lists.hl7.org.uk Subject: [New-ITS] Reshaping should be at the discretion of an implementor All - Allow me to dissent from a prevailing view about flattening/reshaping, as expressed by Charlie: >I think that you are proposing naming different sets of rules for different degrees of flattening etc. >This is going too far, and that if flattening is to happen we will have to agree on one set of rules+annotations that can be used. I think if we try to agree any set of rules that must be applied, then the reshaping will not achieve one of the main aims of the project - to reduce complexity for developers. As a crude measure of developer-perceived complexity, I use 'node count' - the number of distinct nodes in a message definition tree, allowing no repetitions or self-nesting. V3 node counts are very big. For a basic PA 'new Person' message, the node count is 1,129 (cutting off at V3 data types) or 77,550 (going to the leaves of the XML tree). For the lab 'Observation request' message the node count is 65,031 (going down to V3 data types) or 4,414,328 (going to leave of the tree). For a developer who wants to convey, say 100 data items in a message, he has to find the right V3 nodes amongst these thousands or millions to map onto - like a needle in a well-structured haystack. There is a huge impedance mismatch between his application and V3 (as between a domestic kettle and the national grid). That is why suppliers don't do it, unless someone pays them to. One of the main aims of flattening/reshaping is to reduce the impedance mismatch for developers. Flattening one association in a message definition will reduce the node count by precisely 1. Flattening on its own does nothing to reduce complexity as perceived by developers - it has no perceptible effect on node count, and it removes a lot of the tree structure which helps people find their way around (it makes the haystack less well structured, but does not reduce its size). Flattening and renaming is only effective when done in combination with restricting the RMIM, to reduce the node count. This cannot be done in any automatic way, or in a way decreed by HL7 committees - it has to be done by a super-implementor like CfH, knowing the applications they need to integrate. My proposal is to give implementers complete freedom to flatten, restrict and reshape as much as they like, to make messages which work for them and can be mapped to easily by their suppliers. These messages can always be reflated to fully compliant V3, using reliable automatic translation based on the mappings. Implementors can produce full V3 on demand, but don't need to send it always over the wire. Put another way: producing V3 via an intermediate XML is what HL7 already encourages implementers to do. A reshaped, flattened ITS is just such an intermediate form. We are just telling HL7 that an implementor, with a group of communicating applications, may choose to use the intermediate form over the wire between those applications, and only produce full V3 on demand, eg to prove conformance, or to communicate to other applications outside his group. HL7 should be constraining the semantics of what goes over the wire, not its physical form. (And if you are worried about performance costs of reflating to full XML ITS - performance is an implementor issue. Let implementors solve it as they think fit - not by decree from HL7) Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/60b99efe/attachment-0001.htm From david at clininfo.co.uk Thu Aug 31 13:17:57 2006 From: david at clininfo.co.uk (David Markwell) Date: Thu, 31 Aug 2006 13:17:57 +0100 Subject: [New-ITS] Reshaping should be at the discretion of an implementor In-Reply-To: Message-ID: I am far from convinced of the node count as being anything other than a count of nodes. The assumption that it is a proxy for complexity seems a little like suggesting that a staircase is simpler if it has only three steps on it. Fine if you only need to set up half a metre or so but hopeless for reaching my attic. Clearly 1000 steps would be too many (no room for feet) but the issue is not the raw node count but rather appropriateness of the node code to the nature of the information. As an experiment consider a simple and fast way to reduce the node count. Re-engineer most of the current datatypes as attributes rather then elements. The CD datatype could for instance practically vanish into a single attribute containing an expression in SNOMED compositional grammar. Some version of the same idea could be applied to the II and the TS the PQ, the IVL and the IVL etc. Before you know where you are you have cut the node count by a factor of 10. The content of the attribute look like fragments of HL7v2 messages perhaps but hey we just shrunk the node count. Have this really reduced complexity. Probably not and certainly not by as much as the node count was reduced. What you are left with is complexity hidden from the XML parsers waiting to be unwrapped by some other tool. I am willing to be convinced that XML is an inefficient means of representing complexity but as yet the evidence is lacking. In my own experiments XML structures can be parsed in roughly the same time as other more compact structures ... simply because the XML structures are more explicit. Naturally others may disagree with this assertion especially if assumption are based on DOM dependency. Parsing very large XML is possible and tractable. When I refer to very large I mean circa 5 MegaNodes and more than 200 Mb in size (way above most messages I hope). Obviously its a killer putting it all in the DOM but using SAX and only DOM-ing at fragments as needed works rather well. I am not suggesting this precise method is one that is needed with messages but I am suggesting that the fixed mind set of size and node count => complexity => bad => flatten may be flawed by reliance of a particular way of doing business with XML. At the same time move to fixed/default attributes seems to create a greater requirement for processing in exchange for a small saving in space. In my view the simplest way to reduce complexity would be to depend on the attributes and the model of the RIM classes and the complexity lies in difference not in repetition. Kind Regards David Markwell Mailto:david at clininfo.co.uk _____ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden Sent: 31 August 2006 11:57 To: new-its at lists.hl7.org.uk Subject: [New-ITS] Reshaping should be at the discretion of an implementor All - Allow me to dissent from a prevailing view about flattening/reshaping, as expressed by Charlie: >I think that you are proposing naming different sets of rules for different degrees of flattening etc. >This is going too far, and that if flattening is to happen we will have to agree on one set of rules+annotations that can be used. I think if we try to agree any set of rules that must be applied, then the reshaping will not achieve one of the main aims of the project - to reduce complexity for developers. As a crude measure of developer-perceived complexity, I use 'node count' - the number of distinct nodes in a message definition tree, allowing no repetitions or self-nesting. V3 node counts are very big. For a basic PA 'new Person' message, the node count is 1,129 (cutting off at V3 data types) or 77,550 (going to the leaves of the XML tree). For the lab 'Observation request' message the node count is 65,031 (going down to V3 data types) or 4,414,328 (going to leave of the tree). For a developer who wants to convey, say 100 data items in a message, he has to find the right V3 nodes amongst these thousands or millions to map onto - like a needle in a well-structured haystack. There is a huge impedance mismatch between his application and V3 (as between a domestic kettle and the national grid). That is why suppliers don't do it, unless someone pays them to. One of the main aims of flattening/reshaping is to reduce the impedance mismatch for developers. Flattening one association in a message definition will reduce the node count by precisely 1. Flattening on its own does nothing to reduce complexity as perceived by developers - it has no perceptible effect on node count, and it removes a lot of the tree structure which helps people find their way around (it makes the haystack less well structured, but does not reduce its size). Flattening and renaming is only effective when done in combination with restricting the RMIM, to reduce the node count. This cannot be done in any automatic way, or in a way decreed by HL7 committees - it has to be done by a super-implementor like CfH, knowing the applications they need to integrate. My proposal is to give implementers complete freedom to flatten, restrict and reshape as much as they like, to make messages which work for them and can be mapped to easily by their suppliers. These messages can always be reflated to fully compliant V3, using reliable automatic translation based on the mappings. Implementors can produce full V3 on demand, but don't need to send it always over the wire. Put another way: producing V3 via an intermediate XML is what HL7 already encourages implementers to do. A reshaped, flattened ITS is just such an intermediate form. We are just telling HL7 that an implementor, with a group of communicating applications, may choose to use the intermediate form over the wire between those applications, and only produce full V3 on demand, eg to prove conformance, or to communicate to other applications outside his group. HL7 should be constraining the semantics of what goes over the wire, not its physical form. (And if you are worried about performance costs of reflating to full XML ITS - performance is an implementor issue. Let implementors solve it as they think fit - not by decree from HL7) Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/c967a9c7/attachment.htm From Robert.Worden at Charteris.com Thu Aug 31 14:03:20 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Thu, 31 Aug 2006 14:03:20 +0100 Subject: [New-ITS] Reshaping should be at the discretion of an implementor In-Reply-To: <1A3D105C334EAE49BDDD93D8767573F5043C118B@EXCHAQ2.nhsia.nhs.uk> Message-ID: Hi Rik - I do not believe there would be a free-for-all, nor do I believe there would be any performance 'hit', for the following reasons: As a message receiver, you can always insist on receiving only full ITS messages; the sender must be able to send them, if he is V3 conformant. He may choose to do this by creating his local flattened messages, then reflating them; he can always do this easily, because the required transformations come out of the mappings, and are always reliable. The performance cost is his to bear, and it is his choice how to do it. Similarly as a message sender, you can always insist on sending only full V3 ITS; the receiver has to receive them , if he is V3 conformant, and he can do so reliably using automatically generated transforms... etc. Flattened messages only pass between consenting parties - where both parties have agreed that since they are reflating/deflating V3 from the same flattened form, they might as well miss out the 2 intermediate transformations to and from full V3 form. They can do this 'behind closed doors' using any flattened form they like, provided they can both present full V3 ITS to third parties when required to. No incompatibilities arise. I will pursue the analogy no further. In practice, CfH would 'persuade' all its suppliers to consent to certain flattened forms. They should not need much persuading, ads it should make it much easier for them to read and write messages. They could still talk to any V3 party outside CfH with no problem. Not having to use full V3 ITS on the wire is a big performance plus. What about the performance hit of having to transform to and from V3 'on demand' to talk to third parties? This will be no bigger than it was before. Already, HL7 encourages implementers to produce and consume V3 via local intermediate XML forms - so implementers already have the performance cost of transforming between some local form and V3. In this respect, flattened local forms are no better or worse than ad-hoc local XML forms used now. On your last point - I had always taken pure flattening to mean: merge the attributes of the two classes, changing the names to avoid confusion. Then the node count drops by 1. But even if you decided to drop the attributes of one merged class, is, say, dropping 5 nodes in 4 million much better than 1 in 4 million? You would only do it for glue classes with few attributes. I think that any flattening done by HL7 decree or by automatic rule would be a waste of time. The new message format would be no easier to map to than the old. You have to leave reshaping to implementers, who know what problems they have to solve. They know the constraints which will enable much simpler messages with lower node counts - TCs don't. And give implementors the freedom to solve their performance problems, as they think best. Cheers Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. ________________________________ From: Smithies Rik [mailto:rik.smithies at cfh.nhs.uk] Sent: 31 August 2006 12:26 To: Robert Worden; new-its at lists.hl7.org.uk Subject: RE: [New-ITS] Reshaping should be at the discretion of an implementor hi Robert I would say that if there is a free for all on flattening and reshaping, then at the least we need a way to "can" certain profiles, to reduce the number of ways that are in active use, and prevent small incompatibilities creeping in. Allowing people to get back to "pure" XML ITS is one thing, but making this the only practical route to process several messages (all flattened slightly differently) isn't good. I think this transformation overhead is something we need to take into account. Software compression isn't popular, and has a similar overhead. If that was feasible then size issues, another of the main drivers for all this, would disappear at a stroke. >Flattening one association in a message definition will reduce the node count by precisely 1. Surely this will reduce the node count by more than 1 when the attributes and datatypes of that association are considered, as they presumably were in the numbers leading up to that statement. cheers, Rik ________________________________ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden Sent: 31 August 2006 11:57 To: new-its at lists.hl7.org.uk Subject: [New-ITS] Reshaping should be at the discretion of an implementor All - Allow me to dissent from a prevailing view about flattening/reshaping, as expressed by Charlie: >I think that you are proposing naming different sets of rules for different degrees of flattening etc. >This is going too far, and that if flattening is to happen we will have to agree on one set of rules+annotations that can be used. I think if we try to agree any set of rules that must be applied, then the reshaping will not achieve one of the main aims of the project - to reduce complexity for developers. As a crude measure of developer-perceived complexity, I use 'node count' - the number of distinct nodes in a message definition tree, allowing no repetitions or self-nesting. V3 node counts are very big. For a basic PA 'new Person' message, the node count is 1,129 (cutting off at V3 data types) or 77,550 (going to the leaves of the XML tree). For the lab 'Observation request' message the node count is 65,031 (going down to V3 data types) or 4,414,328 (going to leave of the tree). For a developer who wants to convey, say 100 data items in a message, he has to find the right V3 nodes amongst these thousands or millions to map onto - like a needle in a well-structured haystack. There is a huge impedance mismatch between his application and V3 (as between a domestic kettle and the national grid). That is why suppliers don't do it, unless someone pays them to. One of the main aims of flattening/reshaping is to reduce the impedance mismatch for developers. Flattening one association in a message definition will reduce the node count by precisely 1. Flattening on its own does nothing to reduce complexity as perceived by developers - it has no perceptible effect on node count, and it removes a lot of the tree structure which helps people find their way around (it makes the haystack less well structured, but does not reduce its size). Flattening and renaming is only effective when done in combination with restricting the RMIM, to reduce the node count. This cannot be done in any automatic way, or in a way decreed by HL7 committees - it has to be done by a super-implementor like CfH, knowing the applications they need to integrate. My proposal is to give implementers complete freedom to flatten, restrict and reshape as much as they like, to make messages which work for them and can be mapped to easily by their suppliers. These messages can always be reflated to fully compliant V3, using reliable automatic translation based on the mappings. Implementors can produce full V3 on demand, but don't need to send it always over the wire. Put another way: producing V3 via an intermediate XML is what HL7 already encourages implementers to do. A reshaped, flattened ITS is just such an intermediate form. We are just telling HL7 that an implementor, with a group of communicating applications, may choose to use the intermediate form over the wire between those applications, and only produce full V3 on demand, eg to prove conformance, or to communicate to other applications outside his group. HL7 should be constraining the semantics of what goes over the wire, not its physical form. (And if you are worried about performance costs of reflating to full XML ITS - performance is an implementor issue. Let implementors solve it as they think fit - not by decree from HL7) Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ _________________________________________________________________ This message to Charteris plc has been checked for viruses http://www.charteris.com/ 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. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/1f518888/attachment-0001.htm From david at clininfo.co.uk Thu Aug 31 14:52:25 2006 From: david at clininfo.co.uk (David Markwell) Date: Thu, 31 Aug 2006 14:52:25 +0100 Subject: [New-ITS] Considering the XUM and what ITS worth In-Reply-To: <1A3D105C334EAE49BDDD93D8767573F5043C1090@EXCHAQ2.nhsia.nhs.uk> Message-ID: Another view ... * Each new and different model creates more complexity. * Each new acronym creates more complexity * Each new and different element name creates new complexity. So XUM scores 2 instants additions to the complexity count it adds one or two models and acronyms. It seems from some discussions that the element name count is also set to rise with the proposed new ITS so that three strikes. If this bought a massive simplification elsewhere it might be worth it but rather than simplification we have many potential implementation level models and a great deal of mapping to be done. So I think that "more is less" in terms of progress. More new ideas for experts to document clearly. More for them to disagree about. More to teach to people who just want it to work. More to be misinterpreted. Less time and energy to address the practicalities of progress. There is of course a need for business analysis and the differences it creates. However, my experience over the last few years suggests the mistake we have made is failing to to keep these differences and constraint at one level. By allowing them to permeate through everything right down to the instance on the wire we have added complexity. What we have sought to make clear has been obscured in an illusion of familiar names that distract from understanding and consistently processing the real information. If we are trying to reduce the gap between business analysis and end implementation the first step in my views is to contain the differentiation at one level and map to a common end model and the RIM for all its limitations and irritations is as good a starting point as we are likely to get consensus on. I am suggesting ... * Less different models ... Because the only differences need to be is at the top business level and how they map to and constrain a single instance level model. * No new acronyms (well maybe some new ones but an opportunity to toast some in the current stack) * Less different element names. Lets assume a one for one RIM physical class to instance level element name ratio as a starting point for any new ITS. This way we make sure the model really is driven by the vocabulary (both the internal HL7 vocab and the external terminologies). The whole idea of fixing and defaulting attributes is a sign of the dependence on an uncontrolled taxonomy of element names. When I hear people suggesting more business names at the instance level I feel a bit of deja-vue and a tinge of regret that I am at least in part responsible for starting this direction of travel five years ago. If we instantiate the RIM taxonomy as the XML instance taxonomy we remove several layers all at once. I am not saying that there is no problem with the status quo. We all know there is a problem. However, in medical speak the current new ITS work seems me to be addressing the referred pain rather than the underlying cause. Worse still the treatment suggested seems to be application of measure that more likely to worsen than remedy the underlying malaise. Adding more layers of models is not unlike piling blankets on a child shivering with a fever - it may add short term comfort but it is unlikely to lower the temperature and may cause convulsions. If you ask a blanket weaver to provide a remedy for shivering it is understandable that they offer another blanket. So I would suggest that the idea that "less may be more" should be considered. So here in outline is my own sense of what needs to be done. A sort of aspirin remedy and a gentle stripping away of the blankets while assessing the need for antibiotics. _____ 1) Go back to primitive RIM based V3 at instance level by which I mean. i) No business names in the instances. ii) Physical RIM level class ontology directly reflected in XML element names.* iii) classCode/moodCode/typeCode structural code driven next level ontology show in attributes which would be mandatory in all instances (as they determine next level of semantics) iv) Table driven codes/terminologies (HL7, SNOMED CT, and others as needed) representing detailed semantics *ALL instance elements named as RIM physical class names (not just backbone) This provides a complete high level attribute content validation using a single generic H7v3 schema. All other validation is business model driven (see 2) _____ 2) A single model layer linking this to the domain business models for i) static information content [a subset of 3 i plus communication specific information] ii) dynamic interactions [linked to 3 ii] _____ 3) A separate but interrelated statement of the information architecture and high-level behaviour of applications that serve application roles in terms of: i) static information content * Superset of all 2 i without the communication specific information but with local non-communicated information and ii) dynamic behaviour in terms of triggers and receiver responsibilities ii) dynamic behaviour in relation to content updating Although not strictly part of the communication specification this part 3 is essential for addressing business needs through communication. In the case clinical systems this is effectively the kernel of an EHR architecture and functional model. _____ Kind Regards David Markwell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/533d0a25/attachment.htm From Robert.Worden at Charteris.com Thu Aug 31 15:40:03 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Thu, 31 Aug 2006 15:40:03 +0100 Subject: [New-ITS] Complexity Measures Message-ID: David Markwell wrote: * I am far from convinced of the node count as being anything other than a count of nodes. He went on to give reasons why node counts as a measure of complexity may be misleading by factors of the order ten or so, and then went into performance considerations of DOM and SAX etc. So let me try to clarify why in my view, both of these arguments miss the point. V3 has performance issues, but I am far more concerned about the developer cost of implementing, testing and maintaining messages. If you are worried about message size, you can always zip them. But I am concerned about why suppliers have embraced V2, whereas they are hanging back from V3. This seems to me a much more serious issue for HL7 than performance. Set the performance issues on one side. Implementing V3 is hard, in part because the messages are big and complex - so much so that it is hard for an implementor just to find his way around a message to find where some data item should be put. This is the needle in a haystack problem. It seems to me that V2 got this about right, but V3 has not. So I introduced the idea of node count as a measure of the problem. It is, I know, a crude measure of message complexity, but it is a measure. Historically, measures of software complexity are always hard to define. Whether it is lines of code, or function points, or anything else, it is always possible for someone to say 'your measure misses the point because..'; 'I could use fewer lines of code, but longer ones' .. or 'I could cram a big data structure into each XML attribute' or whatever. That is not the point. If this measure is too crude, please someone suggest a better one, and post on this list some real numbers for V3 messages in that measure. I will bet whatever sensible measure is proposed, the V3 lab 'observation request' will still turn out to be huge. Even with David's suggestion of cramming every V3 data type into one attribute, it is still 65,000. What V2 message has 65,000 nodes? I am really not concerned with factors of ten - I am worried about factors of a hundred or a thousand. My concerns are on a log scale. It is all very well for V3 enthusiasts to say 'It may be big in node count, but it is really very elegant and if you will only understand it, it is quite easy...' - but the market does not seem to agree. We need some way to bridge the complexity gap between V3 and the applications that will use it. Having a useful measure of the gap would be a start. Suggestions please. Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/1d889978/attachment-0001.htm From tim.benson at abies.co.uk Thu Aug 31 16:13:59 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Thu, 31 Aug 2006 16:13:59 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: Message-ID: The real reason why complexity and size matter is that both are positively correlated to the number of implementation errors. All other things being equal, the numbers of errors are related to both size and complexity. V3 produces large documents and they are complex to understand; for example the actual meaning of an activityTime may depend on classCode, moodCode, code, status and even value. If implementation errors are caught in the testing process, then it simply adds to the costs and delays in implementing, testing and maintaining messages. If they are not spotted by the test process (and the combinatorial explosion of errors is large), then they may not be identified until patient safety has been jeopardised. Size and complexity are proxy measures, and what always matters most is to avoid making implementation errors. That requires specifications which are not mis-understood by the human beings responsible for implementing and using them. When considering the human-beings, we need to recognise that some stakeholders do understand RBMs and XML, whilst others do not; we need to meet the needs of all stakeholders if we are to reduce implementation errors. Tim On 31/8/06 15:40 Robert Worden wrote: > David Markwell wrote: > > ? I am far from convinced of the node count as being anything other than > a count of nodes. > > He went on to give reasons why node counts as a measure of complexity may be > misleading by factors of the order ten or so, and then went into performance > considerations of DOM and SAX etc. So let me try to clarify why in my view, > both of these arguments miss the point. > > V3 has performance issues, but I am far more concerned about the developer > cost of implementing, testing and maintaining messages. If you are worried > about message size, you can always zip them. But I am concerned about why > suppliers have embraced V2, whereas they are hanging back from V3. This seems > to me a much more serious issue for HL7 than performance. Set the performance > issues on one side. > > Implementing V3 is hard, in part because the messages are big and complex ? so > much so that it is hard for an implementor just to find his way around a > message to find where some data item should be put. This is the needle in a > haystack problem. It seems to me that V2 got this about right, but V3 has not. > > So I introduced the idea of node count as a measure of the problem. It is, I > know, a crude measure of message complexity, but it is a measure. > Historically, measures of software complexity are always hard to define. > Whether it is lines of code, or function points, or anything else, it is > always possible for someone to say ?your measure misses the point because..?; > ?I could use fewer lines of code, but longer ones? .. or ?I could cram a big > data structure into each XML attribute? or whatever. That is not the point. If > this measure is too crude, please someone suggest a better one, and post on > this list some real numbers for V3 messages in that measure. I will bet > whatever sensible measure is proposed, the V3 lab ?observation request? will > still turn out to be huge. Even with David?s suggestion of cramming every V3 > data type into one attribute, it is still 65,000. What V2 message has 65,000 > nodes? > > I am really not concerned with factors of ten ? I am worried about factors of > a hundred or a thousand. My concerns are on a log scale. It is all very well > for V3 enthusiasts to say ?It may be big in node count, but it is really very > elegant and if you will only understand it, it is quite easy?? ? but the > market does not seem to agree. We need some way to bridge the complexity gap > between V3 and the applications that will use it. Having a useful measure of > the gap would be a start. Suggestions please. > > Robert > > Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN > > phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 > > *************************** E-mail confidentiality notice > ******************************* > > This message is intended for the addressee only. It is private, confidential > and may contain > information of a proprietary nature. If you have received this message in > error, please notify > us and remove it from your system. > > > _________________________________________________________________ > This message from Charteris plc has been checked for viruses > http://www.charteris.com/ > > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/95f3c9f6/attachment.htm From david at clininfo.co.uk Thu Aug 31 16:59:29 2006 From: david at clininfo.co.uk (David Markwell) Date: Thu, 31 Aug 2006 16:59:29 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: Message-ID: Robert As per my other message to the list I am not saying there is no problem. However, I do not think the problem is node numbers so much as the complexity that arises from the multiplicity of different element names that each require different understanding and management. Thus my sense is that node variability rather then node count is the bigger issue. Any piece of software can process a million bytes in a flash if each one is processed in the same way but the more exceptions that need to be considered the more processing becomes capable of error. In my view the really interesting count would be the number of differently named clones of the same RIM class that were used with slightly different processing rules. This in my view is the effect of allowing naming changes etc to be carried from the business right down to the wire. In this respect I would agree that within its limits V2 with its OBX and OBR had much merit. As one of the those who in the past celebrated the idea of being able to produce some connection between the domain business names and the XML instances I am by no means feeling smug about this. Instead I am pointing to what I believe in retrospect was a mistake and arguing following this broad path (as per recent CFH MIMs "Weight" "BloodPressure", etc) will lead us further into complexity and chaos. Naturally there is a need to identify such information at the business level and to indicate how it should be conveyed - to the extent that general guidance is inadequate for common data set. However, calling this a different element merely adds another twist to the spiral of complexity into which we appear to be descending. _____ BTW - I was not arguing for the datatype --> attribute move merely seeing this as a convenient way to illustrate that decimating the node count may have no affect on the true complexity. _____ PS: I am sorry that I probably missed this at an earlier point. However, since you quote 65,000 after an hypothetical 10 fold reduction this implies you start out with an example with 650,000 nodes. Could you provide this example or better still a summary of the information it contains and the distribution of the node count (i.e.. types of nodes) I realise this is information you have probably already provided but if it is easily to hand it might help me to understand your issues. Kind Regards David Markwell Mailto:david at clininfo.co.uk _____ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden Sent: 31 August 2006 15:40 To: new-its at lists.hl7.org.uk Subject: [New-ITS] Complexity Measures David Markwell wrote: * I am far from convinced of the node count as being anything other than a count of nodes. He went on to give reasons why node counts as a measure of complexity may be misleading by factors of the order ten or so, and then went into performance considerations of DOM and SAX etc. So let me try to clarify why in my view, both of these arguments miss the point. V3 has performance issues, but I am far more concerned about the developer cost of implementing, testing and maintaining messages. If you are worried about message size, you can always zip them. But I am concerned about why suppliers have embraced V2, whereas they are hanging back from V3. This seems to me a much more serious issue for HL7 than performance. Set the performance issues on one side. Implementing V3 is hard, in part because the messages are big and complex - so much so that it is hard for an implementor just to find his way around a message to find where some data item should be put. This is the needle in a haystack problem. It seems to me that V2 got this about right, but V3 has not. So I introduced the idea of node count as a measure of the problem. It is, I know, a crude measure of message complexity, but it is a measure. Historically, measures of software complexity are always hard to define. Whether it is lines of code, or function points, or anything else, it is always possible for someone to say 'your measure misses the point because..'; 'I could use fewer lines of code, but longer ones' .. or 'I could cram a big data structure into each XML attribute' or whatever. That is not the point. If this measure is too crude, please someone suggest a better one, and post on this list some real numbers for V3 messages in that measure. I will bet whatever sensible measure is proposed, the V3 lab 'observation request' will still turn out to be huge. Even with David's suggestion of cramming every V3 data type into one attribute, it is still 65,000. What V2 message has 65,000 nodes? I am really not concerned with factors of ten - I am worried about factors of a hundred or a thousand. My concerns are on a log scale. It is all very well for V3 enthusiasts to say 'It may be big in node count, but it is really very elegant and if you will only understand it, it is quite easy.' - but the market does not seem to agree. We need some way to bridge the complexity gap between V3 and the applications that will use it. Having a useful measure of the gap would be a start. Suggestions please. Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/d91e0b1a/attachment-0001.htm From Robert.Worden at Charteris.com Thu Aug 31 17:50:05 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Thu, 31 Aug 2006 17:50:05 +0100 Subject: [New-ITS] Node counts Message-ID: David - Just to clarify what I have counted, because we seem to have got wires crossed on factors of 10. The things I am counting are distinct nodes in a message definition, not allowing repeats of nodes or self-nesting. Put another way, I am counting distinct XPaths in the message definition, short of self-nesting. Inasmuch as each XPath is a name for a set of nodes, that is sort-of counting the names of nodes in the message. I made these counts in two ways: 1. going right down to leaf nodes of the XML 2. stopping at V3 data type nodes, counting each V3 data type top node as 1. Doing this for a couple of messages, I got: - PA 'new person' - 1100 XPaths down to data type nodes, 77000 nodes down to leaves - Lab 'observation request' 65,000 XPaths down to data type nodes, 4.4 million down to leaves. So the 65,000 is not 10% of anything - sorry to have misled you. BTW the lab number only includes 1 of the 4 choices at the top. For both messages, the average multiplier from data type nodes to leaves is 70. This is dominated by a few large data types which have large counts on leaf nodes: type: PQ; count: 175 type: IVL_TS; count: 548 type: AD; count: 135 type: PN; count: 592 type: CV; count: 129 type: CR; count: 213 type: ON; count: 576 type: CE; count: 383 type: CD; count: 129 type: PQR; count: 171 type: EN; count: 592 When you weight these by occurrences, there are a few main culprits: Out of the 4.4 million leaf nodes in the lab message: type: ON; count: 315072 type: II; count: 108030 type: CE; count: 1657241 type: IVL_TS; count: 980920 type: AD; count: 238545 type: EN; count: 873792 Now I guess the big data types are almost never nearly 500 nodes in instances, and simplified versions can be learned by developers for use in 99% of cases; so the huge numbers of leaves (average 70 per data type) does not worry me too much. But 65,000 separate XPaths in one message, before you get down to data types, does worry me. By the way, I was really quoting these numbers to agree with you - if node count is at all sensible as a measure of complexity, then any automatic or centrally decreed message flattening will do no good at all, because it hardly reduces node count. I don't think flattening per se will reduce the developer learning curve. I agree with you that HL7 should not increase the burden of message formats it imposes on itself or its implementers. It should let them do their own message reshaping when they want to - knowing they can always 'reflate' messages to be V3 conformant, automatically and accurately, if their recipients prefer a RIM-centric approach. Best wishes Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/eec30d91/attachment.htm From rik.smithies at cfh.nhs.uk Thu Aug 31 18:27:13 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Thu, 31 Aug 2006 18:27:13 +0100 Subject: [New-ITS] Complexity Measures Message-ID: <1A3D105C334EAE49BDDD93D8767573F5043C1390@EXCHAQ2.nhsia.nhs.uk> hi, Complexity isn't the only issue, but when considering it we need to think about types of users. An new ITS shaping mechanism will likely add complexity for message designers, above the RIM-based skills already needed. It will add complexity for a message consumer/generator who sees messages in several different ITS flavours (this concerns me most). It may reduce complexity for a message consumer/generator who only ever has to deal with messages for a single application domain. eg a PDS system writer probably doesn't ever need to see act relationships, and yet the current ITS means they have to be in instances. cheers, Rik ________________________________ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of David Markwell Sent: 31 August 2006 16:59 To: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Complexity Measures Robert As per my other message to the list I am not saying there is no problem. However, I do not think the problem is node numbers so much as the complexity that arises from the multiplicity of different element names that each require different understanding and management. Thus my sense is that node variability rather then node count is the bigger issue. Any piece of software can process a million bytes in a flash if each one is processed in the same way but the more exceptions that need to be considered the more processing becomes capable of error. In my view the really interesting count would be the number of differently named clones of the same RIM class that were used with slightly different processing rules. This in my view is the effect of allowing naming changes etc to be carried from the business right down to the wire. In this respect I would agree that within its limits V2 with its OBX and OBR had much merit. As one of the those who in the past celebrated the idea of being able to produce some connection between the domain business names and the XML instances I am by no means feeling smug about this. Instead I am pointing to what I believe in retrospect was a mistake and arguing following this broad path (as per recent CFH MIMs "Weight" "BloodPressure", etc) will lead us further into complexity and chaos. Naturally there is a need to identify such information at the business level and to indicate how it should be conveyed - to the extent that general guidance is inadequate for common data set. However, calling this a different element merely adds another twist to the spiral of complexity into which we appear to be descending. ________________________________ BTW - I was not arguing for the datatype --> attribute move merely seeing this as a convenient way to illustrate that decimating the node count may have no affect on the true complexity. ________________________________ PS: I am sorry that I probably missed this at an earlier point. However, since you quote 65,000 after an hypothetical 10 fold reduction this implies you start out with an example with 650,000 nodes. Could you provide this example or better still a summary of the information it contains and the distribution of the node count (i.e.. types of nodes) I realise this is information you have probably already provided but if it is easily to hand it might help me to understand your issues. Kind Regards David Markwell Mailto:david at clininfo.co.uk ________________________________ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden Sent: 31 August 2006 15:40 To: new-its at lists.hl7.org.uk Subject: [New-ITS] Complexity Measures David Markwell wrote: * I am far from convinced of the node count as being anything other than a count of nodes. He went on to give reasons why node counts as a measure of complexity may be misleading by factors of the order ten or so, and then went into performance considerations of DOM and SAX etc. So let me try to clarify why in my view, both of these arguments miss the point. V3 has performance issues, but I am far more concerned about the developer cost of implementing, testing and maintaining messages. If you are worried about message size, you can always zip them. But I am concerned about why suppliers have embraced V2, whereas they are hanging back from V3. This seems to me a much more serious issue for HL7 than performance. Set the performance issues on one side. Implementing V3 is hard, in part because the messages are big and complex - so much so that it is hard for an implementor just to find his way around a message to find where some data item should be put. This is the needle in a haystack problem. It seems to me that V2 got this about right, but V3 has not. So I introduced the idea of node count as a measure of the problem. It is, I know, a crude measure of message complexity, but it is a measure. Historically, measures of software complexity are always hard to define. Whether it is lines of code, or function points, or anything else, it is always possible for someone to say 'your measure misses the point because..'; 'I could use fewer lines of code, but longer ones' .. or 'I could cram a big data structure into each XML attribute' or whatever. That is not the point. If this measure is too crude, please someone suggest a better one, and post on this list some real numbers for V3 messages in that measure. I will bet whatever sensible measure is proposed, the V3 lab 'observation request' will still turn out to be huge. Even with David's suggestion of cramming every V3 data type into one attribute, it is still 65,000. What V2 message has 65,000 nodes? I am really not concerned with factors of ten - I am worried about factors of a hundred or a thousand. My concerns are on a log scale. It is all very well for V3 enthusiasts to say 'It may be big in node count, but it is really very elegant and if you will only understand it, it is quite easy...' - but the market does not seem to agree. We need some way to bridge the complexity gap between V3 and the applications that will use it. Having a useful measure of the gap would be a start. Suggestions please. Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/4dd515e4/attachment-0001.htm From david at clininfo.co.uk Thu Aug 31 18:37:23 2006 From: david at clininfo.co.uk (David Markwell) Date: Thu, 31 Aug 2006 18:37:23 +0100 Subject: [New-ITS] Node counts In-Reply-To: Message-ID: Robert Brilliant now I understand - sorry for being so thick as to assume you were referring to a real instance. Also seeing detailed figures and understanding your method leads me to conclude we are agreeing while I thought we were at loggerheads. This is even more Brilliant. The flattening of course does nothing of any relevance to your figures. Proliferation of variant named nodes increases the numbers. Moving to RIM named classes would massively reduce the path count. On data types while not advocating the attributization of them I have long favoured restricting some types to the levels at which they are really used and useful. So forgive my confusion I am a convert to your version of node counting paradigm. I mixed it up with the instance node counts that were presented in an early paper related to the new ITS. Your count of complexity is real and seems to point to reduction in element names variants. The count of message redundancy etc and instance level nodes to covey a specific chunk on information tends to push in completely the opposite direction (i.e. to more and more specialised named elements) which the direction I fear some are travelling and one which I feel leads rather directly to chaos. Kind Regards David Markwell Mailto:david at clininfo.co.uk _____ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 31 August 2006 17:50 To: David Markwell Cc: new-its at lists.hl7.org.uk Subject: Node counts David - Just to clarify what I have counted, because we seem to have got wires crossed on factors of 10. The things I am counting are distinct nodes in a message definition, not allowing repeats of nodes or self-nesting. Put another way, I am counting distinct XPaths in the message definition, short of self-nesting. Inasmuch as each XPath is a name for a set of nodes, that is sort-of counting the names of nodes in the message. I made these counts in two ways: 1. going right down to leaf nodes of the XML 2. stopping at V3 data type nodes, counting each V3 data type top node as 1. Doing this for a couple of messages, I got: - PA 'new person' - 1100 XPaths down to data type nodes, 77000 nodes down to leaves - Lab 'observation request' 65,000 XPaths down to data type nodes, 4.4 million down to leaves. So the 65,000 is not 10% of anything - sorry to have misled you. BTW the lab number only includes 1 of the 4 choices at the top. For both messages, the average multiplier from data type nodes to leaves is 70. This is dominated by a few large data types which have large counts on leaf nodes: type: PQ; count: 175 type: IVL_TS; count: 548 type: AD; count: 135 type: PN; count: 592 type: CV; count: 129 type: CR; count: 213 type: ON; count: 576 type: CE; count: 383 type: CD; count: 129 type: PQR; count: 171 type: EN; count: 592 When you weight these by occurrences, there are a few main culprits: Out of the 4.4 million leaf nodes in the lab message: type: ON; count: 315072 type: II; count: 108030 type: CE; count: 1657241 type: IVL_TS; count: 980920 type: AD; count: 238545 type: EN; count: 873792 Now I guess the big data types are almost never nearly 500 nodes in instances, and simplified versions can be learned by developers for use in 99% of cases; so the huge numbers of leaves (average 70 per data type) does not worry me too much. But 65,000 separate XPaths in one message, before you get down to data types, does worry me. By the way, I was really quoting these numbers to agree with you - if node count is at all sensible as a measure of complexity, then any automatic or centrally decreed message flattening will do no good at all, because it hardly reduces node count. I don't think flattening per se will reduce the developer learning curve. I agree with you that HL7 should not increase the burden of message formats it imposes on itself or its implementers. It should let them do their own message reshaping when they want to - knowing they can always 'reflate' messages to be V3 conformant, automatically and accurately, if their recipients prefer a RIM-centric approach. Best wishes Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/92ad9e85/attachment.htm From david at clininfo.co.uk Thu Aug 31 18:58:50 2006 From: david at clininfo.co.uk (David Markwell) Date: Thu, 31 Aug 2006 18:58:50 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: <1A3D105C334EAE49BDDD93D8767573F5043C1390@EXCHAQ2.nhsia.nhs.uk> Message-ID: Rik, No no please no. Please do not give names to elements just to keep "single message users" happy. It is as I have said earlier building on a mistake I made in supporting the "clone renaming" camp in MnM a few years ago. We were well-intentioned then as are today's advocates of extending our folly. Vendors who support multiple messages will have to learn learn and relearn. Skilled staff will be have to relearn HL7 to move departments. Certainly the majority of significant businesses (vendors) and hospitals as consumers will be in this position (if we ever move close to the CFH vision). Today's problem is that we have a mix of business names and somewhat primitive names. So people see something familiar and want more familiar stuff. I would go 100% primitive on RIM physical class names. If you think I am wrong consider this. HL7v2 is highly successful with names that are very limited OBX OBR etc. Why were those implementable when ActRelationship is not. The reason I think is very simple though I only see it in retrospect and from some distance. Because if you have 10, 20, 40 or whatever element names you can document them consistently and once they are understood they are understood. When you add the next 100 names you think hey this is great its so friendly. However, the next 100 and the next 1000 and the next 10000 names demonstrate the unscalable nature of the maintaining consistency if definitions and understanding. In fact well before you we hit the first 100 the problem appears as people believe their understanding of the name and ignore any definitions that exist. For those wanting to see business names the interesting thing is that going all primitive on the elements provides a much cleaner environment for simple tools to render and convert the data for viewing in line with a business model. Those creating such tools can do so more easily for all the same reasons noted in the previous paragraph. Continuing to support an increase business naming in instance data is creating an unmeetable demand and an illusion of understanding which I think will become more and more an albatross around our necks. Kind Regards David Markwell Mailto:david at clininfo.co.uk _____ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Smithies Rik Sent: 31 August 2006 18:27 To: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Complexity Measures hi, Complexity isn't the only issue, but when considering it we need to think about types of users. An new ITS shaping mechanism will likely add complexity for message designers, above the RIM-based skills already needed. It will add complexity for a message consumer/generator who sees messages in several different ITS flavours (this concerns me most). It may reduce complexity for a message consumer/generator who only ever has to deal with messages for a single application domain. eg a PDS system writer probably doesn't ever need to see act relationships, and yet the current ITS means they have to be in instances. cheers, Rik _____ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of David Markwell Sent: 31 August 2006 16:59 To: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Complexity Measures Robert As per my other message to the list I am not saying there is no problem. However, I do not think the problem is node numbers so much as the complexity that arises from the multiplicity of different element names that each require different understanding and management. Thus my sense is that node variability rather then node count is the bigger issue. Any piece of software can process a million bytes in a flash if each one is processed in the same way but the more exceptions that need to be considered the more processing becomes capable of error. In my view the really interesting count would be the number of differently named clones of the same RIM class that were used with slightly different processing rules. This in my view is the effect of allowing naming changes etc to be carried from the business right down to the wire. In this respect I would agree that within its limits V2 with its OBX and OBR had much merit. As one of the those who in the past celebrated the idea of being able to produce some connection between the domain business names and the XML instances I am by no means feeling smug about this. Instead I am pointing to what I believe in retrospect was a mistake and arguing following this broad path (as per recent CFH MIMs "Weight" "BloodPressure", etc) will lead us further into complexity and chaos. Naturally there is a need to identify such information at the business level and to indicate how it should be conveyed - to the extent that general guidance is inadequate for common data set. However, calling this a different element merely adds another twist to the spiral of complexity into which we appear to be descending. _____ BTW - I was not arguing for the datatype --> attribute move merely seeing this as a convenient way to illustrate that decimating the node count may have no affect on the true complexity. _____ PS: I am sorry that I probably missed this at an earlier point. However, since you quote 65,000 after an hypothetical 10 fold reduction this implies you start out with an example with 650,000 nodes. Could you provide this example or better still a summary of the information it contains and the distribution of the node count (i.e.. types of nodes) I realise this is information you have probably already provided but if it is easily to hand it might help me to understand your issues. Kind Regards David Markwell Mailto:david at clininfo.co.uk _____ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden Sent: 31 August 2006 15:40 To: new-its at lists.hl7.org.uk Subject: [New-ITS] Complexity Measures David Markwell wrote: * I am far from convinced of the node count as being anything other than a count of nodes. He went on to give reasons why node counts as a measure of complexity may be misleading by factors of the order ten or so, and then went into performance considerations of DOM and SAX etc. So let me try to clarify why in my view, both of these arguments miss the point. V3 has performance issues, but I am far more concerned about the developer cost of implementing, testing and maintaining messages. If you are worried about message size, you can always zip them. But I am concerned about why suppliers have embraced V2, whereas they are hanging back from V3. This seems to me a much more serious issue for HL7 than performance. Set the performance issues on one side. Implementing V3 is hard, in part because the messages are big and complex - so much so that it is hard for an implementor just to find his way around a message to find where some data item should be put. This is the needle in a haystack problem. It seems to me that V2 got this about right, but V3 has not. So I introduced the idea of node count as a measure of the problem. It is, I know, a crude measure of message complexity, but it is a measure. Historically, measures of software complexity are always hard to define. Whether it is lines of code, or function points, or anything else, it is always possible for someone to say 'your measure misses the point because..'; 'I could use fewer lines of code, but longer ones' .. or 'I could cram a big data structure into each XML attribute' or whatever. That is not the point. If this measure is too crude, please someone suggest a better one, and post on this list some real numbers for V3 messages in that measure. I will bet whatever sensible measure is proposed, the V3 lab 'observation request' will still turn out to be huge. Even with David's suggestion of cramming every V3 data type into one attribute, it is still 65,000. What V2 message has 65,000 nodes? I am really not concerned with factors of ten - I am worried about factors of a hundred or a thousand. My concerns are on a log scale. It is all very well for V3 enthusiasts to say 'It may be big in node count, but it is really very elegant and if you will only understand it, it is quite easy.' - but the market does not seem to agree. We need some way to bridge the complexity gap between V3 and the applications that will use it. Having a useful measure of the gap would be a start. Suggestions please. Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/6ad75ca7/attachment-0001.htm From Thomas.Beale at OceanInformatics.biz Thu Aug 31 21:20:19 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Thu, 31 Aug 2006 21:20:19 +0100 Subject: [New-ITS] Considering the XUM and what ITS worth In-Reply-To: References: Message-ID: <44F74483.4000305@OceanInformatics.biz> An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/e4e33ca2/attachment.htm From Thomas.Beale at OceanInformatics.biz Thu Aug 31 21:22:48 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Thu, 31 Aug 2006 21:22:48 +0100 Subject: [New-ITS] Reshaping should be at the discretion of an implementor In-Reply-To: References: Message-ID: <44F74518.7080206@OceanInformatics.biz> Robert Worden wrote: > > All ? > > Allow me to dissent from a prevailing view about flattening/reshaping, > as expressed by Charlie: > > >I think that you are proposing naming different sets of rules for > > different degrees of flattening etc. > > >This is going too far, and that if flattening is to happen we will have > > to agree on one set of rules+annotations that can be used. > > I think if we try to agree any set of rules that must be applied, then > the reshaping will not achieve one of the main aims of the project ? > to reduce complexity for developers. > > As a crude measure of developer-perceived complexity, I use ?node > count? ? the number of distinct nodes in a message definition tree, > allowing no repetitions or self-nesting. > > V3 node counts are very big. For a basic PA ?new Person? message, the > node count is 1,129 (cutting off at V3 data types) or 77,550 (going to > the leaves of the XML tree). For the lab ?Observation request? message > the node count is 65,031 (going down to V3 data types) or 4,414,328 > (going to leave of the tree). > Based on a cursory investigation of some of the CFH message structures, my impression is that demographic entities (i.e. any Persons or Roles or other kinds of RIM Entities) are included mutiply by value, rather than once by reference. Can someone confirm this? - thomas beale From david at clininfo.co.uk Thu Aug 31 21:36:57 2006 From: david at clininfo.co.uk (David Markwell) Date: Thu, 31 Aug 2006 21:36:57 +0100 Subject: [New-ITS] Reshaping should be at the discretion of animplementor In-Reply-To: <44F74518.7080206@OceanInformatics.biz> Message-ID: Thomas -----Original Message----- Thomas Beale wrote Based on a cursory investigation of some of the CFH message structures, my impression is that demographic entities (i.e. any Persons or Roles or other kinds of RIM Entities) are included mutiply by value, rather than once by reference. Can someone confirm this? ---------- No I don't think you are right In most cases I think you will find they are there by reference to the PDS and SDS. That's how it was the last time I looked in earnest. However, in some (?all) cases there is the option to send by value where the role/entity is not in the PDS/SDS. For this reason the model/schema provides an option which I imagine could be the source of your impression. It this has changed since I last studied the MIM to that level of detail I am sure someone will correct me. Kind Regards David Markwell Mailto:david at clininfo.co.uk From david at clininfo.co.uk Thu Aug 31 21:57:38 2006 From: david at clininfo.co.uk (David Markwell) Date: Thu, 31 Aug 2006 21:57:38 +0100 Subject: [New-ITS] Considering the XUM and what ITS worth In-Reply-To: <44F74483.4000305@OceanInformatics.biz> Message-ID: Thomas I have not thought of the business models as equivalent to either the DIM or RMIM rather more business process oriented than either. The DIM / RMIM / HMD / MT in my view should lose their current role in message design. The general idea of a CIM (which encompasses all these Constrained Information Models) should usefully remain as ways of expressing constraints on the RIM applicable to message instances. The design tools for this process might even look and feel the same to the user. However the BIG change would be that they no longer generate element names nor dictate the schema for a specific message. Instead the constraints would be applied at the application/business level (by a constraint language that is not element name dependent). The only constraints at the schema and related instance level would be those for the a generic RIM based message. Its an extreme view and a big change for me I admit. One that I can make comfortably from a distance with no direct responsibilities for applying it to the MIM. However, since the new ITS team started to think outside the box I have tried to follow the lead but with for now markedly different results. The big difference is they have the discipline of trying to produce something. In that situation the tendency to add rather than take away from the process is understandable. I have no direct role in this but I do have a strong desire to get the meshing together of terminology models and information models moved forward through Clinical Statement, TermInfo and SNOMED CT. I see the diversification of models as at best a distraction from the real business of clinical communication and at worst .... well lets see what happens. Kind Regards David Markwell Mailto:david at clininfo.co.uk _____ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Thomas Beale Sent: 31 August 2006 21:20 To: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Considering the XUM and what ITS worth David Markwell wrote: David, I agree with your qualitative analysis. In what you write below, are the "domain business models" in 2) the equivalent of HL7v3 DIMs or RMIMs? If the former, where in your scheme of things are content models for clinical, demographic and administrative lumps of information, i.e. what takes the role of the current RMIMs? - thomas beale _____ 1) Go back to primitive RIM based V3 at instance level by which I mean. i) No business names in the instances. ii) Physical RIM level class ontology directly reflected in XML element names.* iii) classCode/moodCode/typeCode structural code driven next level ontology show in attributes which would be mandatory in all instances (as they determine next level of semantics) iv) Table driven codes/terminologies (HL7, SNOMED CT, and others as needed) representing detailed semantics *ALL instance elements named as RIM physical class names (not just backbone) This provides a complete high level attribute content validation using a single generic H7v3 schema. All other validation is business model driven (see 2) _____ 2) A single model layer linking this to the domain business models for i) static information content [a subset of 3 i plus communication specific information] ii) dynamic interactions [linked to 3 ii] _____ 3) A separate but interrelated statement of the information architecture and high-level behaviour of applications that serve application roles in terms of: i) static information content * Superset of all 2 i without the communication specific information but with local non-communicated information and ii) dynamic behaviour in terms of triggers and receiver responsibilities ii) dynamic behaviour in relation to content updating Although not strictly part of the communication specification this part 3 is essential for addressing business needs through communication. In the case clinical systems this is effectively the kernel of an EHR architecture and functional model. _____ Kind Regards David Markwell _____ _______________________________________________ New-ITS mailing list New-ITS at lists.hl7.org.uk http://lists.hl7.org.uk/mailman/listinfo/new-its -- ____________________________________________________________________________ _______ CTO Ocean Informatics (http://www.OceanInformatics.biz) Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/90983113/attachment-0001.htm