openEHR / FHIR data types cross analysis

[Grahame Grieve]

Hey Sam

it's a good day when you can upset both Tom and I equally in a single
paragraph.

Grahame


On Mon, Mar 19, 2012 at 9:24 AM, Sam Heard
wrote:

> Sorry about the Eiffel slur J
>
> Cheers, Sam
>
> ** **
>
> *From:* openehr-technical-bounces at lists.openehr.org [mailto:
> openehr-technical-bounces at lists.openehr.org] *On Behalf Of *Thomas Beale
> *Sent:* Monday, 19 March 2012 8:18 AM
> *To:* openehr-technical at lists.openehr.org
>
> *Subject:* Re: openEHR / FHIR data types cross analysis
>
> ** **
>
>
> Actually, Eiffel has nothing to do with it (I wrote my own date/time
> libraries based on ISO 8601 semantics). What I am influenced by is what I
> see in CKM and other repositories.
>
> openEHR CKM
>
>
>
> NEHTA CKM
>
>
> On 18/03/2012 21:00, Sam Heard wrote: 
>
> Hi
>
> ** **
>
> This is an interesting discussion. It seems that we might have hit the 
> issue
>
> of defining data types independent of a reference model. In a reference
>
> model we do want to know that there are a limited set of types (formally
>
> expressed) that can be used at any point.
>
> ** **
>
> I was influenced by the discussion at CIMI that demonstrated this.
>
> ** **
>
> So the sort of textural elements you have within the datatypes that allow
>
> someone to say Autumn for datetime (HumanDate) are probably best dealt 
> with
>
> in models where that is appropriate and with a suitable set of
>
> terminologies.
>
> ** **
>
> An uncertain datetime is better for processing than a text (soon after my
>
> mother died). There is no doubt about the usefulness of the text, just 
> that
>
> it does not belong in a date field.
>
> ** **
>
> The FHIR may be suitable for messages at this point in time, if so, it is
>
> easy to port information to this.
>
> ** **
>
> Let's keep this thread alive and get a little broader input. Thomas is
>
> influenced by Eiffel, Grahame by XML. Most developers will probably sit
>
> somewhere in between in terms of requirements for rigor.
>
> ** **
>
> Cheers, Sam
>
> * *
>
> * *
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>



-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au/ +61 411 867 065
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/c2fb256f/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 19995 bytes
Desc: not available
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/c2fb256f/attachment-0002.png>
-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 21360 bytes
Desc: not available
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/c2fb256f/attachment-0003.png>

Units, Quantities, etc

[Colin Sutton]

o:grahame at 
>>healthintersections.com.au><mailto:grahame at healthintersections.com.au> / 
>>+61 411 867 065
>>
>>___
>>openEHR-technical mailing list
>>openEHR-technical at lists.openehr.org<mailto:openEHR-technical at 
>>lists.openehr.org><mailto: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<mailto:openEHR-technical at 
> lists.openehr.org><mailto: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<mailto:grahame at 
healthintersections.com.au><mailto:grahame at healthintersections.com.au> / +61 
411 867 065

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org<mailto:openEHR-technical at 
lists.openehr.org><mailto: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<mailto:openEHR-technical at 
lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

#
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>

Units, Quantities, etc

[michael.law...@csiro.au]

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.com" mailto:li...@mybirdfamily.com>>
Reply-To: For openEHR technical discussions mailto:openehr-technical at lists.openehr.org>>
Date: Mon, 19 Mar 2012 16:26:31 +1100
To: For openEHR technical discussions mailto: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: mailto:michael.law...@csiro.au>>
Date: Mon, March 19, 2012 3:03 pm
To: mailto: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.com" mailto:linda at 
mybirdfamily.com>>>
Reply-To: For openEHR technical discussions mailto:openehr-technical at 
lists.openehr.org>>>
Date: Mon, 19 Mar 2012 14:56:39 +1100
To: For openEHR technical discussions mailto: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 Capsule"s, 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 mailto:grahame at 
healthintersections.com.au>>>
Date: Mon, March 19, 2012 12:15 pm
To: For openEHR technical discussions
mailto: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, mailto:Michael.Lawley at csiro.au>>> wrote:
>
> Graha

Units, Quantities, etc

[michael.law...@csiro.au]

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.com" mailto:li...@mybirdfamily.com>>
Reply-To: For openEHR technical discussions mailto:openehr-technical at lists.openehr.org>>
Date: Mon, 19 Mar 2012 14:56:39 +1100
To: For openEHR technical discussions mailto: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 Capsule"s, 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 mailto:grah...@healthintersections.com.au>>
Date: Mon, March 19, 2012 12:15 pm
To: For openEHR technical discussions
mailto: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, mailto: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"
> mailto: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
>>mailto: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 'u

openEHR (local) terminologies

[Diego Boscá]

Thank you both, I found a page on the website
(http://www.openehr.org/releases/1.0.2/architecture/computable/terminology/terminology.html),
but seemed a bit outdated so I took the interesting tables from the
specifications pdf. I will check that the terms are the same

Regards

2012/3/19 Rong Chen :
> 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  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
>>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Units, Quantities, etc

[Grahame Grieve]

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,   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"
>  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
>> 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

openEHR-technical Digest, Vol 67, Issue 34

[Klaus D Veil]

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
>  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

[Daniel Karlsson]

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
>  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 conference - proposal for Lake Bled, Slovenia 2012 - POLL

[Shinji KOBAYASHI]

Hi Sam,

As regards to world-wide economic recession, getting fund for R&D
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 :
> 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 :
>> > 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

Units, Quantities, etc

[michael.law...@csiro.au]

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"
 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
> 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

[Grahame Grieve]

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
 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

[Thomas Beale]

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>

openEHR (local) terminologies

[Rong Chen]

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  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

[Ian McNicoll]

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.pdf<http://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.xsd<http://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 "Statement"s. (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.org lists.openehr.org>
> http://lists.openehr.org/**mailman/listinfo/openehr-**
> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
>



-- 
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

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>

openEHR-technical Digest, Vol 67, Issue 34

[Sam Heard]

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
>  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 conference - proposal for Lake Bled, Slovenia 2012 - POLL

[Dra Carola Hullin Lucay Cossio]

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 :
> > > 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 (local) terminologies

[Sam Heard]

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

[Sam Heard]

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

visualizing AQL result

[Sam Heard]

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 conference - proposal for Lake Bled, Slovenia 2012 - POLL

[Sam Heard]

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 :
> > 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

[Sam Heard]

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 :
> > 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 / FHIR data types cross analysis

[Grahame Grieve]

> 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
>>  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.
>> >>
>> >> >> Shou

openEHR / FHIR data types cross analysis

[Sam Heard]

Sorry about the Eiffel slur J

Cheers, Sam

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Thomas
Beale
Sent: Monday, 19 March 2012 8:18 AM
To: openehr-technical at lists.openehr.org
Subject: Re: openEHR / FHIR data types cross analysis

 


Actually, Eiffel has nothing to do with it (I wrote my own date/time
libraries based on ISO 8601 semantics). What I am influenced by is what I
see in CKM and other repositories.

openEHR CKM



NEHTA CKM


On 18/03/2012 21:00, Sam Heard wrote: 

Hi
 
This is an interesting discussion. It seems that we might have hit the issue
of defining data types independent of a reference model. In a reference
model we do want to know that there are a limited set of types (formally
expressed) that can be used at any point.
 
I was influenced by the discussion at CIMI that demonstrated this.
 
So the sort of textural elements you have within the datatypes that allow
someone to say Autumn for datetime (HumanDate) are probably best dealt with
in models where that is appropriate and with a suitable set of
terminologies.
 
An uncertain datetime is better for processing than a text (soon after my
mother died). There is no doubt about the usefulness of the text, just that
it does not belong in a date field.
 
The FHIR may be suitable for messages at this point in time, if so, it is
easy to port information to this.
 
Let's keep this thread alive and get a little broader input. Thomas is
influenced by Eiffel, Grahame by XML. Most developers will probably sit
somewhere in between in terms of requirements for rigor.
 
Cheers, Sam
 
 
 
 
 
 
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/2e05a44e/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 21360 bytes
Desc: not available
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/2e05a44e/attachment-0002.png>
-- next part --
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 19995 bytes
Desc: not available
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/2e05a44e/attachment-0003.png>

openEHR / FHIR data types cross analysis

[Sam Heard]

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
>  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 a

Units, Quantities, etc

[Grahame Grieve]

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
 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

[Grahame Grieve]

> 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

openEHR / FHIR data types cross analysis

[Grahame Grieve]

> 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

[Heath Frankel]

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>

openEHR / FHIR data types cross analysis

[Grahame Grieve]

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
 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
>> i

openEHR / FHIR data types cross analysis

[Sam Heard]

Hi

This is an interesting discussion. It seems that we might have hit the issue
of defining data types independent of a reference model. In a reference
model we do want to know that there are a limited set of types (formally
expressed) that can be used at any point.

I was influenced by the discussion at CIMI that demonstrated this.

So the sort of textural elements you have within the datatypes that allow
someone to say Autumn for datetime (HumanDate) are probably best dealt with
in models where that is appropriate and with a suitable set of
terminologies.

An uncertain datetime is better for processing than a text (soon after my
mother died). There is no doubt about the usefulness of the text, just that
it does not belong in a date field.

The FHIR may be suitable for messages at this point in time, if so, it is
easy to port information to this.

Let's keep this thread alive and get a little broader input. Thomas is
influenced by Eiffel, Grahame by XML. Most developers will probably sit
somewhere in between in terms of requirements for rigor.

Cheers, Sam


> -Original Message-
> From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
> technical-bounces at lists.openehr.org] On Behalf Of Grahame Grieve
> Sent: Sunday, 18 March 2012 11:50 PM
> To: For openEHR technical discussions
> Subject: Re: openEHR / FHIR data types cross analysis
> 
> >> I just wasn't thinking what I wrote this. In FHIR, a boolean data
> >> type, primitive, is a type that can be used in models an is exactly
> >> equivalent to DV_BOOLEAN.
> >
> > but isn't the problem that it doesn't inherit from some DATA_VALUE
> > parent type (Any in HL7 data types)? How can it be one of the
> possible
> > values in a location like ELEMENT.value which would be statically
> > typed to this parent type (as it is in 13606, HL7 RIM and openEHR)
> > unless it is a descendant of this type?
> 
> FHIR has no such restriction - elements must have a type of one or more
> of the defined types, either primitive or complex
> 
> >>> Well, this is the HL7 modelling mentality, trying to create a data
> >>> type class with all possible attributes, some of which can be
> >>> removed in some subclass.
> >>
> >> not at all. nothing is removed in FHIR. There are some data types
> >> where attributes in the superclass are constrained by the
> definitions
> >> in the subclass.
> >> You do the same.
> >
> > do we?
> 
> yes, check out DV_EHR_URI - this is exactly the same pattern for
> exactly the same reason
> 
> > does anyone use the Java.util calendar type? It's hopeless for dates
> > and times!
> 
> I use java.util.Date. don't know anything about calendar. but so what.
> 
> > I think it is mostly the latter - Date is usually used when time info
> > is really not of interest or expected.
> 
> why shouldn't the relationship between date and datetime be the same as
> that between DV_EHR_URI and DV_URI? I haven't defined that, but that
> would be the natural way to do it in FHIR.
> 
> > I want a spec that looks like an openEHR spec ;-) That's useful
> 
> I don't think I'll do exactly like (framemaker!), but others have asked
> for a formal computable statement of constraints.
> 
> >> Should I do anything about them, or are they just there because they
> >> were thinking of straight text? Do they think
> formatting/hyperlinking
> >> is important?
> >
> > that can be constrained in the archetype as well.
> 
> but it generally isn't - and can't be in the archetype builder.
> So I don't know what was intended.
> 
> >> DV_TEXT is a text, optionally with mappings. DV_CODED_TEXT elevates
> >> one of the mappings to being "defining".
> >
> > well 'defining_code' isn't a mapping; a mapping by definition is an
> > association between two things from two different models or
> > ontologies. A defining code is the code corresponding to the text
> > (description) in the value field.
> 
> really? Sounds like a clear difference until you start working at the
> instance level. Say I have a field in which I want to put the concept
> "Asthma". The Snomed-CT code for this is 195967001: Asthma. I didn't
> get his either by NLP, or by user input - it's configured as part of a
> process.
> 
> Now the interpretation of of DV_TEXT is text, possibly with a code. So
> when I'm going to represent that, I'll use DV_TEXT of "asthma" with a
> mapping to snomed code 195967001 in the mappings. The mapping type will
> be 
> hell, I don't know, does anyone use that, and what do they put in it?
> I don't know whether the Purpose_valid invariant means I need one or
> not (Group_id_term_mapping_purpose is not defined anywhere that I can
> find, for example), but I think not. Anyhow, my snomed code goes in a
> mapping. I can't imagine any normal implementer would think differently
> on this point.
> 
> But if I'm doing a DV_CODED_TEXT, then the snomed code goes on the
> defining_code instead of a mapping.
> 
> >> Does that mean that a DV_TEXT couldn't have a "defining" code
> >> 

Units, Quantities, etc

[Ed Dodds]

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,  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>

Are you doing an academic project using openEHR?

[Thomas Beale]

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>

Units, Quantities, etc

[Thomas Beale]

On 18/03/2012 22:21, Stef Verlinden wrote:
>
> Verstuurd vanaf mijn iPhone
>
> Op 18 mrt. 2012 om 15:15 heeft Thomas Beale 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>

Units, Quantities, etc

[Thomas Beale]

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>

Are you doing an academic project using openEHR?

[pablo pazos]

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>