From Thomas.Beale at OceanInformatics.biz Fri Sep 1 00:07:10 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Fri, 01 Sep 2006 00:07:10 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: References: Message-ID: <44F76B9E.3010706@OceanInformatics.biz> Tim Benson wrote: > 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 > there is a basic quality to all RIM-derived models - they cannot avoid being built from the RIM components. This is a bit like looking at the assembly language of software - a really large number of very small instructions. Human beings stopped looking at machine language as soon as they created higher level formalisms that could be compiled into assembler (or not, these days) - because the semantic gap between what they wanted to say and what assembler can say was too large. Some questions: - should we be using an assembly language to express what are clearly high-order concepts, when there is clearly a large semantic gap? - if not, then should we not develop higher order formal languages, and use those, and leave the assembly language to be the output of some tool (or not....)? - the complexity of what is being said is not a function of the semantic power of the language used to say it - an assembler program and a pascal program for sorting say the same thing. - what we are probably concerned with is different kinds of complexity: a) difficulty of direct human authoring and comprehension of assembly language artifacts b) processing and other resource costs involved in computer processing of these artifacts I submit that currently, the semantic gap between the language of expression and the needs of the authors is too great to prevent a number of well-known problems that occur in these circumstances, and are well-known in computer science for some 40+ years. Any solution involving either more models (and acronyms...) or else a more RISC approach needs to address this. - thomas beale From tim.benson at abies.co.uk Fri Sep 1 08:24:32 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Fri, 01 Sep 2006 08:24:32 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: <44F76B9E.3010706@OceanInformatics.biz> Message-ID: I agree that there is a useful analogy between HL7 V3 and programming languages, with RBMs being at the level of object code (reflecting how the system actually works, and being unambiguous for computers), and FRS being at the level of source code (with the focus on human-readability and being unambiguous for humans). The programming solution of having two levels has worked rather well for about 50 years, and I think that we could do well to use this idea in interoperability. In interoperability, we have traditionally (V2, EDIFACT etc) tended to work at the level of object code, but as things have become harder for humans to understand. We have just three options: (1) Make the object code a lot easier for humans to understand (the thrust of the ITS work) (2) Introduce a new human-understandable source code level (e.g. by having a stringent FRS) (3) Both of the above. However, humans need to know which is master. In programming it is always the source code, with the object code produced automatically by a tool - so there is little to be gained by making the object code more human-friendly - efficiency and error-minimisation are better criteria. Tim On 1/9/06 00:07 Thomas Beale wrote: > Tim Benson wrote: >> 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 >> > there is a basic quality to all RIM-derived models - they cannot avoid > being built from the RIM components. This is a bit like looking at the > assembly language of software - a really large number of very small > instructions. Human beings stopped looking at machine language as soon > as they created higher level formalisms that could be compiled into > assembler (or not, these days) - because the semantic gap between what > they wanted to say and what assembler can say was too large. Some questions: > - should we be using an assembly language to express what are clearly > high-order concepts, when there is clearly a large semantic gap? > - if not, then should we not develop higher order formal languages, and > use those, and leave the assembly language to be the output of some tool > (or not....)? > - the complexity of what is being said is not a function of the semantic > power of the language used to say it - an assembler program and a pascal > program for sorting say the same thing. > - what we are probably concerned with is different kinds of complexity: > a) difficulty of direct human authoring and comprehension of > assembly language artifacts > b) processing and other resource costs involved in computer > processing of these artifacts > > I submit that currently, the semantic gap between the language of > expression and the needs of the authors is too great to prevent a number > of well-known problems that occur in these circumstances, and are > well-known in computer science for some 40+ years. Any solution > involving either more models (and acronyms...) or else a more RISC > approach needs to address this. > > - thomas beale > > > _______________________________________________ > 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 Fri Sep 1 08:26:11 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Fri, 01 Sep 2006 08:26:11 +0100 Subject: [New-ITS] Reshaping should be at the discretion of animplementor In-Reply-To: References: Message-ID: <44F7E093.1000804@OceanInformatics.biz> David Markwell wrote: > 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's certainly there in some cases, but I was not clear on how often, or what was the basis of reference v include-by-value. - thomas From david at clininfo.co.uk Fri Sep 1 08:46:06 2006 From: david at clininfo.co.uk (David Markwell) Date: Fri, 1 Sep 2006 08:46:06 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: <44F76B9E.3010706@OceanInformatics.biz> Message-ID: Thomas You ask if we should be using "assembly language" to express complex concepts. Obviously the answer is "no". However, in my mind the RIM (or any similar information model) is about structure and the way things fit together - it is the grammar and character set rather than the language. It is of course possible as in Chinese and Japanese to use the character set as a rich language. However, in terms of flexibility of expression I (probably for cultural reason) tend to prefer to see the richer meaning as something that is better be driven by vocabularies rather than by specific structures. Thus I write in sentences using characters from a limited set and build meaning. My view is that the way we work with the RIM classes and coded terminologies should not be so very different. That is not to suggest that we should not also be providing a way to express constraints. My view is simply that the use of a small number of small reproducible elements provides the raw material for constraints. The mistake that I think we have made in the last few years in HL7v3 is to take the structural elements create refined structural constructs which are given new names that persist and filter down into the fabric of the grammar of RIM based models. My contention is that a softer form of additional constraint based on treating constrained models as conventions would have served better. So we may be agreeing in one way in that I think we need put much more focus on constraints of a type which I imagine you might regard as archetypes ... rather than for ever extending the set of "normative" variants of models built from the RIM. However, I take the view that basing this all on a common reference model with a small number of classes and an absolutely constrained set of attributes in each class (i.e. the RIM) is still the way forward. Of course there are thing in the RIM that need improvement but nothing is perfect. Kind Regards David Markwell Mailto:david at clininfo.co.uk -----Original Message----- From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Thomas Beale Sent: 01 September 2006 00:07 To: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Complexity Measures Tim Benson wrote: > 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 > there is a basic quality to all RIM-derived models - they cannot avoid being built from the RIM components. This is a bit like looking at the assembly language of software - a really large number of very small instructions. Human beings stopped looking at machine language as soon as they created higher level formalisms that could be compiled into assembler (or not, these days) - because the semantic gap between what they wanted to say and what assembler can say was too large. Some questions: - should we be using an assembly language to express what are clearly high-order concepts, when there is clearly a large semantic gap? - if not, then should we not develop higher order formal languages, and use those, and leave the assembly language to be the output of some tool (or not....)? - the complexity of what is being said is not a function of the semantic power of the language used to say it - an assembler program and a pascal program for sorting say the same thing. - what we are probably concerned with is different kinds of complexity: a) difficulty of direct human authoring and comprehension of assembly language artifacts b) processing and other resource costs involved in computer processing of these artifacts I submit that currently, the semantic gap between the language of expression and the needs of the authors is too great to prevent a number of well-known problems that occur in these circumstances, and are well-known in computer science for some 40+ years. Any solution involving either more models (and acronyms...) or else a more RISC approach needs to address this. - thomas beale _______________________________________________ New-ITS mailing list New-ITS at lists.hl7.org.uk http://lists.hl7.org.uk/mailman/listinfo/new-its From Robert.Worden at Charteris.com Fri Sep 1 09:23:36 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Fri, 1 Sep 2006 09:23:36 +0100 Subject: [New-ITS] Complexity Measures Message-ID: Rik - You wrote: > 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). Taking these in reverse order: I don't think it adds complexity for a message consumer/generator. He can always elect to send and receive full XML ITS; those who prefer to work in other ITS flavours will have to transform their messages into full ITS before sending to him. As I keep saying, these transforms come automatically out of the reshaping process, so they are guaranteed to be accurate. Consider what is already open to CfH to do now, without any change to V3 or its usage. HL7 encourages developers to read/write V3 via an intermediate XML (presumably simpler than V3) which is then transformed to/from V3. CfH could publish an intermediate XML in the MIM, and encourage its suppliers to use it - purely as a way of reading/writing full XML ITS, which will still be what goes over the wire. The intermediate XML for each message is a flattened, restricted version of that message, with business names for nodes. The suppliers will like this, because the flattened messages will be much simpler than V3, and the necessary transforms (to get to and from V3) will be given to them by CfH, rather than having to write the transforms themselves. But still, they will only receive full V3 over the wire, and can do RIM-centric processing on it if they want to. No supplier will need to deal with diverse ITS flavours, if he does not want to. I think this would go a long way towards making V3 easier to implement, while not addressing the performance problem. It does not require HL7.org or HL7 UK to approve anything new. The only 'new' step would be if two suppliers then said to each other: you are transforming to full V3 before you send a message; I am applying the reverse transform when I receive it; why don't we just miss out those two steps so we can send smaller messages over the wire? HL7 UK or HL7.org might object to this, if it wishes to control the physical form of what goes over the wire, as well as the semantics - but I don't think it will. Your second point: will this add complexity for message designers? Yes and no. At first sight, there is an extra task for CfH; after you have designed a full V3 message, you then have to design a 'flattened' form, e.g. using the reshaping tool. But designing the rehaped/flattened form is actually just closing the loop - getting back to your business analysis, and showing how the V3 message structure carries the data which your business analysis shows you need. The original point of reshaping was to get to something closer to the DAM, and that is what you will do. So you might regard it as part of your QA activity. Getting the transforms from flattened form to V3 is then automatic, and is no extra work. In other words: the reshaped model is not only a tool for suppliers to use, it is also a key piece of documentation, showing how the V3 messages relate to the business analysis. I think making it part of the MIM would pay for itself in the quality of CfH output, and in the accuracy of the V3 messages implemented by suppliers. 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/20060901/6d5e8a0c/attachment-0001.htm From Robert.Worden at Charteris.com Fri Sep 1 09:55:54 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Fri, 1 Sep 2006 09:55:54 +0100 Subject: [New-ITS] Node counts In-Reply-To: Message-ID: David - Glad we are getting closer - but while I agree that 'Moving to RIM named classes would massively reduce the path count.', I'm not sure it would reduce it usefully. There is a small point that XML nodes and XPaths will use association names, rather than class names; so in stead of RIM classes like 'Act' we would have RIM association names like 'scoper' . But that is really a small point. If you restricted yourself to RIM names (and used simple XPaths with only node names) then I agree that the number of distinct XPaths would be much smaller - but each XPath would then be very ambiguous, telling you only 'you have got to depth 5 in the structure' and I think not much more. Anybody doing RIM-based processing would be looking at classCodes etc. as he went down the structure, so he would effectively be navigating XPaths with steps like /player[@classCode = 'PAT']/ which would take him more unambiguously down the structure. I think the number of these XPaths would be just as large as my node/path counts, regardless of naming. (Maybe they are Gunther's HPaths.) I agree with you that for some purposes, and for some people, pure RIM-based processing is the right way to go, and avoids a lot of the naming problems you refer to. But I'm not sure it is everybody's cup of tea; I'd rather give a choice and let the market decide. With what I propose, we can have our cake and eat it. Anyone who sends or receives flattened/renamed/reshaped messages must also be able to send or receive full ITS messages - and will have the transforms to move accurately between the two. Anyone who wants to receive only full ITS messages, and do RIM-based processing, can do so (= have cake). Anybody who wants to do other things, using reshaped messages, can do so (= eat it). I don't see that there has to be any dilemma between the two. 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. ________________________________ From: David Markwell [mailto:david at clininfo.co.uk] Sent: 31 August 2006 18:37 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts 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/ _________________________________________________________________ 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060901/34a04a29/attachment-0001.htm From david at clininfo.co.uk Fri Sep 1 10:18:06 2006 From: david at clininfo.co.uk (David Markwell) Date: Fri, 1 Sep 2006 10:18:06 +0100 Subject: [New-ITS] Node counts In-Reply-To: Message-ID: Robert Your comment about ambiguity is interesting. I would argue it is not ambiguous because the meaning should be captured in the coding (classCode, moodCode, code etc). I do not think detailed semantics is a schema level issue - it depends on content. Some apps will inevitably have different models which put different items of information into different structures based on content. They can decide to do that if they wish but the information communicated to them and by them is normalized as RIM physical class instances. At present (or in various other proposal) there is the RIM class, there is the RMIM class name structure and there is the applications way of storing and handling information. The RMIM class business names are neither fish nor fowl. They are not the names in the applications (because these are internal design driven) and they are not the same as the RIM. Implementers try to make sense of the element names and risk ignoring the semantic identify of two statements (i.e. two Acts with identical attribute content) simply because the element names differ. Thus my contention is that this layer of additional names which was intended as a bridge or intermediate abstraction layer has become instead a distraction layer. My original assumption in backing and arguing for business names was that this would make schema validation more effective at checking constraints while any sane application developer would ignore the names and process as advised based only on the classCode etc. How wrong I was and how seriously. I confess that only when people started to add names to ever greater depths of spuriously familiar detailed naming did it strike me how seriously we have failed to communicate this message. Kind Regards David Markwell Mailto:david at clininfo.co.uk _____ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 01 September 2006 09:56 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts David - Glad we are getting closer - but while I agree that 'Moving to RIM named classes would massively reduce the path count.', I'm not sure it would reduce it usefully. There is a small point that XML nodes and XPaths will use association names, rather than class names; so in stead of RIM classes like 'Act' we would have RIM association names like 'scoper' . But that is really a small point. If you restricted yourself to RIM names (and used simple XPaths with only node names) then I agree that the number of distinct XPaths would be much smaller - but each XPath would then be very ambiguous, telling you only 'you have got to depth 5 in the structure' and I think not much more. Anybody doing RIM-based processing would be looking at classCodes etc. as he went down the structure, so he would effectively be navigating XPaths with steps like /player[@classCode = 'PAT']/ which would take him more unambiguously down the structure. I think the number of these XPaths would be just as large as my node/path counts, regardless of naming. (Maybe they are Gunther's HPaths.) I agree with you that for some purposes, and for some people, pure RIM-based processing is the right way to go, and avoids a lot of the naming problems you refer to. But I'm not sure it is everybody's cup of tea; I'd rather give a choice and let the market decide. With what I propose, we can have our cake and eat it. Anyone who sends or receives flattened/renamed/reshaped messages must also be able to send or receive full ITS messages - and will have the transforms to move accurately between the two. Anyone who wants to receive only full ITS messages, and do RIM-based processing, can do so (= have cake). Anybody who wants to do other things, using reshaped messages, can do so (= eat it). I don't see that there has to be any dilemma between the two. 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. _____ From: David Markwell [mailto:david at clininfo.co.uk] Sent: 31 August 2006 18:37 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts 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/ _________________________________________________________________ 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060901/9b90695f/attachment-0001.htm From Robert.Worden at Charteris.com Fri Sep 1 11:47:33 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Fri, 1 Sep 2006 11:47:33 +0100 Subject: [New-ITS] Node counts In-Reply-To: Message-ID: David - I think we are getting somewhere. If RMIM names are neither fish nor fowl: 1. RIM names with classCodes etc. are pure fowl 2. A reshaped RMIM, with business names defined locally by a super-implementor such as CfH, are fish. 3. Accurate fish-to-fowl transformations come out of the reshaping process 4. So anyone can produce or consume fish or fowl to his taste (fish is easier for some, fowl for others) 5. You must be able to produce fowl to be V3 conformant. You can do this by the transformations. 6. Normally, it is fowl that goes over the wire. 7. Between consenting parties, fish may be exchanged (or performance reasons only) All this seems to me perfectly possibly now, and compatible with HL7 methodology - with the possible exception of (7), which needs discussion. 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: David Markwell [mailto:david at clininfo.co.uk] Sent: 01 September 2006 10:18 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts Robert Your comment about ambiguity is interesting. I would argue it is not ambiguous because the meaning should be captured in the coding (classCode, moodCode, code etc). I do not think detailed semantics is a schema level issue - it depends on content. Some apps will inevitably have different models which put different items of information into different structures based on content. They can decide to do that if they wish but the information communicated to them and by them is normalized as RIM physical class instances. At present (or in various other proposal) there is the RIM class, there is the RMIM class name structure and there is the applications way of storing and handling information. The RMIM class business names are neither fish nor fowl. They are not the names in the applications (because these are internal design driven) and they are not the same as the RIM. Implementers try to make sense of the element names and risk ignoring the semantic identify of two statements (i.e. two Acts with identical attribute content) simply because the element names differ. Thus my contention is that this layer of additional names which was intended as a bridge or intermediate abstraction layer has become instead a distraction layer. My original assumption in backing and arguing for business names was that this would make schema validation more effective at checking constraints while any sane application developer would ignore the names and process as advised based only on the classCode etc. How wrong I was and how seriously. I confess that only when people started to add names to ever greater depths of spuriously familiar detailed naming did it strike me how seriously we have failed to communicate this message. Kind Regards David Markwell Mailto:david at clininfo.co.uk ________________________________ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 01 September 2006 09:56 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts David - Glad we are getting closer - but while I agree that 'Moving to RIM named classes would massively reduce the path count.', I'm not sure it would reduce it usefully. There is a small point that XML nodes and XPaths will use association names, rather than class names; so in stead of RIM classes like 'Act' we would have RIM association names like 'scoper' . But that is really a small point. If you restricted yourself to RIM names (and used simple XPaths with only node names) then I agree that the number of distinct XPaths would be much smaller - but each XPath would then be very ambiguous, telling you only 'you have got to depth 5 in the structure' and I think not much more. Anybody doing RIM-based processing would be looking at classCodes etc. as he went down the structure, so he would effectively be navigating XPaths with steps like /player[@classCode = 'PAT']/ which would take him more unambiguously down the structure. I think the number of these XPaths would be just as large as my node/path counts, regardless of naming. (Maybe they are Gunther's HPaths.) I agree with you that for some purposes, and for some people, pure RIM-based processing is the right way to go, and avoids a lot of the naming problems you refer to. But I'm not sure it is everybody's cup of tea; I'd rather give a choice and let the market decide. With what I propose, we can have our cake and eat it. Anyone who sends or receives flattened/renamed/reshaped messages must also be able to send or receive full ITS messages - and will have the transforms to move accurately between the two. Anyone who wants to receive only full ITS messages, and do RIM-based processing, can do so (= have cake). Anybody who wants to do other things, using reshaped messages, can do so (= eat it). I don't see that there has to be any dilemma between the two. 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. ________________________________ From: David Markwell [mailto:david at clininfo.co.uk] Sent: 31 August 2006 18:37 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts 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/ _________________________________________________________________ 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060901/02884445/attachment-0001.htm From david at clininfo.co.uk Fri Sep 1 15:39:32 2006 From: david at clininfo.co.uk (David Markwell) Date: Fri, 1 Sep 2006 15:39:32 +0100 Subject: [New-ITS] Node counts In-Reply-To: Message-ID: Robert I would agree that we seem close to agreement on 1-6. I remain to be convinced that 7 over the wire helps anyone. I think that if 6-->7 mapping is possible (which is implicit in the idea of 7 existing at all) then simple 6-->7 and 7-->6 converters for specific environments would be a far better solution. The reason that I prefer this is as follows: Say that A and B agree to communicate using 7. They are happy ;-) Until one day B needs to communicate with C Unfortunately for B, C who works in a more diverse environment aligned nicely with the generic structures that they use in multiple domains. They use 6 with everyone - they may have use a kind of 7 view from time to time to aid understanding and debugging. However on the wire there stick with 6. Now B argues "I say you chaps we know how to do this we've done it for years with the A Team and it looks like you Cee fellows are at 6's and no 7's" However C replies "look buddy we bin doing dis stuff wid the rest of the alph'bet from Dee throu' Zee you Bees get wid the program or buzz off". Who should win in this show down and who should be stung? Who should be forced to convert? I know whose case I would argue and ... on that basis ... I'd rather avoid the argument by asserting up front that there is no 7 as part of the standard. So while consenting parties can use fax or sneaker-net or funny handshake or their own flavour of 7 that is not the standard. Kind Regards David Markwell Mailto:david at clininfo.co.uk _____ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 01 September 2006 11:48 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts David - I think we are getting somewhere. If RMIM names are neither fish nor fowl: 1. RIM names with classCodes etc. are pure fowl 2. A reshaped RMIM, with business names defined locally by a super-implementor such as CfH, are fish. 3. Accurate fish-to-fowl transformations come out of the reshaping process 4. So anyone can produce or consume fish or fowl to his taste (fish is easier for some, fowl for others) 5. You must be able to produce fowl to be V3 conformant. You can do this by the transformations. 6. Normally, it is fowl that goes over the wire. 7. Between consenting parties, fish may be exchanged (or performance reasons only) All this seems to me perfectly possibly now, and compatible with HL7 methodology - with the possible exception of (7), which needs discussion. 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: David Markwell [mailto:david at clininfo.co.uk] Sent: 01 September 2006 10:18 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts Robert Your comment about ambiguity is interesting. I would argue it is not ambiguous because the meaning should be captured in the coding (classCode, moodCode, code etc). I do not think detailed semantics is a schema level issue - it depends on content. Some apps will inevitably have different models which put different items of information into different structures based on content. They can decide to do that if they wish but the information communicated to them and by them is normalized as RIM physical class instances. At present (or in various other proposal) there is the RIM class, there is the RMIM class name structure and there is the applications way of storing and handling information. The RMIM class business names are neither fish nor fowl. They are not the names in the applications (because these are internal design driven) and they are not the same as the RIM. Implementers try to make sense of the element names and risk ignoring the semantic identify of two statements (i.e. two Acts with identical attribute content) simply because the element names differ. Thus my contention is that this layer of additional names which was intended as a bridge or intermediate abstraction layer has become instead a distraction layer. My original assumption in backing and arguing for business names was that this would make schema validation more effective at checking constraints while any sane application developer would ignore the names and process as advised based only on the classCode etc. How wrong I was and how seriously. I confess that only when people started to add names to ever greater depths of spuriously familiar detailed naming did it strike me how seriously we have failed to communicate this message. Kind Regards David Markwell Mailto:david at clininfo.co.uk _____ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 01 September 2006 09:56 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts David - Glad we are getting closer - but while I agree that 'Moving to RIM named classes would massively reduce the path count.', I'm not sure it would reduce it usefully. There is a small point that XML nodes and XPaths will use association names, rather than class names; so in stead of RIM classes like 'Act' we would have RIM association names like 'scoper' . But that is really a small point. If you restricted yourself to RIM names (and used simple XPaths with only node names) then I agree that the number of distinct XPaths would be much smaller - but each XPath would then be very ambiguous, telling you only 'you have got to depth 5 in the structure' and I think not much more. Anybody doing RIM-based processing would be looking at classCodes etc. as he went down the structure, so he would effectively be navigating XPaths with steps like /player[@classCode = 'PAT']/ which would take him more unambiguously down the structure. I think the number of these XPaths would be just as large as my node/path counts, regardless of naming. (Maybe they are Gunther's HPaths.) I agree with you that for some purposes, and for some people, pure RIM-based processing is the right way to go, and avoids a lot of the naming problems you refer to. But I'm not sure it is everybody's cup of tea; I'd rather give a choice and let the market decide. With what I propose, we can have our cake and eat it. Anyone who sends or receives flattened/renamed/reshaped messages must also be able to send or receive full ITS messages - and will have the transforms to move accurately between the two. Anyone who wants to receive only full ITS messages, and do RIM-based processing, can do so (= have cake). Anybody who wants to do other things, using reshaped messages, can do so (= eat it). I don't see that there has to be any dilemma between the two. 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. _____ From: David Markwell [mailto:david at clininfo.co.uk] Sent: 31 August 2006 18:37 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts 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/ _________________________________________________________________ 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060901/250cd2df/attachment-0001.htm From Thomas.Beale at OceanInformatics.biz Fri Sep 1 18:30:35 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Fri, 01 Sep 2006 18:30:35 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: References: Message-ID: <44F86E3B.7080703@OceanInformatics.biz> David Markwell wrote: > Thomas > > You ask if we should be using "assembly language" to express complex > concepts. > Obviously the answer is "no". However, in my mind the RIM (or any similar > information model) is about structure and the way things fit together - it > is the grammar and character set rather than the language. It is of course > possible as in Chinese and Japanese to use the character set as a rich > language. However, in terms of flexibility of expression I (probably for > cultural reason) tend to prefer to see the richer meaning as something that > is better be driven by vocabularies rather than by specific structures. Thus > I write in sentences using characters from a limited set and build meaning. > My view is that the way we work with the RIM classes and coded terminologies > should not be so very different. > well, the evidence seems to be to me that many RMIMs have a really large number of Act/Act-rel nodes (and also a large number of Entity nodes). The structure by inspection tells us that we are dealing with something quite low level. I would say that the RIM provides 2 patterns: - participation: entity-role-participation-act - composition: act/act-rel hierarchical structures There are a few other things, but generally everything has to be built form these, indeed this is the claimed virtue of the model. But there are other fairly obvious patterns that are needed but are not available, and have to be constructed all the time - a bit like always wanting For-loops and Case-statements, but having to make them yourself each time. The Clinical statement pattern is one response to this need, but there are other patterns needed. One of the friendly challenges I have made for some years with archetypes is: what does the RMIM look like for Apgar result? Without time-series and data structure primitives, it is complicated, whereas with more primitives available it is easy. I do think we need to do something about the lack of other semantic patterns / structures in the RIM. > That is not to suggest that we should not also be providing a way to express > constraints. My view is simply that the use of a small number of small > reproducible elements provides the raw material for constraints. The mistake > that I think we have made in the last few years in HL7v3 is to take the > structural elements create refined structural constructs which are given new > names that persist and filter down into the fabric of the grammar of RIM > based models. My contention is that a softer form of additional constraint > based on treating constrained models as conventions would have served > better. > > So we may be agreeing in one way in that I think we need put much more focus > on constraints of a type which I imagine you might regard as archetypes ... > rather than for ever extending the set of "normative" variants of models > built from the RIM. However, I take the view that basing this all on a > common reference model with a small number of classes and an absolutely > constrained set of attributes in each class (i.e. the RIM) is still the way > forward. I agree with the idea of course - as you well know;-) But - there is still the question of: is what is in the RIM enough? and the evidence of the very large message structures we have in which many basic structures often have to be built from scratch - differently - in each DIM & RMIM. This can only reduce the chances of semantic interoperability. - thomas From Robert.Worden at Charteris.com Sun Sep 3 09:29:40 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Sun, 3 Sep 2006 09:29:40 +0100 Subject: [New-ITS] Node counts In-Reply-To: Message-ID: David - If we agree on 1-6, then that is the most important point. That gets the main benefit of using restricted and reshaped RMIMs (fish) as a way of generating either RIM-based XML (fowl) or current XML ITS (fish-fowl hybrid). The benefit is that restricted and reshaped RMIMs are smaller and easier for implementers to understand and map onto - so implementations should be quicker and (more important) more accurately done. The only point of going to 7 (reshaped message instances over the wire) is a performance benefit - the reshaped instances will be smaller, and you avoid two translations (to/from full ITS). To me the performance point is much less important than the ease of message implementation - but it may be important for others. You say 'I think that if 6-->7 mapping is possible...' and it certainly is. The big benefit of restricting/reshaping an RMIM is that the tool will not allow you to make any illegal moves (e.g. collapsing a 1:N association) and will always keep track of the mappings between the RMIM and the reshaped version - so you can always generate XSLT translations between the two (not write them by hand) and they will be perfectly accurate. You can have 6-7 and 7-6 converters anywhere you like. So to come to your example - A and B agree to use reshaped instances over the wire, because they need the extra performance of smaller message instances. But as soon as C comes along and demands full ITS instances, A has to give them to him - and can easily do so, because he has the transform (automatically generated, accurate) and can just run it each time. I don't see a problem for A, B or C (except maybe understanding each other's English dialects). 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: David Markwell [mailto:david at clininfo.co.uk] Sent: 01 September 2006 15:40 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts Robert I would agree that we seem close to agreement on 1-6. I remain to be convinced that 7 over the wire helps anyone. I think that if 6-->7 mapping is possible (which is implicit in the idea of 7 existing at all) then simple 6-->7 and 7-->6 converters for specific environments would be a far better solution. The reason that I prefer this is as follows: Say that A and B agree to communicate using 7. They are happy ;-) Until one day B needs to communicate with C Unfortunately for B, C who works in a more diverse environment aligned nicely with the generic structures that they use in multiple domains. They use 6 with everyone - they may have use a kind of 7 view from time to time to aid understanding and debugging. However on the wire there stick with 6. Now B argues "I say you chaps we know how to do this we've done it for years with the A Team and it looks like you Cee fellows are at 6's and no 7's" However C replies "look buddy we bin doing dis stuff wid the rest of the alph'bet from Dee throu' Zee you Bees get wid the program or buzz off". Who should win in this show down and who should be stung? Who should be forced to convert? I know whose case I would argue and ... on that basis ... I'd rather avoid the argument by asserting up front that there is no 7 as part of the standard. So while consenting parties can use fax or sneaker-net or funny handshake or their own flavour of 7 that is not the standard. Kind Regards David Markwell Mailto:david at clininfo.co.uk ________________________________ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 01 September 2006 11:48 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts David - I think we are getting somewhere. If RMIM names are neither fish nor fowl: 1. RIM names with classCodes etc. are pure fowl 2. A reshaped RMIM, with business names defined locally by a super-implementor such as CfH, are fish. 3. Accurate fish-to-fowl transformations come out of the reshaping process 4. So anyone can produce or consume fish or fowl to his taste (fish is easier for some, fowl for others) 5. You must be able to produce fowl to be V3 conformant. You can do this by the transformations. 6. Normally, it is fowl that goes over the wire. 7. Between consenting parties, fish may be exchanged (or performance reasons only) All this seems to me perfectly possibly now, and compatible with HL7 methodology - with the possible exception of (7), which needs discussion. 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: David Markwell [mailto:david at clininfo.co.uk] Sent: 01 September 2006 10:18 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts Robert Your comment about ambiguity is interesting. I would argue it is not ambiguous because the meaning should be captured in the coding (classCode, moodCode, code etc). I do not think detailed semantics is a schema level issue - it depends on content. Some apps will inevitably have different models which put different items of information into different structures based on content. They can decide to do that if they wish but the information communicated to them and by them is normalized as RIM physical class instances. At present (or in various other proposal) there is the RIM class, there is the RMIM class name structure and there is the applications way of storing and handling information. The RMIM class business names are neither fish nor fowl. They are not the names in the applications (because these are internal design driven) and they are not the same as the RIM. Implementers try to make sense of the element names and risk ignoring the semantic identify of two statements (i.e. two Acts with identical attribute content) simply because the element names differ. Thus my contention is that this layer of additional names which was intended as a bridge or intermediate abstraction layer has become instead a distraction layer. My original assumption in backing and arguing for business names was that this would make schema validation more effective at checking constraints while any sane application developer would ignore the names and process as advised based only on the classCode etc. How wrong I was and how seriously. I confess that only when people started to add names to ever greater depths of spuriously familiar detailed naming did it strike me how seriously we have failed to communicate this message. Kind Regards David Markwell Mailto:david at clininfo.co.uk ________________________________ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 01 September 2006 09:56 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts David - Glad we are getting closer - but while I agree that 'Moving to RIM named classes would massively reduce the path count.', I'm not sure it would reduce it usefully. There is a small point that XML nodes and XPaths will use association names, rather than class names; so in stead of RIM classes like 'Act' we would have RIM association names like 'scoper' . But that is really a small point. If you restricted yourself to RIM names (and used simple XPaths with only node names) then I agree that the number of distinct XPaths would be much smaller - but each XPath would then be very ambiguous, telling you only 'you have got to depth 5 in the structure' and I think not much more. Anybody doing RIM-based processing would be looking at classCodes etc. as he went down the structure, so he would effectively be navigating XPaths with steps like /player[@classCode = 'PAT']/ which would take him more unambiguously down the structure. I think the number of these XPaths would be just as large as my node/path counts, regardless of naming. (Maybe they are Gunther's HPaths.) I agree with you that for some purposes, and for some people, pure RIM-based processing is the right way to go, and avoids a lot of the naming problems you refer to. But I'm not sure it is everybody's cup of tea; I'd rather give a choice and let the market decide. With what I propose, we can have our cake and eat it. Anyone who sends or receives flattened/renamed/reshaped messages must also be able to send or receive full ITS messages - and will have the transforms to move accurately between the two. Anyone who wants to receive only full ITS messages, and do RIM-based processing, can do so (= have cake). Anybody who wants to do other things, using reshaped messages, can do so (= eat it). I don't see that there has to be any dilemma between the two. 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. ________________________________ From: David Markwell [mailto:david at clininfo.co.uk] Sent: 31 August 2006 18:37 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts 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/ _________________________________________________________________ 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/ _________________________________________________________________ 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060903/036d19f9/attachment-0001.htm From david at clininfo.co.uk Sun Sep 3 09:57:26 2006 From: david at clininfo.co.uk (David Markwell) Date: Sun, 3 Sep 2006 09:57:26 +0100 Subject: [New-ITS] Node counts In-Reply-To: Message-ID: Robert The problem as I see it is that it will be oh so easy for people using reshaped instances to place reliance on the particularity of those instances and to subtly change the way they use them and basically to diverge. The more special case reshapings that exist the higher the risk and the more difficult to spot the offenders in their closed worlds. As they move to the open world suddenly all is revealed. My contention is that to be sure this does not happen these implementers will need to understand the generic foundations and if they do then why not use them. If its just to make messages smaller or simpler to process then one can understand the motivation for the reshape. However if as I suspect they will later need to go all the way then why have them play with fire before giving them the the advice on full and safe ITS? Kind Regards David Markwell Mailto:david at clininfo.co.uk _____ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 03 September 2006 09:30 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts David - If we agree on 1-6, then that is the most important point. That gets the main benefit of using restricted and reshaped RMIMs (fish) as a way of generating either RIM-based XML (fowl) or current XML ITS (fish-fowl hybrid). The benefit is that restricted and reshaped RMIMs are smaller and easier for implementers to understand and map onto - so implementations should be quicker and (more important) more accurately done. The only point of going to 7 (reshaped message instances over the wire) is a performance benefit - the reshaped instances will be smaller, and you avoid two translations (to/from full ITS). To me the performance point is much less important than the ease of message implementation - but it may be important for others. You say 'I think that if 6-->7 mapping is possible.' and it certainly is. The big benefit of restricting/reshaping an RMIM is that the tool will not allow you to make any illegal moves (e.g. collapsing a 1:N association) and will always keep track of the mappings between the RMIM and the reshaped version - so you can always generate XSLT translations between the two (not write them by hand) and they will be perfectly accurate. You can have 6-7 and 7-6 converters anywhere you like. So to come to your example - A and B agree to use reshaped instances over the wire, because they need the extra performance of smaller message instances. But as soon as C comes along and demands full ITS instances, A has to give them to him - and can easily do so, because he has the transform (automatically generated, accurate) and can just run it each time. I don't see a problem for A, B or C (except maybe understanding each other's English dialects). 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: David Markwell [mailto:david at clininfo.co.uk] Sent: 01 September 2006 15:40 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts Robert I would agree that we seem close to agreement on 1-6. I remain to be convinced that 7 over the wire helps anyone. I think that if 6-->7 mapping is possible (which is implicit in the idea of 7 existing at all) then simple 6-->7 and 7-->6 converters for specific environments would be a far better solution. The reason that I prefer this is as follows: Say that A and B agree to communicate using 7. They are happy ;-) Until one day B needs to communicate with C Unfortunately for B, C who works in a more diverse environment aligned nicely with the generic structures that they use in multiple domains. They use 6 with everyone - they may have use a kind of 7 view from time to time to aid understanding and debugging. However on the wire there stick with 6. Now B argues "I say you chaps we know how to do this we've done it for years with the A Team and it looks like you Cee fellows are at 6's and no 7's" However C replies "look buddy we bin doing dis stuff wid the rest of the alph'bet from Dee throu' Zee you Bees get wid the program or buzz off". Who should win in this show down and who should be stung? Who should be forced to convert? I know whose case I would argue and ... on that basis ... I'd rather avoid the argument by asserting up front that there is no 7 as part of the standard. So while consenting parties can use fax or sneaker-net or funny handshake or their own flavour of 7 that is not the standard. Kind Regards David Markwell Mailto:david at clininfo.co.uk _____ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 01 September 2006 11:48 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts David - I think we are getting somewhere. If RMIM names are neither fish nor fowl: 1. RIM names with classCodes etc. are pure fowl 2. A reshaped RMIM, with business names defined locally by a super-implementor such as CfH, are fish. 3. Accurate fish-to-fowl transformations come out of the reshaping process 4. So anyone can produce or consume fish or fowl to his taste (fish is easier for some, fowl for others) 5. You must be able to produce fowl to be V3 conformant. You can do this by the transformations. 6. Normally, it is fowl that goes over the wire. 7. Between consenting parties, fish may be exchanged (or performance reasons only) All this seems to me perfectly possibly now, and compatible with HL7 methodology - with the possible exception of (7), which needs discussion. 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: David Markwell [mailto:david at clininfo.co.uk] Sent: 01 September 2006 10:18 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts Robert Your comment about ambiguity is interesting. I would argue it is not ambiguous because the meaning should be captured in the coding (classCode, moodCode, code etc). I do not think detailed semantics is a schema level issue - it depends on content. Some apps will inevitably have different models which put different items of information into different structures based on content. They can decide to do that if they wish but the information communicated to them and by them is normalized as RIM physical class instances. At present (or in various other proposal) there is the RIM class, there is the RMIM class name structure and there is the applications way of storing and handling information. The RMIM class business names are neither fish nor fowl. They are not the names in the applications (because these are internal design driven) and they are not the same as the RIM. Implementers try to make sense of the element names and risk ignoring the semantic identify of two statements (i.e. two Acts with identical attribute content) simply because the element names differ. Thus my contention is that this layer of additional names which was intended as a bridge or intermediate abstraction layer has become instead a distraction layer. My original assumption in backing and arguing for business names was that this would make schema validation more effective at checking constraints while any sane application developer would ignore the names and process as advised based only on the classCode etc. How wrong I was and how seriously. I confess that only when people started to add names to ever greater depths of spuriously familiar detailed naming did it strike me how seriously we have failed to communicate this message. Kind Regards David Markwell Mailto:david at clininfo.co.uk _____ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 01 September 2006 09:56 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts David - Glad we are getting closer - but while I agree that 'Moving to RIM named classes would massively reduce the path count.', I'm not sure it would reduce it usefully. There is a small point that XML nodes and XPaths will use association names, rather than class names; so in stead of RIM classes like 'Act' we would have RIM association names like 'scoper' . But that is really a small point. If you restricted yourself to RIM names (and used simple XPaths with only node names) then I agree that the number of distinct XPaths would be much smaller - but each XPath would then be very ambiguous, telling you only 'you have got to depth 5 in the structure' and I think not much more. Anybody doing RIM-based processing would be looking at classCodes etc. as he went down the structure, so he would effectively be navigating XPaths with steps like /player[@classCode = 'PAT']/ which would take him more unambiguously down the structure. I think the number of these XPaths would be just as large as my node/path counts, regardless of naming. (Maybe they are Gunther's HPaths.) I agree with you that for some purposes, and for some people, pure RIM-based processing is the right way to go, and avoids a lot of the naming problems you refer to. But I'm not sure it is everybody's cup of tea; I'd rather give a choice and let the market decide. With what I propose, we can have our cake and eat it. Anyone who sends or receives flattened/renamed/reshaped messages must also be able to send or receive full ITS messages - and will have the transforms to move accurately between the two. Anyone who wants to receive only full ITS messages, and do RIM-based processing, can do so (= have cake). Anybody who wants to do other things, using reshaped messages, can do so (= eat it). I don't see that there has to be any dilemma between the two. 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. _____ From: David Markwell [mailto:david at clininfo.co.uk] Sent: 31 August 2006 18:37 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts 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/ _________________________________________________________________ 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/ _________________________________________________________________ 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060903/8e2c4d0c/attachment-0001.htm From grahame at kestral.com.au Mon Sep 4 05:02:46 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 04 Sep 2006 14:02:46 +1000 Subject: [New-ITS] Node counts In-Reply-To: References: Message-ID: <44FBA566.1070706@kestral.com.au> hi all catching up on this thread. It seems to me that from the start of this thread, the concept of "re-use" has been missing. If I track Robert's numbers correctly, they include each use of the same CMET and data type as a separate count. And of course, if you refuse to engage in re-use, you have a large problem in front of you. So no one does, and those figures are misleading. It would be more useful if we compared a number that David hinted at a few times, related to different types & attributes. How many types and attributes are there? But nevertheless, the numbers are very large; they grow so large so quickly because it's so easy to construct things. (This alone tells me that it's wrong to compare the V3 metholodogy to assembly code. It's manifestly a higher level construct. We can argue the merits of particular constructs, but if we start from a wrong assumption about why, we'll get nowhere fast). The fact that the numbers are so large relates to complexity in the datatypes, and chains of re-use in CMETs. Is it really a problem if CMETs create all sorts of re-use potentials, particularly by exploring scoper qualifications? If we allow for any form of coherent re-use, is there really a problem? I don't think that he V3 datatypes are inherently more complex than the v2 datatypes. I pine for a more coherent computational expression of them (and we nearly have one in the UML ITS data types), and of constraints upon them (which I will propose at Boca Raton), but I don't think they themselves are a problem (and multiplying their internal structure by their frequency of use is a non-sensical assessment of their complexity). btw, for interest, using roughly Robert's technique, the count, including datatypes, for a V2.5 lab message (ORU_R01) is 8733 nodes. Grahame David Markwell wrote: > Robert > > The problem as I see it is that it will be oh so easy for people using > reshaped instances to place reliance on the particularity of those instances > and to subtly change the way they use them and basically to diverge. The > more special case reshapings that exist the higher the risk and the more > difficult to spot the offenders in their closed worlds. As they move to the > open world suddenly all is revealed. My contention is that to be sure this > does not happen these implementers will need to understand the generic > foundations and if they do then why not use them. If its just to make > messages smaller or simpler to process then one can understand the > motivation for the reshape. However if as I suspect they will later need to > go all the way then why have them play with fire before giving them the the > advice on full and safe ITS? > > Kind Regards > > David Markwell > > > Mailto:david at clininfo.co.uk > > > _____ > > From: Robert Worden [mailto:Robert.Worden at Charteris.com] > Sent: 03 September 2006 09:30 > To: david at clininfo.co.uk > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > > > David - > > > > If we agree on 1-6, then that is the most important point. That gets the > main benefit of using restricted and reshaped RMIMs (fish) as a way of > generating either RIM-based XML (fowl) or current XML ITS (fish-fowl > hybrid). The benefit is that restricted and reshaped RMIMs are smaller and > easier for implementers to understand and map onto - so implementations > should be quicker and (more important) more accurately done. > > > > The only point of going to 7 (reshaped message instances over the wire) is a > performance benefit - the reshaped instances will be smaller, and you avoid > two translations (to/from full ITS). To me the performance point is much > less important than the ease of message implementation - but it may be > important for others. > > > > You say 'I think that if 6-->7 mapping is possible.' and it certainly is. > The big benefit of restricting/reshaping an RMIM is that the tool will not > allow you to make any illegal moves (e.g. collapsing a 1:N association) and > will always keep track of the mappings between the RMIM and the reshaped > version - so you can always generate XSLT translations between the two (not > write them by hand) and they will be perfectly accurate. You can have 6-7 > and 7-6 converters anywhere you like. > > > > So to come to your example - A and B agree to use reshaped instances over > the wire, because they need the extra performance of smaller message > instances. But as soon as C comes along and demands full ITS instances, A > has to give them to him - and can easily do so, because he has the transform > (automatically generated, accurate) and can just run it each time. I don't > see a problem for A, B or C (except maybe understanding each other's English > dialects). > > > > 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: David Markwell [mailto:david at clininfo.co.uk] > Sent: 01 September 2006 15:40 > To: Robert Worden > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > > > Robert > > > > I would agree that we seem close to agreement on 1-6. > > > > I remain to be convinced that 7 over the wire helps anyone. > > > > I think that if 6-->7 mapping is possible (which is implicit in the idea of > 7 existing at all) then simple 6-->7 and 7-->6 converters for specific > environments would be a far better solution. The reason that I prefer this > is as follows: > > > > Say that A and B agree to communicate using 7. They are happy ;-) > > > > Until one day B needs to communicate with C > > > > Unfortunately for B, C who works in a more diverse environment aligned > nicely with the generic structures that they use in multiple domains. They > use 6 with everyone - they may have use a kind of 7 view from time to time > to aid understanding and debugging. However on the wire there stick with 6. > > > > Now B argues "I say you chaps we know how to do this we've done it for years > with the A Team and it looks like you Cee fellows are at 6's and no 7's" > > > > However C replies "look buddy we bin doing dis stuff wid the rest of the > alph'bet from Dee throu' Zee you Bees get wid the program or buzz off". > > > > Who should win in this show down and who should be stung? > > > > Who should be forced to convert? > > > > I know whose case I would argue and ... on that basis ... I'd rather avoid > the argument by asserting up front that there is no 7 as part of the > standard. So while consenting parties can use fax or sneaker-net or funny > handshake or their own flavour of 7 that is not the standard. > > > > Kind Regards > > David Markwell > > Mailto:david at clininfo.co.uk > > > > > > _____ > > From: Robert Worden [mailto:Robert.Worden at Charteris.com] > Sent: 01 September 2006 11:48 > To: david at clininfo.co.uk > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > David - > > > > I think we are getting somewhere. If RMIM names are neither fish nor fowl: > > > > 1. RIM names with classCodes etc. are pure fowl > > 2. A reshaped RMIM, with business names defined locally by a > super-implementor such as CfH, are fish. > > 3. Accurate fish-to-fowl transformations come out of the reshaping > process > > 4. So anyone can produce or consume fish or fowl to his taste (fish is > easier for some, fowl for others) > > 5. You must be able to produce fowl to be V3 conformant. You can do > this by the transformations. > > 6. Normally, it is fowl that goes over the wire. > > 7. Between consenting parties, fish may be exchanged (or performance > reasons only) > > > > All this seems to me perfectly possibly now, and compatible with HL7 > methodology - with the possible exception of (7), which needs discussion. > > > > 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: David Markwell [mailto:david at clininfo.co.uk] > Sent: 01 September 2006 10:18 > To: Robert Worden > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > > > Robert > > > > Your comment about ambiguity is interesting. I would argue it is not > ambiguous because the meaning should be captured in the coding (classCode, > moodCode, code etc). I do not think detailed semantics is a schema level > issue - it depends on content. Some apps will inevitably have different > models which put different items of information into different structures > based on content. They can decide to do that if they wish but the > information communicated to them and by them is normalized as RIM physical > class instances. > > > > At present (or in various other proposal) there is the RIM class, there is > the RMIM class name structure and there is the applications way of storing > and handling information. The RMIM class business names are neither fish nor > fowl. They are not the names in the applications (because these are internal > design driven) and they are not the same as the RIM. Implementers try to > make sense of the element names and risk ignoring the semantic identify of > two statements (i.e. two Acts with identical attribute content) simply > because the element names differ. > > > > Thus my contention is that this layer of additional names which was intended > as a bridge or intermediate abstraction layer has become instead a > distraction layer. My original assumption in backing and arguing for > business names was that this would make schema validation more effective at > checking constraints while any sane application developer would ignore the > names and process as advised based only on the classCode etc. > > > > How wrong I was and how seriously. I confess that only when people started > to add names to ever greater depths of spuriously familiar detailed naming > did it strike me how seriously we have failed to communicate this message. > > > > Kind Regards > > David Markwell > > Mailto:david at clininfo.co.uk > > > > > > _____ > > From: Robert Worden [mailto:Robert.Worden at Charteris.com] > Sent: 01 September 2006 09:56 > To: david at clininfo.co.uk > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > David - > > > > Glad we are getting closer - but while I agree that 'Moving to RIM named > classes would massively reduce the path count.', I'm not sure it would > reduce it usefully. > > > > There is a small point that XML nodes and XPaths will use association names, > rather than class names; so in stead of RIM classes like 'Act' we would have > RIM association names like 'scoper' . But that is really a small point. If > you restricted yourself to RIM names (and used simple XPaths with only node > names) then I agree that the number of distinct XPaths would be much smaller > - but each XPath would then be very ambiguous, telling you only 'you have > got to depth 5 in the structure' and I think not much more. > > > > Anybody doing RIM-based processing would be looking at classCodes etc. as he > went down the structure, so he would effectively be navigating XPaths with > steps like > > /player[@classCode = 'PAT']/ which would take him more unambiguously down > the structure. I think the number of these XPaths would be just as large as > my node/path counts, regardless of naming. (Maybe they are Gunther's > HPaths.) > > > > I agree with you that for some purposes, and for some people, pure RIM-based > processing is the right way to go, and avoids a lot of the naming problems > you refer to. But I'm not sure it is everybody's cup of tea; I'd rather give > a choice and let the market decide. With what I propose, we can have our > cake and eat it. Anyone who sends or receives flattened/renamed/reshaped > messages must also be able to send or receive full ITS messages - and will > have the transforms to move accurately between the two. Anyone who wants to > receive only full ITS messages, and do RIM-based processing, can do so (= > have cake). Anybody who wants to do other things, using reshaped messages, > can do so (= eat it). I don't see that there has to be any dilemma between > the two. > > > > 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. > > > > _____ > > From: David Markwell [mailto:david at clininfo.co.uk] > Sent: 31 August 2006 18:37 > To: Robert Worden > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > > > 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/ > > _________________________________________________________________ > 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/ > > _________________________________________________________________ > 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 -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Mon Sep 4 05:18:16 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 04 Sep 2006 14:18:16 +1000 Subject: [New-ITS] Complexity Measures In-Reply-To: <44F86E3B.7080703@OceanInformatics.biz> References: <44F86E3B.7080703@OceanInformatics.biz> Message-ID: <44FBA908.4040400@kestral.com.au> so, Thomas, in the context of the RIM, what additional semantic patterns would you propose? what would the class definitions look like? Grahame Thomas Beale wrote: > David Markwell wrote: >> Thomas >> >> You ask if we should be using "assembly language" to express complex >> concepts. >> Obviously the answer is "no". However, in my mind the RIM (or any similar >> information model) is about structure and the way things fit together - it >> is the grammar and character set rather than the language. It is of course >> possible as in Chinese and Japanese to use the character set as a rich >> language. However, in terms of flexibility of expression I (probably for >> cultural reason) tend to prefer to see the richer meaning as something that >> is better be driven by vocabularies rather than by specific structures. Thus >> I write in sentences using characters from a limited set and build meaning. >> My view is that the way we work with the RIM classes and coded terminologies >> should not be so very different. >> > well, the evidence seems to be to me that many RMIMs have a really large > number of Act/Act-rel nodes (and also a large number of Entity nodes). > The structure by inspection tells us that we are dealing with something > quite low level. I would say that the RIM provides 2 patterns: > - participation: entity-role-participation-act > - composition: act/act-rel hierarchical structures > > There are a few other things, but generally everything has to be built > form these, indeed this is the claimed virtue of the model. But there > are other fairly obvious patterns that are needed but are not available, > and have to be constructed all the time - a bit like always wanting > For-loops and Case-statements, but having to make them yourself each > time. The Clinical statement pattern is one response to this need, but > there are other patterns needed. One of the friendly challenges I have > made for some years with archetypes is: what does the RMIM look like for > Apgar result? Without time-series and data structure primitives, it is > complicated, whereas with more primitives available it is easy. > > I do think we need to do something about the lack of other semantic > patterns / structures in the RIM. >> That is not to suggest that we should not also be providing a way to express >> constraints. My view is simply that the use of a small number of small >> reproducible elements provides the raw material for constraints. The mistake >> that I think we have made in the last few years in HL7v3 is to take the >> structural elements create refined structural constructs which are given new >> names that persist and filter down into the fabric of the grammar of RIM >> based models. My contention is that a softer form of additional constraint >> based on treating constrained models as conventions would have served >> better. >> >> So we may be agreeing in one way in that I think we need put much more focus >> on constraints of a type which I imagine you might regard as archetypes ... >> rather than for ever extending the set of "normative" variants of models >> built from the RIM. However, I take the view that basing this all on a >> common reference model with a small number of classes and an absolutely >> constrained set of attributes in each class (i.e. the RIM) is still the way >> forward. > I agree with the idea of course - as you well know;-) But - there is > still the question of: is what is in the RIM enough? and the evidence of > the very large message structures we have in which many basic structures > often have to be built from scratch - differently - in each DIM & RMIM. > This can only reduce the chances of semantic interoperability. > > - thomas > > > _______________________________________________ > 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 grahame at kestral.com.au Mon Sep 4 05:33:59 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 04 Sep 2006 14:33:59 +1000 Subject: [New-ITS] Complexity Measures In-Reply-To: References: Message-ID: <44FBACB7.9090206@kestral.com.au> hi David > 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. really, you are criticising the orientation of the XML ITS. Firstly, I observe that I can interconvert between a "static model diagram" and a constraint statement (say, an archetype using ADL per openEHR) (and I will be dmonstrating this, both logically and a code tool, at Boca). So something you said somewhere else is true - the static diagrams are only constraints on a consistent unerlying model. So we could well choose to serialise the reference model directly. In fact, I'd rather do that, for all the reasons you are saying. Really, V3 is all about the reference model, it's strengths and weaknesses, and we'd do better to just serialise this altogether. My next email will deal with your comments about the XUM. Here, I will comment on the relationship between the XUM and this idea: I am pushing the XUM because if we need to push the idea of serialising models in their own form, we should do it better than we do now. But we would be better overall to serialise the RIM form directly. and in fact, I'm heartened to hear you say this. I recall a conversation that we had about using RIM based serialisation at , where several of us techies thought it was better, but doubted that any one else would be interested - it would be too hard for other implementers. But the more analysis comes out of our work, the less sure I am about that. There is some argument that we should serialise the clinical statement, rather than the RIM, but, as much as I can see the desire, raises all sorts of questions - unless the clinical statement becomes the reference model. > 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. is this really true? by "all primitive" I take you to mean, serialising the RIM constructs directly. I think it's not easier, but it's more real. It's not easier because the structural codes - particularly actClass - can be specialised, so that the XPaths, which use string matching, are too simple, or have to consider multiple possible matches for a single meaning (an issue that is presently under-rated anyway) Grahame From grahame at kestral.com.au Mon Sep 4 05:43:19 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 04 Sep 2006 14:43:19 +1000 Subject: [New-ITS] Complexity Measures In-Reply-To: References: Message-ID: <44FBAEE7.6070303@kestral.com.au> I missed the name of the place we were talked about this - Keukenhof Grahame hi David > 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. really, you are criticising the orientation of the XML ITS. Firstly, I observe that I can interconvert between a "static model diagram" and a constraint statement (say, an archetype using ADL per openEHR) (and I will be dmonstrating this, both logically and a code tool, at Boca). So something you said somewhere else is true - the static diagrams are only constraints on a consistent unerlying model. So we could well choose to serialise the reference model directly. In fact, I'd rather do that, for all the reasons you are saying. Really, V3 is all about the reference model, it's strengths and weaknesses, and we'd do better to just serialise this altogether. My next email will deal with your comments about the XUM. Here, I will comment on the relationship between the XUM and this idea: I am pushing the XUM because if we need to push the idea of serialising models in their own form, we should do it better than we do now. But we would be better overall to serialise the RIM form directly. and in fact, I'm heartened to hear you say this. I recall a conversation that we had about using RIM based serialisation at , where several of us techies thought it was better, but doubted that any one else would be interested - it would be too hard for other implementers. But the more analysis comes out of our work, the less sure I am about that. There is some argument that we should serialise the clinical statement, rather than the RIM, but, as much as I can see the desire, raises all sorts of questions - unless the clinical statement becomes the reference model. > 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. is this really true? by "all primitive" I take you to mean, serialising the RIM constructs directly. I think it's not easier, but it's more real. It's not easier because the structural codes - particularly actClass - can be specialised, so that the XPaths, which use string matching, are too simple, or have to consider multiple possible matches for a single meaning (an issue that is presently under-rated anyway) Grahame From grahame at kestral.com.au Mon Sep 4 05:53:14 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 04 Sep 2006 14:53:14 +1000 Subject: [New-ITS] Reshaping should be at the discretion of an implementor In-Reply-To: References: Message-ID: <44FBB13A.8010201@kestral.com.au> hi I think this should be rephrased as, "implemention should be left to the implementor". No one (I hope) would disagree with this. Reshaping - while useful as an implementation tool - is not going to help with interoperability, unless we can get a single basis for reshaping - and suddenly we are back to where Charlie was. So what would actually be useful is a tool - or set of tools - that can take an RMIM, and a profile on the RMIM - and produce useful implementation constructs, and then this can be offered to the implementors to help them implement. Robert, your tool is a step in the right direction here, and a laudable direction - but it's not going to solve problems at the level of the standard, I think. The hard part is doing the profiling Grahame 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). > > > > 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/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 grahame at kestral.com.au Mon Sep 4 06:19:36 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 04 Sep 2006 15:19:36 +1000 Subject: [New-ITS] Considering the XUM and what ITS worth In-Reply-To: References: Message-ID: <44FBB768.2000603@kestral.com.au> hi David Introducing the XUM per se does not introduce complexity. We take some away - the XUM is a lot less complex than working with the XML ITS, because what you see in the models is what you get on the wire. The XUM is simply a clear documentation of reality, and an acceptance that we must finally be specific if we want to be implementable. Implementors need something to hang their hat on, and there's just nothing in V3 that you can finally rely on at the moment. Even the real insiders who do nothing but V3 disagree on small (but key) things about the instances. For each extra "thing" that we do to the XUM, such as * flattening (associations and into datatypes) * renaming * allowing by reference instead of by value * allowing choice of level to serialise at there's extra complexity, and I am very concerned about this. Each of these has some very coherent merits, and some disadvantages. I'm far from convinced that they are either good or bad. But the fixed/default values thing speaks far more about all this than everything else. My view on this is that: * if you assume that it's reasonable to consult the definition to read the instance, then leaving fixed and default values out, and acting aggressively with regard to the ideas above is a perfectly reasonable thing to do. As long as everything is explained in the definition. And if you tool up for this, then it's all fine. In fact, to implement almost all the things that we have discussed in the javaSig code is easy, simple and transparent - as long as the definition can be found, Gunther and I just fiddle with the parser a little, and no one knows any different (we checked). My own parser is the same. HL7 has a variation on this - we rule that normative models can be found and therefore are usable in this sense. but, not everyone can accept the idea that you have to engage in custom tooling like this. They want to be able to do "semantic processing" - i.e. process the instance based on the V3 semantics alone, *without consultation with the definition*. Either it's too slow, or they don't want to go writing custom specialist code (both, actually. doing it well will make things faster). These are valid implementation concerns. But this leads to my second concern: * To reliably process the instance, whether you need the definition or not, you need a terminology service, and you need to use it well. This is far harder than any of the other problems, so I wonder why people have a problem with the other stuff. Does anyone else really think that you can build industrial strength applications using V3 without a thoroughly integrated terminology service? It seems to me that a RIM level serialisation will increase the importance of this. And since this brings it's own implementation problems, then I'm not sure it's a good idea. Which brings my to your final assertion on the way forward. Maybe I missed the essence of something, but it sounded like the HDF with RIM level serialisation. Ah no - you want a single level of models. I want one more: somewhere to be specific about implementation. How about 3 levels * RIM (reference model) * DIM (domain constraint patterns on the Reference model) * templates (narrow / implementation pattern constraints) + business analysis information and dynamic models. I like this so much I will publish a RIM + Data types Schema suitable for this use in the next couple of days. We (Charlie, Laura and I) have been looking at whether there's a use to marking up the RIM based serialisation with specific static model (whoops, constaint pattern) information. Say, something like this instead of or opinions, anyone? Grahame David Markwell wrote: > 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 > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mon Sep 4 07:40:40 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Mon, 4 Sep 2006 07:40:40 +0100 Subject: [New-ITS] Reshaping should be at the discretion of an implementor In-Reply-To: <44FBB13A.8010201@kestral.com.au> Message-ID: Grahame - You wrote: > Reshaping - while useful as an implementation tool - is > not going to help with interoperability, unless we can get > a single basis for reshaping I disagree! Suppose I use a reshaped and restricted RMIM, purely as a way to get full-ITS V3 onto the wire (not to reveal reshaped instances in public). I use the reshaped model only as an intermediate step between my application and V3. Then: - Because the reshaped model is smaller and simpler than the RMIM, and has business names, I make more accurate mappings onto my applications - Because the mappings of the reshaped XML onto V3 are machine-generated, not hand-coded, there is no potential for error in translation from reshaped XML to the full ITS - Therefore I have a more error-free interface between my applications and V3 full ITS Surely that is 'going to help with interoperability'? And it does not need a single basis for reshaping in order to work. If you don't think so, Grahame, please tell me why. (I am genuinely perplexed at my failure to explain this point to some very clever guys like you!) In using reshaped models like this, I would only be following the advice on the HL7 Implementation Wiki: 'Do add a layer of abstraction, in the form of an intermediate XML based format, and map this to HL7 v3 artefacts, e.g. with the aid of a stylesheet. The structure of the intermediate format should be the best possible mix of the internal database format and the model used by CDA/Clinical statements.' Or: 'If you are working with XSLT you need to define an intermediate XML format for your data. This can be in "close to HL7" form or in "close to native" form.' HL7 does not require standardization of the intermediate XMLs. Only when you go to the next stage, of sending reshaped instances over the wire, do you get interoperability issues. My solution to these issues is: Only send reshaped message instances between consenting parties, who have agreed to use the same reshaped model. If either party wants to use full XML ITS, the other party has to provide it. And he can do so, because he has an accurate transform to do it. (This next stage is not necessary, unless you are concerned about performance and small message instances) Again - have I somehow failed to explain this point to anybody else on the planet? What is wrong with it? Grahame - I think the key to your objection may be where you say 'it's not going to solve problems at the level of the standard'. Maybe it doesn't need to. Perhaps we should distinguish between (a) practical things that implementers can do now, and (b) proposed changes to the standard. We can propose a mix of these if we want to. 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. -----Original Message----- From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame Grieve Sent: 04 September 2006 05:53 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Reshaping should be at the discretion of an implementor hi I think this should be rephrased as, "implemention should be left to the implementor". No one (I hope) would disagree with this. Reshaping - while useful as an implementation tool - is not going to help with interoperability, unless we can get a single basis for reshaping - and suddenly we are back to where Charlie was. So what would actually be useful is a tool - or set of tools - that can take an RMIM, and a profile on the RMIM - and produce useful implementation constructs, and then this can be offered to the implementors to help them implement. Robert, your tool is a step in the right direction here, and a laudable direction - but it's not going to solve problems at the level of the standard, I think. The hard part is doing the profiling Grahame 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). > > > > 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/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 _________________________________________________________________ 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 grahame at kestral.com.au Mon Sep 4 08:05:08 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 04 Sep 2006 17:05:08 +1000 Subject: [New-ITS] Reshaping should be at the discretion of an implementor In-Reply-To: References: Message-ID: <44FBD024.4070804@kestral.com.au> Robert Worden wrote: > Grahame - > > You wrote: > >> Reshaping - while useful as an implementation tool - is >> not going to help with interoperability, unless we can get >> a single basis for reshaping > > I disagree! actually, you agree, nearly. You describe a whole lot of uses of reshaping that are *implementation tool* usages - and they all make sense. Then you assert that > Only send reshaped message instances between consenting > parties, who have agreed to use the same reshaped model. well, perhaps. In fact, fine. But it's not going to help us find an ITS that is useful - which is what we are about here, and nor is it an appropriate thing to engage in at the standards level. In fact, in the end, all of the optimisation things die at the standards level because they make operability easier but interoperability harder. Grahame > Suppose I use a reshaped and restricted RMIM, purely as a way to get > full-ITS V3 onto the wire (not to reveal reshaped instances in public). > I use the reshaped model only as an intermediate step between my > application and V3. Then: > > - Because the reshaped model is smaller and simpler than the RMIM, and > has business names, I make more accurate mappings onto my applications > > - Because the mappings of the reshaped XML onto V3 are > machine-generated, not hand-coded, there is no potential for error in > translation from reshaped XML to the full ITS > > - Therefore I have a more error-free interface between my applications > and V3 full ITS > > Surely that is 'going to help with interoperability'? And it does not > need a single basis for reshaping in order to work. If you don't think > so, Grahame, please tell me why. > > (I am genuinely perplexed at my failure to explain this point to some > very clever guys like you!) > > In using reshaped models like this, I would only be following the > advice on the HL7 Implementation Wiki: > > 'Do add a layer of abstraction, in the form of an intermediate XML based > format, and map this to HL7 v3 artefacts, e.g. with the aid of a > stylesheet. The structure of the intermediate format should be the best > possible mix of the internal database format and the model used by > CDA/Clinical statements.' > > Or: > > 'If you are working with XSLT you need to define an intermediate XML > format for your data. This can be in "close to HL7" form or in "close to > native" form.' > > HL7 does not require standardization of the intermediate XMLs. > > Only when you go to the next stage, of sending reshaped instances over > the wire, do you get interoperability issues. My solution to these > issues is: Only send reshaped message instances between consenting > parties, who have agreed to use the same reshaped model. If either party > wants to use full XML ITS, the other party has to provide it. And he can > do so, because he has an accurate transform to do it. > > (This next stage is not necessary, unless you are concerned about > performance and small message instances) > > Again - have I somehow failed to explain this point to anybody else on > the planet? What is wrong with it? > > Grahame - I think the key to your objection may be where you say 'it's > not going to solve problems at the level of the standard'. Maybe it > doesn't need to. Perhaps we should distinguish between (a) practical > things that implementers can do now, and (b) proposed changes to the > standard. We can propose a mix of these if we want to. > > 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. > > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame > Grieve > Sent: 04 September 2006 05:53 > To: Robert Worden > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Reshaping should be at the discretion of an > implementor > > hi > > I think this should be rephrased as, "implemention > should be left to the implementor". > > No one (I hope) would disagree with this. > > Reshaping - while useful as an implementation tool - is > not going to help with interoperability, unless we can get > a single basis for reshaping - and suddenly we are back to > where Charlie was. > > So what would actually be useful is a tool - or set of tools - that > can take an RMIM, and a profile on the RMIM - and produce useful > implementation constructs, and then this can be offered to the > implementors to help them implement. > > Robert, your tool is a step in the right direction here, and > a laudable direction - but it's not going to solve problems > at the level of the standard, I think. > > The hard part is doing the profiling > > Grahame > > > > 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). >> >> >> >> 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/ >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 david at clininfo.co.uk Mon Sep 4 09:24:45 2006 From: david at clininfo.co.uk (David Markwell) Date: Mon, 4 Sep 2006 09:24:45 +0100 Subject: [New-ITS] Considering the XUM and what ITS worth In-Reply-To: <44FBB768.2000603@kestral.com.au> Message-ID: Grahame See in line comments. Kind Regards David Markwell Mailto:david at clininfo.co.uk -----Original Message----- From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame Grieve Sent: 04 September 2006 06:20 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Considering the XUM and what ITS worth hi David Introducing the XUM per se does not introduce complexity. We take some away - the XUM is a lot less complex than working with the XML ITS, because what you see in the models is what you get on the wire. The XUM is simply a clear documentation of reality, and an acceptance that we must finally be specific if we want to be implementable. Implementors need something to hang their hat on, and there's just nothing in V3 that you can finally rely on at the moment. Even the real insiders who do nothing but V3 disagree on small (but key) things about the instances. For each extra "thing" that we do to the XUM, such as * flattening (associations and into datatypes) This adds rather than reducing complexity and in my view has no merit. * renaming Not sure what is naming and what is renaming. If one sticks with RIM level naming then that reduced complexity. * allowing by reference instead of by value This is essential in that without it you are forced to repetition which in some cases has the potential to be unlimited recursion and in all cases adds to processing or uncertainty (are the two full instances really the same etc.). Thus we need reference and we need to know when it has been used. * allowing choice of level to serialise at there's extra complexity, and I am very concerned about this. I am not adamantly opposed to this. Call me a nouveau RIM naming purist. Each of these has some very coherent merits, and some disadvantages. I'm far from convinced that they are either good or bad. But the fixed/default values thing speaks far more about all this than everything else. My view on this is that: * if you assume that it's reasonable to consult the definition to read the instance, then leaving fixed and default values out, and acting aggressively with regard to the ideas above is a perfectly reasonable thing to do. As long as everything is explained in the definition. And if you tool up for this, then it's all fine. In fact, to implement almost all the things that we have discussed in the javaSig code is easy, simple and transparent - as long as the definition can be found, Gunther and I just fiddle with the parser a little, and no one knows any different (we checked). My own parser is the same. HL7 has a variation on this - we rule that normative models can be found and therefore are usable in this sense. The problem is this presumes named specialized structures as instance level. I feel these are the route of many problems. In the RIM class naming view of the world there are very few truly fixed or default values. but, not everyone can accept the idea that you have to engage in custom tooling like this. They want to be able to do "semantic processing" - i.e. process the instance based on the V3 semantics alone, *without consultation with the definition*. Either it's too slow, or they don't want to go writing custom specialist code (both, actually. doing it well will make things faster). These are valid implementation concerns. But this leads to my second concern: * To reliably process the instance, whether you need the definition or not, you need a terminology service, and you need to use it well. This is far harder than any of the other problems, so I wonder why people have a problem with the other stuff. Terminology services are not necessarily harder than what is being done in HL7v3. Actually I would argue that HL7v3 (as it has evolved) has a level of structural complexity which is greater than the semantic complexity of a any current terminology [discuss]!! However, as you point out below, you need a terminology service to do semantic interoperability with or without HL7v3. Does anyone else really think that you can build industrial strength applications using V3 without a thoroughly integrated terminology service? It seems to me that a RIM level serialisation will increase the importance of this. And since this brings it's own implementation problems, then I'm not sure it's a good idea. I am sure you need terminology services for HL7v3 (or any form of semantically operable application). The level of the service required is more a property of the application than of HL7v3. Thus I would rather see terminology services integrated with applications rather than specifically integrated with HL7v3 (though they do need to be used in message processing they are also essential for semantic operability with applications). Since terminology services are essential to making computational sense of received information it seems that adding variation in the communication instances so you don't need them for communication has no great value and is a distraction. Some people find the idea of a "terminology service" frightening complex. I suspect some of the commercial software providers in this area are partly responsible for this. It really is just a series of lookups and computations that need to optimized not rocket science ... More MP3 science ... once done easy to replicate and enhance. Which brings my to your final assertion on the way forward. Maybe I missed the essence of something, but it sounded like the HDF with RIM level serialisation. Ah no - you want a single level of models. I want one more: somewhere to be specific about implementation. How about 3 levels * RIM (reference model) * DIM (domain constraint patterns on the Reference model) * templates (narrow / implementation pattern constraints) + business analysis information and dynamic models. I like this so much I will publish a RIM + Data types Schema suitable for this use in the next couple of days. We (Charlie, Laura and I) have been looking at whether there's a use to marking up the RIM based serialisation with specific static model (whoops, constaint pattern) information. Say, something like this instead of or opinions, anyone? This does not look like a RIM based instance unless perhaps "participationCode" is meant to be "typeCode". Assuming that is just a typo I still disagree with this approach. What is the point of the tautology "Author" and "AUT" To be clear what I am suggesting is ... If the modelid is not simply repeating the name "AUT" but is referencing a constraint then it would far better to reference the constraint by a uniqueId (GUID /UUID in my view not OID or the current CFH use of a structured templateId). For example: .. would allow a reference to a constraint without any risk of hidden semantics etc. You either have the template that id (then you can validate against it if you wish) or you don't so you process it only based on RIM level schema constraints. Identifiers and names that look familiar or meaningful should be avoided instead the id should reference descriptions and other metadata. Grahame David Markwell wrote: > 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 > > > > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > 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 Thomas.Beale at OceanInformatics.biz Mon Sep 4 09:56:44 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Mon, 04 Sep 2006 09:56:44 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FBA908.4040400@kestral.com.au> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> Message-ID: <44FBEA4C.6010908@OceanInformatics.biz> Grahame Grieve wrote: > so, Thomas, in the context of the RIM, what additional > semantic patterns would you propose? what would the > class definitions look like? > > Grahame > > well, as I say to do something as simple as Apgar (or any time-series observation - and there are hundreds), you need an easy way of doing time-series and an easy way of doing structures (list in the case of Apgar). There are about 6 other things I could propose, but let's just leave it at that for the moment. - thomas From Thomas.Beale at OceanInformatics.biz Mon Sep 4 10:02:45 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Mon, 04 Sep 2006 10:02:45 +0100 Subject: [New-ITS] Reshaping should be at the discretion of animplementor In-Reply-To: <44FBAFE3.7090901@kestral.com.au> References: <44F7E093.1000804@OceanInformatics.biz> <44FBAFE3.7090901@kestral.com.au> Message-ID: <44FBEBB5.4000200@OceanInformatics.biz> [I assume this was meant for the list] Grahame Grieve wrote: > there is never an option for include by reference - at this time. > You must include by value always. > > but in some models there is an option to provide minimal > details including an SDS reference, or full details if the > entity isn't registered on SDS. This is not the same issue. > > Grahame Ok -so references are always in by value - that's normal; how often are references used instead of in-place demographic entities? What is the basis for doing one of the other? Where does the RIM support references to demographic entities rather than including them by value? - thomas From grahame at kestral.com.au Mon Sep 4 11:13:10 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 04 Sep 2006 20:13:10 +1000 Subject: [New-ITS] Reshaping should be at the discretion of animplementor In-Reply-To: <44FBEBB5.4000200@OceanInformatics.biz> References: <44F7E093.1000804@OceanInformatics.biz> <44FBAFE3.7090901@kestral.com.au> <44FBEBB5.4000200@OceanInformatics.biz> Message-ID: <44FBFC36.50207@kestral.com.au> Thomas Beale wrote: > [I assume this was meant for the list] yes, whoops > Grahame Grieve wrote: >> there is never an option for include by reference - at this time. >> You must include by value always. >> >> but in some models there is an option to provide minimal >> details including an SDS reference, or full details if the >> entity isn't registered on SDS. This is not the same issue. >> >> Grahame > > Ok -so references are always in by value - that's normal; how often are > references used instead of in-place demographic entities? What is the > basis for doing one of the other? Where does the RIM support references > to demographic entities rather than including them by value? how often - as the business case requires. I cannot speak for any statistical count. where - there's id and other details. You constrain accordingly Grahame From grahame at kestral.com.au Mon Sep 4 11:13:12 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 04 Sep 2006 20:13:12 +1000 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FBEA4C.6010908@OceanInformatics.biz> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> Message-ID: <44FBFC38.5030705@kestral.com.au> ok. structures. What would a structure do? is it just a tree thingy? It's semantics free? Grahame Thomas Beale wrote: > Grahame Grieve wrote: >> so, Thomas, in the context of the RIM, what additional >> semantic patterns would you propose? what would the >> class definitions look like? >> >> Grahame >> >> > well, as I say to do something as simple as Apgar (or any time-series > observation - and there are hundreds), you need an easy way of doing > time-series and an easy way of doing structures (list in the case of > Apgar). There are about 6 other things I could propose, but let's just > leave it at that for the moment. > > - thomas > > > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Mon Sep 4 11:25:04 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 04 Sep 2006 20:25:04 +1000 Subject: [New-ITS] Considering the XUM and what ITS worth In-Reply-To: References: Message-ID: <44FBFF00.70601@kestral.com.au> ok, David and I agree that RIM level serialisation is the way to go. Just one schema, everything is easy, great. Done, thanks everyone, we'll present this to HL7 next week ... or maybe you don't agree. If you don't, please speak up... > > I am sure you need terminology services for HL7v3 (or any form of > semantically operable application) you can get away without a terminology service in demographics, in straight messaging - no problems. If you bring this background to V3, you wonder why it's so complex. RIM level serialisation is just part of that picture. > Some people find the idea of a "terminology service" frightening complex. I > suspect some of the commercial software providers in this area are partly > responsible for this. It really is just a series of lookups and computations > that need to optimized not rocket science ... More MP3 science ... once done > easy to replicate and enhance. so, join us in Eclipse and do it... ;-) > > > instead of > > or > > > opinions, anyone? > > > This does not look like a RIM based instance unless perhaps > "participationCode" is meant to be "typeCode". yes. whoops. should've checked instead of hurrying through that one. > Assuming that is just a typo I still disagree with this approach. > What is the point of the tautology "Author" and "AUT" > > actually, in the case of AUT, no point at all. stupid example, since Author is derived from AUT anyway. If it was an act, then the name would be more interesting and actually carry extra information > To be clear what I am suggesting is ... > > > > If the modelid is not simply repeating the name "AUT" but is referencing a > constraint then it would far better to reference the constraint by a > uniqueId (GUID /UUID in my view not OID or the current CFH use of a > structured templateId). > > For example: > > templateId="0a951a3b-ff3c-450b-99b2-9538367bf04d"> so why is opaque useless meaning better than suggestive useless meaning. And the problem with templateId is that you want to refer into a model - this only refers to the root of a model. (particularly current CFH models where you have choices that can only be differentiated by reference to the model) Charlie suggested making the root a namespace. Though I shied away from the name templateId since that has higher level non-ITS meaning, this would mean that you'd end up with something like this: not that the actual name really matters - like arguing about whether terminologies should have opaque identifiers really. but you think it's worth having such identifiers? Should writers be required to add them? Grahame From Charlie at ramseysystems.co.uk Mon Sep 4 11:54:58 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Mon, 4 Sep 2006 11:54:58 +0100 Subject: [New-ITS] Reshaping should be at the discretion of animplementor Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FC8B@ramseysc1420.RamseyNet.local> Grahame There are two rationales for the optimisations -- one is performance, and the other is ease of understanding (leading to fewer errors). If there are environments where the performance benefits of reshaping (or some other change to the wire format) are demonstrable then saying that this cannot be appropriately addressed at the standards level is simply wrong. To take the simplest form of reshaping -- allowing fixed and default values to be omitted from the instance and conveyed in the message specification. There appears to be a view that processing the message+specification pair is too complex for current implementations. There is no reason why the standard could not define a format for message specifications that included defaults, fixed, and reshaping annotations in a way that would allow a receiver to process message+specification and get a full rim-graph. Lets say that we agreed that the wire format should be serialised using a single RIM schema (and I agree that this seems the most likely conclusion to draw at this point). I suggest that it could still be useful to agree a format for such reshaping specifications, so that they can be reused in implementations. 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: 04 September 2006 08:05 > To: Robert Worden > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Reshaping should be at the discretion > of animplementor > > > > Robert Worden wrote: > > Grahame - > > > > You wrote: > > > >> Reshaping - while useful as an implementation tool - is > not going to > >> help with interoperability, unless we can get a single basis for > >> reshaping > > > > I disagree! > > actually, you agree, nearly. You describe a whole lot of uses > of reshaping that are *implementation tool* usages - and they > all make sense. > > Then you assert that > > > Only send reshaped message instances between consenting > > parties, who have agreed to use the same reshaped model. > > well, perhaps. In fact, fine. But it's not going to help us > find an ITS that is useful - which is what we are about here, > and nor is it an appropriate thing to engage in at the > standards level. In fact, in the end, all of the optimisation > things die at the standards level because they make > operability easier but interoperability harder. > > Grahame > > > Suppose I use a reshaped and restricted RMIM, purely as a > way to get > > full-ITS V3 onto the wire (not to reveal reshaped > instances in public). > > I use the reshaped model only as an intermediate step between my > > application and V3. Then: > > > > - Because the reshaped model is smaller and simpler than > the RMIM, and > > has business names, I make more accurate mappings onto my > applications > > > > - Because the mappings of the reshaped XML onto V3 are > > machine-generated, not hand-coded, there is no potential > for error in > > translation from reshaped XML to the full ITS > > > > - Therefore I have a more error-free interface between my > applications > > and V3 full ITS > > > > Surely that is 'going to help with interoperability'? And > it does not > > need a single basis for reshaping in order to work. If you > don't think > > so, Grahame, please tell me why. > > > > (I am genuinely perplexed at my failure to explain this > point to some > > very clever guys like you!) > > > > In using reshaped models like this, I would only be following the > > advice on the HL7 Implementation Wiki: > > > > 'Do add a layer of abstraction, in the form of an intermediate XML > > based format, and map this to HL7 v3 artefacts, e.g. with > the aid of a > > stylesheet. The structure of the intermediate format should be the > > best possible mix of the internal database format and the > model used > > by CDA/Clinical statements.' > > > > Or: > > > > 'If you are working with XSLT you need to define an > intermediate XML > > format for your data. This can be in "close to HL7" form or > in "close > > to native" form.' > > > > HL7 does not require standardization of the intermediate XMLs. > > > > Only when you go to the next stage, of sending reshaped > instances over > > the wire, do you get interoperability issues. My solution to these > > issues is: Only send reshaped message instances between consenting > > parties, who have agreed to use the same reshaped model. If either > > party wants to use full XML ITS, the other party has to provide it. > > And he can do so, because he has an accurate transform to do it. > > > > (This next stage is not necessary, unless you are concerned about > > performance and small message instances) > > > > Again - have I somehow failed to explain this point to > anybody else on > > the planet? What is wrong with it? > > > > Grahame - I think the key to your objection may be where > you say 'it's > > not going to solve problems at the level of the standard'. Maybe it > > doesn't need to. Perhaps we should distinguish between (a) > practical > > things that implementers can do now, and (b) proposed > changes to the > > standard. We can propose a mix of these if we want to. > > > > 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. > > > > -----Original Message----- > > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf > Of Grahame > > Grieve > > Sent: 04 September 2006 05:53 > > To: Robert Worden > > Cc: new-its at lists.hl7.org.uk > > Subject: Re: [New-ITS] Reshaping should be at the discretion of an > > implementor > > > > hi > > > > I think this should be rephrased as, "implemention should > be left to > > the implementor". > > > > No one (I hope) would disagree with this. > > > > Reshaping - while useful as an implementation tool - is not > going to > > help with interoperability, unless we can get a single basis for > > reshaping - and suddenly we are back to where Charlie was. > > > > So what would actually be useful is a tool - or set of tools - that > > can take an RMIM, and a profile on the RMIM - and produce useful > > implementation constructs, and then this can be offered to the > > implementors to help them implement. > > > > Robert, your tool is a step in the right direction here, and a > > laudable direction - but it's not going to solve problems > at the level > > of the standard, I think. > > > > The hard part is doing the profiling > > > > Grahame > > > > > > > > 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). > >> > >> > >> > >> 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/ > >> > >> > >> > > > ---------------------------------------------------------------------- > > -- > >> _______________________________________________ > >> 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 > > From Charlie at ramseysystems.co.uk Mon Sep 4 12:15:26 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Mon, 4 Sep 2006 12:15:26 +0100 Subject: [New-ITS] Considering the XUM and what ITS worth Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FC8C@ramseysc1420.RamseyNet.local> Grahame and David If all you are agreeing is that RIM classes should be used for element names, but that constraints can be referenced using templateId (or something like it) -- then you have just shifted the deckchairs. What is the purpose and use of templateId (it is mighty similar to the purpose and use of the current element names that are being ditched) Why not reference the constraints in the element names as GUIDs, and leave out the RIM names (or have them as required attributes). The answer is that the constraints should only be used for validating, and not for processing -- but if this is the case, then lets just make better validation tools, and avoid the confusion of having them in the instance. As a real friendly amendment I suggest that we use the ClassCode/TypeCode for the element names with the RIM class as a required attribute (if we have suddenly discovered that it would be useful to consumers to have this in the instance). These are regularly used in the paths that folk are currently writing, and so will be more useful until folk are happy writing lookup drive code (looking up terminology and or message specifications). Once folk are using lookup driven code whether elements are named after the RIM class name or the ClassCode will make no difference to them 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: 04 September 2006 11:25 > To: david at clininfo.co.uk > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Considering the XUM and what ITS worth > > ok, David and I agree that RIM level serialisation is the way to go. > Just one schema, everything is easy, great. > > Done, thanks everyone, we'll present this to HL7 next week > > ... or maybe you don't agree. If you don't, please speak up... > > > > > I am sure you need terminology services for HL7v3 (or any form of > > semantically operable application) > > you can get away without a terminology service in > demographics, in straight messaging - no problems. If you > bring this background to V3, you wonder why it's so complex. > RIM level serialisation is just part of that picture. > > > Some people find the idea of a "terminology service" frightening > > complex. I suspect some of the commercial software > providers in this > > area are partly responsible for this. It really is just a series of > > lookups and computations that need to optimized not rocket > science ... > > More MP3 science ... once done easy to replicate and enhance. > > so, join us in Eclipse and do it... ;-) > > > > > > > instead of > > > > or > > > > > > opinions, anyone? > > > > > > This does not look like a RIM based instance unless perhaps > > "participationCode" is meant to be "typeCode". > > yes. whoops. should've checked instead of hurrying through that one. > > > Assuming that is just a typo I still disagree with this approach. > > What is the point of the tautology "Author" and "AUT" > > > > > > actually, in the case of AUT, no point at all. stupid > example, since Author is derived from AUT anyway. If it was > an act, then the name would be more interesting and actually > carry extra information > > > To be clear what I am suggesting is ... > > > > > > > > If the modelid is not simply repeating the name "AUT" but is > > referencing a constraint then it would far better to reference the > > constraint by a uniqueId (GUID /UUID in my view not OID or > the current > > CFH use of a structured templateId). > > > > For example: > > > > > templateId="0a951a3b-ff3c-450b-99b2-9538367bf04d"> > > so why is opaque useless meaning better than suggestive > useless meaning. > And the problem with templateId is that you want to refer > into a model - this only refers to the root of a model. > (particularly current CFH models where you have choices that > can only be differentiated by reference to the model) > > Charlie suggested making the root a namespace. Though I shied > away from the name templateId since that has higher level > non-ITS meaning, this would mean that you'd end up with > something like this: > > xmlns:tid="0a951a3b-ff3c-450b-99b2-9538367bf04d" > templateId="tid:ExampleCloneClassName"> > > not that the actual name really matters - like arguing about > whether terminologies should have opaque identifiers really. > > but you think it's worth having such identifiers? Should > writers be required to add them? > > Grahame > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > > From david at clininfo.co.uk Mon Sep 4 12:25:05 2006 From: david at clininfo.co.uk (David Markwell) Date: Mon, 4 Sep 2006 12:25:05 +0100 Subject: [New-ITS] Considering the XUM and what ITS worth In-Reply-To: <44FBFF00.70601@kestral.com.au> Message-ID: Grahame A few quick responses: You said: you can get away without a terminology service in demographics, in straight messaging - no problems. I agree ---- But then you said: If you bring this background to V3, you wonder why it's so complex. RIM level serialisation is just part of that picture. I am not sure that RIM level serialization is such a radical idea. Curiously it is still more specific than HL7v2 naming conventions plus it has all the formalism of the model. --- You said: so, join us in Eclipse and do it... ;-) Not everything is Eclipse, not everything is HL7. My comment about the terminology services being an issues for application integration (rather than specific HL7 integration) means that this is not a doing "it" but rather a being involved in the evolution of "them". Which is precisely where a lot of my mental cycles are directed at present. ;-) --- You said so why is opaque useless meaning better than suggestive useless meaning. This is an established principle in respect of terminology (see Cimino, J, Desiderata for controlled medical vocabularies in the twenty-first century. Methods of Information in Medicine, 1998. 37(4-5): pp. 394-403.) Summarized in http://www.dbmi.columbia.edu/cimino/Presentations/1998%20-%20Swed%20-%20Desi derata%20for%20Controlled%20Medical%20Vocabularies.ppt You can discuss whether the same should apply to message models and anything else. I used to think they were different but the more I look the more I see the same problems that Jim Cimino and others identified in vocabularies. Meaningful identifiers are a hostage to fortune, misinterpretation and scalability etc etc. They are fine in very controlled spaces (e.g. the RIM serialization itself) but in naming constraints meaningful names are a trail of tempting candies that lead us (Hansel and Gretel like) to a dark confined place. Far better to resist this temptation and include more meaning in the metadata associated with the constraint. Kind Regards David Markwell Mailto:david at clininfo.co.uk -----Original Message----- From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame Grieve Sent: 04 September 2006 11:25 To: david at clininfo.co.uk Cc: grahame at jivamedical.com; new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Considering the XUM and what ITS worth ok, David and I agree that RIM level serialisation is the way to go. Just one schema, everything is easy, great. Done, thanks everyone, we'll present this to HL7 next week ... or maybe you don't agree. If you don't, please speak up... > > I am sure you need terminology services for HL7v3 (or any form of > semantically operable application) you can get away without a terminology service in demographics, in straight messaging - no problems. If you bring this background to V3, you wonder why it's so complex. RIM level serialisation is just part of that picture. > Some people find the idea of a "terminology service" frightening > complex. I suspect some of the commercial software providers in this > area are partly responsible for this. It really is just a series of > lookups and computations that need to optimized not rocket science ... > More MP3 science ... once done easy to replicate and enhance. so, join us in Eclipse and do it... ;-) > > > instead of > > or > > > opinions, anyone? > > > This does not look like a RIM based instance unless perhaps > "participationCode" is meant to be "typeCode". yes. whoops. should've checked instead of hurrying through that one. > Assuming that is just a typo I still disagree with this approach. > What is the point of the tautology "Author" and "AUT" > > actually, in the case of AUT, no point at all. stupid example, since Author is derived from AUT anyway. If it was an act, then the name would be more interesting and actually carry extra information > To be clear what I am suggesting is ... > > > > If the modelid is not simply repeating the name "AUT" but is > referencing a constraint then it would far better to reference the > constraint by a uniqueId (GUID /UUID in my view not OID or the current > CFH use of a structured templateId). > > For example: > > templateId="0a951a3b-ff3c-450b-99b2-9538367bf04d"> so why is opaque useless meaning better than suggestive useless meaning. And the problem with templateId is that you want to refer into a model - this only refers to the root of a model. (particularly current CFH models where you have choices that can only be differentiated by reference to the model) Charlie suggested making the root a namespace. Though I shied away from the name templateId since that has higher level non-ITS meaning, this would mean that you'd end up with something like this: not that the actual name really matters - like arguing about whether terminologies should have opaque identifiers really. but you think it's worth having such identifiers? Should writers be required to add them? Grahame From rik.smithies at cfh.nhs.uk Mon Sep 4 12:27:59 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Mon, 4 Sep 2006 12:27:59 +0100 Subject: [New-ITS] Reshaping should be at the discretion of animplementor Message-ID: <1A3D105C334EAE49BDDD93D8767573F5043C18DE@EXCHAQ2.nhsia.nhs.uk> Hi Robert, on the specific point of using the collapsed model as your intermediate XML format, which I only appreciated in your last post, I think that is a little bit of a stretch. The intermediate for an implementer uses may be something close to their existing data structure. This will be quite different from the message format, and different from the receiver's data format, and hence their intermediate XML. If the intermediate format is defined by the message modeller, who may not be aware of either party's format, then it may not be a good fit. So you would probably end up defining another intermediate layer, which is then mapped to the collapsed model format. Now, there is some merit here that the collapsed model may have removed some of the perceived "HL7 junk", defaults, unfamiliar names etc and so be easier to target. These are the proposed benefits of the collapsed model that we are discussing. But I'm not sure we can go further and expect this model will just slot in as the intermediate format for many implementers. cheers, Rik > -----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: 04 September 2006 07:41 > To: grahame at jivamedical.com > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Reshaping should be at the discretion > of animplementor > > Grahame - > > You wrote: > > > Reshaping - while useful as an implementation tool - is not > going to > > help with interoperability, unless we can get a single basis for > > reshaping > > I disagree! > > Suppose I use a reshaped and restricted RMIM, purely as a way > to get full-ITS V3 onto the wire (not to reveal reshaped > instances in public). > I use the reshaped model only as an intermediate step between > my application and V3. Then: > > - Because the reshaped model is smaller and simpler than the > RMIM, and has business names, I make more accurate mappings > onto my applications > > - Because the mappings of the reshaped XML onto V3 are > machine-generated, not hand-coded, there is no potential for > error in translation from reshaped XML to the full ITS > > - Therefore I have a more error-free interface between my > applications and V3 full ITS > > Surely that is 'going to help with interoperability'? And it > does not need a single basis for reshaping in order to work. > If you don't think so, Grahame, please tell me why. > > (I am genuinely perplexed at my failure to explain this point > to some very clever guys like you!) > > In using reshaped models like this, I would only be > following the advice on the HL7 Implementation Wiki: > > 'Do add a layer of abstraction, in the form of an > intermediate XML based format, and map this to HL7 v3 > artefacts, e.g. with the aid of a stylesheet. The structure > of the intermediate format should be the best possible mix of > the internal database format and the model used by > CDA/Clinical statements.' > > Or: > > 'If you are working with XSLT you need to define an > intermediate XML format for your data. This can be in "close > to HL7" form or in "close to native" form.' > > HL7 does not require standardization of the intermediate XMLs. > > Only when you go to the next stage, of sending reshaped > instances over the wire, do you get interoperability issues. > My solution to these issues is: Only send reshaped message > instances between consenting parties, who have agreed to use > the same reshaped model. If either party wants to use full > XML ITS, the other party has to provide it. And he can do so, > because he has an accurate transform to do it. > > (This next stage is not necessary, unless you are concerned > about performance and small message instances) > > Again - have I somehow failed to explain this point to > anybody else on the planet? What is wrong with it? > > Grahame - I think the key to your objection may be where you > say 'it's not going to solve problems at the level of the > standard'. Maybe it doesn't need to. Perhaps we should > distinguish between (a) practical things that implementers > can do now, and (b) proposed changes to the standard. We can > propose a mix of these if we want to. > > 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. > > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of > Grahame Grieve > Sent: 04 September 2006 05:53 > To: Robert Worden > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Reshaping should be at the discretion > of an implementor > > hi > > I think this should be rephrased as, "implemention should be > left to the implementor". > > No one (I hope) would disagree with this. > > Reshaping - while useful as an implementation tool - is not > going to help with interoperability, unless we can get a > single basis for reshaping - and suddenly we are back to > where Charlie was. > > So what would actually be useful is a tool - or set of tools > - that can take an RMIM, and a profile on the RMIM - and > produce useful implementation constructs, and then this can > be offered to the implementors to help them implement. > > Robert, your tool is a step in the right direction here, and > a laudable direction - but it's not going to solve problems > at the level of the standard, I think. > > The hard part is doing the profiling > > Grahame > > > > 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). > > > > > > > > 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/ > > > > > > > -------------------------------------------------------------- > ---------- > > > > _______________________________________________ > > 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 > > _________________________________________________________________ > 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 david at clininfo.co.uk Mon Sep 4 12:35:19 2006 From: david at clininfo.co.uk (David Markwell) Date: Mon, 4 Sep 2006 12:35:19 +0100 Subject: [New-ITS] Reshaping should be at the discretion of animplementor In-Reply-To: <44FBEBB5.4000200@OceanInformatics.biz> Message-ID: Grahame I think Thomas has made an important point here which may be an area of misunderstanding in other discussions also. Inclusion by reference always involves inclusion of some value that represents the reference. In software when we talk of "by reference" the "value" passed is typically a pointer that we neither see nor care about. Whether the pointer is a number representing a memory address or a more complex reference (e.g. an unique object identifier or an Xpath) is a subject of blythe indifference. However in an on the wire instance the "reference" must be represented by a "value" that the recipient can resolve. Be that an SDS identifier, or the Id of an Act class instance. Confusion can arise about this in relation to the distinction between: A) By reference to something in the same message instance. B) By reference to something is another message instance previous communicated. C) By reference to an external resource (such as PDS). In case (A) the reference could be of a nature entirely internal to the message structure (e.g. an IDREF or XPATH). In case (B) it can be argues that an extension of the same IDREF or XPATH approach is theoretically possible. This is only true IF the message instance is also part of the references AND IF we assume operational accessibility of the communicated forms. In my view in most cases the communicated forms should be archived but usually not kept in an operational form that would allow this type of cross-message referencing. In case (C) the reference is to an external resource. Thus the reference must use some mutually understood identificate not an ITS specific reference approach. >From the perspective of simplicity and non-ITS dependence my view is that all uses of "by reference" should be "by reference to a known (or previously communicated) identifier". This works for all cases (A), (B) and (C). Kind Regards David Markwell Mailto:david at clininfo.co.uk -----Original Message----- From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Thomas Beale Sent: 04 September 2006 10:03 To: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Reshaping should be at the discretion of animplementor [I assume this was meant for the list] Grahame Grieve wrote: > there is never an option for include by reference - at this time. > You must include by value always. > > but in some models there is an option to provide minimal details > including an SDS reference, or full details if the entity isn't > registered on SDS. This is not the same issue. > > Grahame Ok -so references are always in by value - that's normal; how often are references used instead of in-place demographic entities? What is the basis for doing one of the other? Where does the RIM support references to demographic entities rather than including them by value? - thomas _______________________________________________ New-ITS mailing list New-ITS at lists.hl7.org.uk http://lists.hl7.org.uk/mailman/listinfo/new-its From Charlie at ramseysystems.co.uk Mon Sep 4 12:30:45 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Mon, 4 Sep 2006 12:30:45 +0100 Subject: [New-ITS] Node counts Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FC8D@ramseysc1420.RamseyNet.local> David / Grahame To address the risk that fish pose to standardisation It seems to me that what the fishy folk are after is an intermediate form that is easier to process (mainly because of smaller node count, but also because of the choice of terminology for the node names (XML element and attribute names). We know that this is happening in implementation projects, with either the project sponsor, or a third party, providing components to "hid the HL7v3 from the implementers". Where the project sponsor is providing this component it is unlikely that whether it is fish of fowl on the wire will make any difference to how interoperable it is -- the sponsor determines what is conformant for the project. Indeed the same is true when there is a variety of technologies used to serialise - the set of valid instances are determined by the projects implementation guide. In terms of maintaining conformance what matters most is the projects approach to conformance. The project may agree that any discovered error in its implementation guide that contradicts the HL7v3 normative edition should be changed as a technical correction, or it may say that in cases of conflict its implementation guide takes priority. In either case it may take care that the implementation guide is defining a true subset of HL7v3 conformant instances, or it may not. We all know that it is perfectly possible to misuse attributes and structures in RIM-based models. Since any changes to the reshaped models will have to be done in the RIM-based model first, it seems that the risk of instances with bad RIM semantics is only marginally increased by having a reshaped wire format, and that IF there were substantial project cost savings as a result, AND these were ploughed into implementation and conformance test tooling and materials, THEN the overall impact on semantic consistency would be positive. I share the concern that conformance should be clear, so that everyone can reap the benefits of requiring and being able to establish what is conformant -- but both reshaping and RIM-class element names will require custom testing tools -- and the fact that these will not come straight from the XML mainstream will make conformance testing more difficult. So the case for not using reshaped models cannot rest on standardisation drift -- however it can rest on a reluctance to process both a message and a message specification at the same time -- and this does indeed limit what can be done at the standards level (to respond to a different email from Grahame) 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: 04 September 2006 05:03 > To: david at clininfo.co.uk > Cc: 'Robert Worden'; new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Node counts > > hi all > > catching up on this thread. > > It seems to me that from the start of this thread, the > concept of "re-use" has been missing. If I track Robert's > numbers correctly, they include each use of the same CMET and > data type as a separate count. And of course, if you refuse > to engage in re-use, you have a large problem in front of > you. So no one does, and those figures are misleading. It > would be more useful if we compared a number that David > hinted at a few times, related to different types & attributes. > How many types and attributes are there? > > But nevertheless, the numbers are very large; they grow so > large so quickly because it's so easy to construct things. > (This alone tells me that it's wrong to compare the V3 > metholodogy to assembly code. It's manifestly a higher level > construct. We can argue the merits of particular constructs, > but if we start from a wrong assumption about why, we'll get > nowhere fast). > > The fact that the numbers are so large relates to complexity > in the datatypes, and chains of re-use in CMETs. Is it really > a problem if CMETs create all sorts of re-use potentials, > particularly by exploring scoper qualifications? If we allow > for any form of coherent re-use, is there really a problem? > > I don't think that he V3 datatypes are inherently more > complex than the v2 datatypes. I pine for a more coherent > computational expression of them (and we nearly have one in > the UML ITS data types), and of constraints upon them (which > I will propose at Boca Raton), but I don't think they > themselves are a problem (and multiplying their internal > structure by their frequency of use is a non-sensical > assessment of their complexity). > > btw, for interest, using roughly Robert's technique, the > count, including datatypes, for a V2.5 lab message (ORU_R01) is > 8733 nodes. > > Grahame > > > > David Markwell wrote: > > Robert > > > > The problem as I see it is that it will be oh so easy for > people using > > reshaped instances to place reliance on the particularity of those > > instances and to subtly change the way they use them and > basically to > > diverge. The more special case reshapings that exist the higher the > > risk and the more difficult to spot the offenders in their closed > > worlds. As they move to the open world suddenly all is > revealed. My > > contention is that to be sure this does not happen these > implementers > > will need to understand the generic foundations and if they do then > > why not use them. If its just to make messages smaller or > simpler to > > process then one can understand the motivation for the reshape. > > However if as I suspect they will later need to go all the way then > > why have them play with fire before giving them the the > advice on full and safe ITS? > > > > Kind Regards > > > > David Markwell > > > > > > Mailto:david at clininfo.co.uk > > > > > > _____ > > > > From: Robert Worden [mailto:Robert.Worden at Charteris.com] > > Sent: 03 September 2006 09:30 > > To: david at clininfo.co.uk > > Cc: new-its at lists.hl7.org.uk > > Subject: RE: Node counts > > > > > > > > David - > > > > > > > > If we agree on 1-6, then that is the most important point. > That gets > > the main benefit of using restricted and reshaped RMIMs (fish) as a > > way of generating either RIM-based XML (fowl) or current XML ITS > > (fish-fowl hybrid). The benefit is that restricted and > reshaped RMIMs > > are smaller and easier for implementers to understand and > map onto - > > so implementations should be quicker and (more important) > more accurately done. > > > > > > > > The only point of going to 7 (reshaped message instances over the > > wire) is a performance benefit - the reshaped instances will be > > smaller, and you avoid two translations (to/from full ITS). > To me the > > performance point is much less important than the ease of message > > implementation - but it may be important for others. > > > > > > > > You say 'I think that if 6-->7 mapping is possible.' and > it certainly is. > > The big benefit of restricting/reshaping an RMIM is that > the tool will > > not allow you to make any illegal moves (e.g. collapsing a 1:N > > association) and will always keep track of the mappings between the > > RMIM and the reshaped version - so you can always generate XSLT > > translations between the two (not write them by hand) and > they will be > > perfectly accurate. You can have 6-7 and 7-6 converters > anywhere you like. > > > > > > > > So to come to your example - A and B agree to use reshaped > instances > > over the wire, because they need the extra performance of smaller > > message instances. But as soon as C comes along and demands > full ITS > > instances, A has to give them to him - and can easily do > so, because > > he has the transform (automatically generated, accurate) > and can just > > run it each time. I don't see a problem for A, B or C (except maybe > > understanding each other's English dialects). > > > > > > > > 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: David Markwell [mailto:david at clininfo.co.uk] > > Sent: 01 September 2006 15:40 > > To: Robert Worden > > Cc: new-its at lists.hl7.org.uk > > Subject: RE: Node counts > > > > > > > > Robert > > > > > > > > I would agree that we seem close to agreement on 1-6. > > > > > > > > I remain to be convinced that 7 over the wire helps anyone. > > > > > > > > I think that if 6-->7 mapping is possible (which is implicit in the > > idea of > > 7 existing at all) then simple 6-->7 and 7-->6 converters > for specific > > environments would be a far better solution. The reason > that I prefer > > this is as follows: > > > > > > > > Say that A and B agree to communicate using 7. They are happy ;-) > > > > > > > > Until one day B needs to communicate with C > > > > > > > > Unfortunately for B, C who works in a more diverse > environment aligned > > nicely with the generic structures that they use in > multiple domains. > > They use 6 with everyone - they may have use a kind of 7 view from > > time to time to aid understanding and debugging. However on > the wire there stick with 6. > > > > > > > > Now B argues "I say you chaps we know how to do this we've > done it for > > years with the A Team and it looks like you Cee fellows are > at 6's and no 7's" > > > > > > > > However C replies "look buddy we bin doing dis stuff wid > the rest of > > the alph'bet from Dee throu' Zee you Bees get wid the > program or buzz off". > > > > > > > > Who should win in this show down and who should be stung? > > > > > > > > Who should be forced to convert? > > > > > > > > I know whose case I would argue and ... on that basis ... > I'd rather > > avoid the argument by asserting up front that there is no 7 > as part of > > the standard. So while consenting parties can use fax or > sneaker-net > > or funny handshake or their own flavour of 7 that is not > the standard. > > > > > > > > Kind Regards > > > > David Markwell > > > > Mailto:david at clininfo.co.uk > > > > > > > > > > > > _____ > > > > From: Robert Worden [mailto:Robert.Worden at Charteris.com] > > Sent: 01 September 2006 11:48 > > To: david at clininfo.co.uk > > Cc: new-its at lists.hl7.org.uk > > Subject: RE: Node counts > > > > David - > > > > > > > > I think we are getting somewhere. If RMIM names are > neither fish nor fowl: > > > > > > > > 1. RIM names with classCodes etc. are pure fowl > > > > 2. A reshaped RMIM, with business names defined locally by a > > super-implementor such as CfH, are fish. > > > > 3. Accurate fish-to-fowl transformations come out of > the reshaping > > process > > > > 4. So anyone can produce or consume fish or fowl to > his taste (fish is > > easier for some, fowl for others) > > > > 5. You must be able to produce fowl to be V3 > conformant. You can do > > this by the transformations. > > > > 6. Normally, it is fowl that goes over the wire. > > > > 7. Between consenting parties, fish may be exchanged > (or performance > > reasons only) > > > > > > > > All this seems to me perfectly possibly now, and compatible > with HL7 > > methodology - with the possible exception of (7), which > needs discussion. > > > > > > > > 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: David Markwell [mailto:david at clininfo.co.uk] > > Sent: 01 September 2006 10:18 > > To: Robert Worden > > Cc: new-its at lists.hl7.org.uk > > Subject: RE: Node counts > > > > > > > > Robert > > > > > > > > Your comment about ambiguity is interesting. I would argue > it is not > > ambiguous because the meaning should be captured in the coding > > (classCode, moodCode, code etc). I do not think detailed > semantics is > > a schema level issue - it depends on content. Some apps will > > inevitably have different models which put different items of > > information into different structures based on content. They can > > decide to do that if they wish but the information communicated to > > them and by them is normalized as RIM physical class instances. > > > > > > > > At present (or in various other proposal) there is the RIM class, > > there is the RMIM class name structure and there is the > applications > > way of storing and handling information. The RMIM class > business names > > are neither fish nor fowl. They are not the names in the > applications > > (because these are internal design driven) and they are not > the same > > as the RIM. Implementers try to make sense of the element names and > > risk ignoring the semantic identify of two statements (i.e. > two Acts > > with identical attribute content) simply because the > element names differ. > > > > > > > > Thus my contention is that this layer of additional names which was > > intended as a bridge or intermediate abstraction layer has become > > instead a distraction layer. My original assumption in backing and > > arguing for business names was that this would make schema > validation > > more effective at checking constraints while any sane application > > developer would ignore the names and process as advised > based only on the classCode etc. > > > > > > > > How wrong I was and how seriously. I confess that only when people > > started to add names to ever greater depths of spuriously familiar > > detailed naming did it strike me how seriously we have > failed to communicate this message. > > > > > > > > Kind Regards > > > > David Markwell > > > > Mailto:david at clininfo.co.uk > > > > > > > > > > > > _____ > > > > From: Robert Worden [mailto:Robert.Worden at Charteris.com] > > Sent: 01 September 2006 09:56 > > To: david at clininfo.co.uk > > Cc: new-its at lists.hl7.org.uk > > Subject: RE: Node counts > > > > David - > > > > > > > > Glad we are getting closer - but while I agree that 'Moving to RIM > > named classes would massively reduce the path count.', I'm > not sure it > > would reduce it usefully. > > > > > > > > There is a small point that XML nodes and XPaths will use > association > > names, rather than class names; so in stead of RIM classes > like 'Act' > > we would have RIM association names like 'scoper' . But > that is really > > a small point. If you restricted yourself to RIM names (and used > > simple XPaths with only node > > names) then I agree that the number of distinct XPaths > would be much > > smaller > > - but each XPath would then be very ambiguous, telling you > only 'you > > have got to depth 5 in the structure' and I think not much more. > > > > > > > > Anybody doing RIM-based processing would be looking at > classCodes etc. > > as he went down the structure, so he would effectively be > navigating > > XPaths with steps like > > > > /player[@classCode = 'PAT']/ which would take him more > unambiguously > > down the structure. I think the number of these XPaths > would be just > > as large as my node/path counts, regardless of naming. > (Maybe they are > > Gunther's > > HPaths.) > > > > > > > > I agree with you that for some purposes, and for some people, pure > > RIM-based processing is the right way to go, and avoids a > lot of the > > naming problems you refer to. But I'm not sure it is > everybody's cup > > of tea; I'd rather give a choice and let the market decide. > With what > > I propose, we can have our cake and eat it. Anyone who sends or > > receives flattened/renamed/reshaped messages must also be > able to send > > or receive full ITS messages - and will have the > transforms to move > > accurately between the two. Anyone who wants to receive > only full ITS > > messages, and do RIM-based processing, can do so (= have cake). > > Anybody who wants to do other things, using reshaped > messages, can do > > so (= eat it). I don't see that there has to be any > dilemma between the two. > > > > > > > > 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. > > > > > > > > _____ > > > > From: David Markwell [mailto:david at clininfo.co.uk] > > Sent: 31 August 2006 18:37 > > To: Robert Worden > > Cc: new-its at lists.hl7.org.uk > > Subject: RE: Node counts > > > > > > > > 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/ > > > > _________________________________________________________________ > > 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/ > > > > _________________________________________________________________ > > 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 > > -- > 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 > > From Thomas.Beale at OceanInformatics.biz Mon Sep 4 12:53:22 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Mon, 04 Sep 2006 12:53:22 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FBFC38.5030705@kestral.com.au> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> Message-ID: <44FC13B2.4060704@OceanInformatics.biz> Grahame Grieve wrote: > ok. structures. What would a structure do? > > is it just a tree thingy? It's semantics free? > No, it's semantics-laden just like everything else. Every node needs to be coded. For example: - nodes of a list need to be coded "systolic", "diastolic", or "PaO2", "PaCO2", or "PCV", "Platelets" etc... - nodes of a time series are coded with their time, e.g. 1 min, 2 min, 5 min, 10 min (= LOINC times for Apgar) Having semantically capable structures is the basis of: a) being able to efficiently build larger structures like messages b) multiple people building such definitions using the same idea of "time-series", "list" etc - that can be understood immediately by software c) semantic paths and querying. I'm just pointing out that a lot of pain is due to these basic lacks in the model. And that's before we get onto the other 6 patterns missing from the RIM;-) - thomas beale From david at clininfo.co.uk Mon Sep 4 12:55:45 2006 From: david at clininfo.co.uk (David Markwell) Date: Mon, 4 Sep 2006 12:55:45 +0100 Subject: [New-ITS] Considering the XUM and what ITS worth In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A04FC8C@ramseysc1420.RamseyNet.local> Message-ID: Charlie See comments I line. Kind Regards David Markwell Mailto:david at clininfo.co.uk -----Original Message----- From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] Sent: 04 September 2006 12:15 To: grahame at jivamedical.com; david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: [New-ITS] Considering the XUM and what ITS worth Grahame and David If all you are agreeing is that RIM classes should be used for element names, but that constraints can be referenced using templateId (or something like it) -- then you have just shifted the deckchairs. What is the purpose and use of templateId (it is mighty similar to the purpose and use of the current element names that are being ditched) Why not reference the constraints in the element names as GUIDs, and leave out the RIM names (or have them as required attributes). The answer is that the constraints should only be used for validating, and not for processing -- but if this is the case, then lets just make better validation tools, and avoid the confusion of having them in the instance. You may describe this as shifting the deckchairs. If so I think it is shifting the deckchairs from the decks of several overloaded rowing boats drifting in different directions around the Bermuda Triangle and relocating them around the pool of 5 star resort. I am arguing for the higher level validation of conformance to be an application level determination. Thus the RIM physical names and the general attribute constraints are Schema testable. Everything else is application level. The basis of this view is that the application in any event has to process the data to store it sensibly in a manner that it can process. The application needs to have access to sufficient terminology services to allow it to appropriately complete any necessary semantic operability of that system. Thus placing validation that requires these services and this level of understanding outside the application layer is creating duplication. There are of course two reasons to want a more general way of doing the validation. First as an input filter to systems that do not have their own semantic operability (i.e. those that merely store and represent data to others) and secondly to provided independent adjudication in cases of dispute. However, this argues in favour of the original proposition since the evidence to date is that managing semantic constraints at schema or even schematron level is non-trivial. An ITS independent form that accepts the communication if it meets the generic schema, stores it accordingly in a RIM compliant class structure and then applies constraints would seem worth considering. As a real friendly amendment I suggest that we use the ClassCode/TypeCode for the element names with the RIM class as a required attribute (if we have suddenly discovered that it would be useful to consumers to have this in the instance). This may be friendly meant but it is not a friendly amendment. I am do not want any class names not explicitly in the RIM diagram appearing in instances. Names based on moodCode and classCode are part of the slippery slope. These are regularly used in the paths that folk are currently writing, and so will be more useful until folk are happy writing lookup drive code (looking up terminology and or message specifications). Once folk are using lookup driven code whether elements are named after the RIM class name or the ClassCode will make no difference to them 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: 04 September 2006 11:25 > To: david at clininfo.co.uk > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Considering the XUM and what ITS worth > > ok, David and I agree that RIM level serialisation is the way to go. > Just one schema, everything is easy, great. > > Done, thanks everyone, we'll present this to HL7 next week > > ... or maybe you don't agree. If you don't, please speak up... > > > > > I am sure you need terminology services for HL7v3 (or any form of > > semantically operable application) > > you can get away without a terminology service in demographics, in > straight messaging - no problems. If you bring this background to V3, > you wonder why it's so complex. > RIM level serialisation is just part of that picture. > > > Some people find the idea of a "terminology service" frightening > > complex. I suspect some of the commercial software > providers in this > > area are partly responsible for this. It really is just a series of > > lookups and computations that need to optimized not rocket > science ... > > More MP3 science ... once done easy to replicate and enhance. > > so, join us in Eclipse and do it... ;-) > > > > > > > instead of > > > > or > > > > > > opinions, anyone? > > > > > > This does not look like a RIM based instance unless perhaps > > "participationCode" is meant to be "typeCode". > > yes. whoops. should've checked instead of hurrying through that one. > > > Assuming that is just a typo I still disagree with this approach. > > What is the point of the tautology "Author" and "AUT" > > > > > > actually, in the case of AUT, no point at all. stupid example, since > Author is derived from AUT anyway. If it was an act, then the name > would be more interesting and actually carry extra information > > > To be clear what I am suggesting is ... > > > > > > > > If the modelid is not simply repeating the name "AUT" but is > > referencing a constraint then it would far better to reference the > > constraint by a uniqueId (GUID /UUID in my view not OID or > the current > > CFH use of a structured templateId). > > > > For example: > > > > > templateId="0a951a3b-ff3c-450b-99b2-9538367bf04d"> > > so why is opaque useless meaning better than suggestive useless > meaning. > And the problem with templateId is that you want to refer into a model > - this only refers to the root of a model. > (particularly current CFH models where you have choices that can only > be differentiated by reference to the model) > > Charlie suggested making the root a namespace. Though I shied away > from the name templateId since that has higher level non-ITS meaning, > this would mean that you'd end up with something like this: > > xmlns:tid="0a951a3b-ff3c-450b-99b2-9538367bf04d" > templateId="tid:ExampleCloneClassName"> > > not that the actual name really matters - like arguing about whether > terminologies should have opaque identifiers really. > > but you think it's worth having such identifiers? Should writers be > required to add them? > > Grahame > > _______________________________________________ > 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 Mon Sep 4 13:04:33 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 04 Sep 2006 22:04:33 +1000 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FC13B2.4060704@OceanInformatics.biz> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> Message-ID: <44FC1651.7060107@kestral.com.au> let's go further than this rather than just saying there's things missing. How does this fit in the RIM? is it some kind of Act-Relationship generator? maybe a generic act relationships for a list of things that have the same kind of relationship with some parameter to differentiate them? > - nodes of a list need to be coded "systolic", "diastolic", or "PaO2", > "PaCO2", or "PCV", "Platelets" etc... really? Why do I look at this and think it's semantics free? Coded how? Grahame Thomas Beale wrote: > Grahame Grieve wrote: >> ok. structures. What would a structure do? >> >> is it just a tree thingy? It's semantics free? >> > No, it's semantics-laden just like everything else. Every node needs to > be coded. For example: > - nodes of a list need to be coded "systolic", "diastolic", or "PaO2", > "PaCO2", or "PCV", "Platelets" etc... > - nodes of a time series are coded with their time, e.g. 1 min, 2 min, 5 > min, 10 min (= LOINC times for Apgar) > > Having semantically capable structures is the basis of: > a) being able to efficiently build larger structures like messages > b) multiple people building such definitions using the same idea of > "time-series", "list" etc - that can be understood immediately by software > c) semantic paths and querying. > > I'm just pointing out that a lot of pain is due to these basic lacks in > the model. And that's before we get onto the other 6 patterns missing > from the RIM;-) > > - thomas beale > > _______________________________________________ > 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 Thomas.Beale at OceanInformatics.biz Mon Sep 4 14:18:56 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Mon, 04 Sep 2006 14:18:56 +0100 Subject: [New-ITS] Reshaping should be at the discretion of animplementor In-Reply-To: References: Message-ID: <44FC27C0.2060101@OceanInformatics.biz> David Markwell wrote: > > Confusion can arise about this in relation to the distinction between: > A) By reference to something in the same message instance. > B) By reference to something is another message instance previous > communicated. > C) By reference to an external resource (such as PDS). > > ... > > >From the perspective of simplicity and non-ITS dependence my view is that > all uses of "by reference" should be "by reference to a known (or previously > communicated) identifier". This works for all cases (A), (B) and (C). > If I understand correctly, the implication is that such references are not supported in the RIM (I know they are not), but have to be made explicit in some intermediate level of model. As soon as you do this, you are invoking the need for a model of "message content" (what is "in" a message) - i.e. a concept in which various content can be serialised, including pieces of content (demographic items) that can be referenced by other pieces of content. You also require the ability to actually state the references - are we suggesting that it only happens at the IDREF (i.e. XML) level? What are the object structures that the serialised content is deserialised into - does it still contain references or is everything expanded out in place again? This might be important if messages are being stored. - thomas From Thomas.Beale at OceanInformatics.biz Mon Sep 4 14:25:23 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Mon, 04 Sep 2006 14:25:23 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FC1651.7060107@kestral.com.au> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> <44FC1651.7060107@kestral.com.au> Message-ID: <44FC2943.9090702@OceanInformatics.biz> Grahame Grieve wrote: > let's go further than this rather than just > saying there's things missing. > > How does this fit in the RIM? Hey - I'm asking the questions here;-) > is it some kind of > Act-Relationship generator? maybe a generic act > relationships for a list of things that have the > same kind of relationship with some parameter to > differentiate them? all interesting possibilities. Maybe it's just a DIM that includes useful patterns that you can then work directly from for creating messages as constraint definitions... > > > - nodes of a list need to be coded "systolic", "diastolic", or "PaO2", > > "PaCO2", or "PCV", "Platelets" etc... > > really? Why do I look at this and think it's semantics free? > Coded how? In an archetype these are all coded with internal archetype codes and then Snomed and/or LOINC codes, depending on availability. In some other system, an equivalent thing has to be done. I'm not sure what you are meaning by "semantics" here if you are saying these are semantics-free, but these information nodes carry the same kind of domain semantics as any other part of an information structure - the coding is saying that this node means "systolic BP value" and that node means "diastolic BP value" and so on. That's why with archetypes + templates we can create XPaths that drill right down to such low level items. The point here is that the RIM doesn't provide enough structure - inbuilt information semantics - to hang codes on - all you get is role-participation-act and act-act_rel hierarchy patterns. - thomas From david at clininfo.co.uk Mon Sep 4 14:36:44 2006 From: david at clininfo.co.uk (David Markwell) Date: Mon, 4 Sep 2006 14:36:44 +0100 Subject: [New-ITS] Reshaping should be at the discretion of animplementor In-Reply-To: <44FC27C0.2060101@OceanInformatics.biz> Message-ID: Thomas I think you missed or I was not clear enough in my summary: Just to repeat ============== >From the perspective of simplicity and non-ITS dependence my view is that all uses of "by reference" should be "by reference to a known (or previously communicated) identifier". This works for all cases (A), (B) and (C). This I am arguing against use of IDREF or XPATH referents. I am saying we should not be using references that are message dependent. Thus the answer to your question is that the Id used in a reference is the Id of a previously communicated and stored instance of some information element - be that a person in a role or a clinical statement or whatever. Its not an Id of something specific to its occurrence in a specific message. Therefore of course I am not suggesting it be expanded up in the recipient system. However, to meet *some* requirements it could naturally be expanded for display or retrieval functions. Kind Regards David Markwell Mailto:david at clininfo.co.uk -----Original Message----- From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Thomas Beale Sent: 04 September 2006 14:19 To: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Reshaping should be at the discretion of animplementor David Markwell wrote: > > Confusion can arise about this in relation to the distinction between: > A) By reference to something in the same message instance. > B) By reference to something is another message instance previous > communicated. > C) By reference to an external resource (such as PDS). > > ... > > >From the perspective of simplicity and non-ITS dependence my view is > >that > all uses of "by reference" should be "by reference to a known (or > previously > communicated) identifier". This works for all cases (A), (B) and (C). > If I understand correctly, the implication is that such references are not supported in the RIM (I know they are not), but have to be made explicit in some intermediate level of model. As soon as you do this, you are invoking the need for a model of "message content" (what is "in" a message) - i.e. a concept in which various content can be serialised, including pieces of content (demographic items) that can be referenced by other pieces of content. You also require the ability to actually state the references - are we suggesting that it only happens at the IDREF (i.e. XML) level? What are the object structures that the serialised content is deserialised into - does it still contain references or is everything expanded out in place again? This might be important if messages are being stored. - thomas _______________________________________________ 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 Mon Sep 4 14:55:17 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 04 Sep 2006 23:55:17 +1000 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FC2943.9090702@OceanInformatics.biz> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> <44FC1651.7060107@kestral.com.au> <44FC2943.9090702@OceanInformatics.biz> Message-ID: <44FC3045.2070702@kestral.com.au> > Hey - I'm asking the questions here;-) oh, sorry. I take it back then >> is it some kind of >> Act-Relationship generator? maybe a generic act >> relationships for a list of things that have the >> same kind of relationship with some parameter to >> differentiate them? > all interesting possibilities. Maybe it's just a DIM that includes > useful patterns that you can then work directly from for creating > messages as constraint definitions... maybe it's just some identified useful codes for creating these patterns with act relationships? >>> - nodes of a list need to be coded "systolic", "diastolic", or "PaO2", >>> "PaCO2", or "PCV", "Platelets" etc... >> really? Why do I look at this and think it's semantics free? >> Coded how? > In an archetype these are all coded with internal archetype codes and > then Snomed and/or LOINC codes, depending on availability. In some other > system, an equivalent thing has to be done. oh - right - real codes with semantics. So how is this better than a set of act relationships. I don't get it > The point here is that the RIM doesn't provide enough structure - > inbuilt information semantics - to hang codes on - all you get is > role-participation-act and act-act_rel hierarchy patterns. you can hang codes there (lots and lots of them). I don't get it... Grahame From grahame at kestral.com.au Mon Sep 4 15:04:28 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Tue, 05 Sep 2006 00:04:28 +1000 Subject: [New-ITS] Considering the XUM and what ITS worth In-Reply-To: References: Message-ID: <44FC326C.2030504@kestral.com.au> hi David I've just had quite a long chat on the phone with Charlie about this. I will respond to to this email later, but a question. Look at Mim 4.1.03 (or close) and look at A_MedicationRecordMinimal. If this was serialised at the RIM level, how would you recognise which of the choices is the right one from the instance? it's hard - and therefore slow. This is not friendly for implementation - but does it matter - is it necessary to recognise the correct clone name, and if so, when? Now you might be tempted to respond to this by criticising the model. So, for another instance of the same thing, check out the Clinical Statement Pattern DIM (which is worse, cause the abstract Act choice is a superset of the others, I don't know how I could right code that recognised that lot correctly without special logic). (and spl does it too) if it matters, is it enough to do it in templateId? If it's done in templateId (as some form of processing instruction, in effect), who gets to say when it has to be present? Is this a model thing or a profile thing? If it's a profile thing, but implementers need it, have we just abandoned interoperability? Grahame David Markwell wrote: > Grahame > > A few quick responses: > > You said: > > > you can get away without a terminology service in demographics, in straight > messaging - no problems. > > > I agree > ---- > > But then you said: > > If you bring this background to V3, you wonder why it's so complex. RIM > level serialisation is just part of that picture. > > > I am not sure that RIM level serialization is such a radical idea. Curiously > it is still more specific than HL7v2 naming conventions plus it has all the > formalism of the model. > > --- > > You said: > > so, join us in Eclipse and do it... ;-) > > > Not everything is Eclipse, not everything is HL7. > My comment about the terminology services being an issues for application > integration (rather than specific HL7 integration) means that this is not a > doing "it" but rather a being involved in the evolution of "them". Which is > precisely where a lot of my mental cycles are directed at present. ;-) > > --- > You said > > so why is opaque useless meaning better than suggestive useless meaning. > > > This is an established principle in respect of terminology (see Cimino, J, > Desiderata for controlled medical vocabularies in the twenty-first century. > Methods of Information in Medicine, 1998. 37(4-5): pp. 394-403.) Summarized > in > http://www.dbmi.columbia.edu/cimino/Presentations/1998%20-%20Swed%20-%20Desi > derata%20for%20Controlled%20Medical%20Vocabularies.ppt > > You can discuss whether the same should apply to message models and anything > else. I used to think they were different but the more I look the more I see > the same problems that Jim Cimino and others identified in vocabularies. > Meaningful identifiers are a hostage to fortune, misinterpretation and > scalability etc etc. They are fine in very controlled spaces (e.g. the RIM > serialization itself) but in naming constraints meaningful names are a trail > of tempting candies that lead us (Hansel and Gretel like) to a dark confined > place. Far better to resist this temptation and include more meaning in the > metadata associated with the constraint. > > > Kind Regards > > David Markwell > > > Mailto:david at clininfo.co.uk > > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame Grieve > Sent: 04 September 2006 11:25 > To: david at clininfo.co.uk > Cc: grahame at jivamedical.com; new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Considering the XUM and what ITS worth > > ok, David and I agree that RIM level serialisation is the way to go. > Just one schema, everything is easy, great. > > Done, thanks everyone, we'll present this to HL7 next week > > ... or maybe you don't agree. If you don't, please speak up... > >> >> I am sure you need terminology services for HL7v3 (or any form of >> semantically operable application) > > you can get away without a terminology service in demographics, in straight > messaging - no problems. If you bring this background to V3, you wonder why > it's so complex. RIM level serialisation is just part of that picture. > >> Some people find the idea of a "terminology service" frightening >> complex. I suspect some of the commercial software providers in this >> area are partly responsible for this. It really is just a series of >> lookups and computations that need to optimized not rocket science ... >> More MP3 science ... once done easy to replicate and enhance. > > so, join us in Eclipse and do it... ;-) > > > >> instead of >> >> or >> >> >> opinions, anyone? >> >> >> This does not look like a RIM based instance unless perhaps >> "participationCode" is meant to be "typeCode". > > yes. whoops. should've checked instead of hurrying through that one. > >> Assuming that is just a typo I still disagree with this approach. >> What is the point of the tautology "Author" and "AUT" >> >> > > actually, in the case of AUT, no point at all. stupid example, since Author > is derived from AUT anyway. If it was an act, then the name would be more > interesting and actually carry extra information > >> To be clear what I am suggesting is ... >> >> >> >> If the modelid is not simply repeating the name "AUT" but is >> referencing a constraint then it would far better to reference the >> constraint by a uniqueId (GUID /UUID in my view not OID or the current >> CFH use of a structured templateId). >> >> For example: >> >> > templateId="0a951a3b-ff3c-450b-99b2-9538367bf04d"> > > so why is opaque useless meaning better than suggestive useless meaning. > And the problem with templateId is that you want to refer into a model - > this only refers to the root of a model. (particularly current CFH models > where you have choices that can only be differentiated by reference to the > model) > > Charlie suggested making the root a namespace. Though I shied away from the > name templateId since that has higher level non-ITS meaning, this would mean > that you'd end up with something like this: > > xmlns:tid="0a951a3b-ff3c-450b-99b2-9538367bf04d" > templateId="tid:ExampleCloneClassName"> > > not that the actual name really matters - like arguing about whether > terminologies should have opaque identifiers really. > > but you think it's worth having such identifiers? Should writers be required > to add them? > > Grahame > > > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From Thomas.Beale at OceanInformatics.biz Mon Sep 4 15:10:55 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Mon, 04 Sep 2006 15:10:55 +0100 Subject: [New-ITS] Reshaping should be at the discretion of animplementor In-Reply-To: References: Message-ID: <44FC33EF.3030509@OceanInformatics.biz> David Markwell wrote: > This I am arguing against use of IDREF or XPATH referents. > > I am saying we should not be using references that are message dependent. > Thus the answer to your question is that the Id used in a reference is the > Id of a previously communicated and stored instance of some information > element - be that a person in a role or a clinical statement or whatever. > Its not an Id of something specific to its occurrence in a specific message. > Therefore of course I am not suggesting it be expanded up in the recipient > system. However, to meet *some* requirements it could naturally be expanded > for display or retrieval functions. > Right. I read too fast. That all makes sense; but of course it is predicated on some distributed / national demographics identification system and repository, which in the case of this country will be available in the Spine. - thomas From Thomas.Beale at OceanInformatics.biz Mon Sep 4 15:17:06 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Mon, 04 Sep 2006 15:17:06 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FC3045.2070702@kestral.com.au> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> <44FC1651.7060107@kestral.com.au> <44FC2943.9090702@OceanInformatics.biz> <44FC3045.2070702@kestral.com.au> Message-ID: <44FC3562.3030806@OceanInformatics.biz> Grahame Grieve wrote: > >> In an archetype these are all coded with internal archetype codes and >> then Snomed and/or LOINC codes, depending on availability. In some other >> system, an equivalent thing has to be done. >> > > oh - right - real codes with semantics. So how is this better than a set > of act relationships. I don't get it > in the same way that the current RIM (or any reference model) is better than a class model that is literally just two classes: Node and Arc. Imagine what the current MIM would look like with only those classes (and 152 billion codes) available. The point of defining any information model more complicated than this is to commit to certain semantics over and above node/arc that we know we want to re-use all over the place, and that we want to standardise across all modelling activities. So the current RIM has 2 patterns (meaning that modellers can now state role-participation-act semantics in a re-usable, standardised way); I am saying that it needs more to ease many of the modelling problems currently being experienced. node/arc = binary RIM = assembler language needed = pascal - thomas From grahame at kestral.com.au Mon Sep 4 15:32:41 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Tue, 05 Sep 2006 00:32:41 +1000 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FC3562.3030806@OceanInformatics.biz> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> <44FC1651.7060107@kestral.com.au> <44FC2943.9090702@OceanInformatics.biz> <44FC3045.2070702@kestral.com.au> <44FC3562.3030806@OceanInformatics.biz> Message-ID: <44FC3909.6070607@kestral.com.au> Thomas Beale wrote: > Grahame Grieve wrote: >>> In an archetype these are all coded with internal archetype codes and >>> then Snomed and/or LOINC codes, depending on availability. In some other >>> system, an equivalent thing has to be done. >>> >> oh - right - real codes with semantics. So how is this better than a set >> of act relationships. I don't get it yeah, I follow the theory. But I don't follow the practice.... > in the same way that the current RIM (or any reference model) is better > than a class model that is literally just two classes: Node and Arc. > Imagine what the current MIM would look like with only those classes > (and 152 billion codes) available. > > The point of defining any information model more complicated than this > is to commit to certain semantics over and above node/arc that we know > we want to re-use all over the place, and that we want to standardise > across all modelling activities. So the current RIM has 2 patterns > (meaning that modellers can now state role-participation-act semantics > in a re-usable, standardised way); I am saying that it needs more to > ease many of the modelling problems currently being experienced. maybe you need to be specific for me. What does this thing look like in UML? > > node/arc = binary > RIM = assembler language > needed = pascal > > - thomas > > _______________________________________________ > 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 Thomas.Beale at OceanInformatics.biz Mon Sep 4 16:03:44 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Mon, 04 Sep 2006 16:03:44 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FC3909.6070607@kestral.com.au> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> <44FC1651.7060107@kestral.com.au> <44FC2943.9090702@OceanInformatics.biz> <44FC3045.2070702@kestral.com.au> <44FC3562.3030806@OceanInformatics.biz> <44FC3909.6070607@kestral.com.au> Message-ID: <44FC4050.7010800@OceanInformatics.biz> Grahame Grieve wrote: > >> >> The point of defining any information model more complicated than this >> is to commit to certain semantics over and above node/arc that we know >> we want to re-use all over the place, and that we want to standardise >> across all modelling activities. So the current RIM has 2 patterns >> (meaning that modellers can now state role-participation-act semantics >> in a re-usable, standardised way); I am saying that it needs more to >> ease many of the modelling problems currently being experienced. >> > > maybe you need to be specific for me. What does this thing look like > in UML? > > well the conclusion is that more classes and patterns are needed - not hundreds, but in the order of 10. We do it in a certain way in openEHR (which you already know) in the Support, Data Structures and Common information models (see http://svn.openehr.org/specification/TRUNK/publishing/architecture/computable/UML/uml_start_view.html). But whatever the details, the problem doesn't go away. The reason these things appeared in openEHR was not because we ordained them, it was because of the feedback from earlier iterations of clinical and demographic modelling. In other words, the need for these things quickly became apparent as we tried to build archetypes for common things. Hence time-series, and particularly the way we finally modelled it were due entirely to the clinical modelling activity requirements. Note that we only finally settled on the current model of this concept less than 12 months ago (see http://www.openehr.org/uml/release-1.0/Browsable/_9_0_76d0249_1109157527311_729550_7234Report.html) - the model you see here is exactly what works with numerous common clinical models, e.g. of lab results, vital signs reporting and so on. The availability of these patterns is why building archetypes in openEHR is easy (technically). So...switching to HL7v3, the need for the same primitive patterns is clearly there (people are trying to build the same kind of structures, and when the clinical modelling starts, it gets 50x more interesting), but the model semantics are not available - we are stuck with the 2 patterns. This is not an academic issue; it is a practical issue with a pervasive influence on the modelling activity. I am just trying to get people to see that there is a major issue here that won't go away even if the message size goes down, and even if constraining is done straight from the RIM (which incidentally I suggested at a WGM in 2003); the RIM itself still doesn't give you enough. Semantic models of content is what we need to be able to define; if we do it by constraining, then we need a rich enough model to constrain. - thomas From joseph.2.waller at bt.com Mon Sep 4 17:10:31 2006 From: joseph.2.waller at bt.com (joseph.2.waller@bt.com) Date: Mon, 4 Sep 2006 17:10:31 +0100 Subject: [New-ITS] So, what's a XUM ? Message-ID: <418B502A3861E242AFDED453F3D5B89C0E821702@i2km99-ukbr.domain1.systemhost.net> Grahame, A pedantic point. But allowing different implementers to implement the model 'slightly' differently could be deemed good for interoperability if many more implementers adopted HL7 as a result. Although the effort to integrate two implementers would be greater, the overall potential for an integratable healthcare industry may go up. ;) Regards, Joe -----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: Thursday, August 31, 2006 4:17 AM To: Smithies Rik Cc: 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 _______________________________________________ New-ITS mailing list New-ITS at lists.hl7.org.uk http://lists.hl7.org.uk/mailman/listinfo/new-its From david at clininfo.co.uk Mon Sep 4 18:57:00 2006 From: david at clininfo.co.uk (David Markwell) Date: Mon, 4 Sep 2006 18:57:00 +0100 Subject: [New-ITS] Considering the XUM and what ITS worth In-Reply-To: <44FC326C.2030504@kestral.com.au> Message-ID: Grahame You may not be able to write code that distinguishes the RMIM level specializations in all those cases. However, my question is if you cannot distinguish them based on vocabulary why do you need to. 1. If you need to know how deep you are in branch of the model then you do need to have some template or model Id in the instance. In general if (as in the medication model you refer to) its really tricky is it possible there is a vocabulary limitation or just a poor mapping from the business model to the RIM? 2. The ClinicalStatement XML should be easier to process as RIM serialization because then you don't need to worry about attributes arbitrarily omitted or fixed. 3. The ACT --> others is easy to do on classCode. Anyway the good news for you is I am going to go mute on the list as I have vital work to do before setting out for the US Wednesday morning. ---- Put another way if you have the following two classes: .... .... Do they or do they not mean the same? "yes" ---- On the other hand if you have: .... Then you have an obvious error - there is no value attribute in "Act". So that's a simple RIM schema validation error. ---- RMIMs specify constraints for one of a number of reasons. I will suggest some here: 1. Business essential: To complete this business process I need this information. ====================== This includes: 1a) Can't do without: What is being request or reported about who, etc 1b) Won't do without: Attribution, authentication, billing, etc. These subcategories are relevant because "can't do without" is generalizable "won't do without" depends on local rules "Can't do without" may contain subcomponents that are "won't do with" E.g. "can't do without knowing who the patient is" "won't do without NHS number" 2. Scope boundaries: ==================== Restrictions about what not to "don't send". For example, do not send the patients entire medical record when requesting every prescription!! In these cases the question is what should happen if excess data is sent. 2a) Its an error - the added information breaks rules. 2b) Its worrisome - the added information may introduce ambiguity. 2c) Its fine to just ignore it. 3. Clarification by limiting attribute level options ==================================================== This relates to choice of attributes and choice of data types to be used to convey a particular item of information. There are problems here (as discussed in TermInfo) but interestingly the problems are worse the more names you have for the same RIM class - because the same issues arises in every case. The names of the class distracts from the underlying semantic issue. For example double negation code/negationInd or inconsistent moodCode/code combinations. 4. Forced semantics =================== These are the ones simple drive a tank through common sense Ruling as some have suggested that in a given RMIM the following is non compliant ... .... Because weight must we in a clone class called weight ... .... This type of constraint show what happens when you allow close naming on the wire. Before long more and more things have to be sent in specially named classes. ================ If we look at each of in turn it seems to me that these are to some extent at least orthogonal constraints and using the same mechanisms (i.e. the RMIM) creates combinatorial explosion of variants. If instead we separated these out and applied different sets of constraints for each there would be less distinct constraints but no less ability to constrain. 1a) Depends on the domain and business purpose This is where standards at a global level can usefully operate. 1b) Depends on the organization (or national) technical environment, conventions, business relationships and laws. This is the stuff of realm (or even organizational) specialization. 2) Depends on a pragmatic way of constraining out non essential information while allowing inclusion of that which is relevant with a mixture of legal and ethical questions (e.g. non-disclosure). The rules here will more often need human interpretation. Was it really wrong or just unnecessary. 3) Depends on a mixture of general semantic issues, refined by the terminologies in use (and potentially by an agreed common record architecture). This needs some general guidelines that apply across domains May vary between different code systems and terminologies. 4) Is a well-meaning but ill-fated attempt to turn the RMIM into its own clinical terminology. Simply a really bad idea so don't do it. ------- I am now going to go mute on this list. Due to time pressure. My silence in response to any comments on this email will not indicate acceptance or disregard. Kind Regards David Markwell Mailto:david at clininfo.co.uk -----Original Message----- From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame Grieve Sent: 04 September 2006 15:04 To: david at clininfo.co.uk Cc: grahame at jivamedical.com; new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Considering the XUM and what ITS worth hi David I've just had quite a long chat on the phone with Charlie about this. I will respond to to this email later, but a question. Look at Mim 4.1.03 (or close) and look at A_MedicationRecordMinimal. If this was serialised at the RIM level, how would you recognise which of the choices is the right one from the instance? it's hard - and therefore slow. This is not friendly for implementation - but does it matter - is it necessary to recognise the correct clone name, and if so, when? Now you might be tempted to respond to this by criticising the model. So, for another instance of the same thing, check out the Clinical Statement Pattern DIM (which is worse, cause the abstract Act choice is a superset of the others, I don't know how I could right code that recognised that lot correctly without special logic). (and spl does it too) if it matters, is it enough to do it in templateId? If it's done in templateId (as some form of processing instruction, in effect), who gets to say when it has to be present? Is this a model thing or a profile thing? If it's a profile thing, but implementers need it, have we just abandoned interoperability? Grahame David Markwell wrote: > Grahame > > A few quick responses: > > You said: > > > you can get away without a terminology service in demographics, in > straight messaging - no problems. > > > I agree > ---- > > But then you said: > > If you bring this background to V3, you wonder why it's so complex. > RIM level serialisation is just part of that picture. > > > I am not sure that RIM level serialization is such a radical idea. > Curiously it is still more specific than HL7v2 naming conventions plus > it has all the formalism of the model. > > --- > > You said: > > so, join us in Eclipse and do it... ;-) > > Not everything is Eclipse, not everything is HL7. > My comment about the terminology services being an issues for > application integration (rather than specific HL7 integration) means > that this is not a doing "it" but rather a being involved in the > evolution of "them". Which is precisely where a lot of my mental > cycles are directed at present. ;-) > > --- > You said > > so why is opaque useless meaning better than suggestive useless meaning. > > > This is an established principle in respect of terminology (see > Cimino, J, Desiderata for controlled medical vocabularies in the twenty-first century. > Methods of Information in Medicine, 1998. 37(4-5): pp. 394-403.) > Summarized in > http://www.dbmi.columbia.edu/cimino/Presentations/1998%20-%20Swed%20-% > 20Desi derata%20for%20Controlled%20Medical%20Vocabularies.ppt > > You can discuss whether the same should apply to message models and > anything else. I used to think they were different but the more I look > the more I see the same problems that Jim Cimino and others identified in vocabularies. > Meaningful identifiers are a hostage to fortune, misinterpretation and > scalability etc etc. They are fine in very controlled spaces (e.g. the > RIM serialization itself) but in naming constraints meaningful names > are a trail of tempting candies that lead us (Hansel and Gretel like) > to a dark confined place. Far better to resist this temptation and > include more meaning in the metadata associated with the constraint. > > > Kind Regards > > David Markwell > > > Mailto:david at clininfo.co.uk > > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame > Grieve > Sent: 04 September 2006 11:25 > To: david at clininfo.co.uk > Cc: grahame at jivamedical.com; new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Considering the XUM and what ITS worth > > ok, David and I agree that RIM level serialisation is the way to go. > Just one schema, everything is easy, great. > > Done, thanks everyone, we'll present this to HL7 next week > > ... or maybe you don't agree. If you don't, please speak up... > >> >> I am sure you need terminology services for HL7v3 (or any form of >> semantically operable application) > > you can get away without a terminology service in demographics, in > straight messaging - no problems. If you bring this background to V3, > you wonder why it's so complex. RIM level serialisation is just part of that picture. > >> Some people find the idea of a "terminology service" frightening >> complex. I suspect some of the commercial software providers in this >> area are partly responsible for this. It really is just a series of >> lookups and computations that need to optimized not rocket science ... >> More MP3 science ... once done easy to replicate and enhance. > > so, join us in Eclipse and do it... ;-) > > > >> instead of >> >> or >> >> >> opinions, anyone? >> >> >> This does not look like a RIM based instance unless perhaps >> "participationCode" is meant to be "typeCode". > > yes. whoops. should've checked instead of hurrying through that one. > >> Assuming that is just a typo I still disagree with this approach. >> What is the point of the tautology "Author" and "AUT" >> >> > > actually, in the case of AUT, no point at all. stupid example, since > Author is derived from AUT anyway. If it was an act, then the name > would be more interesting and actually carry extra information > >> To be clear what I am suggesting is ... >> >> >> >> If the modelid is not simply repeating the name "AUT" but is >> referencing a constraint then it would far better to reference the >> constraint by a uniqueId (GUID /UUID in my view not OID or the >> current CFH use of a structured templateId). >> >> For example: >> >> > templateId="0a951a3b-ff3c-450b-99b2-9538367bf04d"> > > so why is opaque useless meaning better than suggestive useless meaning. > And the problem with templateId is that you want to refer into a model > - this only refers to the root of a model. (particularly current CFH > models where you have choices that can only be differentiated by > reference to the > model) > > Charlie suggested making the root a namespace. Though I shied away > from the name templateId since that has higher level non-ITS meaning, > this would mean that you'd end up with something like this: > > xmlns:tid="0a951a3b-ff3c-450b-99b2-9538367bf04d" > templateId="tid:ExampleCloneClassName"> > > not that the actual name really matters - like arguing about whether > terminologies should have opaque identifiers really. > > but you think it's worth having such identifiers? Should writers be > required to add them? > > Grahame > > > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From Robert.Worden at Charteris.com Mon Sep 4 21:45:01 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Mon, 4 Sep 2006 21:45:01 +0100 Subject: [New-ITS] Reshaping should be at the discretion of an implementor In-Reply-To: <44FBD024.4070804@kestral.com.au> Message-ID: Grahame - You seem to be saying: local reshaping may have its uses, but it is an implementor thing, not a standards activity, so it does not belong in a standards project, which the new ITS project is. I think we can agree that standards are for implementers. But I don't want to debate the right scope for the new ITS project. I will be perfectly happy if the use of local XUMs as intermediate XMLs is regarded as a spinoff from the new ITS project, rather like Teflon from the moon-shot. Do you want to take a giant step for mankind, or just fry eggs? Now you can do both... 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: 04 September 2006 08:05 To: Robert Worden Cc: grahame at jivamedical.com; new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Reshaping should be at the discretion of an implementor Robert Worden wrote: > Grahame - > > You wrote: > >> Reshaping - while useful as an implementation tool - is >> not going to help with interoperability, unless we can get >> a single basis for reshaping > > I disagree! actually, you agree, nearly. You describe a whole lot of uses of reshaping that are *implementation tool* usages - and they all make sense. Then you assert that > Only send reshaped message instances between consenting > parties, who have agreed to use the same reshaped model. well, perhaps. In fact, fine. But it's not going to help us find an ITS that is useful - which is what we are about here, and nor is it an appropriate thing to engage in at the standards level. In fact, in the end, all of the optimisation things die at the standards level because they make operability easier but interoperability harder. Grahame > Suppose I use a reshaped and restricted RMIM, purely as a way to get > full-ITS V3 onto the wire (not to reveal reshaped instances in public). > I use the reshaped model only as an intermediate step between my > application and V3. Then: > > - Because the reshaped model is smaller and simpler than the RMIM, and > has business names, I make more accurate mappings onto my applications > > - Because the mappings of the reshaped XML onto V3 are > machine-generated, not hand-coded, there is no potential for error in > translation from reshaped XML to the full ITS > > - Therefore I have a more error-free interface between my applications > and V3 full ITS > > Surely that is 'going to help with interoperability'? And it does not > need a single basis for reshaping in order to work. If you don't think > so, Grahame, please tell me why. > > (I am genuinely perplexed at my failure to explain this point to some > very clever guys like you!) > > In using reshaped models like this, I would only be following the > advice on the HL7 Implementation Wiki: > > 'Do add a layer of abstraction, in the form of an intermediate XML based > format, and map this to HL7 v3 artefacts, e.g. with the aid of a > stylesheet. The structure of the intermediate format should be the best > possible mix of the internal database format and the model used by > CDA/Clinical statements.' > > Or: > > 'If you are working with XSLT you need to define an intermediate XML > format for your data. This can be in "close to HL7" form or in "close to > native" form.' > > HL7 does not require standardization of the intermediate XMLs. > > Only when you go to the next stage, of sending reshaped instances over > the wire, do you get interoperability issues. My solution to these > issues is: Only send reshaped message instances between consenting > parties, who have agreed to use the same reshaped model. If either party > wants to use full XML ITS, the other party has to provide it. And he can > do so, because he has an accurate transform to do it. > > (This next stage is not necessary, unless you are concerned about > performance and small message instances) > > Again - have I somehow failed to explain this point to anybody else on > the planet? What is wrong with it? > > Grahame - I think the key to your objection may be where you say 'it's > not going to solve problems at the level of the standard'. Maybe it > doesn't need to. Perhaps we should distinguish between (a) practical > things that implementers can do now, and (b) proposed changes to the > standard. We can propose a mix of these if we want to. > > 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. > > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame > Grieve > Sent: 04 September 2006 05:53 > To: Robert Worden > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Reshaping should be at the discretion of an > implementor > > hi > > I think this should be rephrased as, "implemention > should be left to the implementor". > > No one (I hope) would disagree with this. > > Reshaping - while useful as an implementation tool - is > not going to help with interoperability, unless we can get > a single basis for reshaping - and suddenly we are back to > where Charlie was. > > So what would actually be useful is a tool - or set of tools - that > can take an RMIM, and a profile on the RMIM - and produce useful > implementation constructs, and then this can be offered to the > implementors to help them implement. > > Robert, your tool is a step in the right direction here, and > a laudable direction - but it's not going to solve problems > at the level of the standard, I think. > > The hard part is doing the profiling > > Grahame > > > > 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). >> >> >> >> 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/ >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> 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 _________________________________________________________________ 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 Robert.Worden at Charteris.com Mon Sep 4 21:44:54 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Mon, 4 Sep 2006 21:44:54 +0100 Subject: [New-ITS] Reshaping should be at the discretion of animplementor In-Reply-To: <1A3D105C334EAE49BDDD93D8767573F5043C18DE@EXCHAQ2.nhsia.nhs.uk> Message-ID: Rik - Like my other interlocutors, you make a good point. The freedom to reshape an RMIM may not take you far enough to make the local XUM quite as suitable as a less-constrained intermediate XML. Or it may, in a lot of cases - we just need to try it out a bit. My experiments persuade me you can do quite a lot. However, suppose the XUM does not go far enough towards some application's own data model. (As I now see you have already spotted) they could still define another intermediate XML, closer to their own data model, and map that onto the XUM rather than onto the RMIM - in effect going via their own intermediate XML, and the XUM, in series. Now in case you think that would be a bit elaborate and error-prone: - because the XUM-to-RMIM mappings are made automatically and are error-free, the extra stage of translation will not add errors - because the XUM is smaller and closer to their business names than the RMIM, their mappings to the XUM will be more accurate than mappings onto an RMIM - reducing errors - they do not even need to have two stages of physical translation; by mapping their own intermediate XML onto the XUM object model, they can generate one XSLT which wraps up both stages of translation, accurately ('own => RMIM' fully equivalent to 'own => XUM => RMIM'). In effect, the XUM would then never be visible in instances. That might make some people happy. So there are a lot of ways to use local XUMs. We need to get experience of them. In the 'national grid' analogy, if the application is a kettle at 240V and V3 is the national grid at 132,000V, you may introduce several transformers to bridge between the two - especially if one of the transformers is guaranteed to be loss-free. 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: Smithies Rik [mailto:rik.smithies at cfh.nhs.uk] Sent: 04 September 2006 12:28 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: [New-ITS] Reshaping should be at the discretion of animplementor Hi Robert, on the specific point of using the collapsed model as your intermediate XML format, which I only appreciated in your last post, I think that is a little bit of a stretch. The intermediate for an implementer uses may be something close to their existing data structure. This will be quite different from the message format, and different from the receiver's data format, and hence their intermediate XML. If the intermediate format is defined by the message modeller, who may not be aware of either party's format, then it may not be a good fit. So you would probably end up defining another intermediate layer, which is then mapped to the collapsed model format. Now, there is some merit here that the collapsed model may have removed some of the perceived "HL7 junk", defaults, unfamiliar names etc and so be easier to target. These are the proposed benefits of the collapsed model that we are discussing. But I'm not sure we can go further and expect this model will just slot in as the intermediate format for many implementers. cheers, Rik > -----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: 04 September 2006 07:41 > To: grahame at jivamedical.com > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Reshaping should be at the discretion > of animplementor > > Grahame - > > You wrote: > > > Reshaping - while useful as an implementation tool - is not > going to > > help with interoperability, unless we can get a single basis for > > reshaping > > I disagree! > > Suppose I use a reshaped and restricted RMIM, purely as a way > to get full-ITS V3 onto the wire (not to reveal reshaped > instances in public). > I use the reshaped model only as an intermediate step between > my application and V3. Then: > > - Because the reshaped model is smaller and simpler than the > RMIM, and has business names, I make more accurate mappings > onto my applications > > - Because the mappings of the reshaped XML onto V3 are > machine-generated, not hand-coded, there is no potential for > error in translation from reshaped XML to the full ITS > > - Therefore I have a more error-free interface between my > applications and V3 full ITS > > Surely that is 'going to help with interoperability'? And it > does not need a single basis for reshaping in order to work. > If you don't think so, Grahame, please tell me why. > > (I am genuinely perplexed at my failure to explain this point > to some very clever guys like you!) > > In using reshaped models like this, I would only be > following the advice on the HL7 Implementation Wiki: > > 'Do add a layer of abstraction, in the form of an > intermediate XML based format, and map this to HL7 v3 > artefacts, e.g. with the aid of a stylesheet. The structure > of the intermediate format should be the best possible mix of > the internal database format and the model used by > CDA/Clinical statements.' > > Or: > > 'If you are working with XSLT you need to define an > intermediate XML format for your data. This can be in "close > to HL7" form or in "close to native" form.' > > HL7 does not require standardization of the intermediate XMLs. > > Only when you go to the next stage, of sending reshaped > instances over the wire, do you get interoperability issues. > My solution to these issues is: Only send reshaped message > instances between consenting parties, who have agreed to use > the same reshaped model. If either party wants to use full > XML ITS, the other party has to provide it. And he can do so, > because he has an accurate transform to do it. > > (This next stage is not necessary, unless you are concerned > about performance and small message instances) > > Again - have I somehow failed to explain this point to > anybody else on the planet? What is wrong with it? > > Grahame - I think the key to your objection may be where you > say 'it's not going to solve problems at the level of the > standard'. Maybe it doesn't need to. Perhaps we should > distinguish between (a) practical things that implementers > can do now, and (b) proposed changes to the standard. We can > propose a mix of these if we want to. > > 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. > > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of > Grahame Grieve > Sent: 04 September 2006 05:53 > To: Robert Worden > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Reshaping should be at the discretion > of an implementor > > hi > > I think this should be rephrased as, "implemention should be > left to the implementor". > > No one (I hope) would disagree with this. > > Reshaping - while useful as an implementation tool - is not > going to help with interoperability, unless we can get a > single basis for reshaping - and suddenly we are back to > where Charlie was. > > So what would actually be useful is a tool - or set of tools > - that can take an RMIM, and a profile on the RMIM - and > produce useful implementation constructs, and then this can > be offered to the implementors to help them implement. > > Robert, your tool is a step in the right direction here, and > a laudable direction - but it's not going to solve problems > at the level of the standard, I think. > > The hard part is doing the profiling > > Grahame > > > > 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). > > > > > > > > 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/ > > > > > > > -------------------------------------------------------------- > ---------- > > > > _______________________________________________ > > 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 > > _________________________________________________________________ > 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 Robert.Worden at Charteris.com Mon Sep 4 21:45:01 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Mon, 4 Sep 2006 21:45:01 +0100 Subject: [New-ITS] Node counts In-Reply-To: Message-ID: David - The risk you point out of 'offenders in their closed worlds' is a real one and needs to be addressed; but to my mind it is the lesser of two risks. Allowing the free use of local XUMs as intermediate XMLs will, in my view, greatly reduce the risk that implementers misunderstand messages, or get overwhelmed by RMIM complexity, and build bad interfaces. Against that, the risk that they think the XUM is everything, or misunderstand the true RIM significance of XUM elements, is a much smaller risk. Take the smaller risk. The other risk which we are seeing is that implementers just can't be bothered to interface with V3, and the world passes it by. Again, good local XUMs can greatly reduce that risk. Two analogies to muddy the waters: Analogy 1: Healthcare applications are like domestic electrical appliances - kettles and fridges - working at 240 volts. V2 is like a 1000 volt circuit, which suppliers are prepared to connect to. But V3 is like the national grid at 132,000 volts, and nobody wants to connect their kettle to 132,000 volts. HL7 needs to supply good transformers to step down the voltage - or let people like ChF build them. That is what reshaped models are, and they will help more people to connect to V3. Without them, there will be no 'open world' of V3 because nobody will connect to it without a government bribe. Analogy 2: The mediaeval Bible was written in Latin (a highly successful pan-European standard). English-language Bibles were initially banned, for sound theological reasons: Latin is the language for theological debate; if you let these peasants read the Bible in the vernacular, they will miss all the true meaning and even succumb to heresy; better wait until they are properly educated and can appreciate the true meaning....I'd rather have the Bible in English. Put another way, I'd rather have a few offenders in their closed worlds, that HL7 in its closed world. 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: David Markwell [mailto:david at clininfo.co.uk] Sent: 03 September 2006 09:57 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts Robert The problem as I see it is that it will be oh so easy for people using reshaped instances to place reliance on the particularity of those instances and to subtly change the way they use them and basically to diverge. The more special case reshapings that exist the higher the risk and the more difficult to spot the offenders in their closed worlds. As they move to the open world suddenly all is revealed. My contention is that to be sure this does not happen these implementers will need to understand the generic foundations and if they do then why not use them. If its just to make messages smaller or simpler to process then one can understand the motivation for the reshape. However if as I suspect they will later need to go all the way then why have them play with fire before giving them the the advice on full and safe ITS? Kind Regards David Markwell Mailto:david at clininfo.co.uk ________________________________ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 03 September 2006 09:30 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts David - If we agree on 1-6, then that is the most important point. That gets the main benefit of using restricted and reshaped RMIMs (fish) as a way of generating either RIM-based XML (fowl) or current XML ITS (fish-fowl hybrid). The benefit is that restricted and reshaped RMIMs are smaller and easier for implementers to understand and map onto - so implementations should be quicker and (more important) more accurately done. The only point of going to 7 (reshaped message instances over the wire) is a performance benefit - the reshaped instances will be smaller, and you avoid two translations (to/from full ITS). To me the performance point is much less important than the ease of message implementation - but it may be important for others. You say 'I think that if 6-->7 mapping is possible...' and it certainly is. The big benefit of restricting/reshaping an RMIM is that the tool will not allow you to make any illegal moves (e.g. collapsing a 1:N association) and will always keep track of the mappings between the RMIM and the reshaped version - so you can always generate XSLT translations between the two (not write them by hand) and they will be perfectly accurate. You can have 6-7 and 7-6 converters anywhere you like. So to come to your example - A and B agree to use reshaped instances over the wire, because they need the extra performance of smaller message instances. But as soon as C comes along and demands full ITS instances, A has to give them to him - and can easily do so, because he has the transform (automatically generated, accurate) and can just run it each time. I don't see a problem for A, B or C (except maybe understanding each other's English dialects). 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: David Markwell [mailto:david at clininfo.co.uk] Sent: 01 September 2006 15:40 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts Robert I would agree that we seem close to agreement on 1-6. I remain to be convinced that 7 over the wire helps anyone. I think that if 6-->7 mapping is possible (which is implicit in the idea of 7 existing at all) then simple 6-->7 and 7-->6 converters for specific environments would be a far better solution. The reason that I prefer this is as follows: Say that A and B agree to communicate using 7. They are happy ;-) Until one day B needs to communicate with C Unfortunately for B, C who works in a more diverse environment aligned nicely with the generic structures that they use in multiple domains. They use 6 with everyone - they may have use a kind of 7 view from time to time to aid understanding and debugging. However on the wire there stick with 6. Now B argues "I say you chaps we know how to do this we've done it for years with the A Team and it looks like you Cee fellows are at 6's and no 7's" However C replies "look buddy we bin doing dis stuff wid the rest of the alph'bet from Dee throu' Zee you Bees get wid the program or buzz off". Who should win in this show down and who should be stung? Who should be forced to convert? I know whose case I would argue and ... on that basis ... I'd rather avoid the argument by asserting up front that there is no 7 as part of the standard. So while consenting parties can use fax or sneaker-net or funny handshake or their own flavour of 7 that is not the standard. Kind Regards David Markwell Mailto:david at clininfo.co.uk ________________________________ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 01 September 2006 11:48 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts David - I think we are getting somewhere. If RMIM names are neither fish nor fowl: 1. RIM names with classCodes etc. are pure fowl 2. A reshaped RMIM, with business names defined locally by a super-implementor such as CfH, are fish. 3. Accurate fish-to-fowl transformations come out of the reshaping process 4. So anyone can produce or consume fish or fowl to his taste (fish is easier for some, fowl for others) 5. You must be able to produce fowl to be V3 conformant. You can do this by the transformations. 6. Normally, it is fowl that goes over the wire. 7. Between consenting parties, fish may be exchanged (or performance reasons only) All this seems to me perfectly possibly now, and compatible with HL7 methodology - with the possible exception of (7), which needs discussion. 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: David Markwell [mailto:david at clininfo.co.uk] Sent: 01 September 2006 10:18 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts Robert Your comment about ambiguity is interesting. I would argue it is not ambiguous because the meaning should be captured in the coding (classCode, moodCode, code etc). I do not think detailed semantics is a schema level issue - it depends on content. Some apps will inevitably have different models which put different items of information into different structures based on content. They can decide to do that if they wish but the information communicated to them and by them is normalized as RIM physical class instances. At present (or in various other proposal) there is the RIM class, there is the RMIM class name structure and there is the applications way of storing and handling information. The RMIM class business names are neither fish nor fowl. They are not the names in the applications (because these are internal design driven) and they are not the same as the RIM. Implementers try to make sense of the element names and risk ignoring the semantic identify of two statements (i.e. two Acts with identical attribute content) simply because the element names differ. Thus my contention is that this layer of additional names which was intended as a bridge or intermediate abstraction layer has become instead a distraction layer. My original assumption in backing and arguing for business names was that this would make schema validation more effective at checking constraints while any sane application developer would ignore the names and process as advised based only on the classCode etc. How wrong I was and how seriously. I confess that only when people started to add names to ever greater depths of spuriously familiar detailed naming did it strike me how seriously we have failed to communicate this message. Kind Regards David Markwell Mailto:david at clininfo.co.uk ________________________________ From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 01 September 2006 09:56 To: david at clininfo.co.uk Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts David - Glad we are getting closer - but while I agree that 'Moving to RIM named classes would massively reduce the path count.', I'm not sure it would reduce it usefully. There is a small point that XML nodes and XPaths will use association names, rather than class names; so in stead of RIM classes like 'Act' we would have RIM association names like 'scoper' . But that is really a small point. If you restricted yourself to RIM names (and used simple XPaths with only node names) then I agree that the number of distinct XPaths would be much smaller - but each XPath would then be very ambiguous, telling you only 'you have got to depth 5 in the structure' and I think not much more. Anybody doing RIM-based processing would be looking at classCodes etc. as he went down the structure, so he would effectively be navigating XPaths with steps like /player[@classCode = 'PAT']/ which would take him more unambiguously down the structure. I think the number of these XPaths would be just as large as my node/path counts, regardless of naming. (Maybe they are Gunther's HPaths.) I agree with you that for some purposes, and for some people, pure RIM-based processing is the right way to go, and avoids a lot of the naming problems you refer to. But I'm not sure it is everybody's cup of tea; I'd rather give a choice and let the market decide. With what I propose, we can have our cake and eat it. Anyone who sends or receives flattened/renamed/reshaped messages must also be able to send or receive full ITS messages - and will have the transforms to move accurately between the two. Anyone who wants to receive only full ITS messages, and do RIM-based processing, can do so (= have cake). Anybody who wants to do other things, using reshaped messages, can do so (= eat it). I don't see that there has to be any dilemma between the two. 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. ________________________________ From: David Markwell [mailto:david at clininfo.co.uk] Sent: 31 August 2006 18:37 To: Robert Worden Cc: new-its at lists.hl7.org.uk Subject: RE: Node counts 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/ _________________________________________________________________ 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/ _________________________________________________________________ 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060904/d91ca863/attachment-0001.htm From grahame at kestral.com.au Tue Sep 5 01:06:50 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Tue, 05 Sep 2006 10:06:50 +1000 Subject: [New-ITS] Reshaping should be at the discretion of animplementor In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A04FC8B@ramseysc1420.RamseyNet.local> References: <7A55F2E13F53E749A4C13A8E53B7424A04FC8B@ramseysc1420.RamseyNet.local> Message-ID: <44FCBF9A.9070009@kestral.com.au> Hi Charlie The heart of this question is whether V3 is a standard or a meta standard - or, should v3 define a single wire format (per model), or let multiple wire formats exist to suit use cases? No doubt such a framing of the question will create debate. And so it should. Because this is the key question. With the XUM approach, as presented to HL7 UK Aug 23, we pursued the idea that more than one model could be a good idea. There was significant push-back. And the idea that there should be more than one wire format per model (or exchange), that someone (whoever) has to pick one, this is V3 as a meta-standard - a toolkit for creating wire formats. The alternative is there is a normative wire format for exchange, that you use just one, whatever it's weaknesses. What do we need? How do we decide? Grahame Charlie McCay wrote: > Grahame > > There are two rationales for the optimisations -- one is performance, > and the other is ease of understanding (leading to fewer errors). > > If there are environments where the performance benefits of reshaping > (or some other change to the wire format) are demonstrable then saying > that this cannot be appropriately addressed at the standards level is > simply wrong. > To take the simplest form of reshaping -- allowing fixed and default > values to be omitted from the instance and conveyed in the message > specification. There appears to be a view that processing the > message+specification pair is too complex for current implementations. > > There is no reason why the standard could not define a format for > message specifications that included defaults, fixed, and reshaping > annotations in a way that would allow a receiver to process > message+specification and get a full rim-graph. > > Lets say that we agreed that the wire format should be serialised using > a single RIM schema (and I agree that this seems the most likely > conclusion to draw at this point). I suggest that it could still be > useful to agree a format for such reshaping specifications, so that they > can be reused in implementations. > > 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: 04 September 2006 08:05 >> To: Robert Worden >> Cc: new-its at lists.hl7.org.uk >> Subject: Re: [New-ITS] Reshaping should be at the discretion >> of animplementor >> >> >> >> Robert Worden wrote: >>> Grahame - >>> >>> You wrote: >>> >>>> Reshaping - while useful as an implementation tool - is >> not going to >>>> help with interoperability, unless we can get a single basis for >>>> reshaping >>> I disagree! >> actually, you agree, nearly. You describe a whole lot of uses >> of reshaping that are *implementation tool* usages - and they >> all make sense. >> >> Then you assert that >> >> > Only send reshaped message instances between consenting > >> parties, who have agreed to use the same reshaped model. >> >> well, perhaps. In fact, fine. But it's not going to help us >> find an ITS that is useful - which is what we are about here, >> and nor is it an appropriate thing to engage in at the >> standards level. In fact, in the end, all of the optimisation >> things die at the standards level because they make >> operability easier but interoperability harder. >> >> Grahame >> >>> Suppose I use a reshaped and restricted RMIM, purely as a >> way to get >>> full-ITS V3 onto the wire (not to reveal reshaped >> instances in public). >>> I use the reshaped model only as an intermediate step between my >>> application and V3. Then: >>> >>> - Because the reshaped model is smaller and simpler than >> the RMIM, and >>> has business names, I make more accurate mappings onto my >> applications >>> - Because the mappings of the reshaped XML onto V3 are >>> machine-generated, not hand-coded, there is no potential >> for error in >>> translation from reshaped XML to the full ITS >>> >>> - Therefore I have a more error-free interface between my >> applications >>> and V3 full ITS >>> >>> Surely that is 'going to help with interoperability'? And >> it does not >>> need a single basis for reshaping in order to work. If you >> don't think >>> so, Grahame, please tell me why. >>> >>> (I am genuinely perplexed at my failure to explain this >> point to some >>> very clever guys like you!) >>> >>> In using reshaped models like this, I would only be following the >>> advice on the HL7 Implementation Wiki: >>> >>> 'Do add a layer of abstraction, in the form of an intermediate XML >>> based format, and map this to HL7 v3 artefacts, e.g. with >> the aid of a >>> stylesheet. The structure of the intermediate format should be the >>> best possible mix of the internal database format and the >> model used >>> by CDA/Clinical statements.' >>> >>> Or: >>> >>> 'If you are working with XSLT you need to define an >> intermediate XML >>> format for your data. This can be in "close to HL7" form or >> in "close >>> to native" form.' >>> >>> HL7 does not require standardization of the intermediate XMLs. >>> >>> Only when you go to the next stage, of sending reshaped >> instances over >>> the wire, do you get interoperability issues. My solution to these >>> issues is: Only send reshaped message instances between consenting >>> parties, who have agreed to use the same reshaped model. If either >>> party wants to use full XML ITS, the other party has to provide it. >>> And he can do so, because he has an accurate transform to do it. >>> >>> (This next stage is not necessary, unless you are concerned about >>> performance and small message instances) >>> >>> Again - have I somehow failed to explain this point to >> anybody else on >>> the planet? What is wrong with it? >>> >>> Grahame - I think the key to your objection may be where >> you say 'it's >>> not going to solve problems at the level of the standard'. Maybe it >>> doesn't need to. Perhaps we should distinguish between (a) >> practical >>> things that implementers can do now, and (b) proposed >> changes to the >>> standard. We can propose a mix of these if we want to. >>> >>> 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. >>> >>> -----Original Message----- >>> From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf >> Of Grahame >>> Grieve >>> Sent: 04 September 2006 05:53 >>> To: Robert Worden >>> Cc: new-its at lists.hl7.org.uk >>> Subject: Re: [New-ITS] Reshaping should be at the discretion of an >>> implementor >>> >>> hi >>> >>> I think this should be rephrased as, "implemention should >> be left to >>> the implementor". >>> >>> No one (I hope) would disagree with this. >>> >>> Reshaping - while useful as an implementation tool - is not >> going to >>> help with interoperability, unless we can get a single basis for >>> reshaping - and suddenly we are back to where Charlie was. >>> >>> So what would actually be useful is a tool - or set of tools - that >>> can take an RMIM, and a profile on the RMIM - and produce useful >>> implementation constructs, and then this can be offered to the >>> implementors to help them implement. >>> >>> Robert, your tool is a step in the right direction here, and a >>> laudable direction - but it's not going to solve problems >> at the level >>> of the standard, I think. >>> >>> The hard part is doing the profiling >>> >>> Grahame >>> >>> >>> >>> 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). >>>> >>>> >>>> >>>> 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/ >>>> >>>> >>>> >> ---------------------------------------------------------------------- >>> -- >>>> _______________________________________________ >>>> 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 >> >> > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Tue Sep 5 01:09:15 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Tue, 05 Sep 2006 10:09:15 +1000 Subject: [New-ITS] Considering the XUM and what ITS worth In-Reply-To: References: Message-ID: <44FCC02B.8000803@kestral.com.au> Hi David > > you can get away without a terminology service in demographics, in straight > messaging - no problems. > > > I agree > ---- > > But then you said: > > If you bring this background to V3, you wonder why it's so complex. RIM > level serialisation is just part of that picture. > > > I am not sure that RIM level serialization is such a radical idea. Curiously > it is still more specific than HL7v2 naming conventions plus it has all the > formalism of the model. no. V3 itself (i.e. a terminology mediated structure) is a radical idea if your background is simply administrative messaging. everything that follows is variations on the one theme. > You said: > > so, join us in Eclipse and do it... ;-) > > > Not everything is Eclipse, not everything is HL7. yes, of course, but worth asking anyway. Grahame From grahame at kestral.com.au Tue Sep 5 01:12:49 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Tue, 05 Sep 2006 10:12:49 +1000 Subject: [New-ITS] Reshaping should be at the discretion of animplementor In-Reply-To: References: Message-ID: <44FCC101.9000400@kestral.com.au> > A) By reference to something in the same message instance. > B) By reference to something is another message instance previous > communicated. > C) By reference to an external resource (such as PDS). > >From the perspective of simplicity and non-ITS dependence my view is that > all uses of "by reference" should be "by reference to a known (or previously > communicated) identifier". This works for all cases (A), (B) and (C). it only works for (a) if the thing is actually identified. if anyone is still reading - was this ever discussed as a remedy to the batch reference problems? Grahame From grahame at kestral.com.au Tue Sep 5 01:17:05 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Tue, 05 Sep 2006 10:17:05 +1000 Subject: [New-ITS] So, what's a XUM ? In-Reply-To: <418B502A3861E242AFDED453F3D5B89C0E821702@i2km99-ukbr.domain1.systemhost.net> References: <418B502A3861E242AFDED453F3D5B89C0E821702@i2km99-ukbr.domain1.systemhost.net> Message-ID: <44FCC201.1020905@kestral.com.au> Hi Joe > A pedantic point. But allowing different implementers to implement the > model 'slightly' differently could be deemed good for interoperability > if many more implementers adopted HL7 as a result. Although the effort > to integrate two implementers would be greater, the overall potential > for an integratable healthcare industry may go up. ;) ok. it might. It might not either. Is this a question of metrics? can we make any prospective estimations? or is it simply a question of gambling and then finding out later? Grahame From grahame at kestral.com.au Tue Sep 5 01:23:59 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Tue, 05 Sep 2006 10:23:59 +1000 Subject: [New-ITS] Considering the XUM and what ITS worth In-Reply-To: References: Message-ID: <44FCC39F.2050304@kestral.com.au> Hi David > You may not be able to write code that distinguishes the RMIM level > specializations in all those cases. However, my question is if you cannot > distinguish them based on vocabulary why do you need to. ok, that's pretty much our question too. And one possible - indeed probable - answer is that the modelers have assumed that you will know where you are in the model, and therefore the model has meaning that is not properly implicit in the Reference model + terminologies. So you need to if the model breaks a fundamental rule of V3 models. But I don't think this rule, or it's consequences, are widely enough regarded or understood, so it will be regularly violated. The CfH models are a great case in point, I think. > 3. The ACT --> others is easy to do on classCode. but my point is that if one of the choices is a generalisation of all the other choices, it's incredibly difficult to write software that can choose the right choice - it can't go with first match, it has to go with *best match*, and to know what that best match is. Given that this might stretch deep into terminology, therefore you need to enhance the terminology interface to tell you which valueset is a constraint of which other..... we're getting really hard. So we need templateId. And we need to mandate it.... > Anyway the good news for you is I am going to go mute on the list as I have > vital work to do before setting out for the US Wednesday morning. this is good news? no. But I know about vital work. Grahame From grahame at kestral.com.au Tue Sep 5 01:27:07 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Tue, 05 Sep 2006 10:27:07 +1000 Subject: [New-ITS] Node counts In-Reply-To: References: Message-ID: <44FCC45B.30304@kestral.com.au> actually, in this sense, this is not a radical proposal - it really boils down to, let's define an implementation profile, then define a wire format representation of the profile that is related to the normative exchangeable format, but driven by the profile. Robert, it would be nice to see your tool produce or consume profiles (or both) as well it's current functionality Grahame Robert Worden wrote: > David - > > > > The risk you point out of 'offenders in their closed worlds' is a real > one and needs to be addressed; but to my mind it is the lesser of two > risks. > > > > Allowing the free use of local XUMs as intermediate XMLs will, in my > view, greatly reduce the risk that implementers misunderstand messages, > or get overwhelmed by RMIM complexity, and build bad interfaces. Against > that, the risk that they think the XUM is everything, or misunderstand > the true RIM significance of XUM elements, is a much smaller risk. Take > the smaller risk. > > > > The other risk which we are seeing is that implementers just can't be > bothered to interface with V3, and the world passes it by. Again, good > local XUMs can greatly reduce that risk. > > > > Two analogies to muddy the waters: > > > > Analogy 1: Healthcare applications are like domestic electrical > appliances - kettles and fridges - working at 240 volts. V2 is like a > 1000 volt circuit, which suppliers are prepared to connect to. But V3 > is like the national grid at 132,000 volts, and nobody wants to connect > their kettle to 132,000 volts. HL7 needs to supply good transformers to > step down the voltage - or let people like ChF build them. That is what > reshaped models are, and they will help more people to connect to V3. > Without them, there will be no 'open world' of V3 because nobody will > connect to it without a government bribe. > > > > Analogy 2: The mediaeval Bible was written in Latin (a highly successful > pan-European standard). English-language Bibles were initially banned, > for sound theological reasons: Latin is the language for theological > debate; if you let these peasants read the Bible in the vernacular, they > will miss all the true meaning and even succumb to heresy; better wait > until they are properly educated and can appreciate the true > meaning....I'd rather have the Bible in English. > > > > Put another way, I'd rather have a few offenders in their closed worlds, > that HL7 in its closed world. > > > > 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: David Markwell [mailto:david at clininfo.co.uk] > Sent: 03 September 2006 09:57 > To: Robert Worden > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > > > Robert > > > > The problem as I see it is that it will be oh so easy for people using > reshaped instances to place reliance on the particularity of those > instances and to subtly change the way they use them and basically to > diverge. The more special case reshapings that exist the higher the risk > and the more difficult to spot the offenders in their closed worlds. As > they move to the open world suddenly all is revealed. My contention is > that to be sure this does not happen these implementers will need to > understand the generic foundations and if they do then why not use them. > If its just to make messages smaller or simpler to process then one can > understand the motivation for the reshape. However if as I suspect they > will later need to go all the way then why have them play with fire > before giving them the the advice on full and safe ITS? > > > > Kind Regards > > David Markwell > > Mailto:david at clininfo.co.uk > > > > > > ________________________________ > > From: Robert Worden [mailto:Robert.Worden at Charteris.com] > Sent: 03 September 2006 09:30 > To: david at clininfo.co.uk > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > David - > > > > If we agree on 1-6, then that is the most important point. That gets the > main benefit of using restricted and reshaped RMIMs (fish) as a way of > generating either RIM-based XML (fowl) or current XML ITS (fish-fowl > hybrid). The benefit is that restricted and reshaped RMIMs are smaller > and easier for implementers to understand and map onto - so > implementations should be quicker and (more important) more accurately > done. > > > > The only point of going to 7 (reshaped message instances over the wire) > is a performance benefit - the reshaped instances will be smaller, and > you avoid two translations (to/from full ITS). To me the performance > point is much less important than the ease of message implementation - > but it may be important for others. > > > > You say 'I think that if 6-->7 mapping is possible...' and it > certainly is. The big benefit of restricting/reshaping an RMIM is that > the tool will not allow you to make any illegal moves (e.g. collapsing a > 1:N association) and will always keep track of the mappings between the > RMIM and the reshaped version - so you can always generate XSLT > translations between the two (not write them by hand) and they will be > perfectly accurate. You can have 6-7 and 7-6 converters anywhere you > like. > > > > So to come to your example - A and B agree to use reshaped instances > over the wire, because they need the extra performance of smaller > message instances. But as soon as C comes along and demands full ITS > instances, A has to give them to him - and can easily do so, because he > has the transform (automatically generated, accurate) and can just run > it each time. I don't see a problem for A, B or C (except maybe > understanding each other's English dialects). > > > > 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: David Markwell [mailto:david at clininfo.co.uk] > Sent: 01 September 2006 15:40 > To: Robert Worden > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > > > Robert > > > > I would agree that we seem close to agreement on 1-6. > > > > I remain to be convinced that 7 over the wire helps anyone. > > > > I think that if 6-->7 mapping is possible (which is implicit in the idea > of 7 existing at all) then simple 6-->7 and 7-->6 converters for > specific environments would be a far better solution. The reason that I > prefer this is as follows: > > > > Say that A and B agree to communicate using 7. They are happy ;-) > > > > Until one day B needs to communicate with C > > > > Unfortunately for B, C who works in a more diverse environment aligned > nicely with the generic structures that they use in multiple domains. > They use 6 with everyone - they may have use a kind of 7 view from time > to time to aid understanding and debugging. However on the wire there > stick with 6. > > > > Now B argues "I say you chaps we know how to do this we've done it for > years with the A Team and it looks like you Cee fellows are at 6's and > no 7's" > > > > However C replies "look buddy we bin doing dis stuff wid the rest of the > alph'bet from Dee throu' Zee you Bees get wid the program or buzz off". > > > > Who should win in this show down and who should be stung? > > > > Who should be forced to convert? > > > > I know whose case I would argue and ... on that basis ... I'd rather > avoid the argument by asserting up front that there is no 7 as part of > the standard. So while consenting parties can use fax or sneaker-net or > funny handshake or their own flavour of 7 that is not the standard. > > > > Kind Regards > > David Markwell > > Mailto:david at clininfo.co.uk > > > > > > ________________________________ > > From: Robert Worden [mailto:Robert.Worden at Charteris.com] > Sent: 01 September 2006 11:48 > To: david at clininfo.co.uk > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > David - > > > > I think we are getting somewhere. If RMIM names are neither fish nor > fowl: > > > > 1. RIM names with classCodes etc. are pure fowl > > 2. A reshaped RMIM, with business names defined locally by a > super-implementor such as CfH, are fish. > > 3. Accurate fish-to-fowl transformations come out of the reshaping > process > > 4. So anyone can produce or consume fish or fowl to his taste > (fish is easier for some, fowl for others) > > 5. You must be able to produce fowl to be V3 conformant. You can > do this by the transformations. > > 6. Normally, it is fowl that goes over the wire. > > 7. Between consenting parties, fish may be exchanged (or > performance reasons only) > > > > All this seems to me perfectly possibly now, and compatible with HL7 > methodology - with the possible exception of (7), which needs > discussion. > > > > 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: David Markwell [mailto:david at clininfo.co.uk] > Sent: 01 September 2006 10:18 > To: Robert Worden > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > > > Robert > > > > Your comment about ambiguity is interesting. I would argue it is not > ambiguous because the meaning should be captured in the coding > (classCode, moodCode, code etc). I do not think detailed semantics is a > schema level issue - it depends on content. Some apps will inevitably > have different models which put different items of information into > different structures based on content. They can decide to do that if > they wish but the information communicated to them and by them is > normalized as RIM physical class instances. > > > > At present (or in various other proposal) there is the RIM class, there > is the RMIM class name structure and there is the applications way of > storing and handling information. The RMIM class business names are > neither fish nor fowl. They are not the names in the applications > (because these are internal design driven) and they are not the same as > the RIM. Implementers try to make sense of the element names and risk > ignoring the semantic identify of two statements (i.e. two Acts with > identical attribute content) simply because the element names differ. > > > > Thus my contention is that this layer of additional names which was > intended as a bridge or intermediate abstraction layer has become > instead a distraction layer. My original assumption in backing and > arguing for business names was that this would make schema validation > more effective at checking constraints while any sane application > developer would ignore the names and process as advised based only on > the classCode etc. > > > > How wrong I was and how seriously. I confess that only when people > started to add names to ever greater depths of spuriously familiar > detailed naming did it strike me how seriously we have failed to > communicate this message. > > > > Kind Regards > > David Markwell > > Mailto:david at clininfo.co.uk > > > > > > ________________________________ > > From: Robert Worden [mailto:Robert.Worden at Charteris.com] > Sent: 01 September 2006 09:56 > To: david at clininfo.co.uk > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > David - > > > > Glad we are getting closer - but while I agree that 'Moving to RIM > named classes would massively reduce the path count.', I'm not sure it > would reduce it usefully. > > > > There is a small point that XML nodes and XPaths will use association > names, rather than class names; so in stead of RIM classes like 'Act' we > would have RIM association names like 'scoper' . But that is really a > small point. If you restricted yourself to RIM names (and used simple > XPaths with only node names) then I agree that the number of distinct > XPaths would be much smaller - but each XPath would then be very > ambiguous, telling you only 'you have got to depth 5 in the structure' > and I think not much more. > > > > Anybody doing RIM-based processing would be looking at classCodes etc. > as he went down the structure, so he would effectively be navigating > XPaths with steps like > > /player[@classCode = 'PAT']/ which would take him more unambiguously > down the structure. I think the number of these XPaths would be just as > large as my node/path counts, regardless of naming. (Maybe they are > Gunther's HPaths.) > > > > I agree with you that for some purposes, and for some people, pure > RIM-based processing is the right way to go, and avoids a lot of the > naming problems you refer to. But I'm not sure it is everybody's cup of > tea; I'd rather give a choice and let the market decide. With what I > propose, we can have our cake and eat it. Anyone who sends or receives > flattened/renamed/reshaped messages must also be able to send or receive > full ITS messages - and will have the transforms to move accurately > between the two. Anyone who wants to receive only full ITS messages, and > do RIM-based processing, can do so (= have cake). Anybody who wants to > do other things, using reshaped messages, can do so (= eat it). I don't > see that there has to be any dilemma between the two. > > > > 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. > > > > ________________________________ > > From: David Markwell [mailto:david at clininfo.co.uk] > Sent: 31 August 2006 18:37 > To: Robert Worden > Cc: new-its at lists.hl7.org.uk > Subject: RE: Node counts > > > > 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/ > > _________________________________________________________________ > 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/ > > _________________________________________________________________ > 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 -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Tue Sep 5 01:30:11 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Tue, 05 Sep 2006 10:30:11 +1000 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FC4050.7010800@OceanInformatics.biz> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> <44FC1651.7060107@kestral.com.au> <44FC2943.9090702@OceanInformatics.biz> <44FC3045.2070702@kestral.com.au> <44FC3562.3030806@OceanInformatics.biz> <44FC3909.6070607@kestral.com.au> <44FC4050.7010800@OceanInformatics.biz> Message-ID: <44FCC513.3000500@kestral.com.au> hi Tom I feel like I'm going around in circles. let's say I agree that > more classes and patterns are needed let's way that we also agree that timeseries is a narrow but useful requirement to pursue. In the context of the RIM, what would a useful addition for supporting this pattern look like, without toasting the entire existing RIM - or aren't you interested in contributing like this? you say, > This is not an academic issue; it is a practical issue with a pervasive > influence on the modelling activity. fine. I agree. So let's be practical and propose something that contributes to the framework. Grahame From Thomas.Beale at OceanInformatics.biz Tue Sep 5 06:52:42 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Tue, 05 Sep 2006 06:52:42 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FCC513.3000500@kestral.com.au> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> <44FC1651.7060107@kestral.com.au> <44FC2943.9090702@OceanInformatics.biz> <44FC3045.2070702@kestral.com.au> <44FC3562.3030806@OceanInformatics.biz> <44FC3909.6070607@kestral.com.au> <44FC4050.7010800@OceanInformatics.biz> <44FCC513.3000500@kestral.com.au> Message-ID: <44FD10AA.40203@OceanInformatics.biz> Grahame Grieve wrote: > hi Tom > > I feel like I'm going around in circles. > > let's say I agree that > > more classes and patterns are needed > > let's way that we also agree that timeseries is a narrow > but useful requirement to pursue. > > In the context of the RIM, what would a useful addition for > supporting this pattern look like, without toasting the entire > existing RIM - or aren't you interested in contributing like > this? > > well, I can point to a simple UML model of time series (http://www.openehr.org/uml/release-1.0/Browsable/_9_0_76d0249_1109157527311_729550_7234Report.html) and a model of other simple data structures (http://www.openehr.org/uml/release-1.0/Browsable/_9_0_76d0249_1109346709572_859750_3810Report.html, http://svn.openehr.org/specification/TRUNK/publishing/architecture/computable/UML/uml_start_view.html). This is how can be done. The HL7 version would require its own data types and other details etc etc. But the models are simple enough (and the ones I show here are actually debugged after some years of use now). But - there is no possibility of touching the RIM as far as I know - it's the inviolable model of everything just as it is (as extolled most recently by G Schadow at MIE 2006 in Maastricht). So such fixes, although they would provide a huge amount of value aren't available to the community of those required to use the RIM. Something more local is probably required, if the RIM has to continue to be used. - thomas From grahame at kestral.com.au Wed Sep 6 23:42:52 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Thu, 07 Sep 2006 08:42:52 +1000 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FD10AA.40203@OceanInformatics.biz> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> <44FC1651.7060107@kestral.com.au> <44FC2943.9090702@OceanInformatics.biz> <44FC3045.2070702@kestral.com.au> <44FC3562.3030806@OceanInformatics.biz> <44FC3909.6070607@kestral.com.au> <44FC4050.7010800@OceanInformatics.biz> <44FCC513.3000500@kestral.com.au> <44FD10AA.40203@OceanInformatics.biz> Message-ID: <44FF4EEC.4000506@kestral.com.au> so, sticking to time series, for the moment, HL7 already has PIVL. So the idea seems to be that you would reuse this on ActRelationship, and create some kind of PIVL_ACT_RELATIONSHIP which specialises ActRelationship and adds recurrence : PIVL, and has 1..* target {ordered}. You might need to restructure ActRelationship a little, but this would mean that you had a single act relationship pointing to a sequence of Acts all with the same relationship semantics, differing by their time in an ordered manner. Where would you use a structure like this in existing HL7 models? I kind of drew a blank except perhaps in clinical Statement? Really it belongs in areas that HL7 hasn't really modeled, in investigative procedure reports (where frequently they are presented as regular but they actually aren't). It would seem that a more useful pattern was an ActRelationship with more than one target, where there was some ability to mark the target with some arbitrary differentiating information, such as a date, so you could do an irregular series of {investigations, appointments, etc} Grahame Thomas Beale wrote: > Grahame Grieve wrote: >> hi Tom >> >> I feel like I'm going around in circles. >> >> let's say I agree that >> > more classes and patterns are needed >> >> let's way that we also agree that timeseries is a narrow >> but useful requirement to pursue. >> >> In the context of the RIM, what would a useful addition for >> supporting this pattern look like, without toasting the entire >> existing RIM - or aren't you interested in contributing like >> this? >> >> > well, I can point to a simple UML model of time series > (http://www.openehr.org/uml/release-1.0/Browsable/_9_0_76d0249_1109157527311_729550_7234Report.html) > and a model of other simple data structures > (http://www.openehr.org/uml/release-1.0/Browsable/_9_0_76d0249_1109346709572_859750_3810Report.html, > http://svn.openehr.org/specification/TRUNK/publishing/architecture/computable/UML/uml_start_view.html). > > > This is how can be done. The HL7 version would require its own data > types and other details etc etc. But the models are simple enough (and > the ones I show here are actually debugged after some years of use now). > But - there is no possibility of touching the RIM as far as I know - > it's the inviolable model of everything just as it is (as extolled most > recently by G Schadow at MIE 2006 in Maastricht). So such fixes, > although they would provide a huge amount of value aren't available to > the community of those required to use the RIM. Something more local is > probably required, if the RIM has to continue to be used. > > - thomas > > > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From Laura.Sato at cfh.nhs.uk Thu Sep 7 12:33:56 2006 From: Laura.Sato at cfh.nhs.uk (Sato Laura) Date: Thu, 7 Sep 2006 12:33:56 +0100 Subject: [New-ITS] ITS investigation update Message-ID: <1A3D105C334EAE49BDDD93D8767573F504436230@EXCHAQ2.nhsia.nhs.uk> (My apologies for the cross-postings.) As a follow-up to some of our meeting discussions last May, the attached paper summarises ideas for a new ITS and issues for discussion and further testing. For discussion (where agendae allow) in Boca Raton. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060907/eb30a788/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: NewITS-SummaryProposals_v0-6.doc Type: application/msword Size: 475136 bytes Desc: NewITS-SummaryProposals_v0-6.doc Url : http://lists.hl7.org.uk/pipermail/new-its/attachments/20060907/eb30a788/NewITS-SummaryProposals_v0-6-0001.doc From rene.spronk at ringholm.com Thu Sep 7 14:56:49 2006 From: rene.spronk at ringholm.com (Rene Spronk (Ringholm)) Date: Thu, 07 Sep 2006 15:56:49 +0200 Subject: [New-ITS] [Norton AntiSpam] ITS investigation update In-Reply-To: References: Message-ID: <45002521.2080306@ringholm.com> All, For those of you who like to have the URL, the proposal has been uploaded to: http://www.hl7.org/library/committees/inm/NewITS%2DSummaryProposals%5Fv0%2D6%2Edoc Note that the ITS aspects of the proposal are on the INM agenda for WED Q2. Personally I hope the presentation during that INM quarter focuses on the "solution space" aspect of the proposal. The proposal contains a lot of rationale (the "problem space") which IMHO is largely out of scope from an INM perspective (although essential to have as a backgrounder). As long as a proposed ITS (this one included) meets the agreed upon criteria (http://informatics.mayo.edu/wiki/index.php/ITS_Acceptance_Factors) it will be accepted as an INM workitem. The process of annotating "RBMs", HDF/ organizational/ publishing consequences etc. probably have to be tackled elsewhere.. TTYL, -Rene Sato Laura wrote: > (My apologies for the cross-postings.) As a follow-up to some of our > meeting discussions last May, the attached paper summarises ideas for a > new ITS and issues for discussion and further testing. For discussion > (where agendae allow) in Boca Raton. > > > > > > 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 > > > > > > > ************************************************ > You are currently subscribed to conf at lists.hl7.org as > rene.spronk at ringholm.com > To unsubscribe from this list, send a blank email to > leave-conf-133765M at lists.hl7.org > To access the Archives of this list, go to: > http://lists.hl7.org/read/?forum=conf > To access your List Server profile and subscriptions, go to: > http://%%site.domainname%%/read/login -- ------------------------------------------------------------ Rene Spronk Phone: +31(0)655 363 446 Senior Consultant Fax: +31(0)30 695 6915 Ringholm GmbH The Netherlands http://www.ringholm.com mailto:Rene.Spronk at ringholm.nl ------------------------------------------------------------ Ringholm GmbH Integration Consulting - Making Standards Work From Thomas.Beale at OceanInformatics.biz Thu Sep 7 15:50:46 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Thu, 07 Sep 2006 15:50:46 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: <44FF4EEC.4000506@kestral.com.au> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> <44FC1651.7060107@kestral.com.au> <44FC2943.9090702@OceanInformatics.biz> <44FC3045.2070702@kestral.com.au> <44FC3562.3030806@OceanInformatics.biz> <44FC3909.6070607@kestral.com.au> <44FC4050.7010800@OceanInformatics.biz> <44FCC513.3000500@kestral.com.au> <44FD10AA.40203@OceanInformatics.biz> <44FF4EEC.4000506@kestral.com.au> Message-ID: <450031C6.3080807@OceanInformatics.biz> Grahame Grieve wrote: > so, sticking to time series, for the moment, > HL7 already has PIVL. So the idea seems to be > that you would reuse this on ActRelationship, > and create some kind of PIVL_ACT_RELATIONSHIP > which specialises ActRelationship and adds > recurrence : PIVL, and has 1..* target {ordered}. > > You might need to restructure ActRelationship > a little, but this would mean that you had > a single act relationship pointing to a sequence > of Acts all with the same relationship semantics, > differing by their time in an ordered manner. > don't forget - what is needed is that at each time point you can have as large a data structure as you want, detailing what was measured at that point. Example is Apgar - 6 data points per time point, or BP, 2 or more items per time point; ECG - 12 values per time point... Would the structure you suggest be intuitive in a design environment, on the screen etc? > Where would you use a structure like this in > existing HL7 models? I kind of drew a blank > except perhaps in clinical Statement? Really > it belongs in areas that HL7 hasn't really modeled, > in investigative procedure reports (where frequently > they are presented as regular but they actually > aren't). > well, and many lab observations (OGTT an obvious example), and many point of care observations (nearly all vital signs in hospital are time-based), and many others besides (Apgar, orthostatic BP and so on). These are all basic measurements. > It would seem that a more useful pattern was an > ActRelationship with more than one target, where > there was some ability to mark the target with > some arbitrary differentiating information, such > as a date, so you could do an irregular series of > {investigations, appointments, etc} > > History in openEHR copes with irregular series, and even series of mixed point and interval values. But a "series" of investigations, appointments etc is not a time-series in the scientific measurement sense, it is a sequence of events in social/business time, not a series of measured values of a phenomenon. WHat you are suggesting is no doubt also useful, but is a different thing altogether. But in any case, you seem to be suggesting trying to make some contortions on existing RIM classes to make them perform this simple pattern - it sounds complex already! - thomas From grahame at kestral.com.au Thu Sep 7 17:37:57 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Fri, 08 Sep 2006 02:37:57 +1000 Subject: [New-ITS] Complexity Measures In-Reply-To: <450031C6.3080807@OceanInformatics.biz> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> <44FC1651.7060107@kestral.com.au> <44FC2943.9090702@OceanInformatics.biz> <44FC3045.2070702@kestral.com.au> <44FC3562.3030806@OceanInformatics.biz> <44FC3909.6070607@kestral.com.au> <44FC4050.7010800@OceanInformatics.biz> <44FCC513.3000500@kestral.com.au> <44FD10AA.40203@OceanInformatics.biz> <44FF4EEC.4000506@kestral.com.au> <450031C6.3080807@OceanInformatics.biz> Message-ID: <45004AE5.9010106@kestral.com.au> Thomas Beale wrote: > Grahame Grieve wrote: >> so, sticking to time series, for the moment, >> HL7 already has PIVL. So the idea seems to be >> that you would reuse this on ActRelationship, >> and create some kind of PIVL_ACT_RELATIONSHIP >> which specialises ActRelationship and adds >> recurrence : PIVL, and has 1..* target {ordered}. >> >> You might need to restructure ActRelationship >> a little, but this would mean that you had >> a single act relationship pointing to a sequence >> of Acts all with the same relationship semantics, >> differing by their time in an ordered manner. >> > don't forget - what is needed is that at each time point you can have as > large a data structure as you want, detailing what was measured at that > point. Example is Apgar - 6 data points per time point, or BP, 2 or more > items per time point; ECG - 12 values per time point... well, it points to act- you can't get larger than that ;-) > Would the structure you suggest be intuitive in a design environment, on > the screen etc? Well, I think that if you are in the RIM world, then it's intuitive. >> Where would you use a structure like this in >> existing HL7 models? I kind of drew a blank >> except perhaps in clinical Statement? Really >> it belongs in areas that HL7 hasn't really modeled, >> in investigative procedure reports (where frequently >> they are presented as regular but they actually >> aren't). >> > well, and many lab observations (OGTT an obvious example), and many > point of care observations (nearly all vital signs in hospital are > time-based), and many others besides (Apgar, orthostatic BP and so on). > These are all basic measurements. yes, this is the area of templates, so HL7 hasn't devoted much attention to modelling them - nor has CfH, I think >> It would seem that a more useful pattern was an >> ActRelationship with more than one target, where >> there was some ability to mark the target with >> some arbitrary differentiating information, such >> as a date, so you could do an irregular series of >> {investigations, appointments, etc} > History in openEHR copes with irregular series, and even series of mixed > point and interval values. But a "series" of investigations, > appointments etc is not a time-series in the scientific measurement > sense, it is a sequence of events in social/business time, not a series > of measured values of a phenomenon. WHat you are suggesting is no doubt > also useful, but is a different thing altogether. just from working a lab, I know that there's nominal time series, and the actual sequence of measurement > But in any case, you seem to be suggesting trying to make some > contortions on existing RIM classes to make them perform this simple > pattern - it sounds complex already! I don't think you are being fair here. If you adopt the RIM paradigm, then I don't think it's sounds as complex as it might to someone who automatically assumes that the RIM is overly complex Grahame From Thomas.Beale at OceanInformatics.biz Thu Sep 7 17:53:24 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Thu, 07 Sep 2006 17:53:24 +0100 Subject: [New-ITS] Complexity Measures In-Reply-To: <45004AE5.9010106@kestral.com.au> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> <44FC1651.7060107@kestral.com.au> <44FC2943.9090702@OceanInformatics.biz> <44FC3045.2070702@kestral.com.au> <44FC3562.3030806@OceanInformatics.biz> <44FC3909.6070607@kestral.com.au> <44FC4050.7010800@OceanInformatics.biz> <44FCC513.3000500@kestral.com.au> <44FD10AA.40203@OceanInformatics.biz> <44FF4EEC.4000506@kestral.com.au> <450031C6.3080807@OceanInformatics.biz> <45004AE5.9010106@kestral.com.au> Message-ID: <45004E84.9050408@OceanInformatics.biz> Grahame Grieve wrote: > > >> But in any case, you seem to be suggesting trying to make some >> contortions on existing RIM classes to make them perform this simple >> pattern - it sounds complex already! > > I don't think you are being fair here. If you adopt the RIM paradigm, > then I don't think it's sounds as complex as it might to someone > who automatically assumes that the RIM is overly complex fair enough - that's partly a subjective judgement; but the objective part was: we seem still to be stuck in machine-language mode, i.e. forced to build new semantics from existing classes rather than just adding the new semantics in a direct and efficient way. - thomas From grahame at kestral.com.au Thu Sep 7 18:01:11 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Fri, 08 Sep 2006 03:01:11 +1000 Subject: [New-ITS] Complexity Measures In-Reply-To: <45004E84.9050408@OceanInformatics.biz> References: <44F86E3B.7080703@OceanInformatics.biz> <44FBA908.4040400@kestral.com.au> <44FBEA4C.6010908@OceanInformatics.biz> <44FBFC38.5030705@kestral.com.au> <44FC13B2.4060704@OceanInformatics.biz> <44FC1651.7060107@kestral.com.au> <44FC2943.9090702@OceanInformatics.biz> <44FC3045.2070702@kestral.com.au> <44FC3562.3030806@OceanInformatics.biz> <44FC3909.6070607@kestral.com.au> <44FC4050.7010800@OceanInformatics.biz> <44FCC513.3000500@kestral.com.au> <44FD10AA.40203@OceanInformatics.biz> <44FF4EEC.4000506@kestral.com.au> <450031C6.3080807@OceanInformatics.biz> <45004AE5.9010106@kestral.com.au> <45004E84.9050408@OceanInformatics.biz> Message-ID: <45005057.5020006@kestral.com.au> >>> But in any case, you seem to be suggesting trying to make some >>> contortions on existing RIM classes to make them perform this simple >>> pattern - it sounds complex already! >> >> I don't think you are being fair here. If you adopt the RIM paradigm, >> then I don't think it's sounds as complex as it might to someone >> who automatically assumes that the RIM is overly complex > fair enough - that's partly a subjective judgement; but the objective > part was: we seem still to be stuck in machine-language mode, i.e. > forced to build new semantics from existing classes rather than just > adding the new semantics in a direct and efficient way. well, if we want to extend the RIM, we need to do it in harmony with the express strengths of the RIM. trying to introduce a new paradigm isn't going to work. But I don't think anyone is interested ... Grahame From joseph.2.waller at bt.com Tue Sep 12 15:56:29 2006 From: joseph.2.waller at bt.com (joseph.2.waller@bt.com) Date: Tue, 12 Sep 2006 15:56:29 +0100 Subject: [New-ITS] [New ITS] - Industry Tool Support Message-ID: <418B502A3861E242AFDED453F3D5B89C0FA8EDC9@i2km99-ukbr.domain1.systemhost.net> All, Reviewing the sterling work on the XML ITS I wanted to raise an early question for opinions. 'A.3.1 Industry Tool Support' asks why tools blow up. In my experience there are various reasons for this. But one in particular is around the repeated definition of complex types and elements when you try to include multiple schema in a WSDL. Does anyone else think that the way in which the transport data is necessarily included as a wrapper (rather than a separate header element) tends to presuppose an HTTP profile for HL7 v3 (in other words HL7 directly into an HTTP message). Other protocols tend towards placing additional transport data in extensible headers (such as ebXML, WS-Addressing and SOAP standards in general as well as JMS queuing to some extent)? In other words, is there any way to maintain the idea of an interaction as a superset of a message without fixing on an pure HTTP implementation. I'd be interested to hear of other examples of HL7v3 implementation that rely on soapy or 'headery' protocols. Is the current wrapper formulation less HTTP focussed than I assume? Thanks, Joseph Waller |Spine Systems Engineering |National Spine |BT |T: +44 (0)113-306-5310 |M: +44 (0)7793-841-932 |E: joseph.2.waller at bt.com |W: www.bt.com/consulting From grahame at kestral.com.au Wed Sep 13 01:18:55 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 13 Sep 2006 10:18:55 +1000 Subject: [New-ITS] [New ITS] - Industry Tool Support In-Reply-To: <418B502A3861E242AFDED453F3D5B89C0FA8EDC9@i2km99-ukbr.domain1.systemhost.net> References: <418B502A3861E242AFDED453F3D5B89C0FA8EDC9@i2km99-ukbr.domain1.systemhost.net> Message-ID: <45074E6F.5050808@kestral.com.au> > 'A.3.1 Industry Tool Support' asks why tools blow up. In my experience > there are various reasons for this. But one in particular is around the > repeated definition of complex types and elements when you try to > include multiple schema in a WSDL. I guess this and below are two separate issues. Can you be specific about this one? > Does anyone else think that the way in which the transport data is > necessarily included as a wrapper (rather than a separate header > element) tends to presuppose an HTTP profile for HL7 v3 (in other words > HL7 directly into an HTTP message). no, not http, any basic communication protocol where there is a clear an absolute separation between protocol and content, and protocol only deals with network communication InM are revisiting the transmission content, and part of our non-functional requirements will be to figure out how to deliver to our functional requirements for data exchange with HL7 content and process choreography in the context of communication protocols that provide much richer functionality than those anticipated. Grahame From joseph.2.waller at bt.com Mon Sep 18 11:48:58 2006 From: joseph.2.waller at bt.com (joseph.2.waller@bt.com) Date: Mon, 18 Sep 2006 11:48:58 +0100 Subject: [New-ITS] [New ITS] - Industry Tool Support Message-ID: <418B502A3861E242AFDED453F3D5B89C0FBFF3F9@i2km99-ukbr.domain1.systemhost.net> Graham, The two questions are actually kinda related. Question 1 - When you create a WSDL you include a description of the interface as an xsd. This means that you generally include an xsd for each message that makes up that service. HL7 Wrappers necessarily re-describe the Control Act in every message which means that a WSDL validator (for example try XML Spy) will reject a WSDL as the combined description is trying to describe the same complex type more than once. Question 2 - This would not happen is the transmission information was in a separate header. This would allow a WSDL to refer to a generic sending header for all messages. Further, this way that the HL7 message is necessarily wrapped in a wrapper rather than sat alongside an associated header suggests that they were designed for a protocol that does not use headers. i.e. putting an HL7 message directly in HTTP rather than inside SOAP or any SOAP related protocol such as ebXML or WS-Reliable Messaging. If InM are revisiting the transmission content I think it is important that they make the model a) more flexible with more easily separatable transmission information b) contain extensibility elements or - if the transmission information is more seperated - at least allow the profiles to suggest ways of using the extensibility mechanisms in those protocols' headers. The improved relation of HL7 to process choreography will be useful too, as currently the concepts of 'trigger events' and 'interactions' are as you imply not well aligned with wider facilities for process choreography in things like WS-Transactions and WS-Reliable messaging. I recognise I'm not saying anything revolutionary, Joe -----Original Message----- From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame Grieve Sent: Wednesday, September 13, 2006 1:19 AM To: Waller,J,Joseph,JPGA3Y C Cc: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] [New ITS] - Industry Tool Support > 'A.3.1 Industry Tool Support' asks why tools blow up. In my experience > there are various reasons for this. But one in particular is around > the repeated definition of complex types and elements when you try to > include multiple schema in a WSDL. I guess this and below are two separate issues. Can you be specific about this one? > Does anyone else think that the way in which the transport data is > necessarily included as a wrapper (rather than a separate header > element) tends to presuppose an HTTP profile for HL7 v3 (in other > words > HL7 directly into an HTTP message). no, not http, any basic communication protocol where there is a clear an absolute separation between protocol and content, and protocol only deals with network communication InM are revisiting the transmission content, and part of our non-functional requirements will be to figure out how to deliver to our functional requirements for data exchange with HL7 content and process choreography in the context of communication protocols that provide much richer functionality than those anticipated. Grahame From grahame at kestral.com.au Tue Sep 19 00:55:27 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Tue, 19 Sep 2006 09:55:27 +1000 Subject: [New-ITS] [New ITS] - Industry Tool Support In-Reply-To: <418B502A3861E242AFDED453F3D5B89C0FBFF3F9@i2km99-ukbr.domain1.systemhost.net> References: <418B502A3861E242AFDED453F3D5B89C0FBFF3F9@i2km99-ukbr.domain1.systemhost.net> Message-ID: <450F31EF.4090205@kestral.com.au> joseph.2.waller at bt.com wrote: > Graham, > > The two questions are actually kinda related. > > Question 1 - When you create a WSDL you include a description of the > interface as an xsd. This means that you generally include an xsd for > each message that makes up that service. HL7 Wrappers necessarily > re-describe the Control Act in every message which means that a WSDL > validator (for example try XML Spy) will reject a WSDL as the combined > description is trying to describe the same complex type more than once. so, is there a better way? The problem is specifying the type of the inner content. Charlie, why is it that we decided to embed the content when we stitch, instead of doing it serially? I can't remember > Question 2 - This would not happen is the transmission information was > in a separate header. This would allow a WSDL to refer to a generic > sending header for all messages. Further, this way that the HL7 message > is necessarily wrapped in a wrapper rather than sat alongside an > associated header suggests that they were designed for a protocol that > does not use headers. i.e. putting an HL7 message directly in HTTP > rather than inside SOAP or any SOAP related protocol such as ebXML or > WS-Reliable Messaging. > > If InM are revisiting the transmission content I think it is important > that they make the model a) more flexible with more easily separatable > transmission information b) contain extensibility elements or - if the > transmission information is more seperated - at least allow the profiles > to suggest ways of using the extensibility mechanisms in those > protocols' headers. The improved relation of HL7 to process choreography > will be useful too, as currently the concepts of 'trigger events' and > 'interactions' are as you imply not well aligned with wider facilities > for process choreography in things like WS-Transactions and WS-Reliable > messaging. > I recognise I'm not saying anything revolutionary, no, this is much more our (INM) direction now. But it's a committee, so it's not unanimous. Shortly we'll start collecting requirements, hopefully experts like yourself will be able to contribute here. Grahame From Charlie at ramseysystems.co.uk Tue Sep 19 10:23:35 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Tue, 19 Sep 2006 10:23:35 +0100 Subject: [New-ITS] [New ITS] - Industry Tool Support Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FCEA@ramseysc1420.RamseyNet.local> Comments inline 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: 19 September 2006 00:55 > To: joseph.2.waller at bt.com > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] [New ITS] - Industry Tool Support > > > > joseph.2.waller at bt.com wrote: > > Graham, > > > > The two questions are actually kinda related. > > > > Question 1 - When you create a WSDL you include a > description of the > > interface as an xsd. This means that you generally include > an xsd for > > each message that makes up that service. HL7 Wrappers necessarily > > re-describe the Control Act in every message which means > that a WSDL > > validator (for example try XML Spy) will reject a WSDL as > the combined > > description is trying to describe the same complex type > more than once. > > so, is there a better way? > The problem is specifying the type of the inner content. > Charlie, why is it that we decided to embed the content when > we stitch, instead of doing it serially? I can't remember We did try to move to the headers paradigm in one of the later ballots of the XML Structures ( maybe Ballot 7 of 10) but it was voted down on the basis that it did not cleanly reflect the semantic dependancy, creating an arbitary fixed break between what belonged to the header and what belonged to the payload. By using containment the receiver could ignore the boundary and process the entire transmission as a single RIM graph. It is also possible to create schemas to recognise just the transport, or transport+controlAct wrappers, and have xsd:any for the content -- thus supporting a generic WSDL that passes the processing of the inner message on to some other process behind the interface. The HL7 publication has been structured to allow for such schemas to be generated -- just that no-one has had the resource/drive to get them produced. That is how the discussion went that carried the committee against the use of headers. The WSDL combination problem should be resolved now -- I have not checked it recently, but I know that there was a problem with multiple includes of the same file (which should be allowed) causing validation errors with some processors, and also with some unused types causing errors with some processors. Both issues could be addressed by either doing some tweeks to the schemas, or improving the processors, or both. CFH have taken their schema support in-house, and Lloyd has been maintianing the schema generator, so I am not as close to this as I once was... > > > Question 2 - This would not happen is the transmission > information was > > in a separate header. This would allow a WSDL to refer to a generic > > sending header for all messages. Further, this way that the HL7 > > message is necessarily wrapped in a wrapper rather than sat > alongside > > an associated header suggests that they were designed for a > protocol > > that does not use headers. i.e. putting an HL7 message directly in > > HTTP rather than inside SOAP or any SOAP related protocol such as > > ebXML or WS-Reliable Messaging. > > > > If InM are revisiting the transmission content I think it > is important > > that they make the model a) more flexible with more easily > separatable > > transmission information b) contain extensibility elements > or - if the > > transmission information is more seperated - at least allow the > > profiles to suggest ways of using the extensibility mechanisms in > > those protocols' headers. The improved relation of HL7 to process > > choreography will be useful too, as currently the concepts > of 'trigger > > events' and 'interactions' are as you imply not well aligned with > > wider facilities for process choreography in things like > > WS-Transactions and WS-Reliable messaging. > > > I recognise I'm not saying anything revolutionary, > > no, this is much more our (INM) direction now. But it's a > committee, so it's not unanimous. Shortly we'll start > collecting requirements, hopefully experts like yourself will > be able to contribute here. Agreed - it makes a huge difference when there is direct input from those with direct experience > > Grahame > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > > From joseph.2.waller at bt.com Wed Sep 20 10:16:42 2006 From: joseph.2.waller at bt.com (joseph.2.waller@bt.com) Date: Wed, 20 Sep 2006 10:16:42 +0100 Subject: [New-ITS] [New ITS] - Industry Tool Support Message-ID: <418B502A3861E242AFDED453F3D5B89C0FCA0F22@i2km99-ukbr.domain1.systemhost.net> Charlie, It sounds like a reasonable debate took place. Though personally I would still have voted the other way. It's better to allow all possible implementations to work with some imperfections around representing semantic dependency, rather than having schema that simply don't lend themselves to certain implementations. Alternatively, rather than representing transmissions as... [Attributes] [Values] You could represent it... [InteractionId] [Other Attributes] [Values] With the interaction Id repeated as an attribute. This would allow SOAPY implementers to use a separate header with less deconstruction of the standard HL7 representation. I guess this is the 'wrapperless world' debate that we presented a while ago. Regards, Joe -----Original Message----- From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] Sent: Tuesday, September 19, 2006 10:24 AM To: grahame at jivamedical.com; Waller,J,Joseph,JPGA3Y C Cc: new-its at lists.hl7.org.uk Subject: RE: [New-ITS] [New ITS] - Industry Tool Support Comments inline 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: 19 September 2006 00:55 > To: joseph.2.waller at bt.com > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] [New ITS] - Industry Tool Support > > > > joseph.2.waller at bt.com wrote: > > Graham, > > > > The two questions are actually kinda related. > > > > Question 1 - When you create a WSDL you include a > description of the > > interface as an xsd. This means that you generally include > an xsd for > > each message that makes up that service. HL7 Wrappers necessarily > > re-describe the Control Act in every message which means > that a WSDL > > validator (for example try XML Spy) will reject a WSDL as > the combined > > description is trying to describe the same complex type > more than once. > > so, is there a better way? > The problem is specifying the type of the inner content. > Charlie, why is it that we decided to embed the content when we > stitch, instead of doing it serially? I can't remember We did try to move to the headers paradigm in one of the later ballots of the XML Structures ( maybe Ballot 7 of 10) but it was voted down on the basis that it did not cleanly reflect the semantic dependancy, creating an arbitary fixed break between what belonged to the header and what belonged to the payload. By using containment the receiver could ignore the boundary and process the entire transmission as a single RIM graph. It is also possible to create schemas to recognise just the transport, or transport+controlAct wrappers, and have xsd:any for the content -- thus supporting a generic WSDL that passes the processing of the inner message on to some other process behind the interface. The HL7 publication has been structured to allow for such schemas to be generated -- just that no-one has had the resource/drive to get them produced. That is how the discussion went that carried the committee against the use of headers. The WSDL combination problem should be resolved now -- I have not checked it recently, but I know that there was a problem with multiple includes of the same file (which should be allowed) causing validation errors with some processors, and also with some unused types causing errors with some processors. Both issues could be addressed by either doing some tweeks to the schemas, or improving the processors, or both. CFH have taken their schema support in-house, and Lloyd has been maintianing the schema generator, so I am not as close to this as I once was... > > > Question 2 - This would not happen is the transmission > information was > > in a separate header. This would allow a WSDL to refer to a generic > > sending header for all messages. Further, this way that the HL7 > > message is necessarily wrapped in a wrapper rather than sat > alongside > > an associated header suggests that they were designed for a > protocol > > that does not use headers. i.e. putting an HL7 message directly in > > HTTP rather than inside SOAP or any SOAP related protocol such as > > ebXML or WS-Reliable Messaging. > > > > If InM are revisiting the transmission content I think it > is important > > that they make the model a) more flexible with more easily > separatable > > transmission information b) contain extensibility elements > or - if the > > transmission information is more seperated - at least allow the > > profiles to suggest ways of using the extensibility mechanisms in > > those protocols' headers. The improved relation of HL7 to process > > choreography will be useful too, as currently the concepts > of 'trigger > > events' and 'interactions' are as you imply not well aligned with > > wider facilities for process choreography in things like > > WS-Transactions and WS-Reliable messaging. > > > I recognise I'm not saying anything revolutionary, > > no, this is much more our (INM) direction now. But it's a committee, > so it's not unanimous. Shortly we'll start collecting requirements, > hopefully experts like yourself will be able to contribute here. Agreed - it makes a huge difference when there is direct input from those with direct experience > > Grahame > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > > From Charlie at ramseysystems.co.uk Wed Sep 20 11:37:51 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Wed, 20 Sep 2006 11:37:51 +0100 Subject: [New-ITS] [New ITS] - Industry Tool Support Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FCFD@ramseysc1420.RamseyNet.local> Joe That is why we need you to remain engaged as the debate is revisited in the light of experience five years on -- and I think that both experience and shifts in the underlying technology make it easier to spot where the separations should be -- as INM develop the new transport models I expect them/us to come up with something closer to the SOAP paradigm. It seems likely that we will get another 7 years of use out of the new specifications, so it is important to feed into them effectively and efficiently, and I see your "wrapperless world" presentation as a valuable bit of evidence to contribute 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: joseph.2.waller at bt.com [mailto:joseph.2.waller at bt.com] > Sent: 20 September 2006 10:17 > To: Charlie McCay; grahame at jivamedical.com > Cc: new-its at lists.hl7.org.uk > Subject: RE: [New-ITS] [New ITS] - Industry Tool Support > > Charlie, > > It sounds like a reasonable debate took place. Though > personally I would still have voted the other way. It's > better to allow all possible implementations to work with > some imperfections around representing semantic dependency, > rather than having schema that simply don't lend themselves > to certain implementations. > > Alternatively, rather than representing transmissions as... > > > [Attributes] > > [Values] > > > You could represent it... > > > > [InteractionId] > [Other Attributes] > > [Values] > > > With the interaction Id repeated as an attribute. This would > allow SOAPY implementers to use a separate header with less > deconstruction of the standard HL7 representation. I guess > this is the 'wrapperless world' > debate that we presented a while ago. > > Regards, > > Joe > > > > -----Original Message----- > From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk] > Sent: Tuesday, September 19, 2006 10:24 AM > To: grahame at jivamedical.com; Waller,J,Joseph,JPGA3Y C > Cc: new-its at lists.hl7.org.uk > Subject: RE: [New-ITS] [New ITS] - Industry Tool Support > > > Comments inline > > 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: 19 September 2006 00:55 > > To: joseph.2.waller at bt.com > > Cc: new-its at lists.hl7.org.uk > > Subject: Re: [New-ITS] [New ITS] - Industry Tool Support > > > > > > > > joseph.2.waller at bt.com wrote: > > > Graham, > > > > > > The two questions are actually kinda related. > > > > > > Question 1 - When you create a WSDL you include a > > description of the > > > interface as an xsd. This means that you generally include > > an xsd for > > > each message that makes up that service. HL7 Wrappers necessarily > > > re-describe the Control Act in every message which means > > that a WSDL > > > validator (for example try XML Spy) will reject a WSDL as > > the combined > > > description is trying to describe the same complex type > > more than once. > > > > so, is there a better way? > > The problem is specifying the type of the inner content. > > Charlie, why is it that we decided to embed the content when we > > stitch, instead of doing it serially? I can't remember > > We did try to move to the headers paradigm in one of the later ballots > of the XML Structures ( maybe Ballot 7 of 10) but it was voted down on > the basis that it did not cleanly reflect the semantic dependancy, > creating an arbitary fixed break between what belonged to the > header and > what belonged to the payload. By using containment the receiver could > ignore the boundary and process the entire transmission as a > single RIM > graph. It is also possible to create schemas to recognise just the > transport, or transport+controlAct wrappers, and have xsd:any for the > content -- thus supporting a generic WSDL that passes the > processing of > the inner message on to some other process behind the interface. The > HL7 publication has been structured to allow for such schemas to be > generated -- just that no-one has had the resource/drive to get them > produced. That is how the discussion went that carried the committee > against the use of headers. > > The WSDL combination problem should be resolved now -- I have not > checked it recently, but I know that there was a problem with multiple > includes of the same file (which should be allowed) causing validation > errors with some processors, and also with some unused types causing > errors with some processors. Both issues could be addressed by either > doing some tweeks to the schemas, or improving the > processors, or both. > CFH have taken their schema support in-house, and Lloyd has been > maintianing the schema generator, so I am not as close to > this as I once > was... > > > > > > > Question 2 - This would not happen is the transmission > > information was > > > in a separate header. This would allow a WSDL to refer to > a generic > > > sending header for all messages. Further, this way that the HL7 > > > message is necessarily wrapped in a wrapper rather than sat > > alongside > > > an associated header suggests that they were designed for a > > protocol > > > that does not use headers. i.e. putting an HL7 message > directly in > > > HTTP rather than inside SOAP or any SOAP related protocol such as > > > ebXML or WS-Reliable Messaging. > > > > > > If InM are revisiting the transmission content I think it > > is important > > > that they make the model a) more flexible with more easily > > separatable > > > transmission information b) contain extensibility elements > > or - if the > > > transmission information is more seperated - at least allow the > > > profiles to suggest ways of using the extensibility mechanisms in > > > those protocols' headers. The improved relation of HL7 to process > > > choreography will be useful too, as currently the concepts > > of 'trigger > > > events' and 'interactions' are as you imply not well aligned with > > > wider facilities for process choreography in things like > > > WS-Transactions and WS-Reliable messaging. > > > > > I recognise I'm not saying anything revolutionary, > > > > no, this is much more our (INM) direction now. But it's a > committee, > > so it's not unanimous. Shortly we'll start collecting requirements, > > hopefully experts like yourself will be able to contribute here. > > Agreed - it makes a huge difference when there is direct input from > those with direct experience > > > > > Grahame > > > > _______________________________________________ > > 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 Sep 20 13:38:14 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 20 Sep 2006 22:38:14 +1000 Subject: [New-ITS] [New ITS] - Industry Tool Support In-Reply-To: <418B502A3861E242AFDED453F3D5B89C0FCA0F22@i2km99-ukbr.domain1.systemhost.net> References: <418B502A3861E242AFDED453F3D5B89C0FCA0F22@i2km99-ukbr.domain1.systemhost.net> Message-ID: <45113636.4090202@kestral.com.au> > Alternatively, rather than representing transmissions as... > > > [Attributes] > > [Values] > > > You could represent it... > > > > [InteractionId] > [Other Attributes] > > [Values] > > > With the interaction Id repeated as an attribute. This would allow SOAPY > implementers to use a separate header with less deconstruction of the > standard HL7 representation. does it really make much difference? It has a deck-chairs-on-titanic feel about it me. Given the current wire format - the RIMness of it has a strong appeal - could we do schemas that worked for code re-use? Alternatively, in the new ITS, how should it be done? Grahame From Laura.Sato at cfh.nhs.uk Wed Sep 20 14:42:34 2006 From: Laura.Sato at cfh.nhs.uk (Sato Laura) Date: Wed, 20 Sep 2006 14:42:34 +0100 Subject: [New-ITS] highlights from the WGM Message-ID: <1A3D105C334EAE49BDDD93D8767573F504558B4D@EXCHAQ2.nhsia.nhs.uk> All, An informal de-brief with some highlights re the new ITS discussions at the Boca Raton HL7 WGM, for those who weren't there (Grahame, Charlie or others, please feel free to correct or enhance this 'report'): * MnM session 1 - Interestingly, after a review of most of the content in the ITS paper, a straw poll at the end of the session indicated that no one in the room (with 40-odd people) preferred to stick with the current XML ITS (no change). The room was divided, however, between those who wanted only one standard serialisation based on the RIM and those who wanted an option between two 'levels' of standard serialisation (one RIM-based, plus one which is more domain-specific, determined by the relevant technical committee) as long as it was possible to cleanly transform between the two. The latter option was suggested by Lloyd McKenzie. Personally, I don't think the issues between having one or an option between two serialisations had been explored fully enough to take the split between these straw vote opinions too seriously, BUT, I think it is significant that no one in the room was interested in maintaining the status quo (and also that everyone seemed to see a benefit to a more stable and generic serialisation, even if more abstract). The use of specific or local XUMs in mapping from V3 to local data stores was also noted (i.e. the use of XUMs beyond serialisation). * MnM session 2 - Grahame proposed that ADL be used to constrain V3 data types. It was agreed that it would be worthwhile to investigate and further clarify the proposed use of ADL in V3. * InM - Grahame was (literally) applauded for his work on the new ITS. It was noted that some elements within the ITS paper would be improvements for any ITS (i.e. not specific to XML / UML). Also, the data types change proposals were reviewed, but no decisions were made - Grahame said he would release the data types paper to the international lists (this had not been done prior to the WGM). Grahame noted that the intent of the new ITS was to provide at least one V3 model and schema upon which implementers can 'hang their hats' as a true implementation model. One person further observed that the use of UML and having explicit implementation modelling would be a great improvement from the current situation, where the only thing anyone could 'hang a hat' on is in a 'secret language', the MIF. * HL7 Board - a brief update on the investigation was given to the Board. A key point that the presentation team tried to stress was that V3 products would be much more implementation-friendly if specifications, example applications, and test packs were all developed and released in parallel. One Board member, Dan Russler, expressed appreciation for the ITS investigation's approach and indicated that his organisation, Oracle, also had experimental work they would like to share with us. We reported that the next steps for the new ITS were to test the ideas, hopefully with the help of HL7 / UK members and NPfIT suppliers. I'd also like to take this opportunity to thank Grahame for his superlative technical leadership on this work, on behalf of NHS CFH. Still lots of work to do, but I was very impressed by the level of acceptance the proposals received in MnM and InM in their first presentation, and I think this was due to the thoroughness of the analysis and Grahame's leadership in the discussions. 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 Please note on the 9th October 2006 my email address will change to laura.sato at nhs.net 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/20060920/5c28c7c4/attachment-0001.htm From Kenneth.Lunn at cfh.nhs.uk Thu Sep 21 09:08:53 2006 From: Kenneth.Lunn at cfh.nhs.uk (Lunn Kenneth) Date: Thu, 21 Sep 2006 09:08:53 +0100 Subject: [New-ITS] highlights from the WGM Message-ID: <437C33FAECC7DC41A1AD897B989C233B03C2F8A1@exchpe.nhsia.nhs.uk> Just to say that it was an excellent week. There is much left to do, but we have made great strides towards a better and more implementable standard. Thanks to all. Regards, Ken Tel +44 0113 280 6519, Mobile: +44 (0)7766 076863 ________________________________ From: Sato Laura Sent: 20 September 2006 14:43 To: new-its at lists.hl7.org.uk Cc: Lunn Kenneth Subject: highlights from the WGM All, An informal de-brief with some highlights re the new ITS discussions at the Boca Raton HL7 WGM, for those who weren't there (Grahame, Charlie or others, please feel free to correct or enhance this 'report'): * MnM session 1 - Interestingly, after a review of most of the content in the ITS paper, a straw poll at the end of the session indicated that no one in the room (with 40-odd people) preferred to stick with the current XML ITS (no change). The room was divided, however, between those who wanted only one standard serialisation based on the RIM and those who wanted an option between two 'levels' of standard serialisation (one RIM-based, plus one which is more domain-specific, determined by the relevant technical committee) as long as it was possible to cleanly transform between the two. The latter option was suggested by Lloyd McKenzie. Personally, I don't think the issues between having one or an option between two serialisations had been explored fully enough to take the split between these straw vote opinions too seriously, BUT, I think it is significant that no one in the room was interested in maintaining the status quo (and also that everyone seemed to see a benefit to a more stable and generic serialisation, even if more abstract). The use of specific or local XUMs in mapping from V3 to local data stores was also noted (i.e. the use of XUMs beyond serialisation). * MnM session 2 - Grahame proposed that ADL be used to constrain V3 data types. It was agreed that it would be worthwhile to investigate and further clarify the proposed use of ADL in V3. * InM - Grahame was (literally) applauded for his work on the new ITS. It was noted that some elements within the ITS paper would be improvements for any ITS (i.e. not specific to XML / UML). Also, the data types change proposals were reviewed, but no decisions were made - Grahame said he would release the data types paper to the international lists (this had not been done prior to the WGM). Grahame noted that the intent of the new ITS was to provide at least one V3 model and schema upon which implementers can 'hang their hats' as a true implementation model. One person further observed that the use of UML and having explicit implementation modelling would be a great improvement from the current situation, where the only thing anyone could 'hang a hat' on is in a 'secret language', the MIF. * HL7 Board - a brief update on the investigation was given to the Board. A key point that the presentation team tried to stress was that V3 products would be much more implementation-friendly if specifications, example applications, and test packs were all developed and released in parallel. One Board member, Dan Russler, expressed appreciation for the ITS investigation's approach and indicated that his organisation, Oracle, also had experimental work they would like to share with us. We reported that the next steps for the new ITS were to test the ideas, hopefully with the help of HL7 / UK members and NPfIT suppliers. I'd also like to take this opportunity to thank Grahame for his superlative technical leadership on this work, on behalf of NHS CFH. Still lots of work to do, but I was very impressed by the level of acceptance the proposals received in MnM and InM in their first presentation, and I think this was due to the thoroughness of the analysis and Grahame's leadership in the discussions. 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 Please note on the 9th October 2006 my email address will change to laura.sato at nhs.net 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/20060921/c87ed81c/attachment.htm