[Gnumed-devel] [Fwd: Re: [ avoid spammers ] The *other* HealthConnect]

[syan tan]

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: [GPCG_TALK] The *other* HealthConnect
>
>
>
>
> Date: 
>
> Thu, 23 Nov 2006 00:47:19 +1100
>
>
>
>
> > This is a definition recursion, so that DV_INTERVAL is defined
> > as being composed by some DV_ORDERED values, but DV_ORDERED is composed
> > by some DV_INTERVAL values, so neither is defined.
>
> I really think you need to take a look at some modern OO
> languages with more powerful type systems than you may
> be used to in C. I can assure you that mutually recursive
> type definitions are allowed.
>
> > This is easier to see if you have recently worked through writing a
> > simple calculator program , as through the second chapter of Aho's
> > Compiler , or read the first part of chapter 4 of this book about syntax
> > analysis.
>
> Before launching into arguments like this you might like to mentally
> make the assumption that IT people may indeed have taken a compiler
> course and read the dragon book (and indeed written compilers a
> lot more complex than a calculator). I also wouldn't
> base too much of my reasoning on a book written in 1986
> (as great a book as it is - times have changed).
>
> >   You would also recognize that openehr seems almost a pale apparation
> > of a subject  taught to all second year computer science undergrads
>
> I have no idea what this means..
>
> Andrew
> _______________________________________________
> Gpcg_talk mailing list
> address@hidden
> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: [GPCG_TALK] The *other* HealthConnect
>
>
>
>
> Date: 
>
> Thu, 23 Nov 2006 00:38:57 +1100
>
>
>
>
> > Maybe it's a good thing openehr hasn't been proliferated yet,
> > otherwise we'd be stuck with some basic flaws.
>
> I think it's broad statements like this that tend to put peoples
> noses out of joint - this morning you were decrying their lack of
> professionalism because they hadn't done the basics of running
> their schemas through a validator - only for it to be your translation
> that was wrong. Now, because you disagree with a one
> design decision (and you have presented an alternative that
> is for all intensive purposes identical, only with fields moved
> around), you are claiming that the whole effort has some
> basic flaws. My impression of the openehr group is that they
> are more than willing that accept good constructive
> criticism - if you feel you have some insights into the base
> data types you should feed it back to them.
>
> Andrew
> _______________________________________________
> Gpcg_talk mailing list
> address@hidden
> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: [GPCG_TALK] The *other* HealthConnect
>
>
>
>
> Date: 
>
> Wed, 22 Nov 2006 23:57:17 +1100
>
>
>
>
> looking at it again, I missed the minOccurs=0 when translating it
> to a simpler grammar form. Need a marker for optional.
>  Not quite sure why DV_ORDERED has all its extra fields as optional,
> since you could convert any DV_VALUE to DV_ORDERED type, and the type
> would be meaningless ( it's becomes labelled as DV_ORDERED, but doesn't
> contain any information to show why it is ordered). It really should be
> DV_RANGED , as ordered usually means that instances can be sorted into
> an order,  and DV_QUANTIFIED  is a misnomer as well, as it has accuracy
> fields, and being accurate and quantified don't normally imply each
> other. Maybe DV_ACCURACY_GIVEN , and remove the minOccurs ? In fact,
> all the types where the extra fields are all minOccurs =0 shouldn't be
> in an inheritance heirarchy, they should be optional components of
> minOccurs = 0, with mandatory values, in the classes that inherit from
> them currently. e.g. the heirarchy should be refactored to
> DV_ABSTRACT  <--  DV_POSSIBLY_RANGED_POSSIBLY_ACCURACY_GIVEN
>                         - ACCURACY minOccurs=0
>                         - RANGES  minOccurs =0
>
>                        <-- DV_QUANTITY
>                        <-- DV_COUNT
>
> Maybe it's a good thing openehr hasn't been proliferated yet,
> otherwise we'd be stuck with some basic flaws.
>
>
>
>
>
>   
> On Wed, 2006-11-22 at 12:30 +1100, Andrew Patterson wrote:
> > >         It seems obvious they did not run their xml translation
> > > through a verifier, which should have been easy.
> > 
> > Syan, computer people have been using mutually
> > recursive data types for many years. I'm not sure what
> > the problem is here? You are correct that if the
> > mutual type reference elements were compulsory, then it
> > would be impossible to construct a serialized
> > instance - but the references are all optional and
> > hence the recursion stops when we have no more
> > data to fill in...
> > 
> > attached is an (meaningless) instance that validates against
> > this xsd using xerces
> > 
> > Andrew
> > _______________________________________________
> > Gpcg_talk mailing list
> > address@hidden
> > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>
> _______________________________________________
> Gpcg_talk mailing list
> address@hidden
> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: [GPCG_TALK] The *other* HealthConnect
>
>
>
>
> Date: 
>
> Wed, 22 Nov 2006 23:15:07 +1100
>
>
>
>
> I think you are confusing optional value instances , with 
> mandatory definitions of some types being optionally used.
>  
> This is a definition recursion, so that DV_INTERVAL is defined
> as being composed by some DV_ORDERED values, but DV_ORDERED is composed
> by some DV_INTERVAL values, so neither is defined. If neither are
> defined, you can't optionally use them.
>
> Recursion only stops if you have an alternate possibility that
> is not recursive , but the definitions of DV_ORDERED and DV_INTERVAL
> only make sense if the components defined as each other are mandatory
> and present.
>  To be specific, you would expect that lower and upper values of
> DV_INTERVAL to be present in order to define "a interval", and
> DV_ORDERED would be expected to have a mandatory presence of
> normal_range, and even if it didn't , at least one reference range is
> present to have it mean anything, and reference range is also defined as
> having a range value which is also DV_INTERVAL type ( without it, a
> DV_ORDERED would have a "reference range",  which had a single value of
> "meaning" which is text , without giving a value for "range" , which is
> meaningless).
>
> This is easier to see if you have recently worked through writing a
> simple calculator program , as through the second chapter of Aho's
> Compiler , or read the first part of chapter 4 of this book about syntax
> analysis.
>   You would also recognize that openehr seems almost a pale apparation
> of a subject  taught to all second year computer science undergrads
> ( but not to poor old Grad Dips, sniff).  
> However, the main contribution of openehr, is that it tries to apply
> what it recognizes as computer science greatness (but not necessarily
> understands) , to the mundane but real world problem of electronic
> health record structure.
>   
> On Wed, 2006-11-22 at 12:30 +1100, Andrew Patterson wrote:
> > >         It seems obvious they did not run their xml translation
> > > through a verifier, which should have been easy.
> > 
> > Syan, computer people have been using mutually
> > recursive data types for many years. I'm not sure what
> > the problem is here? You are correct that if the
> > mutual type reference elements were compulsory, then it
> > would be impossible to construct a serialized
> > instance - but the references are all optional and
> > hence the recursion stops when we have no more
> > data to fill in...
> > 
> > attached is an (meaningless) instance that validates against
> > this xsd using xerces
> > 
> > Andrew
> > _______________________________________________
> > Gpcg_talk mailing list
> > address@hidden
> > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>
> _______________________________________________
> Gpcg_talk mailing list
> address@hidden
> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>
>
> --- End Message ---

--- Begin Message --- Subject: Re: [GPCG_TALK] The *other* HealthConnect Date: Wed, 22 Nov 2006 12:30:39 +1100

        It seems obvious they did not run their xml translation
through a verifier, which should have been easy.

Syan, computer people have been using mutually
recursive data types for many years. I'm not sure what
the problem is here? You are correct that if the
mutual type reference elements were compulsory, then it
would be impossible to construct a serialized
instance - but the references are all optional and
hence the recursion stops when we have no more
data to fill in...

attached is an (meaningless) instance that validates against
this xsd using xerces

Andrew

sample2.xml
Description: Text Data

_______________________________________________
Gpcg_talk mailing list
address@hidden
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: [GPCG_TALK] The *other* HealthConnect
>
>
>
>
> Date: 
>
> Wed, 22 Nov 2006 11:02:45 +1100
>
>
>
>
> they have a few inconsistencies on their web site.
> http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/BaseTypes.xsd
>
> this is difficult to see as it is not ordered bottom-up
>
> this is a simpler translation , which shows that there is a circular
> definition of DV_INTERVAL and DV_ORDERED, which makes them both
> undefined. 
>         It seems obvious they did not run their xml translation
> through a verifier, which should have been easy.
>
> #Basic Types
> # grammar  :: is "has type of",  (x) is "inherits from x", * is "0 or
> more"
>
>         DATA_VALUE :: xs:sequence
>                 
>
>         DV_BOOLEAN
>                 value  :: xs:boolean
>
>         DV_INTERVAL (DATA_VALUE)
>                 lower   :: DV_ORDERED
>                 upper   :: DV_ORDERED
>                 lower_included :: xs:boolean
>                 upper_included :: xs:boolean
>                 lower_unbounded :: xs:boolean
>                 upper_unbounded :: xs:boolean
>
>         REFERENCE_RANGE
>                  meaning :: DV_TEXT
>                  range   :: DV_INTERVAL
>                 
>         DV_ORDERED
>                 normal_range :: DV_INTERVAL
>                 reference_ranges :: REFERENCE_RANGE *
>                 is_normal :: xs:boolean
>         
>         DV_ORDINAL (DV_ORDERED)
>                 value :: xs::integer
>                 symbol :: DV_TEXT
>
>         DV_QUANTIFIED (DV_ORDERED):
>                 accuracy :: xs:float
>                 accuracy_is_percent :: cs:boolean
>         
> # dv_count and dv_quantity are both dv_quantified: 
> #    count is int, quantity is float    
>
>         DV_COUNT (DV_QUANTIFIED):
>                 magnitude :: xs:unsignedLong
>
>         
>         DV_QUANTITY (DV_QUANTIFIED)
>                 magnitude :: xs:double
>                 units     :: xs:string
>                 precision :: xs:integer
>
> # this is not a fraction , because dv_quantity is float not int
>         DV_QUANTITY_RATIO (DATA_VALUE)
>                 numerator :: DV_QUANTITY
>                 denominator :: DV_QUANTITY
>
> ....
>
>
>
> On Mon, 2006-11-20 at 15:59 +1100, Horst Herb wrote:
> > On Monday 20 November 2006 15:22, Ross Davey wrote:
> > > The shared electronic record implemented as a centralised clinical
> > > record was just one group's vision of how to make information on
> > > patients available to all practitioners who need it.  Maybe the holy
> > > grail; maybe not.
> > 
> > UK experience suggests it it probably not what we want or what would solve 
> > our 
> > problem.
> > 
> > Moot point in any case - Australia simply doesn't have the infrastructure to 
> > support any form of centralized (or other forms of real time data exchange) 
> > record keeping, and at the current rate of progress the necessary 
> > infrastructure will not eventuate  in the next few years either
> > 
> > OpenEHR has long ago solved the problem of merging records even in the 
> > richest 
> > health record systems- makes far more sense to have local repositories with 
> > the option of distribution, and record exchange on demand via 
> > store-and-forward mechanisms that would respond in real time if the 
> > infrastructure of the minute allows it (as SMTP does it anyway)
> > 
> > Horst
> > _______________________________________________
> > Gpcg_talk mailing list
> > address@hidden
> > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
> > 
>
> _______________________________________________
> Gpcg_talk mailing list
> address@hidden
> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>
>
> --- End Message ---

--- Begin Message --- Subject: Re: [GPCG_TALK] The *other* HealthConnect Date: Thu, 23 Nov 2006 04:50:50 +0800 look ,I'm not a lobbyist, I only criticize something to boost my flagging ego.
Just back to the topic of better design,  one of the concrete , may oversimplistic
advantages of having an object-oriented approach,  is that the you can move
a lot of the type testing code out into the class heirarchy / class interaction design.

Take for example the previous comment about DV_POSSIBLY_RANGED_POSSIBLY_ACCURATE ;
that is just better naming to warn programmers that they have to do type testing .

Let's say you want to do something like this:

you want to get a DV_ABSTRACT object,  give it to a GUI_FACTORY object,  and get
back a *viewer/editor* object for the DV_ABSTRACT object , so that the DV_ABSTRACT object
can be manipulated by users.
  
The DV_ABSTRACT object uses the Composite design pattern ,  and there is
something like DV_ENCOUNTER_DATA  that aggregates  the data items that occurred
in an encounter, contains  DV_ABSTRACT  objects, and is itself a DV_ABSTRACT object,
so now the GUI_FACTORY object can use recursive  container walking to create a complex gui object.

Now when DV_COUNT ( actually integer objects), and DV_QUANTIFIED ( actually double/float objects)
are encountered,  the GUI_FACTORY would have to do type testing on DV_COUNT and DV_QUANTIFIED
to see if  needs to especially add say a little box showing that the DV_COUNT object had accuracy information,
or had range information. 

You could use the Visitor pattern  and the Decorator pattern here  (  from  the  gang of  four , around 1995,  one of which is involved with  the  Eclipse project , around 2004 -2006).

Instead of DV_COUNT and DV_QUANTIFIED inheriting from DV_POSSIBLY_RANGED_POSSIBLY_ACCURACY_GIVEN,
which is just the same as the original design as inheriting from abstract DV_ORDERED, whose child is DV_QUANTIFIABLE,
but only explicit about the minOccurs=0 for all the extra data fields,   you can  have a  DV_ABSTRACT child  which
is DV_RANGED ( a renamed DV_ORDERED), which takes  a value field as DV_ABSTRACT , and *decorates* the
original object with range data , and similiarly DV_ACCURACY_GIVEN .   Then  within the
gui factory object,  it uses the visitor pattern to construct different gui  elements e.g.   

createGuiElementFor ( DV_ENCOUNTER_DATA)
createGuiElementFor ( DV_COUNT),
createGuiElementFor( DV_QUANTIFIED) 
createGuiElementFor( DV_ACCURACY_GIVEN)
createGuiElementFor(DV_RANGED) ( which calls createGuiElementFor on the value object of the DV_RANGED object, before attaching range display )  

then it just uses method overloading , and the type of the DV object passed in to the method createGuiElementFor(..) will determine what
kind of gui element is constructed.

I'm guessing that is one reason why the openehr people are doing it object-oriented, but they haven't focussed on the
"I need to design this to avoid type-testing "  objective to get a clearer design.



On Thu Nov 23 0:38 , 'Andrew Patterson' sent:

> Maybe it's a good thing openehr hasn't been proliferated yet,
> otherwise we'd be stuck with some basic flaws.

I think it's broad statements like this that tend to put peoples
noses out of joint - this morning you were decrying their lack of
professionalism because they hadn't done the basics of running
their schemas through a validator - only for it to be your translation
that was wrong. Now, because you disagree with a one
design decision (and you have presented an alternative that
is for all intensive purposes identical, only with fields moved
around), you are claiming that the whole effort has some
basic flaws. My impression of the openehr group is that they
are more than willing that accept good constructive
criticism - if you feel you have some insights into the base
data types you should feed it back to them.

Andrew
_______________________________________________
Gpcg_talk mailing list
address@hidden
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

_______________________________________________
Gpcg_talk mailing list
address@hidden
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

--- End Message ---