# openEHR / FHIR data types cross analysis
**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2012-01-29 17:26 UTC
**Views:** 19
**Replies:** 20
**URL:** https://discourse.openehr.org/t/openehr-fhir-data-types-cross-analysis/15149
---
## Post #1 by @thomas.beale
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-analysis), 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
---
## Post #2 by @system
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
---
## Post #3 by @thomas.beale
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
[details="(attachments)"]
[/details]
---
## Post #4 by @Tim_Cook2
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
---
## Post #5 by @Tim_Cook2
Apologies, this was not intended for the mailing list\.
---
## Post #6 by @grahamegrieve
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
[details="(attachments)"]
[/details]
---
## Post #7 by @thomas.beale
Couple of quick reactions \- you need to talk to clinical modellers to get a better response \(maybe post on clinical list\)\.\.\.
> HI
>
> I have responded to the comments in the wiki\.
>
> Generally, the FHIR data types are not purely for computation; they contain some features related to display\.
> Some further responses here:
>
> \* DV\_BOOLEAN \- maps a to a coded value with true/false\. True and false are defined codes\. I'd be interested to look at cases where a field true/fase justifies a nullFlavor and yet is a true boolean\.
questionnaire questions, which 'classify' the patient: 'ever smoked?'; 'ever had children?' etc\. I don't think that whether nullflavour applies is really the issue \(I am sure there could be questions on an ED form that might not always be answered and therefore require a NF\); the point is to have a type that you can compute with a as a boolean, rather than as some more complex computation with codes etc\. In CKM, there are 52 uses of DV\_BOOLEAN from 277 archetypes, so I guess there is a need\.
> \* Seperation of dates and times: well, there is a Duration data type\. So the question is about defining date as a separate reusable profile over date time\.
Well, this is the HL7 modelling mentality, trying to create a data type or class with all possible attributes, some of which can be removed in some subclass\. This is bad modelling, we should not be doing it\. I'm talking about interfaces here, although, having looked into all the major languages I didn't find any that didn't have distinct date, time, date/time and duration types, so even in implementations, I could not see the point\.
> Personally, I think that defining separate types is not very productive, because you would expect to be able to perform common operations on mixes of dates and datetimes\. I don't think that date is a magical thing \- but what kind of uses does it have?
Date is probably the most commonly used of the date/time types in clinical medicine, outside of timestamps in audit trails\. Diagnosis & problem models are full of dates; date of birth is a date, not a date/time; last date seen by doctor; last date for this vaccination\.\.\. given that there is support in all the major programming languages, even XSD, and the types are regularly used by clinical modellers \(with 'time' being so far nearly non\-existent in archetypes, but probably only a matter of time\)\.\.\. why not include support for these types in a way that matches implementation formalisms?
There are operations that need to be performed on dates & dates; date/times & date/times; dates & durations; date/times and durations; durations and durations and occasionally with times\. In good date/time libraries, all well defined\. Plus partial dates/times need to be supported\. But a Date is not a kind of DateTime\.\.\.\.\.
> \* units is a long discussion\. What I have learnt here in Australia is that the clinical users can only adopt UCUM if their sources do\. And getting the sources to do that is not easy\. Especially not when a number of significant professional clinical groups have strong recommendations to use non\-ucum units for display to humans\. You might question their wisdom \- I do \- but you can't question their impact\. The upshot is that most of the clinical documents in Australia will not use UCUM units for many things \- the creators of the documents could code to UCUM but aren't allowed to\. Hence, FHIR allows both a human and a computable representation of the units\. Nor does it insist on UCUM either, though there is a constraint profile that does\.
well it depends on whether FHIR is about defining good quality data, or about defining user interface\.
> When I look at the mappings, I see that openEHR could interoperate with FHIR data types without much difficulty\. There has been a question of whether openEHR could just \*use\* FHIR data types directly\. I think that a few more constraint profiles and aliases would have to be defined in order for that to happen, but it is actually possible\. The real problems resolve around DV\_TEXT \- I've never been clear about how that actually works\.
Please, no more HL7 'profiles' \- we need to be doing proper object modelling, not breaking all the rules of software maintainability\.
As far as using the FHIR data types, well, we can't answer that until there is an object \(not XML\) model\. The current XML spec includes the many natural language statements \(which seem good, but are still natural language\); these all need to be formally expressed in terms of pre\- and post\-conditions and class invariants\. I think that is the next step for the FHIR datatypes \- a proper formal object model specification\.
DV\_TEXT is simple \- it has a string value, \+ optional coded mappings\. If the text value is in fact the rubric of a code, and the code is there as well, you have a DV\_CODED\_TEXT, whose code\_string carries the concept code, or code phrase\.
\- thomas
---
## Post #8 by @thomas.beale
apparently I was wrong about C# (still stuck with only one DateTime type), but I checked on Java ([Joda](http://joda-time.sourceforge.net/)), Python ([date/time lib](http://docs.python.org/library/datetime.html)), Ruby ([date/time lib](http://www.ruby-doc.org/stdlib-1.9.3/libdoc/date/rdoc/index.html))... all have separate types.
- thomas
---
## Post #9 by @grahamegrieve
> Couple of quick reactions \- you need to talk to clinical modellers to get a
> better response \(maybe post on clinical list\)\.\.\.
um, maybe\. but most are representational questions, not questions of
meaning, I think\.
>> \* DV\_BOOLEAN \- maps a to a coded value with true/false\. True and false are
>> defined codes\. I'd be interested to look at cases where a field true/fase
>> justifies a nullFlavor and yet is a true boolean\.
I just wasn't thinking what I wrote this\. In FHIR, a boolean data
type, primitive, is a
type that can be used in models an is exactly equivalent to DV\_BOOLEAN\.
>> \* Seperation of dates and times: well, there is a Duration data type\. So
>> the question is about defining date as a separate reusable profile over date
>> time\.
>
> Well, this is the HL7 modelling mentality, trying to create a data type or
> class with all possible attributes, some of which can be removed in some
> subclass\.
not at all\. nothing is removed in FHIR\. There are some data types where
attributes in the superclass are constrained by the definitions in the subclass\.
You do the same\.
> about interfaces here, although, having looked into all the major languages
> I didn't find any that didn't have distinct date, time, date/time and
> duration types, so even in implementations, I could not see the point\.
As you later noted, C\# doesn't\. Java\.util also doesn't\. Delphi doesn't
\(not that
many people case\.\.\.\) The windows API doesn't\. SQL, XML Schema, and others
do\. It's hardly conclusive then\.
> Date is probably the most commonly used of the date/time types in clinical
> medicine, outside of timestamps in audit trails\.
right\. But how often do the models use date because date would be sufficient,
as opposed to using date because a time would be innappropriate? Actually,
this is probably a case where UI considerations intervene? \(so much for my
note above about representation only\)
>> \* units is a long discussion\. What I have learnt here in Australia is that
>> the clinical users can only adopt UCUM if their sources do\. And getting the
>> sources to do that is not easy\. Especially not when a number of significant
>> professional clinical groups have strong recommendations to use non\-ucum
>> units for display to humans\. You might question their wisdom \- I do \- but
>> you can't question their impact\. The upshot is that most of the clinical
>> documents in Australia will not use UCUM units for many things \- the
>> creators of the documents could code to UCUM but aren't allowed to\. Hence,
>> FHIR allows both a human and a computable representation of the units\. Nor
>> does it insist on UCUM either, though there is a constraint profile that
>> does\.
>
> well it depends on whether FHIR is about defining good quality data, or
> about defining user interface\.
FHIR is about neither: it is about defining exchange that allows the user
to work with what they have\. Yes, FHIR allows looser data than v3 requires,
and in this regard than what openEHR allows \- but it also allows good quality
data too\. Data that's just fine and dandy, in fact\.
>> When I look at the mappings, I see that openEHR could interoperate with
>> FHIR data types without much difficulty\. There has been a question of
>> whether openEHR could just \*use\* FHIR data types directly\. I think that a
>> few more constraint profiles and aliases would have to be defined in order
>> for that to happen, but it is actually possible\. The real problems resolve
>> around DV\_TEXT \- I've never been clear about how that actually works\.
>
> Please, no more HL7 'profiles' \- we need to be doing proper object
> modelling, not breaking all the rules of software maintainability\.
see above\. I'm not talking about doing anything like that\.
> As far as using the FHIR data types, well, we can't answer that until there
> is an object \(not XML\) model\.
what is it that you want? a class diagram?
\(http://www.healthintersections.com.au/fhir/dt1.png,
http://www.healthintersections.com.au/fhir/dt2.png,
http://www.healthintersections.com.au/fhir/dt3.png)
something else? \(ea source: www\.healthintersections\.com\.au/fhir/fhir\.eap\)
> I think that is the next step for the FHIR datatypes \- a
> proper formal object model specification\.
oh, so you want OCL? because it's so useful\.\.\.\.
> DV\_TEXT is simple \- it has a string value, \+ optional coded mappings\. If the
> text value is in fact the rubric of a code, and the code is there as well,
> you have a DV\_CODED\_TEXT, whose code\_string carries the concept code, or
> code phrase\.
I don't think this is simple at all\. in fact, I don't understand this
explanation at all,
though I thought I understood the types\. if an archetype has DV\_TEXT, how do
I know whether the designer\(s\) thought that the coded mappings matter or not?
Should I do anything about them, or are they just there because they
were thinking
of straight text? Do they think formatting/hyperlinking is important?
DV\_TEXT is a text, optionally with mappings\. DV\_CODED\_TEXT elevates one
of the mappings to being "defining"\. Does that mean that a DV\_TEXT couldn't
have a "defining" code mapping? Or is this constrained from use in
DV\_TEXT\.purpose? And shouldn't you also put the defining phrase in
the DV\_TEXT\.mappings, else you are not conforming to the contract of
DV\_TEXT?
Grahame
---
## Post #10 by @thomas.beale
>> Couple of quick reactions \- you need to talk to clinical modellers to get a
>> better response \(maybe post on clinical list\)\.\.\.
>
> um, maybe\. but most are representational questions, not questions of
> meaning, I think\.
>
>>> \* DV\_BOOLEAN \- maps a to a coded value with true/false\. True and false are
>>> defined codes\. I'd be interested to look at cases where a field true/fase
>>> justifies a nullFlavor and yet is a true boolean\.
>
> I just wasn't thinking what I wrote this\. In FHIR, a boolean data
> type, primitive, is a
> type that can be used in models an is exactly equivalent to DV\_BOOLEAN\.
but isn't the problem that it doesn't inherit from some DATA\_VALUE parent type \(Any in HL7 data types\)? How can it be one of the possible values in a location like ELEMENT\.value which would be statically typed to this parent type \(as it is in 13606, HL7 RIM and openEHR\) unless it is a descendant of this type?
>>> \* Seperation of dates and times: well, there is a Duration data type\. So
>>> the question is about defining date as a separate reusable profile over date
>>> time\.
>>
>> Well, this is the HL7 modelling mentality, trying to create a data type or
>> class with all possible attributes, some of which can be removed in some
>> subclass\.
>
> not at all\. nothing is removed in FHIR\. There are some data types where
> attributes in the superclass are constrained by the definitions in the subclass\.
> You do the same\.
do we?
>> about interfaces here, although, having looked into all the major languages
>> I didn't find any that didn't have distinct date, time, date/time and
>> duration types, so even in implementations, I could not see the point\.
>
> As you later noted, C\# doesn't\. Java\.util also doesn't\. Delphi doesn't
> \(not that
> many people case\.\.\.\) The windows API doesn't\. SQL, XML Schema, and others
> do\. It's hardly conclusive then\.
does anyone use the Java\.util calendar type? It's hopeless for dates and times\!
>> Date is probably the most commonly used of the date/time types in clinical
>> medicine, outside of timestamps in audit trails\.
>
> right\. But how often do the models use date because date would be sufficient,
> as opposed to using date because a time would be innappropriate? Actually,
> this is probably a case where UI considerations intervene? \(so much for my
> note above about representation only\)
I think it is mostly the latter \- Date is usually used when time info is really not of interest or expected\.
>>> \* units is a long discussion\. What I have learnt here in Australia is that
>>> the clinical users can only adopt UCUM if their sources do\. And getting the
>>> sources to do that is not easy\. Especially not when a number of significant
>>> professional clinical groups have strong recommendations to use non\-ucum
>>> units for display to humans\. You might question their wisdom \- I do \- but
>>> you can't question their impact\. The upshot is that most of the clinical
>>> documents in Australia will not use UCUM units for many things \- the
>>> creators of the documents could code to UCUM but aren't allowed to\. Hence,
>>> FHIR allows both a human and a computable representation of the units\. Nor
>>> does it insist on UCUM either, though there is a constraint profile that
>>> does\.
>>
>> well it depends on whether FHIR is about defining good quality data, or
>> about defining user interface\.
>
> FHIR is about neither: it is about defining exchange that allows the user
> to work with what they have\. Yes, FHIR allows looser data than v3 requires,
> and in this regard than what openEHR allows \- but it also allows good quality
> data too\. Data that's just fine and dandy, in fact\.
So, I think it's about defining \(or at least describing\) data ;\-\) But let's follow the units issue up in its own thread\. I am starting to understand better your motivation for the two fields 'code' and 'unit' in the Quantity type\.
>> As far as using the FHIR data types, well, we can't answer that until there
>> is an object \(not XML\) model\.
>
> what is it that you want? a class diagram?
> \(http://www.healthintersections.com.au/fhir/dt1.png,
> http://www.healthintersections.com.au/fhir/dt2.png,
> http://www.healthintersections.com.au/fhir/dt3.png)
> something else? \(ea source: www\.healthintersections\.com\.au/fhir/fhir\.eap\)
>
>> I think that is the next step for the FHIR datatypes \- a
>> proper formal object model specification\.
>
> oh, so you want OCL? because it's so useful\.\.\.\.
I want a spec that looks like an openEHR spec ;\-\) That's useful\.\.\.\.
>> DV\_TEXT is simple \- it has a string value, \+ optional coded mappings\. If the
>> text value is in fact the rubric of a code, and the code is there as well,
>> you have a DV\_CODED\_TEXT, whose code\_string carries the concept code, or
>> code phrase\.
>
> I don't think this is simple at all\. in fact, I don't understand this
> explanation at all,
> though I thought I understood the types\. if an archetype has DV\_TEXT, how do
> I know whether the designer\(s\) thought that the coded mappings matter or not?
they can put a DV\_CODED\_TEXT constraint in as well as a DV\_TEXT constraint if they want to allow either \- e\.g\. prefer coded, but text ok if no code available; the archetype processor is supposed to opt for the more specific subtype by preference\.
e\.g\.
ELEMENT matches \{
value matches \{
DV\_CODED\_TEXT matches \{
defining\_code matches \{\[SNOMEDCT\_20120101::1111111, 222222222, 3333333\]\}
\}
DV\_TEXT matches \{/\.\+\} \-\- non empty string
\}
\}
> 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\.
> 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\.
> 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\.
> Or is this constrained from use in
> DV\_TEXT\.purpose? And shouldn't you also put the defining phrase in
> the DV\_TEXT\.mappings, else you are not conforming to the contract of
> DV\_TEXT?
why would we want to put the defining codephrase in the mappings?
\- thomas
---
## Post #11 by @grahamegrieve
>> 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
---
## Post #12 by @thomas.beale
> > > ```
> > > I just wasn't thinking what I wrote this. In FHIR, a boolean data
> > > type, primitive, is a
> > > type that can be used in models an is exactly equivalent to DV_BOOLEAN.
> > >
> > > ```
> >
> > ```
> > but isn't the problem that it doesn't inherit from some DATA_VALUE parent
> > type (Any in HL7 data types)? How can it be one of the possible values in a
> > location like ELEMENT.value which would be statically typed to this parent
> > type (as it is in 13606, HL7 RIM and openEHR) unless it is a descendant of
> > this type?
> >
> > ```
>
> ```
> FHIR has no such restriction - elements must have a type of one or more
> of the defined types, either primitive or complex
> ```
ok, but how do w write a normal statically typed classes in Java or C# to deal with that?
> > > ```
> > > not at all. nothing is removed in FHIR. There are some data types where
> > > attributes in the superclass are constrained by the definitions in the
> > > subclass.
> > > You do the same.
> > >
> > > ```
> >
> > ```
> > do we?
> >
> > ```
>
> ```
> yes, check out DV_EHR_URI - this is exactly the same pattern for
> exactly the same reason
> ```
This is a pattern where all descendants in the hierarchy just have a String value, but the different descendants provide different ways of parsing it. The FHIR identifiers are done like this (by direct inheritance from String), so are the openEHR Identifiers (by having a single value: String field).
I had momentarily forgotten that you had done HumanDate like this as well. In FHIR, you inherit directly from String, and add syntax functions that parse the string in a certain way. In this case we assume ISO8601 date/time strings. But just having the one semantic type (HumanDate) based on the representation (a String) is not enough when building clinical models. Modellers need to be able to put Date, DateTime, Time (we can assume it will be required somewhere) and Duration (which you have as a constraint on Quantity). I am not against using the representation approach you have used, but it still doesn't provide enough semantic types.
Ideally we need semantic types whose representation could change (e.g. from String in messages to multiple pieces in some programming framework) but whose semantics stay the same.
> > ```
> > I think it is mostly the latter - Date is usually used when time info is
> > really not of interest or expected.
> >
> > ```
>
> ```
> why shouldn't the relationship between date and datetime be the same
> as that between DV_EHR_URI and DV_URI? I haven't defined that, but
> that would be the natural way to do it in FHIR.
> ```
see above. It's not an argument about representation (i.e. different ways of parsing a String), but about semantics. We still need for example some thing that says that Date.diff (otherDate) produces a Duration.
> ```
>
> ```
>
> > ```
> > I want a spec that looks like an openEHR spec ;-) That's useful....
> >
> > ```
>
> ```
> I don't think I'll do exactly like (framemaker!), but others have asked for a
> formal computable statement of constraints.
> ```
haha, I didn't mean FM, just the formal specification.
> ```
>
> that can be constrained in the archetype as well.
>
> ```
>
> ```
> but it generally isn't - and can't be in the archetype builder.
> So I don't know what was intended.
> ```
I wouldn't read much into the current limitations of the Archetype Editor - except that there has been little demand to be able to constrain those fields.
> ```
>
> ```
>
> > > ```
> > > DV_TEXT is a text, optionally with mappings. DV_CODED_TEXT elevates one
> > > of the mappings to being "defining".
> > >
> > > ```
> >
> > ```
> > well 'defining_code' isn't a mapping; a mapping by definition is an
> > association between two things from two different models or ontologies. A
> > defining code is the code corresponding to the text (description) in the
> > value field.
> >
> > ```
>
> ```
> really? Sounds like a clear difference until you start working at the instance
> level. Say I have a field in which I want to put the concept "Asthma". The
> Snomed-CT code for this is 195967001: Asthma. I didn't get his either by
> NLP, or by user input - it's configured as part of a process.
> ```
doesn't matter where it came from. If you want the defining code as well, you have a DV_CODED_TEXT. There is nothing however to prevent you doing a mapping exrecise on the data what maps the above SNOMED code to the text 'Asthma'. I don't really see the use, but it's certainly possible. The 'match' is then 'exact'. ([See the model](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109597816149_873308_762Report.html)).
> ```
>
> Now the interpretation of of DV_TEXT is text, possibly with a code. So when I'm
> going to represent that, I'll use DV_TEXT of "asthma" with a mapping to
> snomed code 195967001 in the mappings. The mapping type will be ....
> hell, I don't know, does anyone use that, and what do they put in it?
> I don't know whether the Purpose_valid invariant means I need one
> or not (Group_id_term_mapping_purpose is not defined anywhere that
> I can find, for example), but I think not. Anyhow, my snomed code goes
> in a mapping. I can't imagine any normal implementer would think
> differently on this point.
> ```
it can easily be different: a very typical UI control is one that combines coded term selection with free text entry. If the archetype specifies either, then that UI control allows either, and at runtime either a DV_TEXT or a DV_CODED_TEXT will be created, depending on what the user does. There are systems doing this today.
> ```
>
> 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.
> ```
>
> ```
>
> > ```
> > 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?
> ```
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. The string may or may not be the rubric of the code from a terminology, but even if it is, the point of the mapping will not usually have been to supply 'defining' codes, but to supply codes for billing, research or other purposes. Supplying defining codes is not out of the question I guess, if the incoming data is all just Text, and some translator is trying to find matches in Snomed, but even then it is a virtual guarantee that only some direct matches will be found.
Anyway, the point of 'defining' is not whether a lexical direct hit was made by some mapping process, but what the intention & understanding of the user (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.
> ```
>
> 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.
>
>
> ```
what's a 'primary' mapping?
- thomas
---
## Post #13 by @system
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
---
## Post #14 by @grahamegrieve
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
---
## Post #15 by @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
---
## Post #16 by @grahamegrieve
> 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
---
## Post #17 by @system
Sorry about the XML slur :\) Sam
---
## Post #18 by @system
Sorry about the Eiffel slur J
Cheers, Sam
[details="(attachments)"]
[/details]
---
## Post #19 by @grahamegrieve
> 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
---
## Post #20 by @grahamegrieve
Hey Sam
it's a good day when you can upset both Tom and I equally in a single paragraph.
Grahame
[details="(attachments)"]
[/details]
---
## Post #21 by @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!!
---
**Canonical:** https://discourse.openehr.org/t/openehr-fhir-data-types-cross-analysis/15149
**Original content:** https://discourse.openehr.org/t/openehr-fhir-data-types-cross-analysis/15149