On 18/03/2012 12:49, Grahame Grieve wrote: >>> 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
ok, but how do w write a normal statically typed classes in Java or C# to deal with that? >>> >>> 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 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. Ideally we need semantic types whose representation could change (e.g. from String in messages to multiple pieces in some programming framework) but whose semantics stay the same. > >> 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. see above. It's not an argument about representation (i.e. different ways of parsing a String), but about semantics. We still need for example some thing that says that Date.diff (otherDate) produces a Duration. > >> 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. haha, I didn't mean FM, just the formal specification. > > 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. 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 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. doesn't matter where it came from. If you want the defining code as well, you have a DV_CODED_TEXT. There is nothing however to prevent you doing a mapping exrecise on the data what maps the above SNOMED code to the text 'Asthma'. I don't really see the use, but it's certainly possible. The 'match' is then 'exact'. (See the model <http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109597816149_873308_762Report.html>). > > 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. it can easily be different: a very typical UI control is one that combines coded term selection with free text entry. If the archetype specifies either, then that UI control allows either, and at runtime either a DV_TEXT or a DV_CODED_TEXT will be created, depending on what the user does. There are systems doing this today. > > 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. > >> 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? 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. The string may or may not be the rubric of the code from a terminology, but even if it is, the point of the mapping will not usually have been to supply 'defining' codes, but to supply codes for billing, research or other purposes. Supplying defining codes is not out of the question I guess, if the incoming data is all just Text, and some translator is trying to find matches in Snomed, but even then it is a virtual guarantee that only some direct matches will be found. Anyway, the point of 'defining' is not whether a lexical direct hit was made by some mapping process, but what the intention & understanding of the user (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. > > 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. > > * > * what's a 'primary' mapping? - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120318/b490dc39/attachment.html>
