Re: [COAS-List] Action item from Denver

["R.M.Dixon" <R.M.Dixon@dcs.hull.ac.uk>]

> I have read it and have a few comments and questions.  

Me too.  I agree there are similarities with other models - actually, the 
GEHR project produced an ASN.1 exchange format and I suspect EHCR-SupA 
may do so too.

> Does the Related Surface Forms (RSF) show up in LQS?  At first I thought
> it was the Systemizations but then saw they are covered under
> SemanticLinks (I think?).  RSF don't look like Presentations either
> since the original concept and the RSF each have presentations.

I think they are Presentations.  The BaseCoded corresponds to 
QualifiedCode with text - actually it corresponds very much to the 
EHCR-SupA Term_Ref and the arguments for each of the attributes being in 
there are much the same as we used.

> The choices for type Value are similar to those in DICOM SR.  I used
> both lists (and GEHR and Sunquest model) to create a complete list of
> observation value types in some IDL yesterday.  I plan to get this out
> on the mail list soon (at least before next Tuesday's concall).  Do we
> need a dateTime as a separate type?  Chuck and I had it as one of the
> main attributes of all observations.  Does the dateTime have a special
> meaning or can it be used for times on other other things (like when a
> decision was made or when something was entered as opposed to when an
> observation was made)?

I see no reason not to use dateTime anywhere necessary.
 
> The Attribute type has some interesting fields - negation, numericOp,
> uncertainty, machineProb, userStatedProb, modifier, units, precision.  I
> assume 'negation' deals mainly with a Value of type 'coded' and
> 'numericOp' deals with numerical types ('decimal', 'long1', 'long2').  I
> believe the uncertainty/probability are important but I'm not sure what
> the difference is.  I believe 'modifier' will be part of the name/value
> pairs and/or a list of QualifiedCodes.  'units' of course will be dealt
> with for numerical types.  The 'precision' concept also came up in
> Richard's model for measurement quantities.  I'm not sure how it might
> relate to accuracy in Ricahrd's model.

I agree there are some interesting attributes!  Negation is dealt with 2 
ways in SupA - for text/coded values and in conjunction with the 
numericOp to imply ranges - I have to say I think SupA models these better.

The other ranges expressed here are also covered in GEHR/SupA.

I too am unclear what the distinction between uncertainty and
userstatedprob is.  MachineProb is, IMHO, a property of the machine and
not of the value recorded and as such is not an attribute of the value. (I
have quite a few latest views on this aspect of measurements if anyone
want to see them when I get back) Precision is (should) refer to the
precision with which the value was recorded (which may not be the same as
that with which the machine yields them - again a property of the machine
NOT the recorded value).  It is not the same as accuracy which expresses
how close the recorded value is likely to be to the true value.  For
example, if the true value were 2.45, a recorded value might be 2.1
recorded with a precision of 1 decimal place but accurate to +/- 1.0. 
Again we are talking about the accuracy of the recorded value, not of the
machine (or other data source). 

I don't think I understand the modifier
attribute and my views on what to do with units are already known. 

The area of 'not the type that was expected' is, IMHO another ball game 
all together.  We are now getting into application, enterprise and domain 
models, i.e. what the application, users or model of care being used 
might expect or want to see as appropriate types.  This is, IMHO, outside 
the scope of both the health care record model and of COAS.

> I presume EventActionSequence is out of scope for what we are doing?

Probably - I need to go through this in more detail.

> BaseObservation has a value (obsValue) and can contain a set of other
> observations (via commonMods and obsMods).  At this week's conference
> call Richard indicated the GEHR and ECHR-SupA always have them
> separate.  The expanded model we discussed in Denver also had them
> separate.  On the other hand the BaseEvent is almost identical to
> BaseObservation except it does not have a value and it contains EITHER a
> set of other BaseEvents OR a set of BaseObservations.  The BaseEvent
> seems to be similar to the GEHR 'Observation' and the BaseObservation
> seems to be similar to the GEHR Health_Record_Item with the exception
> that the Health_Record_Item does not recurse.

Agreed (I think!).

> Another thing the Event Model has is the ability to define specific
> structures for the events and observations.  This is similar to using
> DTDs to define valid XML documents.  We have not discussed how to do
> this for COAS except it was remarked that RDF should be used.
> 

> Can anyone more knowledgable with the model clear up any of these
> issues.
> 
> 
> Tim

I haven't had chance to read the rest of the paper in depth yet (it's now 
2am here!), but it seems to me to be (a) similar, as you say, to other 
models yet (b) yet another go at producing an information model for EHCR 
data.  I think there are some issues in it which are, IMHO, muddied. 

My view is, as it always has been, that ASN.1 (like IDL and others) is a 
useful way of expressing the structure of the data for a specific purpose 
(be that data exchange or interoperability interfaces etc).  However, it 
is not the best way to express a model and should be a bi-product of the 
model, not a substitute for it.  Therefore I would like to see/extract 
the proposed information model from this ASN.1 and comment on that, 
rather than how it might be expressed in ASN.1.  That said, as far as I 
can tell, almost all the parts of the underlying model there are covered 
by SupA and, IMHO, in a better way.

I would be happy to discuss this further, but I am away on holiday in 
less than 24 hours so my further views will have to wait until I return.

I hope this has been of some help, folks.

Best regards,
Richard