> Sorry about the XML slur :) Sam sigh. I'll get over it. Eventually. At least you didn't claim I was influenced by sql.
Grahame > >> -----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 > > > _______________________________________________ > 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
