Dear all,
the Data Types RM document I put up yesterday was damaged, and has been replaced.
See http://www.deepthought.com.au/health/openEHR/data_types_1_5_2.pdf
- thomas beale
Tom
TBD_2: The language translations should be new versions from my point of
view and should not be transmitted unless they are persistent transactions
and have become the primary data source. DV_CODED_TERM would not be
translated anyway if others agree with no rubrics in DV_CODED_TERM - so this
should enable translations to remain primary on each occasion.
TBD_3: DV_TEXT.Value needs to be unicode for languages that require
unicode - this is a certain requirement.
TBD_5: The idea of statistical reference was that a variety of normals could
be used. I am not sure how to proceed here except that normal ranges will
usually be given without indication of their statistical meaning.
TBD_6: I do not think that this is sensible as there are a huge variety and
they can be expressed in the text string as you have done in the TBD.
Ordinals are really the standard in urinalysis and the fact that a provider
might show the ranges of each ordinal in their product is not so important -
if we move to numeric then the data value can change to a range for example.
TBD_7: I am not sure where the property names come from - I thought it was
part of the ISO standard?? Otherwise, there is a very comprehensive list in
HL7 that I think has too many - but we could reference that??
TBD_8: OK but there are many others - numbers of Red blood cells per cL of
blood, pure ratios 1:128....
TBD_9: Yes, how are we to do this - probably needs to be built in - Does the
Eiffel Library have one?
TBD_14 and 15: I think that we need to consider this. I would propose that
our URI is the best way to have a link and the idea of references is the way
to go. I am not sure that we need this - the 'In response to' probably
should be archetyped rather than be a link value - ?? ideas.
Cheers, Sam
Sam Heard wrote:
Tom
TBD_2: The language translations should be new versions from my point of
view and should not be transmitted unless they are persistent transactions
and have become the primary data source. DV_CODED_TERM would not be
translated anyway if others agree with no rubrics in DV_CODED_TERM - so this
should enable translations to remain primary on each occasion.
David Lloyd brought up the scenario where a brazilian doctor (we always use Brazilian's don't we - it's because we're all envious of their lifestyle;-) write narrative in portuguese but codes using english because that's all she's got available. Does this kind of thing ever happen? If it does, it means that there are two languages inside one Transaction...
TBD_3: DV_TEXT.Value needs to be unicode for languages that require
unicode - this is a certain requirement.
I think it is time to put this in.
TBD_5: The idea of statistical reference was that a variety of normals could
be used. I am not sure how to proceed here except that normal ranges will
usually be given without indication of their statistical meaning.TBD_6: I do not think that this is sensible as there are a huge variety and
they can be expressed in the text string as you have done in the TBD.
Ordinals are really the standard in urinalysis and the fact that a provider
might show the ranges of each ordinal in their product is not so important -
if we move to numeric then the data value can change to a range for example.
What if two pathology labs have different ranges both mapped to "+", "++" etc? If we don't have the association of ranges, then that info is lost in the record. It could be modelled fairly easily as an optional DV_INTERVAL<DV_QUANTITY> in DV_ORDINAL.
TBD_7: I am not sure where the property names come from - I thought it was
part of the ISO standard?? Otherwise, there is a very comprehensive list in
HL7 that I think has too many - but we could reference that??
the standards provide property names for base terms, so UCUM has brought together these names for nearly every unit under the sun. However, the "property" here is the property of combined units, e.g. "m.s^-2", where the property is "acceleration", or "kg/m^2", which is "pressure". I don't know if there are any lists of these terms and their correspondences with combined units - anyone?
TBD_8: OK but there are many others - numbers of Red blood cells per cL of
blood, pure ratios 1:128....
so what's the solution here?
TBD_9: Yes, how are we to do this - probably needs to be built in - Does the
Eiffel Library have one?
that's not the point - the point is to identify an algorithm. I have a reference for D. A. Hatcher's algorithms for converting across calendars and to and from a "computational calendar" - this was published in 1986, and is probably the definitive way to do this sort of thing.
Which reminds me - we don't currently store the name of the calendar in dates, and we probably should, to ensure the other major calendars such as Islamic, Baha'i, Coptic etc can be natively represented in openEHR data (else we are forcing them to always convert to and from Gregorian (western christian) or Julian (eastern orthodox)...
- thomas beale
Yep.
There are two.
But one relates to the language of the text and the other to an indicated
coding system. I don't expect that the English version and the translated
Portugese one will ever have the same unique identiyer, I may hope?
Gerard
-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
+31 252 544896
+31 654 792800