>> 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?
FHIR has no such restriction - elements must have a type of one or more of the defined types, either primitive or complex >>> Well, this is the HL7 modelling mentality, trying to create a data type >>> 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? yes, check out DV_EHR_URI - this is exactly the same pattern for exactly the same reason > does anyone use the Java.util calendar type? It's hopeless for dates and > times! I use java.util.Date. don't know anything about calendar. but so what. > I think it is mostly the latter - Date is usually used when time info is > really not of interest or expected. why shouldn't the relationship between date and datetime be the same as that between DV_EHR_URI and DV_URI? I haven't defined that, but that would be the natural way to do it in FHIR. > I want a spec that looks like an openEHR spec ;-) That's useful.... I don't think I'll do exactly like (framemaker!), but others have asked for a formal computable statement of constraints. >> 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. but it generally isn't - and can't be in the archetype builder. So I don't know what was intended. >> 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. really? Sounds like a clear difference until you start working at the instance level. Say I have a field in which I want to put the concept "Asthma". The Snomed-CT code for this is 195967001: Asthma. I didn't get his either by NLP, or by user input - it's configured as part of a process. Now the interpretation of of DV_TEXT is text, possibly with a code. So when I'm going to represent that, I'll use DV_TEXT of "asthma" with a mapping to snomed code 195967001 in the mappings. The mapping type will be .... hell, I don't know, does anyone use that, and what do they put in it? I don't know whether the Purpose_valid invariant means I need one or not (Group_id_term_mapping_purpose is not defined anywhere that I can find, for example), but I think not. Anyhow, my snomed code goes in a mapping. I can't imagine any normal implementer would think differently on this point. But if I'm doing a DV_CODED_TEXT, then the snomed code goes on the defining_code instead of a mapping. >> 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. really? You'll have to define that difference a lot better in the spec, because I don't see it, and because that's not how it's being used in practice. And what's a match of "=" other than defining? so: > why would we want to put the defining codephrase in the mappings? because most users couldn't tell a defining code apart from a primary mapping in most situations. Grahame
