On 30/01/2012 20:56, Sam Heard wrote: > > Thanks Tom for this useful work. > > A couple of thoughts: > > 1)It might be worth explaining the need for DV_BOOLEAN -- and not just > use Boolean >
The openEHR RM, like 13606, CDA and most other such models has a generic structure part for building trees of name-value information. For openEHR & 13606, the leaf level class is ELEMENT, whose 'value' attribute is of abstract type DATA_VALUE. Any concrete type needs to be a subtype of this type. Boolean is just a primitive type. To provide a Boolean valued subtype of DATA_VALUE needs a new type - in openEHR's case, DV_BOOLEAN. In the HL7 types used in 13606 and HL7 it is BL. > 2)The separation of date and time is not usual in computing languages > at the moment and I would guess is a consideration -- we certainly do > not model these separately but as a constraint > Well, in the libraries in Java (Joda <http://joda-time.sourceforge.net/quickstart.html>), Python <http://docs.python.org/library/datetime.html>, Ruby <http://www.ruby-doc.org/stdlib-1.9.3/libdoc/date/rdoc/index.html>, Eiffel <http://docs.eiffel.com/book/solutions/eiffeltime-tutorial> all do, and XML <http://www.w3schools.com/schema/schema_dtypes_date.asp> all distinguish these types. Many of these libraries (including XML and openEHR's types) are based on the ISO 8601 standard that defines strings corresponding to date, time, date_time and duration. This is what people program with, so I don't see any issue. We currently use the separate types in archetypes, according to these statistics. > 3)The ability to have codes as units in quantity is an interesting > approach which has been around for a while in HL7 v2 where you are not > limited to SI units/UCUM but can have TAB for tablets etc. > ok, but TAB is not a unit, it needs a separate field. Mixing it up with units is a recipe for disaster. > You state: "The FHIR choice to represent units as a code or a string > seems unnecessarily complicated. A UCUM units string should be > adequate. There is an example with unit=mcg/L and code=ug. What can > this mean?" > > Nota sure how we could have a code for a unit that is UCUM/SI -- this > does not make sense really -- but having the ability to put in > quantities that are not SI Units does have some merit. Pulse is a good > example -- it is really a frequency x/min but people often say bpm or > beats per minute. The amount of tobacco people use can be in > cigarettes per day or oz/week or gm/day. At the moment we have to > divide these into different parts of the archetype. > I have no problem with any of these; to my knowledge they are all accommodated with UCUM. UCUM isn't a fixed list of units, it's an expression syntax. So you can always create an expression 'oz/week' or whatever. Beats per minute unit is '/min' or equivalently 'min^-1'. The 'beats' part is not part of a unit system. I agree that pseudo units like 'bpm' are useful to support, but we have to do that in a different data field, since if we don't have systematically computable units in the units field, we kill its computability. Similarly, 'puffs', 'drops' and all the rest need a place to go. Just not in the units field. > That is not to say that it is right to put the counted thing as a unit > and not keep it in the leaf node name but TAB/CAP/Puff/Drop etc are > common for medication and do cause some difficulty. > It may be worth having a special subtype of Quantity that includes an extra field for these arbitrary discretisations. I know Grahame and others spent a long time arguing about this. The following description for the Quantity data type on the FHIR page <http://www.healthintersections.com.au/fhir/datatypes.htm#Quantity> makes me think they have some way to go yet: The /unit/ element must contain a unit that defines what is measured. The unit may additionally be coded in the /code/ and the /system/, which is a URI, OID, or a SID that defines the code (see CodeableConcept <http://www.healthintersections.com.au/fhir/datatypes.htm#CodeableConcept> for further information). Note that the /unit/ element will often contain a valid UCUM unit, but it cannot be assumed that it does. *If a UCUM unit is provided in the /code/ *then a canonical value can be generated for purposes of comparison between quantities. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120130/37869fcd/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: faecaeee.png Type: image/png Size: 10434 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120130/37869fcd/attachment.png>
