[New-ITS] So, what's a XUM ?

joseph.2.waller@bt.com joseph.2.waller at bt.com
Mon Sep 4 17:10:31 BST 2006


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




More information about the New-ITS mailing list