# Data Types RM document replaced

**URL:** https://discourse.openehr.org/t/data-types-rm-document-replaced/15682
**Category:** Technical (archive)
**Created:** [15 August 2002 23:26 UTC](https://discourse.openehr.org/t/data-types-rm-document-replaced/15682 "2002-08-15T23:26:06Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [15 August 2002 23:26 UTC](https://discourse.openehr.org/t/data-types-rm-document-replaced/15682/1 "2002-08-15T23:26:06Z")

</div>

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](http://www.deepthought.com.au/health/openEHR/data_types_1_5_2.pdf)

- thomas beale

---

<div class="post-metadata">

### Author: ![Sam](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@Sam](https://discourse.openehr.org/u/Sam)
#### Post date: [20 August 2002 00:54 UTC](https://discourse.openehr.org/t/data-types-rm-document-replaced/15682/2 "2002-08-20T00:54:28Z")

</div>

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

---

<div class="post-metadata">

### Author: ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [20 August 2002 02:13 UTC](https://discourse.openehr.org/t/data-types-rm-document-replaced/15682/3 "2002-08-20T02:13:38Z")

</div>

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

---

<div class="post-metadata">

### Author: ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)
#### Post date: [29 August 2002 22:57 UTC](https://discourse.openehr.org/t/data-types-rm-document-replaced/15682/4 "2002-08-29T22:57:42Z")

</div>

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
