Hi Sam Actually, this has come up in a couple of other places. The FHIR data types are defined for use within the FHIR framework. There's two very important parts of FHIR that influence the modeling of the data types: * the FHIR take on extensibility * the fact that all FHIR resources have a narrative section It's become clear to me that this will mean that the FHIR data types aren't suitable for use elsewhere
More generally, I don't think you can define a set of data types independently of a set of framework assumptions - and therefore data types are only independent of reference models if said reference models share the same framework assumptions. But I'm quite offended by the notion that I'm influenced by XML. Bah. Might as well have said that I'm influenced by text..... Actually, like Thomas, I prefer to work in a 3gl framework ;-) Grahame On Mon, Mar 19, 2012 at 8:00 AM, Sam Heard <sam.heard at oceaninformatics.com> wrote: > Hi > > This is an interesting discussion. It seems that we might have hit the issue > of defining data types independent of a reference model. In a reference > model we do want to know that there are a limited set of types (formally > expressed) that can be used at any point. > > I was influenced by the discussion at CIMI that demonstrated this. > > So the sort of textural elements you have within the datatypes that allow > someone to say Autumn for datetime (HumanDate) are probably best dealt with > in models where that is appropriate and with a suitable set of > terminologies. > > An uncertain datetime is better for processing than a text (soon after my > mother died). There is no doubt about the usefulness of the text, just that > it does not belong in a date field. > > The FHIR may be suitable for messages at this point in time, if so, it is > easy to port information to this. > > Let's keep this thread alive and get a little broader input. Thomas is > influenced by Eiffel, Grahame by XML. Most developers will probably sit > somewhere in between in terms of requirements for rigor. > > Cheers, Sam > > >> -----Original Message----- >> From: openehr-technical-bounces at lists.openehr.org [mailto:openehr- >> technical-bounces at lists.openehr.org] On Behalf Of Grahame Grieve >> Sent: Sunday, 18 March 2012 11:50 PM >> To: For openEHR technical discussions >> Subject: Re: openEHR / FHIR data types cross analysis >> >> >> 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 >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr- >> technical_lists.openehr.org > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- ----- http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065
