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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
