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 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 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. 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. 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. Cheers, Sam From: [email protected] [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Monday, 30 January 2012 4:27 AM To: Openehr-Technical Subject: openEHR / FHIR data types cross analysis I have started a gap analysis of the openEHR and FHIR data types <http://www.openehr.org/wiki/display/stds/FHIR+-+openEHR+Data+Types+cross-an alysis> , created by Grahame Grieve as part of the HL7 'fresh look' activity. ANyone is welcome to add to the tables on this page - I am just slowly working on it in the background. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/8bab1f24/attachment.html>
