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
Units, Quantities, etc
Are discrete units only encountered in administrative directives? Do you prohibit people from making observations or measurements that include discrete units such as puffs, tablets, patches, vials, strips etc? why? HL7 does because we claim that you have to have UCUM codes so the data can be computable. If people simply want to exchange it in a structured but non-computable fashion... they can go to hell. And as for computable: we insist on a ucum code, and then say that for these discrete unit kind of things, well, you just put 1 for countable units, and then put the effective unit somewhere else - somewhere that no one can actually pull off in practice - because this is more computable. Huh? We do not make sense on this. So much for HL7... what's openEHR's excuse? Grahame On Sun, Mar 18, 2012 at 11:18 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: As Grahame mentioned on an earlier post, the question of units is thorny. Although we technical people would like to mandate UCUM or some other well-designed computable syntax, on its own, it won't work. There seem to be two reasons for this: it doesn't take care of the need for a displayable form of units, e.g. the computable form 'mcg' or 'ug', where as the displayable is '?g' (Greek mu followed by 'g') it doesn't take care of 'units' like puffs, tablets, patches, vials, strips, and other discrete delivery units it doesn't take care of discrete delivery units per time, e.g. '2 puffs / hour' Grahame and others have already done a lot of thinking on this here - there are a lot of excellent examples from Linda Bird on the Singapore programme. The more I think about the last two above, the more I think it is not about quantities per se but about an administration directive (how the patient should take something). Trying to make Quantity do that kind of stuff doesn't make sense to me - there is obviously a Quantity to indicate the dose in scientific form, but another data element may be needed to indicate how (in what discrete measures) to take the medication. I would therefore expect a distinct data element in the Medication Cluster archetype rather than a re-engineered Quantity type to deal with these last two. For the first one - displayable v computable, we will need a CR to change DV_QUANTITY, and make it work like the FHIR Quantity - i.e. have a second units field. Some of my earlier thoughts are actually on the above wiki page - the concept of a DiscretisedQuantity type inheriting from Quantity, which I think is also a reasonable alternative. what do others think? - thomas ___ 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 / 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
Units, Quantities, etc
well it's not prevented from being expressed; it's just expressed using a Quantity field (e.g. a DV_COUNT) and another field saying what you are counting (there are a reasonable number of examples of this already in the archetypes - number of cigarettes a day, number of previous pregnancies, number of steps taken in physiotherapy etc). If we made this a Quantity, we could in theory then use an instance to say '3 puffs'. But this is not an amount of substance, it's a count of 'delivery' units or 'grains' of substance. I still think Quantities should be computable as such - if we don't know how many mcg of substance 3 puffs is, we can't compute with it. ok, so you say it should be computable, but then allow a fixed unit of one, and some other code as well. And this in a subclass of Quantity, so you could always use it or encounter it in place of quantity. So if that's the case, why not simply make it a property of Quantity? What's really important is not that all Quantities are computable, but that you know whether you can compute with it. And in fact, making it a property of Quantity makes it easier to manage and/or constrain Grahame
Units, Quantities, etc
Hi Thomas, I had an issue recently were I was receiving HL7 V2 Lab messages with units such as x10^6/L, the equivalent in UCUM is 10*6/l, which was used in the archetype constraint for an RBC element. I translated the HL7 unit into the archetype constrained unit as required to be valid. However, when we displayed this in our application that was going through a conformance process for this particular Lab?s interface to allowed to retrieve messages within the enterprise, the Lab said that we *must* display the unit as x10^6/L as provided in the HL7 message. Therefore we had to translate it back again in our app? sigh. This scenario demonstrates this exact conversation. Personally I don?t like the idea of another attribute for displayable units. I am thinking that we need to have a means to lookup a particular set of ?displayable? units and get the computable unit for when we need to do any conversion, which I have yet to come across any need to do so in current implementations (not that this will not be required at some point but it will certainly be in very limited set of cases). I am thinking the units attribute should be our ?displayable?, and tat in cases where we need to convert to other units we provide a similar concept to mappings in DV_TEXT. Perhaps this should be the reverse, but because the displayable unit is the 99.99% use case I think we should make this the easiest representation with minimal change to RM. In archetypes, if the units attribute is allowed to any value, we can then specify a conversion mapping for each unit, which may allow multiple ?displayable? units to be defined and mapped to the same UCUM unit. So this conversion mapping is represented as knowledge in the archetype, but we also start getting some consistent representation of ?displayable? units without the weirdness of UCUM syntax. Hope this triggers further thoughts. Heath From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Thomas Beale Sent: Sunday, 18 March 2012 10:49 PM To: Openehr-Technical Subject: Units, Quantities, etc As Grahame mentioned on an earlier post, the question of units is thorny. Although we technical people would like to mandate UCUM or some other well-designed computable syntax, on its own, it won't work. There seem to be two reasons for this: * it doesn't take care of the need for a displayable form of units, e.g. the computable form 'mcg' or 'ug', where as the displayable is '?g' (Greek mu followed by 'g') * it doesn't take care of 'units' like puffs, tablets, patches, vials, strips, and other discrete delivery units * it doesn't take care of discrete delivery units per time, e.g. '2 puffs / hour' Grahame and others have already done a lot of thinking on this here http://www.healthintersections.com.au/wiki/index.php?title=Non-ucum_units_in_Quantity - there are a lot of excellent examples from Linda Bird on the Singapore programme. The more I think about the last two above, the more I think it is not about quantities per se but about an administration directive (how the patient should take something). Trying to make Quantity do that kind of stuff doesn't make sense to me - there is obviously a Quantity to indicate the dose in scientific form, but another data element may be needed to indicate how (in what discrete measures) to take the medication. I would therefore expect a distinct data element in the Medication Cluster archetype rather than a re-engineered Quantity type to deal with these last two. For the first one - displayable v computable, we will need a CR to change DV_QUANTITY, and make it work like the FHIR Quantity - i.e. have a second units field. Some of my earlier thoughts are actually on the above wiki page - the concept of a DiscretisedQuantity type inheriting from Quantity, which I think is also a reasonable alternative. what do others think? - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/ce91de2c/attachment.html
Units, Quantities, etc
Hi Heath yes, this the problem. I don't know if your solution works. I've considered putting a service up in the cloud that provides a service to take represented units and convert them to ucum units. But it's a many to many mapping unless the conversion is actually done in the context of a specific LOINC code, in which case there's a huge amount of duplication of mapping work. Grahame On Mon, Mar 19, 2012 at 8:51 AM, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Thomas, I had an issue recently were I was receiving HL7 V2 Lab messages with units such as x10^6/L, the equivalent in UCUM is 10*6/l, which was used in the archetype constraint for an RBC element. I translated the HL7 unit into the archetype constrained unit as required to be valid. However, when we displayed this in our application that was going through a conformance process for this particular Lab?s interface to allowed to retrieve messages within the enterprise, the Lab said that we *must* display the unit as x10^6/L as provided in the HL7 message. Therefore we had to translate it back again in our app? sigh. This scenario demonstrates this exact conversation. Personally I don?t like the idea of another attribute for displayable units.? I am thinking that we need to have a means to lookup a particular set of ?displayable? units and get the computable unit for when we need to do any conversion, which I have yet to come across any need to do so in current implementations (not that this will not be required at some point but it will certainly be in very limited set of cases). I am thinking the units attribute should be our ?displayable?, and tat in cases where we need to convert to other units we provide a similar concept to mappings in DV_TEXT. Perhaps this should be the reverse, but because the displayable unit is the 99.99% use case I think we should make this the easiest representation with minimal change to RM. In archetypes, if the units attribute is allowed to any value, we can then specify a conversion mapping for each unit, which may allow multiple ?displayable? units to be defined and mapped to the same UCUM unit.? So this conversion mapping is represented as knowledge in the archetype, but we also start getting some consistent representation of ?displayable? units without the weirdness of UCUM syntax. Hope this triggers further thoughts. Heath From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Thomas Beale Sent: Sunday, 18 March 2012 10:49 PM To: Openehr-Technical Subject: Units, Quantities, etc As Grahame mentioned on an earlier post, the question of units is thorny. Although we technical people would like to mandate UCUM or some other well-designed computable syntax, on its own, it won't work. There seem to be two reasons for this: it doesn't take care of the need for a displayable form of units, e.g. the computable form 'mcg' or 'ug', where as the displayable is '?g' (Greek mu followed by 'g') it doesn't take care of 'units' like puffs, tablets, patches, vials, strips, and other discrete delivery units it doesn't take care of discrete delivery units per time, e.g. '2 puffs / hour' Grahame and others have already done a lot of thinking on this here - there are a lot of excellent examples from Linda Bird on the Singapore programme. The more I think about the last two above, the more I think it is not about quantities per se but about an administration directive (how the patient should take something). Trying to make Quantity do that kind of stuff doesn't make sense to me - there is obviously a Quantity to indicate the dose in scientific form, but another data element may be needed to indicate how (in what discrete measures) to take the medication. I would therefore expect a distinct data element in the Medication Cluster archetype rather than a re-engineered Quantity type to deal with these last two. For the first one - displayable v computable, we will need a CR to change DV_QUANTITY, and make it work like the FHIR Quantity - i.e. have a second units field. Some of my earlier thoughts are actually on the above wiki page - the concept of a DiscretisedQuantity type inheriting from Quantity, which I think is also a reasonable alternative. what do others think? - thomas ___ 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
Units, Quantities, etc
Verstuurd vanaf mijn iPhone Op 18 mrt. 2012 om 15:15 heeft Thomas Beale thomas.beale at oceaninformatics.com het volgende geschreven: I still think Quantities should be computable as such - if we don't know how many mcg of substance 3 puffs is, we can't compute with it. Although i tend to agree with you, this won't work because then you assume that we're talking about the absolute truth. The absolute truth only exist when you're talking, for instance, about astronomics. In medicine you can't say 25 ml of alcohol is lethal. You can only say something like: 25 ml of alcohol is lethal in an adult man of 80 kg. And only when he doesn't drink more than 15 unit alcohol ? week. When he drinks more then The lethal dose is higher. For ? roman of the same weight who drinks 15 units ? week, the lethal dose is lower. My point is that an absolute quantity alone doesn't meander much. At The other hand, we know empirically that if someone has smoked 15 pack years he's at serious risk. Then about puffs. I' m almost sure that you can translate ? puff info a volume. If i remember it correctly 40 drops is 1 ml. So the same should go for puffs. Cheers, Stef
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; a
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 conference - proposal for Lake Bled, Slovenia 2012 - POLL
Hi Shinji We could not get sponsorship for the conference, which is a shame. For that reason it looks like that will not happen until we have Associates and some core funding. I would like to organise some Google handouts at different times each month - probably 3/month suiting Asia, Europe/Africa and the Americas. Would others be interested in meeting for a chat every month, with Video. We could use GoToWebinar for some more formal gatherings. Cheers, Sam -Original Message- From: openehr-technical-bounces at lists.openehr.org [mailto:openehr- technical-bounces at lists.openehr.org] On Behalf Of Shinji KOBAYASHI Sent: Friday, 2 March 2012 10:40 AM To: For openEHR technical discussions Subject: Re: openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL Hi all, Can I resume this topic? I am much looking forward to meeting this conference. I know there are many problems, but just to do it very great for us. Regards, Shinji 2012/1/13 Thomas Beale thomas.beale at oceaninformatics.com: On 13/01/2012 08:14, Ian McNicoll wrote: I do like the idea but I would prefer that each conference has its own very clear identity, albeit that some sessions could be shared, along with venue etc. A couple of the MIE conferences have operated this way with local informatics conferences being co-hosted/located with the European event, with some joint sessions but otherwise a very clear individual agenda and focus. Right - that could be a solution. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr- technical_lists.openehr.org
openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL
Hi Shinji We could not get sponsorship for the conference, which is a shame. For that reason it looks like that will not happen until we have Associates and some core funding. I would like to organise some Google handouts at different times each month - probably 3/month suiting Asia, Europe/Africa and the Americas. Would others be interested in meeting for a chat every month, with Video. We could use GoToWebinar for some more formal gatherings. Cheers, Sam -Original Message- From: openehr-technical-bounces at lists.openehr.org [mailto:openehr- technical-bounces at lists.openehr.org] On Behalf Of Shinji KOBAYASHI Sent: Friday, 2 March 2012 10:40 AM To: For openEHR technical discussions Subject: Re: openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL Hi all, Can I resume this topic? I am much looking forward to meeting this conference. I know there are many problems, but just to do it very great for us. Regards, Shinji 2012/1/13 Thomas Beale thomas.beale at oceaninformatics.com: On 13/01/2012 08:14, Ian McNicoll wrote: I do like the idea but I would prefer that each conference has its own very clear identity, albeit that some sessions could be shared, along with venue etc. A couple of the MIE conferences have operated this way with local informatics conferences being co-hosted/located with the European event, with some joint sessions but otherwise a very clear individual agenda and focus. Right - that could be a solution. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr- technical_lists.openehr.org
visualizing AQL result
Leykun The result of the query might be a table or some objects (as XML). The display of these needs to use a script - which I believe is available in the public domain. I will copy to Heath to ask about this. Cheers, Sam From: openehr-technical-boun...@lists.openehr.org [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Leykun Melkamu Sent: Friday, 2 March 2012 9:31 AM To: openehr-technical at openehr.org Subject: visualizing AQL result Hello! I am a student and working my thesis on openEHR application can I get help on how to visualize the result of my AQL queries. How can I use the operational template and the c # code generated from oceans template designer? Thanks in advance for your help. Best regards, Leykun -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/3d94f7b7/attachment.html
openEHR (local) terminologies
Hi Diego Rong has made this generally available - or it is in the download of the archetype editor. Cheers, Sam -Original Message- From: openehr-technical-bounces at lists.openehr.org [mailto:openehr- technical-bounces at lists.openehr.org] On Behalf Of Diego Bosc? Sent: Thursday, 1 March 2012 8:39 PM To: For openEHR technical discussions Subject: openEHR (local) terminologies I sent this email when I thought the migration process was over, but it wasn't. I am sending it again, sorry if someone receives two copies :) Is there any place where openEHR local terminology files (e.g. the possible values from C_DV_QUANTITY.property or DV_CODED_TEXT.defining_code) can be viewed? (as code/description tables) Regards ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr- technical_lists.openehr.org
openEHR (local) terminologies
Hi Diego Rong has made this generally available - or it is in the download of the archetype editor. Cheers, Sam -Original Message- From: openehr-technical-bounces at lists.openehr.org [mailto:openehr- technical-bounces at lists.openehr.org] On Behalf Of Diego Bosc? Sent: Thursday, 1 March 2012 8:39 PM To: For openEHR technical discussions Subject: openEHR (local) terminologies I sent this email when I thought the migration process was over, but it wasn't. I am sending it again, sorry if someone receives two copies :) Is there any place where openEHR local terminology files (e.g. the possible values from C_DV_QUANTITY.property or DV_CODED_TEXT.defining_code) can be viewed? (as code/description tables) Regards ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr- technical_lists.openehr.org
openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL
Happy to help this initiative in LAC. IMIA LAC assist this type of communities. Dra. Hullin Lucay Cossio (RN,BN,Hons,PhD,Post Doc) IMIA LAC President www.imia-lac.net From: sam.heard at oceaninformatics.com To: openehr-technical at lists.openehr.org; openehr-technical at openehr.org Subject: RE: openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL Date: Mon, 19 Mar 2012 09:29:24 +1100 Hi Shinji We could not get sponsorship for the conference, which is a shame. For that reason it looks like that will not happen until we have Associates and some core funding. I would like to organise some Google handouts at different times each month - probably 3/month suiting Asia, Europe/Africa and the Americas. Would others be interested in meeting for a chat every month, with Video. We could use GoToWebinar for some more formal gatherings. Cheers, Sam -Original Message- From: openehr-technical-bounces at lists.openehr.org [mailto:openehr- technical-bounces at lists.openehr.org] On Behalf Of Shinji KOBAYASHI Sent: Friday, 2 March 2012 10:40 AM To: For openEHR technical discussions Subject: Re: openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL Hi all, Can I resume this topic? I am much looking forward to meeting this conference. I know there are many problems, but just to do it very great for us. Regards, Shinji 2012/1/13 Thomas Beale thomas.beale at oceaninformatics.com: On 13/01/2012 08:14, Ian McNicoll wrote: I do like the idea but I would prefer that each conference has its own very clear identity, albeit that some sessions could be shared, along with venue etc. A couple of the MIE conferences have operated this way with local informatics conferences being co-hosted/located with the European event, with some joint sessions but otherwise a very clear individual agenda and focus. Right - that could be a solution. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/ab975053/attachment-0001.html
openEHR-technical Digest, Vol 67, Issue 34
Hi Tim HL7 Twittered about making things more openly available the other daydoes anyone have the link? Cheers, Sam -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Timothy Cook Sent: Thursday, 23 February 2012 4:44 AM To: For openEHR technical discussions Subject: Re: openEHR-technical Digest, Vol 67, Issue 34 How can anyone say that HL7 is open in any fashion? You are not free to distribute it outside of your organization except in small parts so that the specifications cannot reproduced. See the paragraph immediately preceding the one previously quoted here: HL7 CORPORATE/ORGANIZATIONAL MEMBERS are authorized to: reproduce and distribute Material on an internal basis solely for use within their organization; reproduce and distribute excerpts of Material (not entire domains or chapters) to any customers of a product or service implementing those Material, provided that the HL7 Access database may not be included, either in whole or in part, in any product intended for direct or indirect commercial resale; use excerpts of Material to create customized implementation guides; and use Material in the development of software applications and messaging systems for direct use or distribution without additional licensing fees. There is NOTHING open about this, fee paid or not. --Tim On Mon, Feb 20, 2012 at 17:55, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 20/02/2012 22:34, William Goossen wrote: Hi Heath, Thomas, My experience is that HL7 v3 is an open standard and OpenEHR is proprietary (as owned by the OpenEHR foundation holding the copyrights, albeit I understand that work is underway to sort that out). Correction: HL7 is open, although requires a small fee for use; openEHR is an open and free specification. Neither are proprietary; proprietary essentially means 'not openly published and usable'. That does not apply to either HL7 or openEHR. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Timothy Cook, MSc LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Units, Quantities, etc
On 18/03/2012 21:45, Grahame Grieve wrote: ok, so you say it should be computable, but then allow a fixed unit of one, and some other code as well. And this in a subclass of Quantity, so you could always use it or encounter it in place of quantity. So if that's the case, why not simply make it a property of Quantity? because it only applies in a small number of cases. Most Quantity instances will never have this because they don't represent this kind of information. - thomas
Units, Quantities, etc
you'll still have to look, even though it's not many cases. Grahame On Mon, Mar 19, 2012 at 10:57 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 18/03/2012 21:45, Grahame Grieve wrote: ok, so you say it should be computable, but then allow a fixed unit of one, and some other code as well. And this in a subclass of Quantity, so you could always use it or encounter it in place of quantity. So if that's the case, why not simply make it a property of Quantity? because it only applies in a small number of cases. Most Quantity instances will never have this because they don't represent this kind of information. - thomas ___ 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
Units, Quantities, etc
On 18/03/2012 21:51, Heath Frankel wrote: Hi Thomas, I had an issue recently were I was receiving HL7 V2 Lab messages with units such as x10^6/L, the equivalent in UCUM is 10*6/l, which was used in the archetype constraint for an RBC element. I translated the HL7 unit into the archetype constrained unit as required to be valid. However, when we displayed this in our application that was going through a conformance process for this particular Lab's interface to allowed to retrieve messages within the enterprise, the Lab said that we **must** display the unit as x10^6/L as provided in the HL7 message. Therefore we had to translate it back again in our app... sigh. This scenario demonstrates this exact conversation. Personally I don't like the idea of another attribute for displayable units. I am thinking that we need to have a means to lookup a particular set of displayable units and get the computable unit for when we need to do any conversion, which I have yet to come across any need to do so in current implementations (not that this will not be required at some point but it will certainly be in very limited set of cases). I think that might work theoretically, but it means establishing yet another terminology (or piece of SCT) that is going to take time to agree, and then has to be deployed and in every computing environment. I also don't think we can predict how much it will be used in the future - the future is all about computing with data, unlike today, where we are still just moving it around. I could be wrong - maybe the units work in SCT is further ahead than I think. The other problem is the problem of synonyms - there is not always a 1:1 mapping between display and computable forms. I am thinking the units attribute should be our displayable, and tat in cases where we need to convert to other units we provide a similar concept to mappings in DV_TEXT. Perhaps this should be the reverse, but because the displayable unit is the 99.99% use case I think we should make this the easiest representation with minimal change to RM. Well, that is only true if we think the data are only being used for display. But if the data need to be computed with - even if large research projects only start using openEHR data in a few years time - imagine the frustration when researchers discover non-computable units all over the place. In archetypes, if the units attribute is allowed to any value, we can then specify a conversion mapping for each unit, which may allow multiple displayable units to be defined and mapped to the same UCUM unit. So this conversion mapping is represented as knowledge in the archetype, but we also start getting some consistent representation of displayable units without the weirdness of UCUM syntax. we could do it that way we would need to look at some actual data examples and see if that would work. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/887557f7/attachment-0001.html
Units, Quantities, etc
On 18/03/2012 22:21, Stef Verlinden wrote: Verstuurd vanaf mijn iPhone Op 18 mrt. 2012 om 15:15 heeft Thomas Bealethomas.beale at oceaninformatics.com het volgende geschreven: I still think Quantities should be computable as such - if we don't know how many mcg of substance 3 puffs is, we can't compute with it. Although i tend to agree with you, this won't work because then you assume that we're talking about the absolute truth. The absolute truth only exist when you're talking, for instance, about astronomics. In medicine you can't say 25 ml of alcohol is lethal. You can only say something like: 25 ml of alcohol is lethal in an adult man of 80 kg. And only when he doesn't drink more than 15 unit alcohol ? week. When he drinks more then The lethal dose is higher. For ? roman of the same weight who drinks 15 units ? week, the lethal dose is lower. My point is that an absolute quantity alone doesn't meander much. At The other hand, we know empirically that if someone has smoked 15 pack years he's at serious risk. Then about puffs. I' m almost sure that you can translate ? puff info a volume. If i remember it correctly 40 drops is 1 ml. So the same should go for puffs. ok but you are still talking about making it computable somehow - by assuming 1ml = 40 drops or whatever. If we want a kind of quantity that accommodates only representation in non-systematic units, we should not mix this type up with a proper Quantity that can be used with 90% (or maybe its only 75%) of all clinical data. - thomas * * * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/a33f3164/attachment.html
Are you doing an academic project using openEHR?
On 18/03/2012 17:45, pablo pazos wrote: Hi Thomas, Armando Prieto and Juan Escalante are students from Venezuela, they took our Open EHRGen framework and improve it to create an EMR for the SOS Telemedicine for Venezuela project. They can give you more information about the project specifics. * * We don't have an entry for openEHRGen either - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/7178ab88/attachment.html
openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL
Hi Sam, As regards to world-wide economic recession, getting fund for RD is far difficult. I am challenging some funds from our government or funds in Japan, such as this. http://www.jsps.go.jp/english/e-meeting/index.html This fund aims to support conference in Japan, but I think it would be better in Singapore or Kuala Lumpur with less cost. However, lottery might be more promising. sigh. Regards, Shinji 2012/3/19 Sam Heard sam.heard at oceaninformatics.com: Hi Shinji We could not get sponsorship for the conference, which is a shame. For that reason it looks like that will not happen until we have Associates and some core funding. I would like to organise some Google handouts at different times each month - probably 3/month suiting Asia, Europe/Africa and the Americas. Would others be interested in meeting for a chat every month, with Video. We could use GoToWebinar for some more formal gatherings. Cheers, Sam -Original Message- From: openehr-technical-bounces at lists.openehr.org [mailto:openehr- technical-bounces at lists.openehr.org] On Behalf Of Shinji KOBAYASHI Sent: Friday, 2 March 2012 10:40 AM To: For openEHR technical discussions Subject: Re: openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL Hi all, Can I resume this topic? I am much looking forward to meeting this conference. I know there are many problems, but just to do it very great for us. Regards, Shinji 2012/1/13 Thomas Beale thomas.beale at oceaninformatics.com: On 13/01/2012 08:14, Ian McNicoll wrote: I do like the idea but I would prefer that each conference has its own very clear identity, albeit that some sessions could be shared, along with venue etc. A couple of the MIE conferences have operated this way with local informatics conferences being co-hosted/located with the European event, with some joint sessions but otherwise a very clear individual agenda and focus. Right - that could be a solution. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ 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
openEHR-technical Digest, Vol 67, Issue 34
Hi Sam, You might have been thinking about this: www.healthcareitnews.com/news/hl7-makes-ip-freely-available-ehrs and https://www.hl7.org/store/index.cfm?item=DAMFP Klaus _ Klaus D Veil Adj. Assoc. Professor - University of Western Sydney Vice-President - Australasian College of Health Informatics CoChair - Standards Australia IT014-06 IT014-06-03 Past Chair - HL7 Australia Certified V2.4, V2.5 V2.6 Specialist - HL7 Intl. (USA) Principal - HL7 Systems Services, Sydney, Australia Phone: +61 412 746 457 Skype: KlausDVeil Fax: +61 2 9475 0303e-Mail: Klaus at Veil.net.au Profile: www.Veil.net.au http://www.veil.net.au/ -Original Message- From: openehr-technical-boun...@lists.openehr.org [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Sam Heard Sent: Monday, 19 March 2012 09:34 To: 'For openEHR technical discussions' Subject: RE: openEHR-technical Digest, Vol 67, Issue 34 Hi Tim HL7 Twittered about making things more openly available the other daydoes anyone have the link? Cheers, Sam -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Timothy Cook Sent: Thursday, 23 February 2012 4:44 AM To: For openEHR technical discussions Subject: Re: openEHR-technical Digest, Vol 67, Issue 34 How can anyone say that HL7 is open in any fashion? You are not free to distribute it outside of your organization except in small parts so that the specifications cannot reproduced. See the paragraph immediately preceding the one previously quoted here: HL7 CORPORATE/ORGANIZATIONAL MEMBERS are authorized to: reproduce and distribute Material on an internal basis solely for use within their organization; reproduce and distribute excerpts of Material (not entire domains or chapters) to any customers of a product or service implementing those Material, provided that the HL7 Access database may not be included, either in whole or in part, in any product intended for direct or indirect commercial resale; use excerpts of Material to create customized implementation guides; and use Material in the development of software applications and messaging systems for direct use or distribution without additional licensing fees. There is NOTHING open about this, fee paid or not. --Tim On Mon, Feb 20, 2012 at 17:55, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 20/02/2012 22:34, William Goossen wrote: Hi Heath, Thomas, My experience is that HL7 v3 is an open standard and OpenEHR is proprietary (as owned by the OpenEHR foundation holding the copyrights, albeit I understand that work is underway to sort that out). Correction: HL7 is open, although requires a small fee for use; openEHR is an open and free specification. Neither are proprietary; proprietary essentially means 'not openly published and usable'. That does not apply to either HL7 or openEHR. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Timothy Cook, MSc LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/af4dbdcc/attachment-0001.html
Units, Quantities, etc
Graham, I'm trying to make sense of this discussion around computability -- what are the kinds of things that one wants to compute with these kinds of countable things? michael On 18/03/12 10:57 PM, Grahame Grieve grahame at healthintersections.com.au wrote: Are discrete units only encountered in administrative directives? Do you prohibit people from making observations or measurements that include discrete units such as puffs, tablets, patches, vials, strips etc? why? HL7 does because we claim that you have to have UCUM codes so the data can be computable. If people simply want to exchange it in a structured but non-computable fashion... they can go to hell. And as for computable: we insist on a ucum code, and then say that for these discrete unit kind of things, well, you just put 1 for countable units, and then put the effective unit somewhere else - somewhere that no one can actually pull off in practice - because this is more computable. Huh? We do not make sense on this. So much for HL7... what's openEHR's excuse? Grahame On Sun, Mar 18, 2012 at 11:18 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: As Grahame mentioned on an earlier post, the question of units is thorny. Although we technical people would like to mandate UCUM or some other well-designed computable syntax, on its own, it won't work. There seem to be two reasons for this: it doesn't take care of the need for a displayable form of units, e.g. the computable form 'mcg' or 'ug', where as the displayable is '?g' (Greek mu followed by 'g') it doesn't take care of 'units' like puffs, tablets, patches, vials, strips, and other discrete delivery units it doesn't take care of discrete delivery units per time, e.g. '2 puffs / hour' Grahame and others have already done a lot of thinking on this here - there are a lot of excellent examples from Linda Bird on the Singapore programme. The more I think about the last two above, the more I think it is not about quantities per se but about an administration directive (how the patient should take something). Trying to make Quantity do that kind of stuff doesn't make sense to me - there is obviously a Quantity to indicate the dose in scientific form, but another data element may be needed to indicate how (in what discrete measures) to take the medication. I would therefore expect a distinct data element in the Medication Cluster archetype rather than a re-engineered Quantity type to deal with these last two. For the first one - displayable v computable, we will need a CR to change DV_QUANTITY, and make it work like the FHIR Quantity - i.e. have a second units field. Some of my earlier thoughts are actually on the above wiki page - the concept of a DiscretisedQuantity type inheriting from Quantity, which I think is also a reasonable alternative. what do others think? - thomas ___ 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
Units, Quantities, etc
for me, conversion between different units that are comparable. You should ask Tom what else he thinks it yields up. I'd be interested. Grahame On Mon, Mar 19, 2012 at 11:06 AM, Michael.Lawley at csiro.au wrote: Graham, I'm trying to make sense of this discussion around computability -- what are the kinds of things that one wants to compute with these kinds of countable things? michael On 18/03/12 10:57 PM, Grahame Grieve grahame at healthintersections.com.au wrote: Are discrete units only encountered in administrative directives? Do you prohibit people from making observations or measurements that include discrete units such as puffs, tablets, patches, vials, strips etc? why? HL7 does because we claim that you have to have UCUM codes so the data can be computable. If people simply want to exchange it in a structured but non-computable fashion... they can go to hell. And as for computable: we insist on a ucum code, and then say that for these discrete unit kind of things, well, you just put 1 for countable units, and then put the effective unit somewhere else - somewhere that no one can actually pull off in practice - because this is more computable. Huh? We do not make sense on this. So much for HL7... what's openEHR's excuse? Grahame On Sun, Mar 18, 2012 at 11:18 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: As Grahame mentioned on an earlier post, the question of units is thorny. Although we technical people would like to mandate UCUM or some other well-designed computable syntax, on its own, it won't work. There seem to be two reasons for this: it doesn't take care of the need for a displayable form of units, e.g. the computable form 'mcg' or 'ug', where as the displayable is '?g' (Greek mu followed by 'g') it doesn't take care of 'units' like puffs, tablets, patches, vials, strips, and other discrete delivery units it doesn't take care of discrete delivery units per time, e.g. '2 puffs / hour' Grahame and others have already done a lot of thinking on this here - there are a lot of excellent examples from Linda Bird on the Singapore programme. The more I think about the last two above, the more I think it is not about quantities per se but about an administration directive (how the patient should take something). Trying to make Quantity do that kind of stuff doesn't make sense to me - there is obviously a Quantity to indicate the dose in scientific form, but another data element may be needed to indicate how (in what discrete measures) to take the medication. I would therefore expect a distinct data element in the Medication Cluster archetype rather than a re-engineered Quantity type to deal with these last two. For the first one - displayable v computable, we will need a CR to change DV_QUANTITY, and make it work like the FHIR Quantity - i.e. have a second units field. Some of my earlier thoughts are actually on the above wiki page - the concept of a DiscretisedQuantity type inheriting from Quantity, which I think is also a reasonable alternative. what do others think? - thomas ___ 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 ___ 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
Are you doing an academic project using openEHR?
Hi Thomas, we are here: http://www.openehr.org/shared-resources/usage/nonprofit.html -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 19 Mar 2012 00:13:22 + From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: Are you doing an academic project using openEHR? On 18/03/2012 17:45, pablo pazos wrote: Hi Thomas, Armando Prieto and Juan Escalante are students from Venezuela, they took our Open EHRGen framework and improve it to create an EMR for the SOS Telemedicine for Venezuela project. They can give you more information about the project specifics. We don't have an entry for openEHRGen either - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/d65a3091/attachment.html
Units, Quantities, etc
Hi Linda, I think your first example demonstrates why tablet is not a Unit -- I could equally say: 2 Mountains of Paracetamol 500 mg + Codeine Phosphate 15mg Mountains is therapeutically equivalent to 1 Mountain of Paracetamol 1g + Codeine Phosphate 30 mg Mountains Really what I am saying here is: 2 of Paracetamol 500 mg + Codeine Phosphate 15mg Tablet is therapeutically equivalent to 1 of Paracetamol 1g + Codeine Phosphate 30 mg Tablet In your next example, both orders are for 500mg of Amoxicllin in capsule form but the second case also says 1 capsule and carries with it a business rule that says you cannot convert this. However, it still doesn't change the therapeutically equivalent relation. That is, therapeutically equivalence should be treated separately from can be substituted for when dispensing. michael From: linda at mybirdfamily.commailto:linda at mybirdfamily.com linda at mybirdfamily.commailto:li...@mybirdfamily.com Reply-To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Date: Mon, 19 Mar 2012 14:56:39 +1100 To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Subject: RE: Units, Quantities, etc Ok ... can't resist replying ... Doesn't 'computability' depend on having clearly defined rules on how the UOMs relate to each other? Yes, UCUM provides this - however I don't understand why (in the context of a national program), we would exclude another terminology-based knowledge source (e.g. a SNOMED CT extension) providing these computational rules. If, for example, we referred to 2 tablets of Paracetamol 500 mg + Codeine Phosphate 15 mg Tablet, and we have a knowledge base that tells us that each of these tablets has 500 mg of Paracetamol and 15 mg of Codeine Phosphate, then we can compute that: 2 tablets of Paracetamol 500 mg + Codeine Phosphate 15mg Tablet is therapeutically equivalent to 1 tablet of Paracetamol 1g + Codeine Phosphate 30 mg Tablet This is just one of many 'computations' which are possible with an additional knowledge base that is very useful for decision-support purposes. Clinicians may order 500 mg of Amoxicillin Capsules, or 1 capsule of Amoxicllin 500 mg Capsule ... and these actually mean different things (the former could either mean 1 x 500 mg capsule, 2 x 250 mg capsules, etc; while the later specifically means 1 x 500 mg capsule). In the case of simple dosing, clinicians would expect to see only 2 fields - dose_value and dose_units, irrespective of whether the units is mg or capsules ... with the knowledge base determining the 'computability' rules. Regards, Linda. ___ Dr Linda Bird Information Architect Ph: 0411 274 870 Original Message Subject: Re: Units, Quantities, etc From: Grahame Grieve grahame at healthintersections.com.aumailto:grah...@healthintersections.com.au Date: Mon, March 19, 2012 12:15 pm To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org for me, conversion between different units that are comparable. You should ask Tom what else he thinks it yields up. I'd be interested. Grahame On Mon, Mar 19, 2012 at 11:06 AM, Michael.Lawley at csiro.aumailto:Michael.Lawley at csiro.au wrote: Graham, I'm trying to make sense of this discussion around computability -- what are the kinds of things that one wants to compute with these kinds of countable things? michael On 18/03/12 10:57 PM, Grahame Grieve grahame at healthintersections.com.aumailto:grahame at healthintersections.com.au wrote: Are discrete units only encountered in administrative directives? Do you prohibit people from making observations or measurements that include discrete units such as puffs, tablets, patches, vials, strips etc? why? HL7 does because we claim that you have to have UCUM codes so the data can be computable. If people simply want to exchange it in a structured but non-computable fashion... they can go to hell. And as for computable: we insist on a ucum code, and then say that for these discrete unit kind of things, well, you just put 1 for countable units, and then put the effective unit somewhere else - somewhere that no one can actually pull off in practice - because this is more computable. Huh? We do not make sense on this. So much for HL7... what's openEHR's excuse? Grahame On Sun, Mar 18, 2012 at 11:18 PM, Thomas Beale thomas.beale at oceaninformatics.commailto:thomas.beale at oceaninformatics.com wrote: As Grahame mentioned on an earlier post, the question of units is thorny. Although we technical people would like to mandate UCUM or some other well-designed computable syntax, on its own, it won't work. There seem to be two reasons for this:
Units, Quantities, etc
On Mar 18, 2012 9:15 PM, Grahame Grieve grahame at healthintersections.com.au wrote: for me, conversion between different units that are comparable. You should ask Tom what else he thinks it yields up. I'd be interested. Grahame On Mon, Mar 19, 2012 at 11:06 AM, Michael.Lawley at csiro.au wrote: Graham, I'm trying to ... -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/b7a7a778/attachment.html
Units, Quantities, etc
Well I'm still stuck trying to understand what you mean by 'computable'. And, no, a clinician cannot prescribe (just) 2 tablets -- I cannot compare that with 500 mg unless I know how much is in each tablet. Once you've told me how much is in each tablet, then (from a computability perspective), I may as well have just said 2 units. michael From: linda at mybirdfamily.commailto:linda at mybirdfamily.com linda at mybirdfamily.commailto:li...@mybirdfamily.com Reply-To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Date: Mon, 19 Mar 2012 16:26:31 +1100 To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Subject: RE: Units, Quantities, etc Sorry Michael - I don't follow your reasoning. In clinical practice, a clinician may either order a dose of '2 tablets' or alternatively '500 mg'. I would argue that these are both equally 'computable', given the appropriate knowledge base. Regards, Linda. ___ Dr Linda Bird Information Architect Ph: 0411 274 870 Original Message Subject: Re: Units, Quantities, etc From: Michael.Lawley at csiro.aumailto:michael.law...@csiro.au Date: Mon, March 19, 2012 3:03 pm To: openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Hi Linda, I think your first example demonstrates why tablet is not a Unit -- I could equally say: 2 Mountains of Paracetamol 500 mg + Codeine Phosphate 15mg Mountains is therapeutically equivalent to 1 Mountain of Paracetamol 1g + Codeine Phosphate 30 mg Mountains Really what I am saying here is: 2 of Paracetamol 500 mg + Codeine Phosphate 15mg Tablet is therapeutically equivalent to 1 of Paracetamol 1g + Codeine Phosphate 30 mg Tablet In your next example, both orders are for 500mg of Amoxicllin in capsule form but the second case also says 1 capsule and carries with it a business rule that says you cannot convert this. However, it still doesn't change the therapeutically equivalent relation. That is, therapeutically equivalence should be treated separately from can be substituted for when dispensing. michael From: linda at mybirdfamily.commailto:linda at mybirdfamily.commailto:linda at mybirdfamily.com linda at mybirdfamily.commailto:linda at mybirdfamily.commailto:li...@mybirdfamily.com Reply-To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Date: Mon, 19 Mar 2012 14:56:39 +1100 To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Subject: RE: Units, Quantities, etc Ok ... can't resist replying ... Doesn't 'computability' depend on having clearly defined rules on how the UOMs relate to each other? Yes, UCUM provides this - however I don't understand why (in the context of a national program), we would exclude another terminology-based knowledge source (e.g. a SNOMED CT extension) providing these computational rules. If, for example, we referred to 2 tablets of Paracetamol 500 mg + Codeine Phosphate 15 mg Tablet, and we have a knowledge base that tells us that each of these tablets has 500 mg of Paracetamol and 15 mg of Codeine Phosphate, then we can compute that: 2 tablets of Paracetamol 500 mg + Codeine Phosphate 15mg Tablet is therapeutically equivalent to 1 tablet of Paracetamol 1g + Codeine Phosphate 30 mg Tablet This is just one of many 'computations' which are possible with an additional knowledge base that is very useful for decision-support purposes. Clinicians may order 500 mg of Amoxicillin Capsules, or 1 capsule of Amoxicllin 500 mg Capsule ... and these actually mean different things (the former could either mean 1 x 500 mg capsule, 2 x 250 mg capsules, etc; while the later specifically means 1 x 500 mg capsule). In the case of simple dosing, clinicians would expect to see only 2 fields - dose_value and dose_units, irrespective of whether the units is mg or capsules ... with the knowledge base determining the 'computability' rules. Regards, Linda. ___ Dr Linda Bird Information Architect Ph: 0411 274 870 Original Message Subject: Re: Units, Quantities, etc From: Grahame Grieve grahame at healthintersections.com.aumailto:grahame at healthintersections.com.aumailto:grah...@healthintersections.com.au Date: Mon, March 19, 2012 12:15 pm To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org for me, conversion between
Units, Quantities, etc
# This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal # IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The CTC is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the CTC. If you receive this e-mail in error, please immediately delete it and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. # -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/a3051c9a/attachment-0001.html
openEHR (local) terminologies
The URL to the terminology file as part of a minimum terminology service is here, http://www.openehr.org/svn/ref_impl_java/TRUNK/mini-termserv/src/main/resources/openehr_terminology_en.xml Cheers, Rong On 18 March 2012 23:32, Sam Heard sam.heard at oceaninformatics.com wrote: Hi Diego Rong has made this generally available - or it is in the download of the archetype editor. Cheers, Sam -Original Message- From: openehr-technical-bounces at lists.openehr.org [mailto:openehr- technical-bounces at lists.openehr.org] On Behalf Of Diego Bosc? Sent: Thursday, 1 March 2012 8:39 PM To: For openEHR technical discussions Subject: openEHR (local) terminologies I sent this email when I thought the migration process was over, but it wasn't. I am sending it again, sorry if someone receives two copies :) Is there any place where openEHR local terminology files (e.g. the possible values from C_DV_QUANTITY.property or DV_CODED_TEXT.defining_code) can be viewed? (as code/description tables) Regards ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr- technical_lists.openehr.org
Regarding the available Template XML schema
Hi Athanasios, Ocean operational template (Template.xsd) and thew proposed TOM changes marry up as Operational Templates. As I understand it the proposed TOM operational template schema is virtually identical to the current Ocean operational template template.xsd. Would the following be correct? 1) A template is archetypeable which means that it too will have an ID and its own path prefix Yes, all that happens is that the archetyped data carries a template identifier, in addition to the archetypeID. Querying can completely ignore the templating aspect. 3) A template must contain section elements. These are archetypeable entities. Each section describes a list of archetypeable Items. No - Section elements are completely optional and only apply to Composition templates - see below. 4) A template might contain subsection elements if this is required. Yes 2) A template must contain a composition which contains a list of archetypeable Items. No - Templates can be applied to any archetype. Many templates will be at Composition level but others just add constraints to Entry or even Cluster archetypes. We call these embedded templates in the Ocean tools and as the name suggests these can be re-used within other templates. Just think of templates as another layer of constraint. In ADL1.5, templates and specialised archetypes are essentially identical. The only difference (yet to be decided) is that templates cannot add new content. Both can further constrain their parent. On 16 March 2012 14:08, Athanasios Anastasiou athanasios.anastasiou at plymouth.ac.uk wrote: Hello everyone I was wondering if there are any updates regarding openEHR Templates? I am not sure how the material in the TOM (http://www.openehr.org/svn/** specification/TRUNK/**publishing/architecture/am/**tom.pdfhttp://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/tom.pdf) maps to the currently available XSD at (http://www.openehr.org/** releases/1.0.2/its/XML-schema/**Template.xsdhttp://www.openehr.org/releases/1.0.2/its/XML-schema/Template.xsd ) Would the following be correct? 1) A template is archetypeable which means that it too will have an ID and its own path prefix 3) A template must contain section elements. These are archetypeable entities. Each section describes a list of archetypeable Items. 4) A template might contain subsection elements if this is required. 2) A template must contain a composition which contains a list of archetypeable Items. Therefore to build a Template, one would first need to list the composing archetypes as Items of subsections (if subsections are required). Then list the subsections as items of sections and finally, list sections as items of the Composition. And this concludes at least with the structural part (?) 3) A template must contain either Observation or Evaluation elements (depending on the nature of the template (?)) that describe lists of Entry. These elements set the default values of the composing archetypes individual fields through a series of Statements. (or evaluate expressions) Would this be an accurate description? Looking forward to hearing from you Athanasios Anastasiou __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://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 Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor 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/20120319/25dcef71/attachment.html
Units, Quantities, etc
On 19/03/2012 02:15, Grahame Grieve wrote: for me, conversion between different units that are comparable. You should ask Tom what else he thinks it yields up. I'd be interested. Grahame * * well any mathematical operation working on quantities - e.g. averages, max, min, variance, standard deviation etc etc. These kind of operations are ubiquitous in research queries, and will become increasingly so in personal health records. Just consider what is needed to determine the actual amount of tobacco consumed by each of 10,000 patients in a cohort - each of whom report their usage in terms of 'tailor-made cigarettes', 'hand-rolled cigarettes', 'cigars', 'chewing tobacco' (okay not popular, but still in use in some places!), 'grams a week (of pipe tobacco)', etc etc. Some patients have a mixture of these. Same argument for amounts of drugs taken by patients in a cancer study, amounts of sugar, salt, cholesterol computed from food recorded in patient diet and so on. How about a query that finds all patients with blood sugar over 7? What if they input the data (at home) in different unit systems due to different equipment? We simply can't do any useful /computing /if we can't trust the data. We don't do that much computing now with it because of the unreliability of the available data, but the only interesting future really is being able to do intelligent computing with the data. To get there we have to be able to compute reliably with quantities. I have no problem with data that records only 'puffs', 'patches', 'pessaries', 'pills', 'pellets' or 'powder' but we don't want to compromise data that record normal scientific quantities. Therefore I think we should be treating these kind of amounts as a separate type. This is distinct from the problem of Quantities that do have scientific units, but there is a conflict with the displayable form. I think we should accommodate that in the current data type - a small modification would take care of that. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/d866d2e2/attachment.html
Units, Quantities, etc
Dear all, On s?n, 2012-03-18 at 13:57 +0100, Grahame Grieve wrote: Are discrete units only encountered in administrative directives? Do you prohibit people from making observations or measurements that include discrete units such as puffs, tablets, patches, vials, strips etc? There are examples of counting observables in both the laboratory and clinical domains like number of erythrocytes in urine, number of complement C3b receptors on thrombocytes, number of petechiae of skin per cm^2. If for example assuming the SI system base quantities, the kind of quantity is number with N as symbol and 1 or one as the unit. Comparing to another commonly known kind of quantity, length, and the unit meter, 1.83 m means 1.83 times the length of the Paris meter. Further, my body height quantity inheres in my body and the unit meter may be used to represent the length on a ratio scale, i.e. my body height = 1.83 m or 1.83 times the Paris meter. However, this quantity may be represented using other units such as the International foot. Going back to tablets, in 2 tablets 500 mg paracetamol the part tablets 500 mg paracetamol is not just a point of reference for representing the number quantity but part if of the quantity being observed (or stated). This part cannot be exchanged and thus cannot be a unit. The DV_QUANTITY class has no attribute for specifying the kind of quantity of which the magnitude field is a result of observation (or decision). Previously, this has been managed within archetypes, e.g. the systolic blood pressure quantity is referred to by binding the at0004 code to the term Systolic and through this node's context within the archetype. In instances, there is no reference to any kind of quantity apart from units, which do not fully describe the kind of quantity, and any reference to the archetype on which the instance is based. Thus, my 2-cent suggestion is to stay on the path, keep DV_QUANTITY clean, and manage any issues around representation of doses in archetypes. Finally, there is the whole science of metrology backing this up. Please refrain from giving this solid ground up. Regards, Daniel why? HL7 does because we claim that you have to have UCUM codes so the data can be computable. If people simply want to exchange it in a structured but non-computable fashion... they can go to hell. And as for computable: we insist on a ucum code, and then say that for these discrete unit kind of things, well, you just put 1 for countable units, and then put the effective unit somewhere else - somewhere that no one can actually pull off in practice - because this is more computable. Huh? We do not make sense on this. So much for HL7... what's openEHR's excuse? Grahame On Sun, Mar 18, 2012 at 11:18 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: As Grahame mentioned on an earlier post, the question of units is thorny. Although we technical people would like to mandate UCUM or some other well-designed computable syntax, on its own, it won't work. There seem to be two reasons for this: it doesn't take care of the need for a displayable form of units, e.g. the computable form 'mcg' or 'ug', where as the displayable is '?g' (Greek mu followed by 'g') it doesn't take care of 'units' like puffs, tablets, patches, vials, strips, and other discrete delivery units it doesn't take care of discrete delivery units per time, e.g. '2 puffs / hour' Grahame and others have already done a lot of thinking on this here - there are a lot of excellent examples from Linda Bird on the Singapore programme. The more I think about the last two above, the more I think it is not about quantities per se but about an administration directive (how the patient should take something). Trying to make Quantity do that kind of stuff doesn't make sense to me - there is obviously a Quantity to indicate the dose in scientific form, but another data element may be needed to indicate how (in what discrete measures) to take the medication. I would therefore expect a distinct data element in the Medication Cluster archetype rather than a re-engineered Quantity type to deal with these last two. For the first one - displayable v computable, we will need a CR to change DV_QUANTITY, and make it work like the FHIR Quantity - i.e. have a second units field. Some of my earlier thoughts are actually on the above wiki page - the concept of a DiscretisedQuantity type inheriting from Quantity, which I think is also a reasonable alternative. what do others think? - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
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
