On 17/03/2012 22:18, Grahame Grieve wrote: >> Couple of quick reactions - you need to talk to clinical modellers to get a >> better response (maybe post on clinical list)... > um, maybe. but most are representational questions, not questions of > meaning, I think. > >>> * 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. > I just wasn't thinking what I wrote this. In FHIR, a boolean data > type, primitive, is a > type that can be used in models an is exactly equivalent to DV_BOOLEAN.
but isn't the problem that it doesn't inherit from some DATA_VALUE parent type (Any in HL7 data types)? How can it be one of the possible values in a location like ELEMENT.value which would be statically typed to this parent type (as it is in 13606, HL7 RIM and openEHR) unless it is a descendant of this type? >>> * 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. >> Well, this is the HL7 modelling mentality, trying to create a data type or >> class with all possible attributes, some of which can be removed in some >> subclass. > not at all. nothing is removed in FHIR. There are some data types where > attributes in the superclass are constrained by the definitions in the > subclass. > You do the same. do we? >> about interfaces here, although, having looked into all the major languages >> I didn't find any that didn't have distinct date, time, date/time and >> duration types, so even in implementations, I could not see the point. > As you later noted, C# doesn't. Java.util also doesn't. Delphi doesn't > (not that > many people case...) The windows API doesn't. SQL, XML Schema, and others > do. It's hardly conclusive then. does anyone use the Java.util calendar type? It's hopeless for dates and times! >> Date is probably the most commonly used of the date/time types in clinical >> medicine, outside of timestamps in audit trails. > right. But how often do the models use date because date would be sufficient, > as opposed to using date because a time would be innappropriate? Actually, > this is probably a case where UI considerations intervene? (so much for my > note above about representation only) I think it is mostly the latter - Date is usually used when time info is really not of interest or expected. >>> * 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. >> well it depends on whether FHIR is about defining good quality data, or >> about defining user interface. > FHIR is about neither: it is about defining exchange that allows the user > to work with what they have. Yes, FHIR allows looser data than v3 requires, > and in this regard than what openEHR allows - but it also allows good quality > data too. Data that's just fine and dandy, in fact. So, I think it's about defining (or at least describing) data ;-) But let's follow the units issue up in its own thread. I am starting to understand better your motivation for the two fields 'code' and 'unit' in the Quantity type. > >> As far as using the FHIR data types, well, we can't answer that until there >> is an object (not XML) model. > what is it that you want? a class diagram? > (http://www.healthintersections.com.au/fhir/dt1.png, > http://www.healthintersections.com.au/fhir/dt2.png, > http://www.healthintersections.com.au/fhir/dt3.png) > something else? (ea source: www.healthintersections.com.au/fhir/fhir.eap) > >> I think that is the next step for the FHIR datatypes - a >> proper formal object model specification. > oh, so you want OCL? because it's so useful.... I want a spec that looks like an openEHR spec ;-) That's useful.... >> DV_TEXT is simple - it has a string value, + optional coded mappings. If the >> text value is in fact the rubric of a code, and the code is there as well, >> you have a DV_CODED_TEXT, whose code_string carries the concept code, or >> code phrase. > I don't think this is simple at all. in fact, I don't understand this > explanation at all, > though I thought I understood the types. if an archetype has DV_TEXT, how do > I know whether the designer(s) thought that the coded mappings matter or not? they can put a DV_CODED_TEXT constraint in as well as a DV_TEXT constraint if they want to allow either - e.g. prefer coded, but text ok if no code available; the archetype processor is supposed to opt for the more specific subtype by preference. e.g. ELEMENT matches { value matches { DV_CODED_TEXT matches { defining_code matches {[SNOMEDCT_20120101::1111111, 222222222, 3333333]} } DV_TEXT matches {/.+} -- non empty string } } > Should I do anything about them, or are they just there because they > were thinking > of straight text? Do they think formatting/hyperlinking is important? that can be constrained in the archetype as well. > > DV_TEXT is a text, optionally with mappings. DV_CODED_TEXT elevates one > of the mappings to being "defining". well 'defining_code' isn't a mapping; a mapping by definition is an association between two things from two different models or ontologies. A defining code is the code corresponding to the text (description) in the value field. > Does that mean that a DV_TEXT couldn't > have a "defining" code mapping? I don't think that would make sense; mappings are for things like 'billing', 'research project X', 'CDC coding' etc. > Or is this constrained from use in > DV_TEXT.purpose? And shouldn't you also put the defining phrase in > the DV_TEXT.mappings, else you are not conforming to the contract of > DV_TEXT? why would we want to put the defining codephrase in the mappings? - thomas
