-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
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
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
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
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
/ 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
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
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
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
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
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
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,
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
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
-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
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
Again, FYI. If you would like help in doing the cross ref. with MLHIM
let me know. However, this might be a good project for Sergio???
--Tim
On Sun, Jan 29, 2012 at 10:26, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
I have started a gap analysis of the openEHR and FHIR data
, Jan 29, 2012 at 10:26, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
I have started a gap analysis of the openEHR and FHIR data types, created by
Grahame Grieve as part of the HL7 'fresh look' activity. ANyone is welcome
to add to the tables on this page - I am just slowly working
to see.
Within RFH, Grahame has proposed a new data types model.? In practical terms
this will presumably mean that implementations directly based on the RIM and
21090, and particularly the creation of RIM/21090 data instances will see
much reduced use in the future. From the point of view
-known
over-complexity of HL7v3. According to his report on the reception of RFH at
the HL7 meeting, there appears to be a real appetite for change at HL7,
which is good to see.
Within RFH, Grahame has proposed a new data types model.? In practical terms
this will presumably mean
It sound as a very interesting proposal.
As you say, profiling ISO 21090 data types leads to several problems of
inconsistency and non-interoperability. And in terms of efficiency, our
tests using the new data types in LinkEHR are not satisfactory at all.
But my main question
, there appears to be a real appetite for change at HL7,
which is good to see.
Within RFH, Grahame has proposed a new data types model.? In practical terms
this will presumably mean that implementations directly based on the RIM and
21090, and particularly the creation of RIM/21090 data instances
- How do we best set up communication links between the communities?
Is it by joining each others mailing-lists/discussions? Other ways?
Maybe by meeting (some of) them personally in Amsterdam on 15th November:
http://wiki.hl7.org/index.php?title=RIMBAA_20_Agenda
Best regards,
Roger
Hi Roger,
- How do we best set up communication links between the communities?
Is it by joining each others mailing-lists/discussions? Other ways?
Maybe by meeting (some of) them personally in Amsterdam on 15th November:
http://wiki.hl7.org/index.php?title=RIMBAA_20_Agenda
That is
Hoi Roger, ik heb me geregistreerd, doe jij dat ook? Lijkt me wel zinvol.
Maar dan moet ik misschien de bedrijfsnaam veranderen, anders is de
vertegenwoordiging vanuit Zorggemak wel erg zwaar.
groet
Bert
On 19-09-11 11:07, Roger Erens wrote:
- How do we best set up communication links between
Hoi Bert,
die datum valt waarschijnlijk in de vakantie van onze oppas, en ik
moet even afwachten hoe de agenda van mijn vrouw is gevuld.
Vanavond weet ik wat meer.
Groeten,
Roger
2011/9/19 Bert Verhees bert.verhees at rosa.nl:
Hoi Roger, ik heb me geregistreerd, doe jij dat ook? Lijkt me wel
Dear all,
apologies for polluting the list, I thought I replied to Bert in private.
Roger
2011/9/19 Roger Erens roger.erens at e-s-c.biz:
Hoi Bert,
die datum valt waarschijnlijk in de vakantie van onze oppas, en ik
moet even afwachten hoe de agenda van mijn vrouw is gevuld.
Vanavond weet
On 19/09/2011 09:55, David Moner wrote:
It sound as a very interesting proposal.
As you say, profiling ISO 21090 data types leads to several problems
of inconsistency and non-interoperability. And in terms of efficiency,
our tests using the new data types in LinkEHR are not satisfactory
Excuse me for replying a private message to the list, that caused Roger
also to reply to the list.
My fault.
regards
Bert Verhees
On 19-09-11 15:22, Roger Erens wrote:
Dear all,
apologies for polluting the list, I thought I replied to Bert in private.
Roger
2011/9/19 Roger
of HL7v3. According to his
report http://www.healthintersections.com.au/?p=610 on the reception
of RFH at the HL7 meeting, there appears to be a real appetite for
change at HL7, which is good to see.
Within RFH, Grahame has proposed a new data types model
http://www.healthintersections.com.au
harmonization CR regarding CLUSTER/TABLE etc and
ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hi!
I now noticed that my message with the pencil-modified UML diagram
bounced four days ago because of attachment size. Now it's edited
below to only include link to the image
http
Hi Zam! :-)
I was merely trying to keep most of the same semantic power in the
change suggestion as when the abstract ITEM_STRUCTURE (that subsumed
ITEM_SINGLE, ITEM_TREE etc) was used rather than ITEM_TREE in various
places in the RM model. But you might be completely correct that it
would be
On 13/11/2010 00:07, pablo pazos wrote:
Hi,
I would also concur with your statements about the ENTRY sub
types, as Sam mentioned we have built an INSTRUCTION index that
tracks the current state/care flow step of instructions and their
associated ACTIONs providing efficient
Hi!
I now noticed that my message with the pencil-modified UML diagram
bounced four days ago because of attachment size. Now it's edited
below to only include link to the image
http://www.imt.liu.se/~erisu/2010/openEHR/RM-pencil.jpg
After that mail was written Heath indicated that one of Tom's
] On Behalf Of Erik Sundvall
Sent: Wednesday, 10 November 2010 11:16 PM
To: For openEHR technical discussions
Subject: openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and
ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hello again!
Here comes a more complete version
In a message dated 10-11-2010 8:41:09 W. Europe Standard Time,
hugh.leslie at oceaninformatics.com writes:
Hi William
I didn't see anyone say that the hl7 models have been developed without
clinical input. I am certain this isn't true.
I don't completely agree with you about the
Hi Ed,
I am a mouse that roars (sometimes) :-)
Met vriendelijke groet,
Results 4 Care b.v.
dr. William TF Goossen
directeur
De Stinse 15
3823 VM Amersfoort
email: wgoossen at results4care.nl
telefoon +31 (0)654614458
fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713
On 11/11/2010 23:14, Heath Frankel wrote:
Hi Erik,
Interestingly, this is the same proposal I put to Thomas about 8 years
ago and I go the same response. I do understand his rationale for
making a table a class rather than an attribute with additional
conformance statements to ensure a
Hi,
I would also concur with your statements about
the ENTRY sub
types, as Sam mentioned we have built an INSTRUCTION index
that tracks the current
state/care flow step of instructions and their associated
ACTIONs providing
org
Subject
Re: ISO 21090 data types too
11/12/2010 05:46 complex
regarding CLUSTER/TABLE etc
and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hi!
On Wed, Nov 10, 2010 at 17:26, tom.seabury at nhs.net wrote:
My simple reading of this is that what are currently trees would
instead be
expressed as a sparsely populated arrays
You can find here the related work to this problem from our colleagues at
the University of Murcia.
An approach for the semantic interoperability of ISO EN 13606 and OpenEHR
archetypes.
Catalina Mart?nez-Costa, Marcos Men?rguez Tortosa, Jesualdo Tom?s
Fern?ndez-Breis
Journal of Biomedical
On Thu, 2010-11-11 at 08:52 +0930, Sam Heard wrote:
We have learned a lot over the past few years - but I am a practicing
clinician and the following should be read with that in mind!
While a lot has been learned. The universe of people actually
developing archetypes is rather small when
On 11/11/2010 12:32, Tim Cook wrote:
As far as the comment about the ENTRY sub-classes intruding on the
ontological space. They do not intrude, that is a point of intersection
where one represents knowledge and the other gives it structure. Both
are a requirement for interoperability.
well
Hi William
I didn't see anyone say that the hl7 models have been developed without
clinical input. I am certain this isn't true.
I don't completely agree with you about the ease of accessibility for
clinicians of UML models and MIF models - it's not our experience.
Regards Hugh
Sent
a reality. If the concept of DCM has any future it
needs to not support any model specifically. I think the ISO data types are
in the same boat. They are NOT the HL7 V2 or V3 data types at this stage,
they came into existence before that and hopefully HL7 will move towards
them
Oops, I intended to push the save-button, not the send-button on that last
message. Now we'll just have to make a fire, shovel some snow, milk our
goats, say good morning to cat and chickens, fix a leaking car tire, get
kids to school and myself and my wife to work before I can continue writing.
Hello again!
Here comes a more complete version of the mail I happened to send unfinished
this morning.
I hope you don't mind me breaking out a side thread with concrete
harmonisation suggestions. First an openEHR change request (CR), then an ISO
13606 change request.
1. item_structure (openEHR
technical discussions
Subject: Re: openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and
ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Tom, did I really express myself in such an unclear way or did you not read
properly? Or did you respond to the wrong thread somehow? Perhaps
On 10/11/2010 16:16, Erik Sundvall wrote:
Tom, did I really express myself in such an unclear way or did you not
read properly? Or did you respond to the wrong thread somehow? Perhaps
i misinterpret your tone and arguments so please clarify if you have
problems with the following:
Audiogram, reflexes and vision results are sometimes recorded and
displayed in two-column tables in clinical settings. There is an
audiogram Observation archetype on CKM at Audiogram result
http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.44 -
this does not use a table
Just for info the only current example of a CKM archetype which uses
ITEM_TABLE is
Tendon and Babinski reflexes
http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.256_1
and the Audiogram example in Thomas's link shows exactly why
ITEM_TABLE in an archetype root is unhelpful, since
Hi!
On Wed, Nov 10, 2010 at 17:26, tom.seabury at nhs.net wrote:
My simple reading of this is that what are currently trees would instead be
expressed as a sparsely populated arrays ? is that the point?
Just to clarify it is has not already been clarified enough by others:
Everything that is
need the OID registry and CTS to make this work (since
you asked how it would). We discussed the notion of putting the
entire value set in the data type, but this is not properly in the
scope of the data types. I think that models can and should
use the data types to communicate the possible set
Hi all,
For those that remember me, I was quite active in HL7 up until about 5 years
ago. About that time I attended an ISO meeting in Berlin as an Australian
delegate to try to facilitate the harmonization of HL7/CEN/ISO data types
for healthcare. At the meeting there were a lot of frustrated
that any of them would talk with software or
data built on the pure 21090 specification.
but if they've profiled according to the method above, then they will talk to
each to the degree that their requirements match. Solving mismatched
requirements is outside the scope of a data types standard
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101109/e630e31e/attachment.html
on the pure 21090 specification.
but if they've profiled according to the method above, then they will talk to
each to the degree that their requirements match. Solving mismatched
requirements is outside the scope of a data types standard.
If they've profiled *and mapped*, then it's not so
gain a backward compatible
encoding, which means we can actually use it. (And the data model is
actually transformable into another encoding if desired)
Similarly we adapt HL7V2 data for use in the Virtual Medical Record (VMR)
and use ISO data types there, not because they are a seamless match
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101109/a0b3c13d/attachment.html
www.zorginformatiemodel.nl is available since about 2005.
Met vriendelijke groet,
Results 4 Care b.v.
dr. William TF Goossen
directeur
De Stinse 15
3823 VM Amersfoort
email: wgoossen at results4care.nl
telefoon +31 (0)654614458
fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713
success. So we are back to the same
position we were in 5 years ago, with another data types standard that is
unable to be used out of the box ubiquitously in healthcare information
systems.
hypothetical.
[HKF: ] Obviously this deliberate decision was made without the parties that
were in Berlin who had come to that conclusion for a very good reason, they
had already tried that approach without success. ?So we are back to the same
position we were in 5 years ago, with another data
On 09/11/2010 00:37, Grahame Grieve wrote:
There is no escaping from the fact that having a type called 'Any'
representing a concept that should be called something like 'AnyDataValue'
(in openEHR it is DV_ANY) is annoying and has to be dealt with in some way.
really? You've not heard of
Hi Diego,
it has never been said that ADL is intended to be any kind of
replacement of UML. Instead it relies on the UML object meta-model, and
defines a constraint formalism on top of it. This allows you to define a
static class model in the normal way, e.g. in a UML tool or whatever,
and
On 09/11/2010 05:54, Williamtfgoossen at cs.com wrote:
They (the clinical models in HL7 v3 R-MIM format) are all part of
extensive clinician input and review, sorry clinicians do understand
the modeling in HL7 space, but indeed like any other modeling effort,
need some education first.
Hi All,
I think this is a good intelectual interchange, but I really don't know what
conclussions will reach.
From outside I see people comparing positions and opinions, instead of
searching some common point of harmonization. Instead we talk about formats
and ways of modeling (it's like the
Pablo
I agree that this is a good intellectual exchange. I also agree that
the delight and interest in finding differences exemplified in this
discussion sometimes obscures the substantial amount of (very similar)
utility that these various elephants provide.
I have confidence that the ants can
21090 data types too
11/09/2010 12:29 complex?
PM
Hi Charlie,
Alongside that I would say that these architectural and process
discussions are valuable - There is nothing so practical as a good
theory [1] -- interestingly Kurt Lewin was as interested in how to
find good theories, as in maintaining a productive balance between
theory and
Have a look at ISO 11404, it is an intersection (datetime is defined
elsewhere ) and every programming language, database system and
serialisation format uses it and extends it as required.
On 09/11/2010 7:13 PM, Grahame Grieve grahame at kestral.com.au wrote:
which is more likely to be used
I second that!!
Carol
Dra Carola Hullin Lucay Cossio
Presidente of IMIA-LAC
PhD Health Informatics
www.imia-lac.net
+5628979701 Chile
From: s...@vivici.nl
Subject: Re: ISO 21090 data types too complex?
Date: Sun, 7 Nov 2010 14:53:04 +0100
To: openehr-technical at openehr.org
- Harmonized data types for information interchange without the
monumental effort of Grahame Grieve in producing and managing the draft.
However, it is, first and foremost, an HL7 flavoured standard. The most recent
draft I have seen is, according to its forward, a shared document between
Health Level
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/ee957113/attachment.html
, but that is for me out of scope
for
what I am asked to discuss).
Eric is very right that we do need more than just data types. We need
vocabulary, we need units, we need relationships and we need the clinical
knowledge around it, and proof that the persons doing the work can be trusted.
How I
of course there is discussion again on the yes and no's of
calculating averages, there is no science without debate, but that is for me
out of scope for what I am asked to discuss).
Eric is very right that we do need more than just data types. We need
vocabulary, we need units, we need
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/ea79d47f/attachment.html
)
Similarly we adapt HL7V2 data for use in the Virtual Medical Record (VMR) and
use ISO data types there, not because they are a seamless match for HL7V2,
but because the ISO data types are a standard and we would otherwise have to
ballot a whole new standard. Its planned to constrain out many
and find the best possible solution? Can we bring together the SDO
organizations. I also have a problem that openEHR refuses to be an SDO.
Perhaps because they have no rules to follow - while HL7 is bound by ANSI
and ISO rules.
By the way CEN also votes on the data types.
I would like to see some
On Mon, 2010-11-08 at 08:45 -0500, William E Hammond wrote:
I would like to see some real proposals to try to provide simpler, workable
global solutions. It's like World Peace - a great idea but probably not
achievable.
I think that pretty much sums up the situation. :-)
Cheers,
Tim
compatible encoding, which means we can actually
use it. (And the data model is actually transformable into another
encoding if desired)
Similarly we adapt HL7V2 data for use in the Virtual Medical Record
(VMR) and use ISO data types there, not because they are a seamless
match for HL7V2
On 08/11/2010 13:45, William E Hammond wrote:
I appreciate all of the remarks that have been make thus far. I am
responding because I think we might have some shot at being better. I
think many of you tak pot-shots at HL7, and that's OK.
I want to clarify one thing: HL7v2 is an excellent
Well said Ed!
Met vriendelijke groet,
Results 4 Care b.v.
dr. William TF Goossen
directeur
De Stinse 15
3823 VM Amersfoort
email: wgoossen at results4care.nl
telefoon +31 (0)654614458
fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713
-- next part --
An
In a message dated 8-11-2010 15:38:26 W. Europe Standard Time,
thomas.beale at oceaninformatics.com writes:
I have been asking HL7 since 2003 or so to show a clean model of any of
the following in RIM or CDA structures:
2 or 3 sample Apgar
standard 3 sample GTT (glucose tolerance test)
Great, do you have a link where they can be found/seen.
Cheers,
Stef
Op 8 nov 2010, om 21:02 heeft Williamtfgoossen at cs.com het volgende
geschreven:
In a message dated 8-11-2010 15:38:26 W. Europe Standard Time, thomas.beale
at oceaninformatics.com writes:
I have been asking HL7 since
.org
Subject
Re: ISO 21090 data types too
11/08/2010 03:03 complex?
PM
On 08/11/2010 20:02, Williamtfgoossen at cs.com wrote:
In a message dated 8-11-2010 15:38:26 W. Europe Standard Time,
thomas.beale at oceaninformatics.com writes:
I have been asking HL7 since 2003 or so to show a clean model of any
of the following in RIM or CDA structures:
2 or 3 sample
have N pseudo-standards, and no real standard.
This can't be anybody's idea of an easy way to get started with a data
types standard.
2. Some people have responded vehemently to Tom's initial comments
I suppose I'm a little guilty. I don't mind people criticising ISO 21090.
Other's people's
From: openehr-technical-bounces at openehr.org
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: 08 November 2010 21:19
To: openehr-technical at openehr.org
Subject: Re: ISO 21090 data types too complex?
On 08/11/2010 18:51, Grahame Grieve wrote:
hi All
A roll up
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101107/49910900/attachment.html
hi Tom
David's points are right on the money. The heart of the matter
is not invented here. A related issue is the fact that the
ISO 21090 data types are optimised for exchange, not storage
(explicitly a statement in their scope), but the NCI scope includes
storage - which raises hard questions
Grahame,
On 06/11/2010 21:17, Grahame Grieve wrote:
hi Tom
David's points are right on the money. The heart of the matter
is not invented here.
they might well be; my original question was: is this the only possible
reaction (these data types are complex, untested and risky
and will
cause some upgrading of most messages.
It (ISO 21090) could have been more an OpenEHR standard if OpenEHR had
more cooperated in this space instead of reinventing again their own data
types.
Met vriendelijke groet,
Results 4 Care b.v.
dr. William TF Goossen
directeur
De Stinse 15
Wiliiam,
openEHR 'cooperating more' and not 'reinventing' would have been
impossible without time travel. The openEHR data types were started in
2002, and were in production use in Australia in 2004. Since then nearly
all changes have involved refactorings of functions and abstract types
types are complex, untested and risky); is there no
standard that could have been written to get a better reaction?
I contend that there is.
* perhaps, but not a political reality
a few people realise this, but not many. Most think that the title Health
Informatics ? Harmonized data types
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101107/5d3a9dc8/attachment.html
It is not clear to me that Tom's remarks help either. HL7 had data types
very early. That is not the point. The issue is is there anything in the
future we can agree and work togwether. Unfortunately, I have come to the
conclusion we cannot not, and as a result we shall let the market make
standard on datatypes should be about
a set of clean, clear core data types
a set of wrapper types designed to use the core types, optimised for messaging
other sets of wrapper types as needed, optimised for other specific purposes,
e.g. storage or whatever
If no, how would your ideal standard look like
It looks like we're getting to the heart of the matter here.
What I really would like to know from the others what their opinion's on these
subjects are?
If it indeed turns out to be true that Tom don't understand how datatypes, RIM
or data types are working, we, as the openEHR community
on the NCI wiki (blue emphasis mine):
~~ from NCI CBIIT Guidelines for Using the ISO
21090 Standard ~
Guidelines
* The use of ISO 21090 data types is encouraged for CBIIT funded
projects.However, given
1 - 100 of 142 matches
Mail list logo
