Couple of quick reactions - you need to talk to clinical modellers to get a better response (maybe post on clinical list)...
On 10/03/2012 19:34, Grahame Grieve wrote: > 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. questionnaire questions, which 'classify' the patient: 'ever smoked?'; 'ever had children?' etc. I don't think that whether nullflavour applies is really the issue (I am sure there could be questions on an ED form that might not always be answered and therefore require a NF); the point is to have a type that you can compute with a as a boolean, rather than as some more complex computation with codes etc. In CKM, there are 52 uses of DV_BOOLEAN from 277 archetypes, so I guess there is a need. > > * 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. This is bad modelling, we should not be doing it. I'm talking 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. > 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? Date is probably the most commonly used of the date/time types in clinical medicine, outside of timestamps in audit trails. Diagnosis & problem models are full of dates; date of birth is a date, not a date/time; last date seen by doctor; last date for this vaccination... given that there is support in all the major programming languages, even XSD, and the types are regularly used by clinical modellers (with 'time' being so far nearly non-existent in archetypes, but probably only a matter of time)... why not include support for these types in a way that matches implementation formalisms? There are operations that need to be performed on dates & dates; date/times & date/times; dates & durations; date/times and durations; durations and durations and occasionally with times. In good date/time libraries, all well defined. Plus partial dates/times need to be supported. But a Date is not a kind of DateTime..... > > * 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. > > 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. Please, no more HL7 'profiles' - we need to be doing proper object modelling, not breaking all the rules of software maintainability. As far as using the FHIR data types, well, we can't answer that until there is an object (not XML) model. The current XML spec includes the many natural language statements (which seem good, but are still natural language); these all need to be formally expressed in terms of pre- and post-conditions and class invariants. I think that is the next step for the FHIR datatypes - a proper formal object model specification. 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. - thomas
