Sorry about the XML slur :) 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: Monday, 19 March 2012 8:16 AM
> To: For openEHR technical discussions
> Subject: Re: openEHR / FHIR data types cross analysis
>
> 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.open
> > ehr.org
>
>
>
> --
> -----
> http://www.healthintersections.com.au /
> grahame at healthintersections.com.au / +61 411 867 065
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
