Unable to express an unit of measurements in UCUM syntax
Hi Tom It's a strange concept for sure. The real question here is whether UCUM and PQ/DV_QUANTITY are for real measurements, or whether they for quantitative notions. There's general agreement that things like "tablet" etc are not UCUM units - because they're not quantitative. Now we have a different issue - these are quantitative, but not real. I can see the grounds for keeping them out of UCUM. In addition, I'd have to recode my ucum library for this, and it's an odd challenge for such a strange notion. On the other hand, why not let scientists how measure things measure them how they want, as long as the units are meaningful - to them. Grahame On Fri, Apr 29, 2011 at 7:14 PM, Thomas Beale wrote: > > it is a pretty weird unit, since it is partway between 2-d and 3-d space, > and therefore partway between the concept of 'area' and that of 'volume'. So > whether it is acceptable depends on whether we think that such concepts are > meaningful in the activity we call 'measurement' in the physical world. > Probably there are weird units like this in quantum mechanics, or other > esoteric mathematical spaces, so then it comes down to scope of UCUM - > presumably not all of science, just physical measurement? > > Changing openEHR or HL7 to handle it probably would not be hard, but it > might open up a can of worms, and also just plain annoyances, by allowing > fractional dimensions (i.e. as soon as you start using floating point > numbers for values that are almost always integers, computers struggle to > get it right...). > > - thomas > > On 29/04/2011 01:48, Grahame Grieve wrote: > > Hi Leo > > Gunther says that these units are not proper units. > > http://www.xkaw.com/Education_Reference/Science_Mathematics.asp?id=2276318 > > There's a possible question of scope alignment here. It's kind of tantamount > to > saying that a measure like that is not a proper measurement. I don't think > I agree with that. > > To pursue the UCUM issue, you need to make at ticket at > http://www.unitsofmeasure.org/ > > I think that there's a tension here between the notion of purity from UCUMs > point of view, and the use of UCUM in the measurement data types (PQ in > HL7 v3 and DV_QUANTITY in openEHR - both have the same scope and the > same usage of UCUM) > > Also see http://www.unitsofmeasure.org/wiki/ProcedureDefinedUnits > > Grahame > > > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065
Unable to express an unit of measurements in UCUM syntax
This kind of scenario is very common and we need to establish some guidelines and governance about how to handle these sort of 'pseudo-units', so that vendors can get on with some kind of implementation while these sort of difficult and obscure issues are discussed. Am I correct in thinking that since 'units' is a string, there is no particular barrier to the use of a non-UCUM term? We obviously want to enforce UCUM use where-ever possible but this will not always be sensible or possible and we need to give developers alternatives (perhaps temporary) and a clear change request mechanism. e.g. As alternatives 1. Use the pseudo-unit in the unit attribute, as a qualified real 2. Use a qualified real and keep the name of the unit in the element name 'LV function factor (m2/kg3/m)' or whatever. Ian Dr Ian McNicoll office +44 (0)1536 414 994 +44 (0)2032 392 970 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org On 29 April 2011 12:27, Thomas Beale wrote: > > I think that we at least need to find out what the physical basis of this > unit is. I could not find any definitive reference online, only papers > reporting its use. Any cardiologists here? > > - thomas > > > On 29/04/2011 10:25, Grahame Grieve wrote: > > Hi Tom > > It's a strange concept for sure. The real question here is whether > UCUM and PQ/DV_QUANTITY are for real measurements, or > whether they for quantitative notions. > > There's general agreement that things like "tablet" etc are not > UCUM units - because they're not quantitative. Now we have a different > issue - these are quantitative, but not real. > > I can see the grounds for keeping them out of UCUM. In > addition, I'd have to recode my ucum library for this, and > it's an odd challenge for such a strange notion. > > On the other hand, why not let scientists how measure things > measure them how they want, as long as the units are meaningful > - to them. > > > * > * > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/4a45cf66/attachment.html>
Unable to express an unit of measurements in UCUM syntax
I think that we at least need to find out what the physical basis of this unit is. I could not find any definitive reference online, only papers reporting its use. Any cardiologists here? - thomas On 29/04/2011 10:25, Grahame Grieve wrote: > Hi Tom > > It's a strange concept for sure. The real question here is whether > UCUM and PQ/DV_QUANTITY are for real measurements, or > whether they for quantitative notions. > > There's general agreement that things like "tablet" etc are not > UCUM units - because they're not quantitative. Now we have a different > issue - these are quantitative, but not real. > > I can see the grounds for keeping them out of UCUM. In > addition, I'd have to recode my ucum library for this, and > it's an odd challenge for such a strange notion. > > On the other hand, why not let scientists how measure things > measure them how they want, as long as the units are meaningful > - to them. > * * -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/987d608b/attachment.html>
Reverse Relations
Op 29-04-11 03:03, Heath Frankel schreef: > > I agree with Thomas, the reverse relationships should be derived from > the forward relationships. The RM doesn't necessarily need to be > reflected in the persistence model. > Thanks Heath, this is indeed a pitfall, trying to reflect the RM. I sometimes fall into it too. > Having said that, we do have a fundamental issue regarding OBJECT_REF > with regard to using VERSIONED_OBJECT uid or VERSION uid, in some > cases it is desirable to use the former because you want the > relationship to exits even if the referenced object is revised, whilst > in other case this may not be safe practice. I think this issue > deserves some discussion and a Wiki page for the outcome. > A PartyRelationship can change in its details without change to the source and target-attribute. For example, the meaning of the Relation can change, a wife can become an ex-wife. Still the same target and source. As the specs are now: When this happens the target-party will need a new version because one of its attributes have changed (because the LocatableRef changed), and the PartyRelationship needs a new version, because its details changed. I think it is desirable that in a case like this, only the PartyRelationship need a new version, not the target-party, and if I am right, it is sufficient to use a PartyRef as ReverseRelation instead of a LocatableRef This idea is extra confirmed because it does not seem logically to write a new version of a PartyRelationship in case the source of the target change, because, in that case, the relation doesn't exist any more, I cannot imagine a situation in which there would be a reason to prolong the lifetime (write a new version) of a PartyRelationship when the relation finish to exist. But, I am not sure. Bert -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/7738699f/attachment.html>
openEHR artifact namespace identifiers
Source file class in a program language have names and in the cases of COM they have an ID such as a GUID. The issue here is related to the later, not the former. More than happy with a GUID, in fact our knowledge resource repository does exactly what David Moner proposed, it assigns a resource ID (GUID) and maintains a version tree ID. Really I don't see the difference between a GUID and OID, as you say elsewhere, they are just strings. It is just the process used to create the string that differs and when we start introducing governance with publishing organisations, having an OID root for the publishing organisation and an extension for each artefact generated by a repository system aligns so nicely with the OID approach I can't understand why we so easily blow this option off. Once we have a reliable UID of some kind we can generate URIs. The alternative of generating a composite UID from meta data sounds complicated, contentious, unreliable and frankly worse than the same kind of issues you have with OIDs. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Friday, 29 April 2011 2:16 AM To: openehr-technical at openehr.org Subject: Re: openEHR artifact namespace identifiers On 08/04/2011 01:49, Heath Frankel wrote: Thomas, Your proposed changes to the archetype Identifiers and governance actually aligns with the same management and inferencing requirements as OIDs, the only benefit left is the readability, but even that is becoming hard to do with the additional namespaces and delimiters. In addition, having meaningful IDs and deriving meaning from IDs is counter to what good practice in terminology identifier management. for atomic concepts a la SNOMED, meaningless identifiers make sense; for complex artefacts like programming language source files - of which archetypes are an example, they don't really - they just obscures meaning from developers. Meaningless identifiers of the Guid variety make sense for deployed versions of these artefacts - i.e. generated template OPTs, assemblies etc. Where identification really matters is a) in data and b) in deployed software artefacts that were generated from templates & archetypes. The future may well be to do as David Moner (I think, or maybe Diego, can't remember now) said - to create archetype meta-data attributes to carry the pieces of the id, and generate the strings that we currently use as ids when and as needed. Attaching Guids to source archetypes can also be done obviously, but I think for source artefacts, Oids provide little gain and a lot of pain. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/e86f9e97/attachment.html>
Reverse Relations
Thanks, Thomas, for your reply. >> The problem is that ReverseRelationships are a Set of LocatableRef. >> This means that the PartyRelationship has to be stored before it can >> be added to a party ReverseRelationship list. >> The PartyRelationship has to be stored because LocatableRef takes a >> ObjectVersionID as constructor-argument. > > I presume this is in the Java implementation, since constructors are > not defined in the openEHR specifications? Obviously using > constructors is not the only possibility, setter routines could also > be used. IN any case, creation of identifiers does not rely on > persistence; it should be knowable beforehand, so I would expect the > use of a constructor to be fine. It is true this is in a java-implementation. But the way to assign a ObjectVersionID to a version-able object in my code is to persist it, after which my code does some checks, also on versions, and then returns the ObjectVersionID. This can be re-coded, I could predict the ObjectVersionID, reserve it (protect it against other threads trying to do the same simultaneously), and first create the LocatableRef, then set it in the target-Party which needs the ReverseRelation and if no exceptions occur then persist the PartyRelationship. As you can see, this will be very complex code. The way I solved the problem now does also not deserve a prize in a beauty contest (dutch saying). I describe it to illustrate which problems this situation causes to me. I, first, persist the PartyRelationship, then try to assign it to the source and target, and if that fails, for example because the archetype of the source-Party does not allow that (or any) PartyRelationship to be assigned, than I need to remove the persisted PartyRelationship. Because my persistence-code does not have any removal (from persistence)-code, I have to assign the orphaned and persisted PartyRelationship as "deleted", which is not a nice solution, but does not put a (relatively) heavy load on my kernel-functionality. > > > I think a better solution is that PARTY simply does not contain > reverse relationships, because it is essentially solving a database > indexing problem, which could be better solved by maintaining index > objects and/or native indexes, depending on how the demographic model > persistence is implemented. This is a good idea, there shouldn't be any optimization attributes in the RM-specifications. It is always possible to retrieve ReverseRelationships at the moment of getting a Party from the persistence-layer. Thanks, this is the best solution, it really helps me further. > >> // >> I don't understand why that is, it seems a bad thing which causes >> extra complexity. >> More logically would seem to me to connect the UID of to the list >> ReverseRelationships in the target Party, instead of the ObjectVersionID. > > that would probably risk the reverse_relationships attribute getting > out of data quickly and containing wrong information, unless the > implementation meticulously checked whether the validity was always > maintained or not. I don't understand, my code always retrieves the latest version of a persisted object, when queried by UID. The version-functionality is not yet used in an API. But the storage is already prepared to use it in the future, so, there is code, and are tables and indexes already in use (data are stored), for when that API will come, (which will be within a year or so) -- This is another (but comes to mind) subject: For now, it is enough that in case the kernel has to show a complete situation from somewhere in the past, it is prepared and able to do so. I have no idea how an API using the versioning would look like. I haven't really thought about it much. What I can think of is that the kernel can act as a time-machine. For example: show me the complete database as it was on a specific moment in the past. For that, my kernel is able to do (theoretically) Are there any more API's described somewhere to use the versioning (object) features, I would like to read about it. > > I would be interested to know what other experience there is with this > attribute; my suspicion is that it should be deprecated. Regards Bert ------ next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/4b3715e4/attachment.html>
Unable to express an unit of measurements in UCUM syntax
Hi Leo Gunther says that these units are not proper units. http://www.xkaw.com/Education_Reference/Science_Mathematics.asp?id=2276318 There's a possible question of scope alignment here. It's kind of tantamount to saying that a measure like that is not a proper measurement. I don't think I agree with that. To pursue the UCUM issue, you need to make at ticket at http://www.unitsofmeasure.org/ I think that there's a tension here between the notion of purity from UCUMs point of view, and the use of UCUM in the measurement data types (PQ in HL7 v3 and DV_QUANTITY in openEHR - both have the same scope and the same usage of UCUM) Also see http://www.unitsofmeasure.org/wiki/ProcedureDefinedUnits Grahame On Fri, Apr 29, 2011 at 9:20 AM, Grahame Grieve wrote: > There's some question about whether such a funky unit is > a proper unit. It does look rather like a statistical imagination > to me, rather than an actual unit. > > I'm not sure where the right place to discuss this is. I'll let > you know when I find out. > > Grahame > > > On Fri, Apr 29, 2011 at 12:50 AM, Leonardo Moretti > wrote: >> >> Hi >> there are a lots of scientific publications treating the indexations of left >> ventricular mass (LVM). >> I can link some abstracts, but the whole PDF documents are not public: >> - http://www.nature.com/jhh/journal/v23/n11/full/jhh200916a.html >> - http://www.ncbi.nlm.nih.gov/pubmed/11729247 >> or here >> https://www.stanford.edu/group/ccm_echocardio/cgi-bin/mediawiki/index.php/Left_ventricle_wall_thickness >> >> It can be used to detect left ventricular hypertrophy. >> You can google "mass/height^2.7" to find more references. >> >> Thanks for your help. >> leo >> >> >> Grahame Grieve-3 wrote: >>> >>> Hi Leo >>> >>> Can you please provide some references to show the use of height^2.7? >>> >>> Grahame >>> >>> >>> On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo >>> wrote: In cardiology, left ventricular mass (LVM) is often indexed to better identify left ventricular hypertrophy. Possible indexations are: - LVM/BSA (body surface area) - LVM/height - LVM/height^2.7 The first and the latter are often used. The units of measurement of the latter is usually g/m2.7 [gram/(meter^2.7)]. In DV_QUANTITY, "units" attribute should be expressed in UCUM unit syntax. UCUM doesn't allow not integer exponent (see http://aurora.regenstrief.org/~ucum/ucum.html#section-Syntax-Rules), so I have the problem that I cannot express the units as g/m2.7. Any suggestion to solve this problem!? Best regards leo ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> >>> >>> >>> -- >>> - >>> http://www.healthintersections.com.au / >>> grahame at healthintersections.com.au / +61 411 867 065 >>> ___ >>> openEHR-technical mailing list >>> openEHR-technical at openehr.org >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/Unable-to-express-an-unit-of-measurements-in-UCUM-syntax-tp31494533p31497302.html >> Sent from the openehr-technical mailing list archive at Nabble.com. >> >> ___ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > > > > -- > - > http://www.healthintersections.com.au / > grahame at healthintersections.com.au / +61 411 867 065 > -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065
Reverse Relations
I agree with Thomas, the reverse relationships should be derived from the forward relationships. The RM doesn't necessarily need to be reflected in the persistence model. Having said that, we do have a fundamental issue regarding OBJECT_REF with regard to using VERSIONED_OBJECT uid or VERSION uid, in some cases it is desirable to use the former because you want the relationship to exits even if the referenced object is revised, whilst in other case this may not be safe practice. I think this issue deserves some discussion and a Wiki page for the outcome. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Thursday, 28 April 2011 11:49 PM To: openehr-technical at openehr.org Subject: Re: Reverse Relations Hi Bert, On 19/04/2011 11:54, Bert Verhees wrote: Hi, Excuse for the bit complex text below, I don't know how to say it more simple I have a small problem with the way ReverseRelationships are connected to Party in the Demographic RM. Maybe my problem is because of my misunderstanding. The problem is not only conceptual, but it also causes problems in coding (programming) the kernel. The problem is that ReverseRelationships are a Set of LocatableRef. This means that the PartyRelationship has to be stored before it can be added to a party ReverseRelationship list. The PartyRelationship has to be stored because LocatableRef takes a ObjectVersionID as constructor-argument. I presume this is in the Java implementation, since constructors are not defined in the openEHR specifications? Obviously using constructors is not the only possibility, setter routines could also be used. IN any case, creation of identifiers does not rely on persistence; it should be knowable beforehand, so I would expect the use of a constructor to be fine. The conceptual problem is that the ReverseRelationship in this way is defined as a version of a specific PartyRelationship. If the PartyRelationship changes, for example in its details, than the new version is not anymore connected to the target-Party, or this connection needs extra code to restore (replace the ObjectVersionID in the target-Party ReverseRelationship-set, maybe even create a new version of the PArty, because of a new version in another object, namely the PartyRelationship-object) the reverse_relationships attribute of PARTY is intended to contain a set of reverse pointers to PARTY_RELATIONSHIPs for which the PARTY is a 'target'. The first thing to note is that the attribute is optional, and you can ignore it if you want. If you use it, it should always contain the current list of PARTY_RELATIONSHIPs for which the PARTY is a 'target'. If any such relationship is changed, then the relevant PARTYs would have to be updated. The problem you point out is that if the change in the PARTY_RELATIONSHIP (taking it from version 3 to 4, let's say) doesn't affect a given PARTY, which is a target of version 3 of the PARTY_RELATIONSHIP, then you are still forced to update the PARTY so that it its reverse_relationships now has the v4 id for the updated PARTY_RELATIONSHIP rather than the v3 id. One way to fix this would be if we were to enable a 'latest' version id that always automatically pointed to the latest version of something. This is defined for openEHR EHR URIs, but not for the type OBJECT_VERSION_ID, used in LOCATABLE_REF. I think a better solution is that PARTY simply does not contain reverse relationships, because it is essentially solving a database indexing problem, which could be better solved by maintaining index objects and/or native indexes, depending on how the demographic model persistence is implemented. I don't understand why that is, it seems a bad thing which causes extra complexity. More logically would seem to me to connect the UID of to the list ReverseRelationships in the target Party, instead of the ObjectVersionID. that would probably risk the reverse_relationships attribute getting out of data quickly and containing wrong information, unless the implementation meticulously checked whether the validity was always maintained or not. I would be interested to know what other experience there is with this attribute; my suspicion is that it should be deprecated. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/68009f4e/attachment.html>
Reverse Relations
On 29/04/2011 02:03, Heath Frankel wrote: > > I agree with Thomas, the reverse relationships should be derived from > the forward relationships. The RM doesn't necessarily need to be > reflected in the persistence model. > > Having said that, we do have a fundamental issue regarding OBJECT_REF > with regard to using VERSIONED_OBJECT uid or VERSION uid, in some > cases it is desirable to use the former because you want the > relationship to exits even if the referenced object is revised, whilst > in other case this may not be safe practice. I think this issue > deserves some discussion and a Wiki page for the outcome. > that's probably the best way to implement the 'latest' version idea. We should describe that use.. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/354fef15/attachment.html>
Unable to express an unit of measurements in UCUM syntax
it is a pretty weird unit, since it is partway between 2-d and 3-d space, and therefore partway between the concept of 'area' and that of 'volume'. So whether it is acceptable depends on whether we think that such concepts are meaningful in the activity we call 'measurement' in the physical world. Probably there are weird units like this in quantum mechanics, or other esoteric mathematical spaces, so then it comes down to scope of UCUM - presumably not all of science, just physical measurement? Changing openEHR or HL7 to handle it probably would not be hard, but it might open up a can of worms, and also just plain annoyances, by allowing fractional dimensions (i.e. as soon as you start using floating point numbers for values that are almost always integers, computers struggle to get it right...). - thomas On 29/04/2011 01:48, Grahame Grieve wrote: > Hi Leo > > Gunther says that these units are not proper units. > > http://www.xkaw.com/Education_Reference/Science_Mathematics.asp?id=2276318 > > There's a possible question of scope alignment here. It's kind of tantamount > to > saying that a measure like that is not a proper measurement. I don't think > I agree with that. > > To pursue the UCUM issue, you need to make at ticket at > http://www.unitsofmeasure.org/ > > I think that there's a tension here between the notion of purity from UCUMs > point of view, and the use of UCUM in the measurement data types (PQ in > HL7 v3 and DV_QUANTITY in openEHR - both have the same scope and the > same usage of UCUM) > > Also see http://www.unitsofmeasure.org/wiki/ProcedureDefinedUnits > > Grahame > > * * -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/9213f009/attachment.html>
Unable to express an unit of measurements in UCUM syntax
There's some question about whether such a funky unit is a proper unit. It does look rather like a statistical imagination to me, rather than an actual unit. I'm not sure where the right place to discuss this is. I'll let you know when I find out. Grahame On Fri, Apr 29, 2011 at 12:50 AM, Leonardo Moretti wrote: > > Hi > there are a lots of scientific publications treating the indexations of left > ventricular mass (LVM). > I can link some abstracts, but the whole PDF documents are not public: > - http://www.nature.com/jhh/journal/v23/n11/full/jhh200916a.html > - http://www.ncbi.nlm.nih.gov/pubmed/11729247 > or here > https://www.stanford.edu/group/ccm_echocardio/cgi-bin/mediawiki/index.php/Left_ventricle_wall_thickness > > It can be used to detect left ventricular hypertrophy. > You can google "mass/height^2.7" to find more references. > > Thanks for your help. > leo > > > Grahame Grieve-3 wrote: >> >> Hi Leo >> >> Can you please provide some references to show the use of height^2.7? >> >> Grahame >> >> >> On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo >> wrote: >>> In cardiology, left ventricular mass (LVM) is often indexed to better >>> identify left ventricular hypertrophy. >>> Possible indexations are: >>> - LVM/BSA (body surface area) >>> - LVM/height >>> - LVM/height^2.7 >>> The first and the latter are often used. >>> The units of measurement of the latter is usually g/m2.7 >>> [gram/(meter^2.7)]. >>> >>> In DV_QUANTITY, "units" attribute should be expressed in UCUM unit >>> syntax. >>> UCUM doesn't allow not integer exponent (see >>> http://aurora.regenstrief.org/~ucum/ucum.html#section-Syntax-Rules), so I >>> have the problem that I cannot express the units as g/m2.7. >>> >>> Any suggestion to solve this problem!? >>> Best regards >>> leo >>> ___ >>> openEHR-technical mailing list >>> openEHR-technical at openehr.org >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> >>> >> >> >> >> -- >> - >> http://www.healthintersections.com.au / >> grahame at healthintersections.com.au / +61 411 867 065 >> ___ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> > > -- > View this message in context: > http://old.nabble.com/Unable-to-express-an-unit-of-measurements-in-UCUM-syntax-tp31494533p31497302.html > Sent from the openehr-technical mailing list archive at Nabble.com. > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065
