> 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. >> * 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. > 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. > 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) >> * 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. >> 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. see above. I'm not talking about doing anything like that. > 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.... > 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? 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? DV_TEXT is a text, optionally with mappings. DV_CODED_TEXT elevates one of the mappings to being "defining". Does that mean that a DV_TEXT couldn't have a "defining" code mapping? 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? Grahame
