openEHR / FHIR data types cross analysis
Hi all, A few belated comments on Booleans. In my experience there are a few genuine booleans in clinical data e.g. Is the prostate specimen present Y/N in the context of histopath . Well it either is or it ain't. Not much use for null flavours or 'yes ... but' , but in most circumstances the Yes/No construct is essentially a mangled clinical statement with all the ifs, buts and maybes that implies. Is the urine blood-stained- Yes is equivalent to Urine bloodstained and . Is the urine blood-stained- No is equivalent to Urine not bloodstained. It is now my standard practice in virtually all cases to model these clinical booleans as term lists, generally ensuring that the key semantics are carried in the value i.e Urine blood-stained , rather than just Yes but this definitely annoys developers who without clinical understanding can find it difficult to know how to map the terms to the checkbox or radio-button boolean paradigm in their requirements documents. It is easy to dismiss this as just 'a GUI / presentational issue' but I think that the clinical questionnaire pattern is actually a legitimate if unsupported kind of clinical recording which has been largely overlooed by informatics, and should be acknowleged and supported in openEHR., even if the key undelying paradigm (as for HL7 and SNOMED) is the clinical statement. So one immediate requirement is for a DV_BOOLEAN to allow term-bindings (including internal atCoded terms to the possible values but I think there is whole world of interesting PhDs to be done on the subject!! On 19 March 2012 12:40, Grahame Grieve grahame at healthintersections.com.auwrote: Hey Sam it's a good day when you can upset both Tom and I equally in a single paragraph. Grahame On Mon, Mar 19, 2012 at 9:24 AM, Sam Heard sam.heard at oceaninformatics.com wrote: Sorry about the Eiffel slur J Cheers, Sam ** ** *From:* openehr-technical-bounces at lists.openehr.org [mailto: openehr-technical-bounces at lists.openehr.org] *On Behalf Of *Thomas Beale *Sent:* Monday, 19 March 2012 8:18 AM *To:* openehr-technical at lists.openehr.org *Subject:* Re: openEHR / FHIR data types cross analysis ** ** Actually, Eiffel has nothing to do with it (I wrote my own date/time libraries based on ISO 8601 semantics). What I am influenced by is what I see in CKM and other repositories. openEHR CKM NEHTA CKM On 18/03/2012 21:00, Sam Heard 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 * * * * ** ** ** ** ** ** ** ** ___ 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 ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com *Primary Health Info 23 ? 25th April in Warwick ? are you coming?http://www.primaryhealthinfo.org/ * Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/7ab9cf0d/attachment-0001.html
openEHR / FHIR data types cross analysis
Hey Sam it's a good day when you can upset both Tom and I equally in a single paragraph. Grahame On Mon, Mar 19, 2012 at 9:24 AM, Sam Heard sam.heard at oceaninformatics.comwrote: Sorry about the Eiffel slur J Cheers, Sam ** ** *From:* openehr-technical-bounces at lists.openehr.org [mailto: openehr-technical-bounces at lists.openehr.org] *On Behalf Of *Thomas Beale *Sent:* Monday, 19 March 2012 8:18 AM *To:* openehr-technical at lists.openehr.org *Subject:* Re: openEHR / FHIR data types cross analysis ** ** Actually, Eiffel has nothing to do with it (I wrote my own date/time libraries based on ISO 8601 semantics). What I am influenced by is what I see in CKM and other repositories. openEHR CKM NEHTA CKM On 18/03/2012 21:00, Sam Heard 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 * * * * ** ** ** ** ** ** ** ** ___ 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/c2fb256f/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 19995 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/c2fb256f/attachment-0002.png -- next part -- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 21360 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/c2fb256f/attachment-0003.png
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 / 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
openEHR / FHIR data types cross analysis
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
openEHR / FHIR data types cross analysis
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
openEHR / FHIR data types cross analysis
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
openEHR / FHIR data types cross analysis
Sorry about the Eiffel slur J Cheers, Sam From: openehr-technical-boun...@lists.openehr.org [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Thomas Beale Sent: Monday, 19 March 2012 8:18 AM To: openehr-technical at lists.openehr.org Subject: Re: openEHR / FHIR data types cross analysis Actually, Eiffel has nothing to do with it (I wrote my own date/time libraries based on ISO 8601 semantics). What I am influenced by is what I see in CKM and other repositories. openEHR CKM NEHTA CKM On 18/03/2012 21:00, Sam Heard 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/2e05a44e/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 21360 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/2e05a44e/attachment-0002.png -- next part -- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 19995 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/2e05a44e/attachment-0003.png
openEHR / FHIR data types cross analysis
Couple of quick reactions - you need to talk to clinical modellers to get a better response (maybe post on clinical list)... um, maybe. but most are representational questions, not questions of meaning, I think. * DV_BOOLEAN - maps a to a coded value with true/false. True and false are defined codes. I'd be interested to look at cases where a field true/fase justifies a nullFlavor and yet is a true boolean. 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. * Seperation of dates and times: well, there is a Duration data type. So the question is about defining date as a separate reusable profile over date time. Well, this is the HL7 modelling mentality, trying to create a data type or 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. about interfaces here, although, having looked into all the major languages I didn't find any that didn't have distinct date, time, date/time and duration types, so even in implementations, I could not see the point. As you later noted, C# doesn't. Java.util also doesn't. Delphi doesn't (not that many people case...) The windows API doesn't. SQL, XML Schema, and others do. It's hardly conclusive then. Date is probably the most commonly used of the date/time types in clinical medicine, outside of timestamps in audit trails. right. But how often do the models use date because date would be sufficient, as opposed to using date because a time would be innappropriate? Actually, this is probably a case where UI considerations intervene? (so much for my note above about representation only) * units is a long discussion. What I have learnt here in Australia is that the clinical users can only adopt UCUM if their sources do. And getting the sources to do that is not easy. Especially not when a number of significant professional clinical groups have strong recommendations to use non-ucum units for display to humans. You might question their wisdom - I do - but you can't question their impact. The upshot is that most of the clinical documents in Australia will not use UCUM units for many things - the creators of the documents could code to UCUM but aren't allowed to. Hence, FHIR allows both a human and a computable representation of the units. Nor does it insist on UCUM either, though there is a constraint profile that does. well it depends on whether FHIR is about defining good quality data, or about defining user interface. FHIR is about neither: it is about defining exchange that allows the user to work with what they have. Yes, FHIR allows looser data than v3 requires, and in this regard than what openEHR allows - but it also allows good quality data too. Data that's just fine and dandy, in fact. When I look at the mappings, I see that openEHR could interoperate with FHIR data types without much difficulty. There has been a question of whether openEHR could just *use* FHIR data types directly. I think that a few more constraint profiles and aliases would have to be defined in order for that to happen, but it is actually possible. The real problems resolve around DV_TEXT - I've never been clear about how that actually works. Please, no more HL7 'profiles' - we need to be doing proper object modelling, not breaking all the rules of software maintainability. see above. I'm not talking about doing anything like that. As far as using the FHIR data types, well, we can't answer that until there is an object (not XML) model. what is it that you want? a class diagram? (http://www.healthintersections.com.au/fhir/dt1.png, http://www.healthintersections.com.au/fhir/dt2.png, http://www.healthintersections.com.au/fhir/dt3.png) something else? (ea source: www.healthintersections.com.au/fhir/fhir.eap) I think that is the next step for the FHIR datatypes - a proper formal object model specification. oh, so you want OCL? because it's so useful DV_TEXT is simple - it has a string value, + optional coded mappings. If the text value is in fact the rubric of a code, and the code is there as well, you have a DV_CODED_TEXT, whose code_string carries the concept code, or code phrase. I don't think this is simple at all. in fact, I don't understand this explanation at all, though I thought I understood the types. if an archetype has DV_TEXT, how do I know whether the designer(s) thought that the coded mappings matter or not? 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? DV_TEXT is a text, optionally with mappings. DV_CODED_TEXT elevates one of the mappings to being defining. Does that mean that a DV_TEXT couldn't have a
openEHR / FHIR data types cross analysis
On 17/03/2012 22:18, Grahame Grieve wrote: Couple of quick reactions - you need to talk to clinical modellers to get a better response (maybe post on clinical list)... um, maybe. but most are representational questions, not questions of meaning, I think. * DV_BOOLEAN - maps a to a coded value with true/false. True and false are defined codes. I'd be interested to look at cases where a field true/fase justifies a nullFlavor and yet is a true boolean. 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? * Seperation of dates and times: well, there is a Duration data type. So the question is about defining date as a separate reusable profile over date time. Well, this is the HL7 modelling mentality, trying to create a data type or 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? about interfaces here, although, having looked into all the major languages I didn't find any that didn't have distinct date, time, date/time and duration types, so even in implementations, I could not see the point. As you later noted, C# doesn't. Java.util also doesn't. Delphi doesn't (not that many people case...) The windows API doesn't. SQL, XML Schema, and others do. It's hardly conclusive then. does anyone use the Java.util calendar type? It's hopeless for dates and times! Date is probably the most commonly used of the date/time types in clinical medicine, outside of timestamps in audit trails. right. But how often do the models use date because date would be sufficient, as opposed to using date because a time would be innappropriate? Actually, this is probably a case where UI considerations intervene? (so much for my note above about representation only) I think it is mostly the latter - Date is usually used when time info is really not of interest or expected. * units is a long discussion. What I have learnt here in Australia is that the clinical users can only adopt UCUM if their sources do. And getting the sources to do that is not easy. Especially not when a number of significant professional clinical groups have strong recommendations to use non-ucum units for display to humans. You might question their wisdom - I do - but you can't question their impact. The upshot is that most of the clinical documents in Australia will not use UCUM units for many things - the creators of the documents could code to UCUM but aren't allowed to. Hence, FHIR allows both a human and a computable representation of the units. Nor does it insist on UCUM either, though there is a constraint profile that does. well it depends on whether FHIR is about defining good quality data, or about defining user interface. FHIR is about neither: it is about defining exchange that allows the user to work with what they have. Yes, FHIR allows looser data than v3 requires, and in this regard than what openEHR allows - but it also allows good quality data too. Data that's just fine and dandy, in fact. So, I think it's about defining (or at least describing) data ;-) But let's follow the units issue up in its own thread. I am starting to understand better your motivation for the two fields 'code' and 'unit' in the Quantity type. As far as using the FHIR data types, well, we can't answer that until there is an object (not XML) model. what is it that you want? a class diagram? (http://www.healthintersections.com.au/fhir/dt1.png, http://www.healthintersections.com.au/fhir/dt2.png, http://www.healthintersections.com.au/fhir/dt3.png) something else? (ea source: www.healthintersections.com.au/fhir/fhir.eap) I think that is the next step for the FHIR datatypes - a proper formal object model specification. oh, so you want OCL? because it's so useful I want a spec that looks like an openEHR spec ;-) That's useful DV_TEXT is simple - it has a string value, + optional coded mappings. If the text value is in fact the rubric of a code, and the code is there as well, you have a DV_CODED_TEXT, whose code_string carries the concept code, or code phrase. I don't think this is simple at all. in fact, I don't understand this explanation at all, though I thought I understood the types. if an archetype has DV_TEXT, how do I know whether the designer(s) thought that the coded mappings matter or not? they can put a DV_CODED_TEXT constraint in as well as a DV_TEXT
openEHR / FHIR data types cross analysis
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
openEHR / FHIR data types cross analysis
On 11/03/2012 09:43, Thomas Beale wrote: Well, this is the HL7 modelling mentality, trying to create a data type or class with all possible attributes, some of which can be removed in some subclass. This is bad modelling, we should not be doing it. I'm talking about interfaces here, although, having looked into all the major languages I didn't find any that didn't have distinct date, time, date/time and duration types, so even in implementations, I could not see the point. apparently I was wrong about C# (still stuck with only one DateTime type), but I checked on Java (Joda http://joda-time.sourceforge.net/), Python (date/time lib http://docs.python.org/library/datetime.html), Ruby (date/time lib http://www.ruby-doc.org/stdlib-1.9.3/libdoc/date/rdoc/index.html)... all have separate types. * * - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120312/1f2e71c2/attachment.html
openEHR / FHIR data types cross analysis
HI I have responded to the comments in the wiki. Generally, the FHIR data types are not purely for computation; they contain some features related to display. Some further responses here: * DV_BOOLEAN - maps a to a coded value with true/false. True and false are defined codes. I'd be interested to look at cases where a field true/fase justifies a nullFlavor and yet is a true boolean. * Seperation of dates and times: well, there is a Duration data type. So the question is about defining date as a separate reusable profile over date time. Personally, I think that defining separate types is not very productive, because you would expect to be able to perform common operations on mixes of dates and datetimes. I don't think that date is a magical thing - but what kind of uses does it have? * units is a long discussion. What I have learnt here in Australia is that the clinical users can only adopt UCUM if their sources do. And getting the sources to do that is not easy. Especially not when a number of significant professional clinical groups have strong recommendations to use non-ucum units for display to humans. You might question their wisdom - I do - but you can't question their impact. The upshot is that most of the clinical documents in Australia will not use UCUM units for many things - the creators of the documents could code to UCUM but aren't allowed to. Hence, FHIR allows both a human and a computable representation of the units. Nor does it insist on UCUM either, though there is a constraint profile that does. When I look at the mappings, I see that openEHR could interoperate with FHIR data types without much difficulty. There has been a question of whether openEHR could just *use* FHIR data types directly. I think that a few more constraint profiles and aliases would have to be defined in order for that to happen, but it is actually possible. The real problems resolve around DV_TEXT - I've never been clear about how that actually works. Grahame On Tue, Jan 31, 2012 at 8:51 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 30/01/2012 20:56, Sam Heard wrote: Thanks Tom for this useful work. ** ** A couple of thoughts: 1) It might be worth explaining the need for DV_BOOLEAN ? and not just use Boolean The openEHR RM, like 13606, CDA and most other such models has a generic structure part for building trees of name-value information. For openEHR 13606, the leaf level class is ELEMENT, whose 'value' attribute is of abstract type DATA_VALUE. Any concrete type needs to be a subtype of this type. Boolean is just a primitive type. To provide a Boolean valued subtype of DATA_VALUE needs a new type - in openEHR's case, DV_BOOLEAN. In the HL7 types used in 13606 and HL7 it is BL. 2) The separation of date and time is not usual in computing languages at the moment and I would guess is a consideration ? we certainly do not model these separately but as a constraint Well, in the libraries in Java (Jodahttp://joda-time.sourceforge.net/quickstart.html), Python http://docs.python.org/library/datetime.html, Rubyhttp://www.ruby-doc.org/stdlib-1.9.3/libdoc/date/rdoc/index.html, Eiffel http://docs.eiffel.com/book/solutions/eiffeltime-tutorial all do, and XML http://www.w3schools.com/schema/schema_dtypes_date.asp all distinguish these types. Many of these libraries (including XML and openEHR's types) are based on the ISO 8601 standard that defines strings corresponding to date, time, date_time and duration. This is what people program with, so I don't see any issue. We currently use the separate types in archetypes, according to these statistics. 3) The ability to have codes as units in quantity is an interesting approach which has been around for a while in HL7 v2 where you are not limited to SI units/UCUM but can have TAB for tablets etc. ok, but TAB is not a unit, it needs a separate field. Mixing it up with units is a recipe for disaster. ** ** You state: ?The FHIR choice to represent units as a code or a string seems unnecessarily complicated. A UCUM units string should be adequate. There is an example with unit=mcg/L and code=ug. What can this mean?? ** ** Nota sure how we could have a code for a unit that is UCUM/SI ? this does not make sense really ? but having the ability to put in quantities that are not SI Units does have some merit. Pulse is a good example ? it is really a frequency x/min but people often say bpm or beats per minute. The amount of tobacco people use can be in cigarettes per day or oz/week or gm/day. At the moment we have to divide these into different parts of the archetype. I have no problem with any of these; to my knowledge they are all accommodated with UCUM. UCUM isn't a fixed list of units, it's an expression syntax. So you can always create an expression 'oz/week' or whatever. Beats per minute unit is '/min' or equivalently 'min^-1'. The
openEHR / FHIR data types cross analysis
Couple of quick reactions - you need to talk to clinical modellers to get a better response (maybe post on clinical list)... On 10/03/2012 19:34, Grahame Grieve wrote: HI I have responded to the comments in the wiki. Generally, the FHIR data types are not purely for computation; they contain some features related to display. Some further responses here: * DV_BOOLEAN - maps a to a coded value with true/false. True and false are defined codes. I'd be interested to look at cases where a field true/fase justifies a nullFlavor and yet is a true boolean. questionnaire questions, which 'classify' the patient: 'ever smoked?'; 'ever had children?' etc. I don't think that whether nullflavour applies is really the issue (I am sure there could be questions on an ED form that might not always be answered and therefore require a NF); the point is to have a type that you can compute with a as a boolean, rather than as some more complex computation with codes etc. In CKM, there are 52 uses of DV_BOOLEAN from 277 archetypes, so I guess there is a need. * Seperation of dates and times: well, there is a Duration data type. So the question is about defining date as a separate reusable profile over date time. Well, this is the HL7 modelling mentality, trying to create a data type or class with all possible attributes, some of which can be removed in some subclass. This is bad modelling, we should not be doing it. I'm talking about interfaces here, although, having looked into all the major languages I didn't find any that didn't have distinct date, time, date/time and duration types, so even in implementations, I could not see the point. Personally, I think that defining separate types is not very productive, because you would expect to be able to perform common operations on mixes of dates and datetimes. I don't think that date is a magical thing - but what kind of uses does it have? Date is probably the most commonly used of the date/time types in clinical medicine, outside of timestamps in audit trails. Diagnosis problem models are full of dates; date of birth is a date, not a date/time; last date seen by doctor; last date for this vaccination... given that there is support in all the major programming languages, even XSD, and the types are regularly used by clinical modellers (with 'time' being so far nearly non-existent in archetypes, but probably only a matter of time)... why not include support for these types in a way that matches implementation formalisms? There are operations that need to be performed on dates dates; date/times date/times; dates durations; date/times and durations; durations and durations and occasionally with times. In good date/time libraries, all well defined. Plus partial dates/times need to be supported. But a Date is not a kind of DateTime. * units is a long discussion. What I have learnt here in Australia is that the clinical users can only adopt UCUM if their sources do. And getting the sources to do that is not easy. Especially not when a number of significant professional clinical groups have strong recommendations to use non-ucum units for display to humans. You might question their wisdom - I do - but you can't question their impact. The upshot is that most of the clinical documents in Australia will not use UCUM units for many things - the creators of the documents could code to UCUM but aren't allowed to. Hence, FHIR allows both a human and a computable representation of the units. Nor does it insist on UCUM either, though there is a constraint profile that does. well it depends on whether FHIR is about defining good quality data, or about defining user interface. When I look at the mappings, I see that openEHR could interoperate with FHIR data types without much difficulty. There has been a question of whether openEHR could just *use* FHIR data types directly. I think that a few more constraint profiles and aliases would have to be defined in order for that to happen, but it is actually possible. The real problems resolve around DV_TEXT - I've never been clear about how that actually works. Please, no more HL7 'profiles' - we need to be doing proper object modelling, not breaking all the rules of software maintainability. As far as using the FHIR data types, well, we can't answer that until there is an object (not XML) model. The current XML spec includes the many natural language statements (which seem good, but are still natural language); these all need to be formally expressed in terms of pre- and post-conditions and class invariants. I think that is the next step for the FHIR datatypes - a proper formal object model specification. DV_TEXT is simple - it has a string value, + optional coded mappings. If the text value is in fact the rubric of a code, and the code is there as well, you have a DV_CODED_TEXT, whose code_string carries the concept code, or code
openEHR / FHIR data types cross analysis
Thanks Tom for this useful work. A couple of thoughts: 1) It might be worth explaining the need for DV_BOOLEAN - and not just use Boolean 2) The separation of date and time is not usual in computing languages at the moment and I would guess is a consideration - we certainly do not model these separately but as a constraint 3) The ability to have codes as units in quantity is an interesting approach which has been around for a while in HL7 v2 where you are not limited to SI units/UCUM but can have TAB for tablets etc. You state: The FHIR choice to represent units as a code or a string seems unnecessarily complicated. A UCUM units string should be adequate. There is an example with unit=mcg/L and code=ug. What can this mean? Nota sure how we could have a code for a unit that is UCUM/SI - this does not make sense really - but having the ability to put in quantities that are not SI Units does have some merit. Pulse is a good example - it is really a frequency x/min but people often say bpm or beats per minute. The amount of tobacco people use can be in cigarettes per day or oz/week or gm/day. At the moment we have to divide these into different parts of the archetype. That is not to say that it is right to put the counted thing as a unit and not keep it in the leaf node name but TAB/CAP/Puff/Drop etc are common for medication and do cause some difficulty. Cheers, Sam From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Monday, 30 January 2012 4:27 AM To: Openehr-Technical Subject: openEHR / FHIR data types cross analysis I have started a gap analysis of the openEHR and FHIR data types http://www.openehr.org/wiki/display/stds/FHIR+-+openEHR+Data+Types+cross-an alysis , created by Grahame Grieve as part of the HL7 'fresh look' activity. ANyone is welcome to add to the tables on this page - I am just slowly working on it in the background. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/8bab1f24/attachment.html
openEHR / FHIR data types cross analysis
On 30/01/2012 20:56, Sam Heard wrote: Thanks Tom for this useful work. A couple of thoughts: 1)It might be worth explaining the need for DV_BOOLEAN -- and not just use Boolean The openEHR RM, like 13606, CDA and most other such models has a generic structure part for building trees of name-value information. For openEHR 13606, the leaf level class is ELEMENT, whose 'value' attribute is of abstract type DATA_VALUE. Any concrete type needs to be a subtype of this type. Boolean is just a primitive type. To provide a Boolean valued subtype of DATA_VALUE needs a new type - in openEHR's case, DV_BOOLEAN. In the HL7 types used in 13606 and HL7 it is BL. 2)The separation of date and time is not usual in computing languages at the moment and I would guess is a consideration -- we certainly do not model these separately but as a constraint Well, in the libraries in Java (Joda http://joda-time.sourceforge.net/quickstart.html), Python http://docs.python.org/library/datetime.html, Ruby http://www.ruby-doc.org/stdlib-1.9.3/libdoc/date/rdoc/index.html, Eiffel http://docs.eiffel.com/book/solutions/eiffeltime-tutorial all do, and XML http://www.w3schools.com/schema/schema_dtypes_date.asp all distinguish these types. Many of these libraries (including XML and openEHR's types) are based on the ISO 8601 standard that defines strings corresponding to date, time, date_time and duration. This is what people program with, so I don't see any issue. We currently use the separate types in archetypes, according to these statistics. 3)The ability to have codes as units in quantity is an interesting approach which has been around for a while in HL7 v2 where you are not limited to SI units/UCUM but can have TAB for tablets etc. ok, but TAB is not a unit, it needs a separate field. Mixing it up with units is a recipe for disaster. You state: The FHIR choice to represent units as a code or a string seems unnecessarily complicated. A UCUM units string should be adequate. There is an example with unit=mcg/L and code=ug. What can this mean? Nota sure how we could have a code for a unit that is UCUM/SI -- this does not make sense really -- but having the ability to put in quantities that are not SI Units does have some merit. Pulse is a good example -- it is really a frequency x/min but people often say bpm or beats per minute. The amount of tobacco people use can be in cigarettes per day or oz/week or gm/day. At the moment we have to divide these into different parts of the archetype. I have no problem with any of these; to my knowledge they are all accommodated with UCUM. UCUM isn't a fixed list of units, it's an expression syntax. So you can always create an expression 'oz/week' or whatever. Beats per minute unit is '/min' or equivalently 'min^-1'. The 'beats' part is not part of a unit system. I agree that pseudo units like 'bpm' are useful to support, but we have to do that in a different data field, since if we don't have systematically computable units in the units field, we kill its computability. Similarly, 'puffs', 'drops' and all the rest need a place to go. Just not in the units field. That is not to say that it is right to put the counted thing as a unit and not keep it in the leaf node name but TAB/CAP/Puff/Drop etc are common for medication and do cause some difficulty. It may be worth having a special subtype of Quantity that includes an extra field for these arbitrary discretisations. I know Grahame and others spent a long time arguing about this. The following description for the Quantity data type on the FHIR page http://www.healthintersections.com.au/fhir/datatypes.htm#Quantity makes me think they have some way to go yet: The /unit/ element must contain a unit that defines what is measured. The unit may additionally be coded in the /code/ and the /system/, which is a URI, OID, or a SID that defines the code (see CodeableConcept http://www.healthintersections.com.au/fhir/datatypes.htm#CodeableConcept for further information). Note that the /unit/ element will often contain a valid UCUM unit, but it cannot be assumed that it does. *If a UCUM unit is provided in the /code/ *then a canonical value can be generated for purposes of comparison between quantities. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120130/37869fcd/attachment.html -- next part -- A non-text attachment was scrubbed... Name: faecaeee.png Type: image/png Size: 10434 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120130/37869fcd/attachment.png
openEHR / FHIR data types cross analysis
Again, FYI. If you would like help in doing the cross ref. with MLHIM let me know. However, this might be a good project for Sergio??? --Tim On Sun, Jan 29, 2012 at 10:26, Thomas Beale thomas.beale at oceaninformatics.com wrote: I have started a gap analysis of the openEHR and FHIR data types, created by Grahame Grieve as part of the HL7 'fresh look' activity. ANyone is welcome to add to the tables on this page - I am just slowly working on it in the background. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Timothy Cook, MSc ? ? ? ? ? +1 281 506 2860 LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook
openEHR / FHIR data types cross analysis
Apologies, this was not intended for the mailing list. On Mon, Jan 30, 2012 at 19:39, Timothy Cook timothywayne.cook at gmail.com wrote: Again, FYI. ?If you would like help in doing the cross ref. with MLHIM let me know. ?However, this might be a good project for Sergio??? --Tim On Sun, Jan 29, 2012 at 10:26, Thomas Beale thomas.beale at oceaninformatics.com wrote: I have started a gap analysis of the openEHR and FHIR data types, created by Grahame Grieve as part of the HL7 'fresh look' activity. ANyone is welcome to add to the tables on this page - I am just slowly working on it in the background. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Timothy Cook, MSc ? ? ? ? ? +1 281 506 2860 LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook -- Timothy Cook, MSc ? ? ? ? ? +1 281 506 2860 LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook
