openEHR / FHIR data types cross analysis

[Ian McNicoll]

Hi all,

A few belated comments on Booleans. In my experience there are a few
genuine booleans in clinical data e.g. "Is the prostate specimen present
Y/N" in the context of histopath . Well it either is or it ain't. Not much
use for null flavours or 'yes ... but' , but in most circumstances the
Yes/No construct is essentially a mangled clinical statement with all the
ifs, buts and maybes that implies.

"Is the urine blood-stained-> Yes is equivalent to "Urine bloodstained" and
.
"Is the urine blood-stained-> No is equivalent to "Urine not bloodstained".

It is now my standard practice in virtually all cases to model these
clinical booleans as term lists, generally ensuring that the key semantics
are carried in the value i.e "Urine blood-stained" , rather than just "Yes"
but this definitely annoys developers who without clinical understanding
can find it difficult to know how to map the terms to the checkbox or
radio-button boolean paradigm in their requirements documents.

It is easy to dismiss this as just 'a GUI / presentational issue' but I
think that the clinical questionnaire pattern is actually a legitimate if
unsupported kind of clinical recording which has been largely overlooed by
informatics, and should be acknowleged and supported in openEHR., even if
the key undelying paradigm (as for HL7 and SNOMED) is the clinical
statement.

So one immediate requirement is for a DV_BOOLEAN to allow term-bindings
(including internal atCoded terms to the possible values but I think there
is whole world of interesting PhDs to be done on the subject!!


On 19 March 2012 12:40, Grahame Grieve
wrote:

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

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>

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 constraine

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 anythin

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

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
>

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 d

openEHR / FHIR data types cross analysis

[Grahame Grieve]

>> I just wasn't thinking what I wrote this. In FHIR, a boolean data
>> type, primitive, is a
>> type that can be used in models an is exactly equivalent to DV_BOOLEAN.
>
> but isn't the problem that it doesn't inherit from some DATA_VALUE parent
> type (Any in HL7 data types)? How can it be one of the possible values in a
> location like ELEMENT.value which would be statically typed to this parent
> type (as it is in 13606, HL7 RIM and openEHR) unless it is a descendant of
> this type?

FHIR has no such restriction - elements must have a type of one or more
of the defined types, either primitive or complex

>>> Well, this is the HL7 modelling mentality, trying to create a data type
>>> class with all possible attributes, some of which can be removed in some
>>> subclass.
>>
>> not at all. nothing is removed in FHIR. There are some data types where
>> attributes in the superclass are constrained by the definitions in the
>> subclass.
>> You do the same.
>
> do we?

yes, check out DV_EHR_URI - this is exactly the same pattern for
exactly the same reason

> does anyone use the Java.util calendar type? It's hopeless for dates and
> times!

I use java.util.Date. don't know anything about calendar. but so what.

> I think it is mostly the latter - Date is usually used when time info is
> really not of interest or expected.

why shouldn't the relationship between date and datetime be the same
as that between DV_EHR_URI and DV_URI? I haven't defined that, but
that would be the natural way to do it in FHIR.

> I want a spec that looks like an openEHR spec ;-) That's useful

I don't think I'll do exactly like (framemaker!), but others have asked for a
formal computable statement of constraints.

>> Should I do anything about them, or are they just there because they
>> were thinking
>> of straight text? Do they think formatting/hyperlinking is important?
>
> that can be constrained in the archetype as well.

but it generally isn't - and can't be in the archetype builder.
So I don't know what was intended.

>> DV_TEXT is a text, optionally with mappings. DV_CODED_TEXT elevates one
>> of the mappings to being "defining".
>
> well 'defining_code' isn't a mapping; a mapping by definition is an
> association between two things from two different models or ontologies. A
> defining code is the code corresponding to the text (description) in the
> value field.

really? Sounds like a clear difference until you start working at the instance
level. Say I have a field in which I want to put the concept "Asthma". The
Snomed-CT code for this is 195967001: Asthma. I didn't get his either by
NLP, or by user input - it's configured as part of a process.

Now the interpretation of of DV_TEXT is text, possibly with a code. So when I'm
going to represent that, I'll use DV_TEXT of "asthma" with a mapping to
snomed code 195967001 in the mappings. The mapping type will be 
hell, I don't know, does anyone use that, and what do they put in it?
I don't know whether the Purpose_valid invariant means I need one
or not (Group_id_term_mapping_purpose is not defined anywhere that
I can find, for example), but I think not. Anyhow, my snomed code goes
in a mapping. I can't imagine any normal implementer would think
differently on this point.

But if I'm doing a DV_CODED_TEXT, then the snomed code goes
on the defining_code instead of a mapping.

>> Does that mean that a DV_TEXT couldn't
>> have a "defining" code mapping?
> I don't think that would make sense; mappings are for things like 'billing',
> 'research project X', 'CDC coding' etc.

really? You'll have to define that difference a lot better in the spec,
because I don't see it, and because that's not how it's being used
in practice. And what's a match of "=" other than defining?

so:

> why would we want to put the defining codephrase in the mappings?

because most users couldn't tell a defining code apart from a
primary mapping in most situations.

Grahame

openEHR / FHIR data types cross analysis

[Thomas Beale]

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: 

-- next part --
A non-text attachment was scrubbed...
Name: fggghfab.png
Type: image/png
Size: 21360 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: adfjbjhd.png
Type: image/png
Size: 19995 bytes
Desc: not available
URL: 

openEHR / FHIR data types cross analysis

[Thomas Beale]

On 18/03/2012 12:49, Grahame Grieve wrote:
>>> I just wasn't thinking what I wrote this. In FHIR, a boolean data
>>> type, primitive, is a
>>> type that can be used in models an is exactly equivalent to DV_BOOLEAN.
>> but isn't the problem that it doesn't inherit from some DATA_VALUE parent
>> type (Any in HL7 data types)? How can it be one of the possible values in a
>> location like ELEMENT.value which would be statically typed to this parent
>> type (as it is in 13606, HL7 RIM and openEHR) unless it is a descendant of
>> this type?
> FHIR has no such restriction - elements must have a type of one or more
> of the defined types, either primitive or complex

ok, but how do w write a normal statically typed classes in Java or C# 
to deal with that?

>>>
>>> not at all. nothing is removed in FHIR. There are some data types where
>>> attributes in the superclass are constrained by the definitions in the
>>> subclass.
>>> You do the same.
>> do we?
> yes, check out DV_EHR_URI - this is exactly the same pattern for
> exactly the same reason

This is a pattern where all descendants in the hierarchy just have a 
String value, but the different descendants provide different ways of 
parsing it. The FHIR identifiers are done like this (by direct 
inheritance from String), so are the openEHR Identifiers (by having a 
single value: String field).

I had momentarily forgotten that you had done HumanDate like this as 
well. In FHIR, you inherit directly from String, and add syntax 
functions that parse the string in a certain way. In this case we assume 
ISO8601 date/time strings. But just having the one semantic type 
(HumanDate) based on the representation (a String) is not enough when 
building clinical models. Modellers need to be able to put Date, 
DateTime, Time (we can assume it will be required somewhere) and 
Duration (which you have as a constraint on Quantity). I am not against 
using the representation approach you have used, but it still doesn't 
provide enough semantic types.

Ideally we need semantic types whose representation could change (e.g. 
from String in messages to multiple pieces in some programming 
framework) but whose semantics stay the same.

>
>> I think it is mostly the latter - Date is usually used when time info is
>> really not of interest or expected.
> why shouldn't the relationship between date and datetime be the same
> as that between DV_EHR_URI and DV_URI? I haven't defined that, but
> that would be the natural way to do it in FHIR.

see above. It's not an argument about representation (i.e. different 
ways of parsing a String), but about semantics. We still need for 
example some thing that says that Date.diff (otherDate) produces a 
Duration.

>
>> I want a spec that looks like an openEHR spec ;-) That's useful
> I don't think I'll do exactly like (framemaker!), but others have asked for a
> formal computable statement of constraints.

haha, I didn't mean FM, just the formal specification.

>
> that can be constrained in the archetype as well.
> but it generally isn't - and can't be in the archetype builder.
> So I don't know what was intended.

I wouldn't read much into the current limitations of the Archetype 
Editor - except that there has been little demand to be able to 
constrain those fields.

>
>>> DV_TEXT is a text, optionally with mappings. DV_CODED_TEXT elevates one
>>> of the mappings to being "defining".
>> well 'defining_code' isn't a mapping; a mapping by definition is an
>> association between two things from two different models or ontologies. A
>> defining code is the code corresponding to the text (description) in the
>> value field.
> really? Sounds like a clear difference until you start working at the instance
> level. Say I have a field in which I want to put the concept "Asthma". The
> Snomed-CT code for this is 195967001: Asthma. I didn't get his either by
> NLP, or by user input - it's configured as part of a process.

doesn't matter where it came from. If you want the defining code as 
well, you have a DV_CODED_TEXT. There is nothing however to prevent you 
doing a mapping exrecise on the data what maps the above SNOMED code to 
the text 'Asthma'. I don't really see the use, but it's certainly 
possible. The 'match' is then 'exact'. (See the model 
).

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

openEHR / FHIR data types cross analysis

[Grahame Grieve]

> Couple of quick reactions - you need to talk to clinical modellers to get a
> better response (maybe post on clinical list)...

um, maybe. but most are representational questions, not questions of
meaning, I think.

>> * DV_BOOLEAN - maps a to a coded value with true/false. True and false are
>> defined codes. I'd be interested to look at cases where a field true/fase
>> justifies a nullFlavor and yet is a true boolean.

I just wasn't thinking what I wrote this. In FHIR, a boolean data
type, primitive, is a
type that can be used in models an is exactly equivalent to DV_BOOLEAN.

>> * Seperation of dates and times: well, there is a Duration data type. So
>> the question is about defining date as a separate reusable profile over date
>> time.
>
> Well, this is the HL7 modelling mentality, trying to create a data type or
> class with all possible attributes, some of which can be removed in some
> subclass.

not at all. nothing is removed in FHIR. There are some data types where
attributes in the superclass are constrained by the definitions in the subclass.
You do the same.

> about interfaces here, although, having looked into all the major languages
> I didn't find any that didn't have distinct date, time, date/time and
> duration types, so even in implementations, I could not see the point.

As you later noted, C# doesn't. Java.util also doesn't. Delphi doesn't
(not that
many people case...) The windows API doesn't. SQL, XML Schema, and others
do. It's hardly conclusive then.

> Date is probably the most commonly used of the date/time types in clinical
> medicine, outside of timestamps in audit trails.

right. But how often do the models use date because date would be sufficient,
as opposed to using date because a time would be innappropriate? Actually,
this is probably a case where UI considerations intervene? (so much for my
note above about representation only)

>> * units is a long discussion. What I have learnt here in Australia is that
>> the clinical users can only adopt UCUM if their sources do. And getting the
>> sources to do that is not easy. Especially not when a number of significant
>> professional clinical groups have strong recommendations to use non-ucum
>> units for display to humans. You might question their wisdom - I do - but
>> you can't question their impact. The upshot is that most of the clinical
>> documents in Australia will not use UCUM units for many things - the
>> creators of the documents could code to UCUM but aren't allowed to. Hence,
>> FHIR allows both a human and a computable representation of the units. Nor
>> does it insist on UCUM either, though there is a constraint profile that
>> does.
>
> well it depends on whether FHIR is about defining good quality data, or
> about defining user interface.

FHIR is about neither: it is about defining exchange that allows the user
to work with what they have. Yes, FHIR allows looser data than v3 requires,
and in this regard than what openEHR allows - but it also allows good quality
data too. Data that's just fine and dandy, in fact.

>> When I look at the mappings, I see that openEHR could interoperate with
>> FHIR data types without much difficulty. There has been a question of
>> whether openEHR could just *use* FHIR data types directly. I think that a
>> few more constraint profiles and aliases would have to be defined in order
>> for that to happen, but it is actually possible. The real problems resolve
>> around DV_TEXT - I've never been clear about how that actually works.
>
>
> Please, no more HL7 'profiles' - we need to be doing proper object
> modelling, not breaking all the rules of software maintainability.

see above. I'm not talking about doing anything like that.

> As far as using the FHIR data types, well, we can't answer that until there
> is an object (not XML) model.

what is it that you want? a class diagram?
(http://www.healthintersections.com.au/fhir/dt1.png,
http://www.healthintersections.com.au/fhir/dt2.png,
http://www.healthintersections.com.au/fhir/dt3.png)
something else? (ea source: www.healthintersections.com.au/fhir/fhir.eap)

> I think that is the next step for the FHIR datatypes - a
> proper formal object model specification.

oh, so you want OCL? because it's so useful

> DV_TEXT is simple - it has a string value, + optional coded mappings. If the
> text value is in fact the rubric of a code, and the code is there as well,
> you have a DV_CODED_TEXT, whose code_string carries the concept code, or
> code phrase.

I don't think this is simple at all. in fact, I don't understand this
explanation at all,
though I thought I understood the types. if an archetype has DV_TEXT, how do
I know whether the designer(s) thought that the coded mappings matter or not?
Should I do anything about them, or are they just there because they
were thinking
of straight text? Do they think formatting/hyperlinking is important?

DV_TEXT is a text, optionally with mappings. DV_CODED_TEXT elevates one
of the mappings 

openEHR / FHIR data types cross analysis

[Thomas Beale]

On 17/03/2012 22:18, Grahame Grieve wrote:
>> Couple of quick reactions - you need to talk to clinical modellers to get a
>> better response (maybe post on clinical list)...
> um, maybe. but most are representational questions, not questions of
> meaning, I think.
>
>>> * DV_BOOLEAN - maps a to a coded value with true/false. True and false are
>>> defined codes. I'd be interested to look at cases where a field true/fase
>>> justifies a nullFlavor and yet is a true boolean.
> I just wasn't thinking what I wrote this. In FHIR, a boolean data
> type, primitive, is a
> type that can be used in models an is exactly equivalent to DV_BOOLEAN.

but isn't the problem that it doesn't inherit from some DATA_VALUE 
parent type (Any in HL7 data types)? How can it be one of the possible 
values in a location like ELEMENT.value which would be statically typed 
to this parent type (as it is in 13606, HL7 RIM and openEHR) unless it 
is a descendant of this type?

>>> * Seperation of dates and times: well, there is a Duration data type. So
>>> the question is about defining date as a separate reusable profile over date
>>> time.
>> Well, this is the HL7 modelling mentality, trying to create a data type or
>> class with all possible attributes, some of which can be removed in some
>> subclass.
> not at all. nothing is removed in FHIR. There are some data types where
> attributes in the superclass are constrained by the definitions in the 
> subclass.
> You do the same.

do we?

>> about interfaces here, although, having looked into all the major languages
>> I didn't find any that didn't have distinct date, time, date/time and
>> duration types, so even in implementations, I could not see the point.
> As you later noted, C# doesn't. Java.util also doesn't. Delphi doesn't
> (not that
> many people case...) The windows API doesn't. SQL, XML Schema, and others
> do. It's hardly conclusive then.

does anyone use the Java.util calendar type? It's hopeless for dates and 
times!

>> Date is probably the most commonly used of the date/time types in clinical
>> medicine, outside of timestamps in audit trails.
> right. But how often do the models use date because date would be sufficient,
> as opposed to using date because a time would be innappropriate? Actually,
> this is probably a case where UI considerations intervene? (so much for my
> note above about representation only)

I think it is mostly the latter - Date is usually used when time info is 
really not of interest or expected.

>>> * units is a long discussion. What I have learnt here in Australia is that
>>> the clinical users can only adopt UCUM if their sources do. And getting the
>>> sources to do that is not easy. Especially not when a number of significant
>>> professional clinical groups have strong recommendations to use non-ucum
>>> units for display to humans. You might question their wisdom - I do - but
>>> you can't question their impact. The upshot is that most of the clinical
>>> documents in Australia will not use UCUM units for many things - the
>>> creators of the documents could code to UCUM but aren't allowed to. Hence,
>>> FHIR allows both a human and a computable representation of the units. Nor
>>> does it insist on UCUM either, though there is a constraint profile that
>>> does.
>> well it depends on whether FHIR is about defining good quality data, or
>> about defining user interface.
> FHIR is about neither: it is about defining exchange that allows the user
> to work with what they have. Yes, FHIR allows looser data than v3 requires,
> and in this regard than what openEHR allows - but it also allows good quality
> data too. Data that's just fine and dandy, in fact.

So, I think it's about defining (or at least describing) data ;-) But 
let's follow the units issue up in its own thread. I am starting to 
understand better your motivation for the two fields 'code' and 'unit' 
in the Quantity type.

>
>> As far as using the FHIR data types, well, we can't answer that until there
>> is an object (not XML) model.
> what is it that you want? a class diagram?
> (http://www.healthintersections.com.au/fhir/dt1.png,
> http://www.healthintersections.com.au/fhir/dt2.png,
> http://www.healthintersections.com.au/fhir/dt3.png)
> something else? (ea source: www.healthintersections.com.au/fhir/fhir.eap)
>
>> I think that is the next step for the FHIR datatypes - a
>> proper formal object model specification.
> oh, so you want OCL? because it's so useful

I want a spec that looks like an openEHR spec ;-) That's useful

>> DV_TEXT is simple - it has a string value, + optional coded mappings. If the
>> text value is in fact the rubric of a code, and the code is there as well,
>> you have a DV_CODED_TEXT, whose code_string carries the concept code, or
>> code phrase.
> I don't think this is simple at all. in fact, I don't understand this
> explanation at all,
> though I thought I understood the types. if an archetype has DV_TEXT, how do
> I know whether the des

openEHR / FHIR data types cross analysis

[Thomas Beale]

On 11/03/2012 09:43, Thomas Beale wrote:
>
> Well, this is the HL7 modelling mentality, trying to create a data 
> type or class with all possible attributes, some of which can be 
> removed in some subclass. This is bad modelling, we should not be 
> doing it. I'm talking about interfaces here, although, having looked 
> into all the major languages I didn't find any that didn't have 
> distinct date, time, date/time and duration types, so even in 
> implementations, I could not see the point.

apparently I was wrong about C# (still stuck with only one DateTime 
type), but I checked on Java (Joda ), 
Python (date/time lib ), 
Ruby (date/time lib 
)... 
all have separate types.
*
* - thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR / FHIR data types cross analysis

[Thomas Beale]

Couple of quick reactions - you need to talk to clinical modellers to 
get a better response (maybe post on clinical list)...

On 10/03/2012 19:34, Grahame Grieve wrote:
> HI
>
> I have responded to the comments in the wiki.
>
> Generally, the FHIR data types are not purely for computation; they 
> contain some features related to display.
> Some further responses here:
>
> * DV_BOOLEAN - maps a to a coded value with true/false. True and false 
> are defined codes. I'd be interested to look at cases where a field 
> true/fase justifies a nullFlavor and yet is a true boolean.

questionnaire questions, which 'classify' the patient: 'ever smoked?'; 
'ever had children?' etc. I don't think that whether nullflavour applies 
is really the issue (I am sure there could be questions on an ED form 
that might not always be answered and therefore require a NF); the point 
is to have a type that you can compute with a as a boolean, rather than 
as some more complex computation with codes etc. In CKM, there are 52 
uses of DV_BOOLEAN from 277 archetypes, so I guess there is a need.

>
> * Seperation of dates and times: well, there is a Duration data type. 
> So the question is about defining date as a separate reusable profile 
> over date time. 

Well, this is the HL7 modelling mentality, trying to create a data type 
or class with all possible attributes, some of which can be removed in 
some subclass. This is bad modelling, we should not be doing it. I'm 
talking about interfaces here, although, having looked into all the 
major languages I didn't find any that didn't have distinct date, time, 
date/time and duration types, so even in implementations, I could not 
see the point.

> Personally, I think that defining separate types is not very 
> productive, because you would expect to be able to perform common 
> operations on mixes of dates and datetimes. I don't think that date is 
> a magical thing - but what kind of uses does it have?

Date is probably the most commonly used of the date/time types in 
clinical medicine, outside of timestamps in audit trails. Diagnosis & 
problem models are full of dates; date of birth is a date, not a 
date/time; last date seen by doctor; last date for this vaccination... 
given that there is support in all the major programming languages, even 
XSD, and the types are regularly used by clinical modellers (with 'time' 
being so far nearly non-existent in archetypes, but probably only a 
matter of time)... why not include support for these types in a way that 
matches implementation formalisms?

There are operations that need to be performed on dates & dates;  
date/times & date/times; dates & durations; date/times and durations; 
durations and durations and occasionally with times. In good date/time 
libraries, all well defined. Plus partial dates/times need to be 
supported. But a Date is not a kind of DateTime.

>
> * units is a long discussion. What I have learnt here in Australia is 
> that the clinical users can only adopt UCUM if their sources do. And 
> getting the sources to do that is not easy. Especially not when a 
> number of significant professional clinical groups have strong 
> recommendations to use non-ucum units for display to humans. You might 
> question their wisdom - I do - but you can't question their impact. 
> The upshot is that most of the clinical documents in Australia will 
> not use UCUM units for many things - the creators of the documents 
> could code to UCUM but aren't allowed to. Hence, FHIR allows both a 
> human and a computable representation of the units. Nor does it insist 
> on UCUM either, though there is a constraint profile that does.

well it depends on whether FHIR is about defining good quality data, or 
about defining user interface.

>
> When I look at the mappings, I see that openEHR could interoperate 
> with FHIR data types without much difficulty. There has been a 
> question of whether openEHR could just *use* FHIR data types directly. 
> I think that a few more constraint profiles and aliases would have to 
> be defined in order for that to happen, but it is actually possible. 
> The real problems resolve around DV_TEXT - I've never been clear about 
> how that actually works.

Please, no more HL7 'profiles' - we need to be doing proper object 
modelling, not breaking all the rules of software maintainability.

As far as using the FHIR data types, well, we can't answer that until 
there is an object (not XML) model. The current XML spec includes the 
many natural language statements (which seem good, but are still natural 
language); these all need to be formally expressed in terms of pre- and 
post-conditions and class invariants. I think that is the next step for 
the FHIR datatypes - a proper formal object model specification.

DV_TEXT is simple - it has a string value, + optional coded mappings. If 
the text value is in fact the rubric of a code, and the code is there as 
well, you have a DV_CODED_TEXT, whose code_str

openEHR / FHIR data types cross analysis

[Grahame Grieve]

 HI

I have responded to the comments in the wiki.

Generally, the FHIR data types are not purely for computation; they contain
some features related to display.
Some further responses here:

* DV_BOOLEAN - maps a to a coded value with true/false. True and false are
defined codes. I'd be interested to look at cases where a field true/fase
justifies a nullFlavor and yet is a true boolean.

* Seperation of dates and times: well, there is a Duration data type. So
the question is about defining date as a separate reusable profile over
date time. Personally, I think that defining separate types is not very
productive, because you would expect to be able to perform common
operations on mixes of dates and datetimes. I don't think that date is a
magical thing - but what kind of uses does it have?

* units is a long discussion. What I have learnt here in Australia is that
the clinical users can only adopt UCUM if their sources do. And getting the
sources to do that is not easy. Especially not when a number of significant
professional clinical groups have strong recommendations to use non-ucum
units for display to humans. You might question their wisdom - I do - but
you can't question their impact. The upshot is that most of the clinical
documents in Australia will not use UCUM units for many things - the
creators of the documents could code to UCUM but aren't allowed to. Hence,
FHIR allows both a human and a computable representation of the units. Nor
does it insist on UCUM either, though there is a constraint profile that
does.

When I look at the mappings, I see that openEHR could interoperate with
FHIR data types without much difficulty. There has been a question of
whether openEHR could just *use* FHIR data types directly. I think that a
few more constraint profiles and aliases would have to be defined in order
for that to happen, but it is actually possible. The real problems resolve
around DV_TEXT - I've never been clear about how that actually works.

Grahame


On Tue, Jan 31, 2012 at 8:51 AM, Thomas Beale <
thomas.beale at oceaninformatics.com> wrote:

>  On 30/01/2012 20:56, Sam Heard wrote:
>
>  Thanks Tom for this useful work.
>
> ** **
>
> A couple of thoughts:
>
> 1)  It might be worth explaining the need for DV_BOOLEAN ? and not
> just use Boolean
>
>
> The openEHR RM, like 13606, CDA and most other such models has a generic
> structure part for building trees of name-value information. For openEHR &
> 13606, the leaf level class is ELEMENT, whose 'value' attribute is of
> abstract type DATA_VALUE. Any concrete type needs to be a subtype of this
> type. Boolean is just a primitive type. To provide a Boolean valued subtype
> of DATA_VALUE needs a new type - in openEHR's case, DV_BOOLEAN. In the HL7
> types used in 13606 and HL7 it is BL.
>
>
>  
>
> 2)  The separation of date and time is not usual in computing
> languages at the moment and I would guess is a consideration ? we certainly
> do not model these separately but as a constraint
>
>
> Well, in the libraries in Java 
> (Joda),
> Python , 
> Ruby,
> Eiffel  all
> do, and XML  all
> distinguish these types. Many of these libraries (including XML and
> openEHR's types) are based on the ISO 8601 standard that defines strings
> corresponding to date, time, date_time and duration. This is what people
> program with, so I don't see any issue. We currently use the separate types
> in archetypes, according to these statistics.
>
>
>
>  
>
> 3)  The ability to have codes as units in quantity is an interesting
> approach which has been around for a while in HL7 v2 where you are not
> limited to SI units/UCUM but can have TAB for tablets etc.
>
>
> ok, but TAB is not a unit, it needs a separate field. Mixing it up with
> units is a recipe for disaster.
>
>
>  
>
> ** **
>
> You state: ?The FHIR choice to represent units as a code or a string
> seems unnecessarily complicated. A UCUM units string should be adequate.
> There is an example with unit=mcg/L and code=ug. What can this mean??
>
> ** **
>
> Nota sure how we could have a code for a unit that is UCUM/SI ? this does
> not make sense really ? but having the ability to put in quantities that
> are not SI Units does have some merit. Pulse is a good example ? it is
> really a frequency x/min but people often say bpm or beats per minute. The
> amount of tobacco people use can be in cigarettes per day or oz/week or
> gm/day. At the moment we have to divide these into different parts of the
> archetype.
>
>
> I have no problem with any of these; to my knowledge they are all
> accommodated with UCUM. UCUM isn't a fixed list of units, it's an
> expression syntax. So you can always create an expression 

openEHR / FHIR data types cross analysis

[Sam Heard]

Thanks Tom for this useful work.

 

A couple of thoughts:

1)  It might be worth explaining the need for DV_BOOLEAN - and not just
use Boolean

2)  The separation of date and time is not usual in computing languages
at the moment and I would guess is a consideration - we certainly do not
model these separately but as a constraint

3)  The ability to have codes as units in quantity is an interesting
approach which has been around for a while in HL7 v2 where you are not
limited to SI units/UCUM but can have TAB for tablets etc.

 

You state: "The FHIR choice to represent units as a code or a string seems
unnecessarily complicated. A UCUM units string should be adequate. There is
an example with unit=mcg/L and code=ug. What can this mean?"

 

Nota sure how we could have a code for a unit that is UCUM/SI - this does
not make sense really - but having the ability to put in quantities that are
not SI Units does have some merit. Pulse is a good example - it is really a
frequency x/min but people often say bpm or beats per minute. The amount of
tobacco people use can be in cigarettes per day or oz/week or gm/day. At the
moment we have to divide these into different parts of the archetype.

 

That is not to say that it is right to put the counted thing as a unit and
not keep it in the leaf node name but TAB/CAP/Puff/Drop etc are common for
medication and do cause some difficulty.

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Monday, 30 January 2012 4:27 AM
To: Openehr-Technical
Subject: openEHR / FHIR data types cross analysis

 


I have started a gap analysis of the openEHR and FHIR data types
<http://www.openehr.org/wiki/display/stds/FHIR+-+openEHR+Data+Types+cross-an
alysis> , created by Grahame Grieve as part of the HL7 'fresh look'
activity. ANyone is welcome to add to the tables on this page - I am just
slowly working on it in the background.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/8bab1f24/attachment.html>

openEHR / FHIR data types cross analysis

[Thomas Beale]

On 30/01/2012 20:56, Sam Heard wrote:
>
> Thanks Tom for this useful work.
>
> A couple of thoughts:
>
> 1)It might be worth explaining the need for DV_BOOLEAN -- and not just 
> use Boolean
>

The openEHR RM, like 13606, CDA and most other such models has a generic 
structure part for building trees of name-value information. For openEHR 
& 13606, the leaf level class is ELEMENT, whose 'value' attribute is of 
abstract type DATA_VALUE. Any concrete type needs to be a subtype of 
this type. Boolean is just a primitive type. To provide a Boolean valued 
subtype of DATA_VALUE needs a new type - in openEHR's case, DV_BOOLEAN. 
In the HL7 types used in 13606 and HL7 it is BL.

> 2)The separation of date and time is not usual in computing languages 
> at the moment and I would guess is a consideration -- we certainly do 
> not model these separately but as a constraint
>

Well, in the libraries in Java (Joda 
), Python 
, Ruby 
, 
Eiffel  all 
do, and XML  all 
distinguish these types. Many of these libraries (including XML and 
openEHR's types) are based on the ISO 8601 standard that defines strings 
corresponding to date, time, date_time and duration. This is what people 
program with, so I don't see any issue. We currently use the separate 
types in archetypes, according to these statistics.



> 3)The ability to have codes as units in quantity is an interesting 
> approach which has been around for a while in HL7 v2 where you are not 
> limited to SI units/UCUM but can have TAB for tablets etc.
>

ok, but TAB is not a unit, it needs a separate field. Mixing it up with 
units is a recipe for disaster.

> You state: "The FHIR choice to represent units as a code or a string 
> seems unnecessarily complicated. A UCUM units string should be 
> adequate. There is an example with unit=mcg/L and code=ug. What can 
> this mean?"
>
> Nota sure how we could have a code for a unit that is UCUM/SI -- this 
> does not make sense really -- but having the ability to put in 
> quantities that are not SI Units does have some merit. Pulse is a good 
> example -- it is really a frequency x/min but people often say bpm or 
> beats per minute. The amount of tobacco people use can be in 
> cigarettes per day or oz/week or gm/day. At the moment we have to 
> divide these into different parts of the archetype.
>

I have no problem with any of these; to my knowledge they are all 
accommodated with UCUM. UCUM isn't a fixed list of units, it's an 
expression syntax. So you can always create an expression 'oz/week' or 
whatever. Beats per minute unit is '/min' or equivalently 'min^-1'. The 
'beats' part is not part of a unit system. I agree that pseudo units 
like 'bpm' are useful to support, but we have to do that in a different 
data field, since if we don't have systematically computable units in 
the units field, we kill its computability.

Similarly, 'puffs', 'drops' and all the rest need a place to go. Just 
not in the units field.

> That is not to say that it is right to put the counted thing as a unit 
> and not keep it in the leaf node name but TAB/CAP/Puff/Drop etc are 
> common for medication and do cause some difficulty.
>

It may be worth having a special subtype of Quantity that includes an 
extra field for these arbitrary discretisations. I know Grahame and 
others spent a long time arguing about this. The following description 
for the Quantity data type on the FHIR page 
 
makes me think they have some way to go yet:

The /unit/ element must contain a unit that defines what is
measured. The unit may additionally be coded in the /code/ and the
/system/, which is a URI, OID, or a SID that defines the code (see
CodeableConcept

for further information). Note that the /unit/ element will often
contain a valid UCUM unit, but it cannot be assumed that it does.
*If a UCUM unit is provided in the /code/ *then a canonical value
can be generated for purposes of comparison between quantities.


- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: faecaeee.png
Type: image/png
Size: 10434 bytes
Desc: not available
URL: 

openEHR / FHIR data types cross analysis

[Timothy Cook]

Apologies, this was not intended for the mailing list.


On Mon, Jan 30, 2012 at 19:39, Timothy Cook  
wrote:
> Again, FYI. ?If you would like help in doing the cross ref. with MLHIM
> let me know. ?However, this might be a good project for Sergio???
>
> --Tim
>
> On Sun, Jan 29, 2012 at 10:26, Thomas Beale
>  wrote:
>>
>> I have started a gap analysis of the openEHR and FHIR data types, created by
>> Grahame Grieve as part of the HL7 'fresh look' activity. ANyone is welcome
>> to add to the tables on this page - I am just slowly working on it in the
>> background.
>>
>> - thomas
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>
>
>
> --
> 
> Timothy Cook, MSc ? ? ? ? ? +1 281 506 2860
> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
> Skype ID == timothy.cook
> Academic.Edu Profile: http://uff.academia.edu/TimothyCook



-- 

Timothy Cook, MSc ? ? ? ? ? +1 281 506 2860
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Skype ID == timothy.cook
Academic.Edu Profile: http://uff.academia.edu/TimothyCook

openEHR / FHIR data types cross analysis

[Timothy Cook]

Again, FYI.  If you would like help in doing the cross ref. with MLHIM
let me know.  However, this might be a good project for Sergio???

--Tim

On Sun, Jan 29, 2012 at 10:26, Thomas Beale
 wrote:
>
> I have started a gap analysis of the openEHR and FHIR data types, created by
> Grahame Grieve as part of the HL7 'fresh look' activity. ANyone is welcome
> to add to the tables on this page - I am just slowly working on it in the
> background.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>



-- 

Timothy Cook, MSc ? ? ? ? ? +1 281 506 2860
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Skype ID == timothy.cook
Academic.Edu Profile: http://uff.academia.edu/TimothyCook

openEHR / FHIR data types cross analysis

[Thomas Beale]

I have started a gap analysis of the openEHR and FHIR data types 
,
 
created by Grahame Grieve as part of the HL7 'fresh look' activity. 
ANyone is welcome to add to the tables on this page - I am just slowly 
working on it in the background.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: