> FHIR has no such restriction - elements must have a type of one or more > of the defined types, either primitive or complex > > ok, but how do w write a normal statically typed classes in Java or C# to > deal with that?
Many boolean elements are mandatory - they map straight onto the primitive boolean anyway, since no nullFlavor is allowed. If a nullFlavor is allowed, then you can either define a sub-type of something directly, or use the Nullable pattern from C#, or define a mixin if that's possible. Which is best depends on the capabilities of the language. See the note here: http://www.healthintersections.com.au/fhir/mixins.htm But in fact, many implementers will not define types at all. > This is a pattern where all descendants in the hierarchy just have a String > value, but the different descendants provide different ways of parsing it. > The FHIR identifiers are done like this (by direct inheritance from String), > so are the openEHR Identifiers (by having a single value: String field). > > I had momentarily forgotten that you had done HumanDate like this as well. > In FHIR, you inherit directly from String, and add syntax functions that > parse the string in a certain way. In this case we assume ISO8601 date/time > strings. But just having the one semantic type (HumanDate) based on the > representation (a String) is not enough when building clinical models. > Modellers need to be able to put Date, DateTime, Time (we can assume it will > be required somewhere) and Duration (which you have as a constraint on > Quantity). I am not against using the representation approach you have used, > but it still doesn't provide enough semantic types. Is time used in the existing archetypes? what for? I'll add Date to FHIR, and Duration already exists. > We still need for example some thing > that says that Date.diff (otherDate) produces a Duration. FHIR is consciously not a specification that says that sort of thing. > I wouldn't read much into the current limitations of the Archetype Editor - > except that there has been little demand to be able to constrain those > fields. (DV_TEXT formatting) right - why not? Do people think they don't matter because they assume the fields will exist, or because they don't want them? > But if I'm doing a DV_CODED_TEXT, then the snomed code goes > on the defining_code instead of a mapping. > > you don't have to lock the field type down to only DV_TEXT or DV_CODED_TEXT > at design time; the archetype can allow both, and either can be chosen at > runtime. ok, but archetypes are used outside the context of pure openEHR. How does this play out in a template environment or where archetypes are being used for specifying general interoperability? Often such mapping is lost (a la NEHTA, for instance) > we can always improve the spec, no doubt about that. A match of '=' just > means that the code is understood as a direct match for the string. so what is the meaning of 'defining', if that's not it? As a receiver of archetyped data, what should I make of the difference between a DV_TEXT with a snomed code in the mapping, and a DV_CODED_TEXT with a snomed code as the code_phrase? > (or other agent) was at the time of data generation. Just because they put > 'Asthma' as a string value, doesn't mean you can then go and put a mapping > to the Snomed code 195967001 and mark it as 'defining'. The 'meaning' of a > code in Snomed is based on its computable location in the IS-A hierachy and > its properties. That might or might not match the user's understanding of > the meaning. But mostly Snomed (and other) codes come from configuration and/or manual assignment to an interface terminology. I don't know how that plays out from the spec. I think that some clarity is definitely required here. We often argue about this kind of thing in NEHTA, for instance. Grahame
