HI I have responded to the comments in the wiki.
Generally, the FHIR data types are not purely for computation; they contain some features related to display. Some further responses here: * DV_BOOLEAN - maps a to a coded value with true/false. True and false are defined codes. I'd be interested to look at cases where a field true/fase justifies a nullFlavor and yet is a true boolean. * Seperation of dates and times: well, there is a Duration data type. So the question is about defining date as a separate reusable profile over date time. Personally, I think that defining separate types is not very productive, because you would expect to be able to perform common operations on mixes of dates and datetimes. I don't think that date is a magical thing - but what kind of uses does it have? * units is a long discussion. What I have learnt here in Australia is that the clinical users can only adopt UCUM if their sources do. And getting the sources to do that is not easy. Especially not when a number of significant professional clinical groups have strong recommendations to use non-ucum units for display to humans. You might question their wisdom - I do - but you can't question their impact. The upshot is that most of the clinical documents in Australia will not use UCUM units for many things - the creators of the documents could code to UCUM but aren't allowed to. Hence, FHIR allows both a human and a computable representation of the units. Nor does it insist on UCUM either, though there is a constraint profile that does. When I look at the mappings, I see that openEHR could interoperate with FHIR data types without much difficulty. There has been a question of whether openEHR could just *use* FHIR data types directly. I think that a few more constraint profiles and aliases would have to be defined in order for that to happen, but it is actually possible. The real problems resolve around DV_TEXT - I've never been clear about how that actually works. Grahame On Tue, Jan 31, 2012 at 8:51 AM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120311/f56c57e6/attachment-0001.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/pipermail/openehr-technical_lists.openehr.org/attachments/20120311/f56c57e6/attachment-0001.png>
