l@openehr.org\>
> > Thanks for your reply... The situation is certainly more complex as
> > the HL7 Clinical Document Architecture XML framework clearly
> > demonstrates... Just picked the first and simplest examples at hand.
> >
> > Tom
>
> [apologies for cross posting but I doubt it'll offend too many]
>
> Hi Tom (and all),
>
> This is certainly true.
>
> The CDA and the more constrained CCD demonstrate very effectively the
> difficulty in transferring health care information along with it's
> semantic context.
>
> This is of course the reason for the development of two level modeling
> and the maturation of over two decades work into the openEHR Reference
> Model and Archetypes as data descriptors. See: [http://www.openehr.org](http://www.openehr.org)
>
> I hope to (very soon now) introduce a query language based on openEHR
> archetypes that will also allow for a certain amount of "possibility and
> fuzzy" matching. This will allow the use of object database storage and
> retrieval based on a true data model. This will avoid the tragic
> mismatch and data fragmentation of object - relational mapping and the
> horror of SQL masquerading as a true relational model.
>
> The point is though, that the true "killer app" in health care must be
> based on a REAL health care data model.
>
> Cheers,
> --
> Timothy Cook, MSc
> Health Informatics Consulting
> [http://home.comcast.net/~tw\_cook/](http://home.comcast.net/~tw_cook/)
> 01-904-322-8582
>
> [attachment "signature.asc" deleted by William E
Hammond/Dept\_CFM/mc/Duke]
---
### Author:  [@Philippe\_AMELINE](https://discourse.openehr.org/u/Philippe_AMELINE)
#### Post date: [21 March 2007 21:14 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/5 "2007-03-21T21:14:20Z")
Ed,
Of course, it is possible to see a model as an "information mold" that
you need to build before it is possible to craft any piece of information.
And putting data here and there "by chance" won't lead to anything...
except if (by chance) you find some order in the entropy.
But I think that it is "thinking the usual way"... and Tim spoke of
"killer application".
a "perfect data model", but an application which is able to tell the
"health journey story" of a person.
If a formal language is able to tell such a story with a sufficient
level of accuracy, we can expect that it is ideally possible, from this
information, to automatically fill any kind of attribute/value grid (say
to comply with any usual data model).
And even if this ideal is not reachable, we can expect this technology
to be able to locally comply to any data model in use while keeping its
global genericness. For example, for continuity of care purposes, the
personal health record of Mr Smith must be able to locally comply to the
data model used in Hospital X while remaining the plain property of its
owner.
Even if it is not easy every day π
Philippe
William E Hammond wrote:
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [22 March 2007 06:02 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/6 "2007-03-22T06:02:02Z")
Given Tim's message below about a new openEHR query language, it seems
worthwhile indicating one of our future directions in openEHR. As you
may have noticed, there are now two categories of specifications:
'stable' and 'in-development' (see the release 1.0.1 roadmap page). As
soon as we are done with Release 1.0.1, I would proposed that a third
category will come into play, which for now I will call 'industry
specifications'. These are proposals for further specifications in
openEHR, where the original offerings come from industry, or in fact any
external source (including individuals). The process I believe we should
follow (and this is up for discussion by the community) is something
very close to that of the OMG RFP process, whereby external proposals
are made in response to an OMG, or in this case, openEHR, request for
proposals for a particular new specification, e.g. a query language. As
it happens, my own company has created a new archetype-based query
language (paper will be published in MedInifo 2007); the UCL group will
most likely propose something. Any other similar proposals, such as Tims
are strongly encouraged.
Therefore in this third category of specifications, final specifications
would be developed by a process of review and collaborative work on all
received proposals leading to a synthesised specification. The OMG has a
well recognised process for doing this which takes 18 months from RFP to
final standard (or abandonment).
The above at the moment is my opinion, and we would encourage community
input both on the process itself, as well as particular specifications.
One of the question is whether to clone the OMG process (assuming we
agreed that it was a good one to follow), or whether the openEHR
Foundation sought a formal relationship with OMG. For similar reasons,
relationships with say W3C may be worth considering.
I will leave further thoughts to later, in order to see what reactions
the community might have.
- thomas beale
Tim Cook wrote:
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [22 March 2007 06:32 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/7 "2007-03-22T06:32:44Z")
William E Hammond wrote:
> Tom and Tim,
>
> I am not sure what this messages says or recommends what we need to do. I
> particularly don't understand the comment "The point is though, that the
> true "killer app" in health care must be based on a REAL health care data
> model." I think much of the clinical world is confused about the number of
> types of models and models now being presented. What kinds of models do we
> need and how should they be used? We have the RIM, activity models, data
> models, DAMs, use cases, story books, BRIDG, and others. Sorting this
> might be an excellent project for AMIA CIS WG.
>
> Part of the problem also is sorting through the activities of various SDOs.
> None of the SDOs seem to offer an overwhelming solution to all the problems
> for a number of reasons, including scope.
Ed,
a few comments mainly for other (probably newer) members of the
community (Ed knows more about this stuff than most of us)....
in terms of engaging with the domain, if you are a provider, government,
or vendor, the challenge is exactly as Ed says. If I was coming in cold
now, e.g. as the IS manager of a large hospital and did some research, I
would find all the things Ed has mentioned, and would probably have to
spend a year getting on various lists, going to meetings etc in order to
even have a starting clue of what to do about it.
Obviously in openEHR we think we have a 'pretty good answer' to some
problems, and don't resile from that - indeed, I would not want to be
involving anyone else in a journey whose direction wasn't reasonably
coherent and justified by evidence, implementation and real-world use.
So, for the benefit of newer people who might be here, the technical
offering of openEHR is essentially:
\* a set of generic information models that include the notions of
'record', 'subject', various kinds of scientific observation,
assessment, and a few other technical notions such as versioning etc
\* a capability to build a second level of models called archetypes
based on the first level, representing clinical and other domain
content models (not of concepts, like in Snomed, but of 'data
shapes' for data capture and validation); this layer can integrate
in sophisticated ways to terminology such as Snomed, LOINC, ICDx etc
\* a capability to build a third level of models called 'templates',
which underpin screen forms and reports (e.g. discharge summaries)
and messages
\* a capability to build software systems (back-ends) from layer 1,
which can process artifacts from layers 2 and 3
\* a capability to build front-end applications that talk seamlessly
to the back-end services using the templates and archetypes
\* a capability to integrate the system and its internal data with
external data sources (HL7 messages, 13606 Extracts, CDA
documents, relational data extracts etc)
\* a capability to query the data using portable queries based on the
archetypes; this provides the basis (possibly for the first time)
for decision support to get at longitudinal data from multiple
enterprises using reusable queries.
The rest is all detail (there are all kinds of documents about the
details;-). This approach changes a number of things; it involves
clinical people directly (they develop the archetypes), enterprise
ICT/clinical people (they develop the templates and some of the
applications). It \_integrates\_ the information, clinical models and
terminology viewpoints; it provides a solid \_semantic\_ basis for
querying, giving decision support new possibilities. We hope it will
also significantly change the software engineering/solution
deployment/delivery economics for the better while increasing quality.
Not all of this is proven by any means, but quite a lot has; the
prospects for success appear very good based on implementations so far.
Other organisations have approached the problem in different ways, and
often addressing a different subset of the total possible scope. We have
made a commitment to a certain split between information models and
higher level kinds of models (Reference Models and Archetypes, in
openEHR-speak); this is proving to work very well indeed, but of course
others have differing opinions. The only proof that matters is in
ultimate deployment: does the system work, does it scale, and is it
economic to build and run; does it add something good to the way we do
health? That is what we are focussed on - outcomes.
I think the best approach for dealing with the plethora of SDOs is
firstly not to become another one, and secondly to do our best (via
members) at cross-review and fertilisation. A bit of healthy competition
is not bad either. (Some people, including Ed have suggested that
openEHR does in fact become an SDO; I wonder what others think about this).
As soon as Release 1.0.1 is finalised I think we need to flesh out where
openEHR will go from here, and I imagine (hope) there will be much input
into what the roadmap should include.
- thomas beale
---
### Author:  [@Tim\_Cook3](https://discourse.openehr.org/u/Tim_Cook3)
#### Post date: [22 March 2007 11:56 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/8 "2007-03-22T11:56:10Z")
since my proposal for an archetype query language is hardly past the
musing stage and Ocean is prepared to present theirs at MedInfo; I won't
pursue it any further. Archetypes only need one query language. π
Cheers,
Tim
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [22 March 2007 11:59 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/9 "2007-03-22T11:59:09Z")
Dear Colleagues,
Let me explain by means of a metaphor what we must expect from the killer app for health ICT.
What the present situation is, using the Message Paradigm.
Compare it with the Two Level Model Paradigm.
We all know what to expect from the healthcare of the future.
We all know what the ICT-requirements are that are capable to support the healthcare of the future.
I know where to look for the killer Applications.
I know on what models and standards, they can be based.
EN13606 and openEHR.
EN13606 part 1 is published as European standard.
And is accepted (but not published yet) as ISO standard.
The other parts will follow soon.
**Metaphor: the letter**
When we accept that health ICT is about informing a colleague or your self by means of a letter at a later point in time and or other place in the word, then the Microsoft Word word editor is the example of the killer app we need.
Why?
What we expect from an application for writing letters is that it is a tool that can be used to write about anything we care, or have to, write about.
Avionics, banking, my children, health, etc.
The word editor is completely agnostic about model of the world people are in and write about.
**What is the present situation translated to the metaphor?**
What is the method of the Message Paradigm HL7 is using and CEN was using in the past?
People from the healthcare world define a restricted syntax, medical dictionary, text phrases, all assembled in a logical structure.
For each clinical domain people meet and produce this.
What they have produced in effect are sets of fixed electronic forms in a fixed structure. And each domain will produce its own set, own text phrases and dictionary.
All the sets of unique electronic forms are specific for each clinical domain and are used in countries, regions, or the whole world.
Since each community is using its own dictionary and dialect, it results in many variations expressing the same concept.
System vendors are overwhelmed by the number of electronic forms, each form needing specifically developed software to process it.
It is obvious that it takes a lot of discussion and complex consensus to produce these electronic forms and in addition a lot of time to implement these forms in an uniform way in regions, countries or the whole world. (if possible at all) This results in static, in flexible, consensus based electronic forms that can not be adapted fast enough for the ever changing health care. And it places a lot of constraints on nation, regional or local variations that have to be expressed and exchanged. So people start to use work arounds with the electronic forms.
_The result using the metaphor_
The ICT-application functions as a very dedicated application that can process a limited set of electronic forms.
In effect this Message Paradigm results in the situation that any system vendor (it could be Microsoft in my example) writes unique software for each electronic form defined in a community.
In present healthcare it will be hundreds or thousands of vendors that will produce proprietary applications that process the electronic forms.
For each new version of the electronic form large communities of healthcare providers and software vendors will have to go thru the whole process.
The ICT tools used are very context dependent. They contain a lot of domain knowledge.
Semantic interoperability will come at a very high cost. it will be inflexible, limited and incomplete at best.
**What is the situation using the new paradigm?**
A new paradigm is used. The Two Level Model paradigm.
This means that the software tool is completely agnostic about dictionaries, and text phrases used in any domain.
It is gnostic about the syntaxe (the generic structure of each possible letter or document) since not only must humans be able to read the text. Computers need to a model based syntaxe in order to process the information.
In the metaphor there is one application that functions as a generic tool based on a standard.
Healthcare providers using a second tool produce letter as they see fit.
They use dictionaries as they see fit; text phrases as they see fit.
It is in their domain that they must come to the definition of concepts they need.
It is their responsibility to become and stay interoperable.
Whatever they decide the process using a specific editor. On the screen they see what they have agreed, but the output of this so called Archetype Editor is machine readable.
The Archetype Editor (freely available as open source and based on a published specification, is based on a second computer processable model.
All text they produce as kinds of letters are conformant to the unified generic syntaxe.
Any time they can change the content of the letters, the documents. On the fly these letters and documents can be processed by systems.
_The result using the metaphor_
It acts like any normal **word** -processor. Each community is able to decide what in a specific context they have to (or want to write) in what kind of document.
Microsoft (or any competitor) will not have to rewrite software to accomodate new documents.
The healthcare application is able to process all possible letters/documents because they are conformant to the unified generic syntaxe.
Without re-programming all possible variations of letters can be processed.
All data, information, and knowledge in the letters can be read, stored, retrieved, presented and exchanged without the need to write software.
Instantaneously new letters/documents can be defined and processed.
Any community can come to agreements about the content of the letter/document with the type of content they need.
This community can be small (N=1, N=2, ..) Or very large (Region, Country, Cardiology, ENT, β¦)
There is plug-and-play semantic interoperability between conformant systems and users.
Systems become extremely flexible.
The ICT-tools used, are really generic tools that can be used in all possible contexts.
The ICT-tools do not contain any domain knowledge.
It knows how to store, retrieve, present and exchange all possible documents and all concepts that are defined in any community.
Semantic interoperability will come at very low cost. It will be very flexible and comprehensive.
Gerard Freriks
**conexis**
---
### Author:  [@Tim\_Cook3](https://discourse.openehr.org/u/Tim_Cook3)
#### Post date: [22 March 2007 12:17 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/10 "2007-03-22T12:17:16Z")
Tom,
Thanks for your reply to Ed's question.
I would like to answer his comment about not understanding what I meant
by the killer app needing to be based on a real health care data model.
The thread on the CIS WG list was about the capabilities required of the
killer app in health care. There were some great ideas in that thread.
However, I was making the point that those functions would not be fully
useful or even possible if a solid data model was not used as a
foundation. I was of course referring to the two level model approach
of openEHR. This approach is beneficial to any industry but the subject
at hand was health care. π
Thinking out loud -- I believe that the openEHR RM & AOM "could" be the
OO Data Model that the OMDG [http://www.odmg.org/](http://www.odmg.org/) was never able to
popularize. This would have far reaching effects on OO application
development and interoperability across all industries.
Regards,
Tim
---
### Author:  [@William\_E\_Hammond](https://discourse.openehr.org/u/William_E_Hammond)
#### Post date: [22 March 2007 13:33 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/11 "2007-03-22T13:33:23Z")
Tim,
I appreciate the response. The question is what do we do with the
alternate choices to the two level openEHR model. The HL7 RIM was never
intended to be the data model for healthcare, but a reference model. I do
think that other m,odels, including work out of CDISC (and HL7) including
the BRIDG model is useful and usuable. Also work by caBIG has value. My
question is is there any give in which we can blend efforts rather than
compete. A real world model will not come pout of an abstract model. It
will result only from and by people who are actually engaged in real world
scenarios. We need to engage those people.
Ed Hammond
Tim Cook
\ To
Sent by: Thomas Beale
openehr-technical \
-bounces@openehr. cc
org AMIA CIS WG
\, For
openEHR technical discussions
03/22/2007 08:17 \
AM Subject
Re: [cis-wg] Complexity, killer
apps and other conundrums of
Please respond to health information was: cis-wg
tw\_cook@comcast.n Digest, Vol 37, Issue 12 (Juliana
et; Please Brixey)
respond to
For openEHR
technical
discussions
\
Tom,
Thanks for your reply to Ed's question.
I would like to answer his comment about not understanding what I meant
by the killer app needing to be based on a real health care data model.
The thread on the CIS WG list was about the capabilities required of the
killer app in health care. There were some great ideas in that thread.
However, I was making the point that those functions would not be fully
useful or even possible if a solid data model was not used as a
foundation. I was of course referring to the two level model approach
of openEHR. This approach is beneficial to any industry but the subject
at hand was health care. π
Thinking out loud -- I believe that the openEHR RM & AOM "could" be the
OO Data Model that the OMDG [http://www.odmg.org/](http://www.odmg.org/) was never able to
popularize. This would have far reaching effects on OO application
development and interoperability across all industries.
Regards,
Tim
> William E Hammond wrote:
> \> Tom and Tim,
> \>
> \> I am not sure what this messages says or recommends what we need to do.
I
> \> particularly don't understand the comment "The point is though, that
the
> \> true "killer app" in health care must be based on a REAL health care
data
> \> model." I think much of the clinical world is confused about the
number of
> \> types of models and models now being presented. What kinds of models
do we
> \> need and how should they be used? We have the RIM, activity models,
data
> \> models, DAMs, use cases, story books, BRIDG, and others. Sorting this
> \> might be an excellent project for AMIA CIS WG.
> \>
> \> Part of the problem also is sorting through the activities of various
SDOs.
> \> None of the SDOs seem to offer an overwhelming solution to all the
problems
> \> for a number of reasons, including scope.
> \>
> \>
> Ed,
> a few comments mainly for other (probably newer) members of the
> community (Ed knows more about this stuff than most of us)....
> in terms of engaging with the domain, if you are a provider, government,
> or vendor, the challenge is exactly as Ed says. If I was coming in cold
> now, e.g. as the IS manager of a large hospital and did some research, I
> would find all the things Ed has mentioned, and would probably have to
> spend a year getting on various lists, going to meetings etc in order to
> even have a starting clue of what to do about it.
>
> Obviously in openEHR we think we have a 'pretty good answer' to some
> problems, and don't resile from that - indeed, I would not want to be
> involving anyone else in a journey whose direction wasn't reasonably
> coherent and justified by evidence, implementation and real-world use.
> So, for the benefit of newer people who might be here, the technical
> offering of openEHR is essentially:
>
> \* a set of generic information models that include the notions of
> 'record', 'subject', various kinds of scientific observation,
> assessment, and a few other technical notions such as versioning
etc
> \* a capability to build a second level of models called archetypes
> based on the first level, representing clinical and other domain
> content models (not of concepts, like in Snomed, but of 'data
> shapes' for data capture and validation); this layer can integrate
> in sophisticated ways to terminology such as Snomed, LOINC, ICDx
etc
> \* a capability to build a third level of models called 'templates',
> which underpin screen forms and reports (e.g. discharge summaries)
> and messages
> \* a capability to build software systems (back-ends) from layer 1,
> which can process artifacts from layers 2 and 3
> \* a capability to build front-end applications that talk seamlessly
> to the back-end services using the templates and archetypes
> \* a capability to integrate the system and its internal data with
> external data sources (HL7 messages, 13606 Extracts, CDA
> documents, relational data extracts etc)
> \* a capability to query the data using portable queries based on the
> archetypes; this provides the basis (possibly for the first time)
> for decision support to get at longitudinal data from multiple
> enterprises using reusable queries.
>
> The rest is all detail (there are all kinds of documents about the
> details;-). This approach changes a number of things; it involves
> clinical people directly (they develop the archetypes), enterprise
> ICT/clinical people (they develop the templates and some of the
> applications). It \_integrates\_ the information, clinical models and
> terminology viewpoints; it provides a solid \_semantic\_ basis for
> querying, giving decision support new possibilities. We hope it will
> also significantly change the software engineering/solution
> deployment/delivery economics for the better while increasing quality.
> Not all of this is proven by any means, but quite a lot has; the
> prospects for success appear very good based on implementations so far.
>
> Other organisations have approached the problem in different ways, and
> often addressing a different subset of the total possible scope. We have
> made a commitment to a certain split between information models and
> higher level kinds of models (Reference Models and Archetypes, in
> openEHR-speak); this is proving to work very well indeed, but of course
> others have differing opinions. The only proof that matters is in
> ultimate deployment: does the system work, does it scale, and is it
> economic to build and run; does it add something good to the way we do
> health? That is what we are focussed on - outcomes.
>
> I think the best approach for dealing with the plethora of SDOs is
> firstly not to become another one, and secondly to do our best (via
> members) at cross-review and fertilisation. A bit of healthy competition
> is not bad either. (Some people, including Ed have suggested that
> openEHR does in fact become an SDO; I wonder what others think about
this).
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [22 March 2007 13:38 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/12 "2007-03-22T13:38:16Z")
Tim Cook wrote:
> since my proposal for an archetype query language is hardly past the
> musing stage and Ocean is prepared to present theirs at MedInfo; I won't
> pursue it any further. Archetypes only need one query language. π
>
> Cheers,
> Tim
well, that wasn't the reaction I was seeking π It would be great to
get more minds on these problems. I hate the thought that some great
idea might slip into oblivion!
- thomas
---
### Author:  [@William\_E\_Hammond](https://discourse.openehr.org/u/William_E_Hammond)
#### Post date: [22 March 2007 13:41 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/13 "2007-03-22T13:41:37Z")
Thomas,
These are wise words and I appreciate ypur thoughts. Fortunately (or
unfortunately) the clinicaol community is now beginning to become involved.
We need to lead them gently into the night.
Ed
Thomas Beale
\ For openEHR technical discussions
Sent by: \
openehr-technical cc
-bounces@openehr.
org Subject
Re: [cis-wg] Complexity, killer
apps and other conundrums of
03/22/2007 02:32 health information was: cis-wg
AM Digest, Vol 37, Issue 12 (Juliana
Brixey)
Please respond to
For openEHR
technical
discussions
\
William E Hammond wrote:
> Tom and Tim,
>
> I am not sure what this messages says or recommends what we need to do.
I
> particularly don't understand the comment "The point is though, that the
> true "killer app" in health care must be based on a REAL health care data
> model." I think much of the clinical world is confused about the number
of
> types of models and models now being presented. What kinds of models do
we
> need and how should they be used? We have the RIM, activity models, data
> models, DAMs, use cases, story books, BRIDG, and others. Sorting this
> might be an excellent project for AMIA CIS WG.
>
> Part of the problem also is sorting through the activities of various
SDOs.
> None of the SDOs seem to offer an overwhelming solution to all the
problems
> for a number of reasons, including scope.
Ed,
a few comments mainly for other (probably newer) members of the
community (Ed knows more about this stuff than most of us)....
in terms of engaging with the domain, if you are a provider, government,
or vendor, the challenge is exactly as Ed says. If I was coming in cold
now, e.g. as the IS manager of a large hospital and did some research, I
would find all the things Ed has mentioned, and would probably have to
spend a year getting on various lists, going to meetings etc in order to
even have a starting clue of what to do about it.
Obviously in openEHR we think we have a 'pretty good answer' to some
problems, and don't resile from that - indeed, I would not want to be
involving anyone else in a journey whose direction wasn't reasonably
coherent and justified by evidence, implementation and real-world use.
So, for the benefit of newer people who might be here, the technical
offering of openEHR is essentially:
\* a set of generic information models that include the notions of
'record', 'subject', various kinds of scientific observation,
assessment, and a few other technical notions such as versioning etc
\* a capability to build a second level of models called archetypes
based on the first level, representing clinical and other domain
content models (not of concepts, like in Snomed, but of 'data
shapes' for data capture and validation); this layer can integrate
in sophisticated ways to terminology such as Snomed, LOINC, ICDx etc
\* a capability to build a third level of models called 'templates',
which underpin screen forms and reports (e.g. discharge summaries)
and messages
\* a capability to build software systems (back-ends) from layer 1,
which can process artifacts from layers 2 and 3
\* a capability to build front-end applications that talk seamlessly
to the back-end services using the templates and archetypes
\* a capability to integrate the system and its internal data with
external data sources (HL7 messages, 13606 Extracts, CDA
documents, relational data extracts etc)
\* a capability to query the data using portable queries based on the
archetypes; this provides the basis (possibly for the first time)
for decision support to get at longitudinal data from multiple
enterprises using reusable queries.
The rest is all detail (there are all kinds of documents about the
details;-). This approach changes a number of things; it involves
clinical people directly (they develop the archetypes), enterprise
ICT/clinical people (they develop the templates and some of the
applications). It \_integrates\_ the information, clinical models and
terminology viewpoints; it provides a solid \_semantic\_ basis for
querying, giving decision support new possibilities. We hope it will
also significantly change the software engineering/solution
deployment/delivery economics for the better while increasing quality.
Not all of this is proven by any means, but quite a lot has; the
prospects for success appear very good based on implementations so far.
Other organisations have approached the problem in different ways, and
often addressing a different subset of the total possible scope. We have
made a commitment to a certain split between information models and
higher level kinds of models (Reference Models and Archetypes, in
openEHR-speak); this is proving to work very well indeed, but of course
others have differing opinions. The only proof that matters is in
ultimate deployment: does the system work, does it scale, and is it
economic to build and run; does it add something good to the way we do
health? That is what we are focussed on - outcomes.
I think the best approach for dealing with the plethora of SDOs is
firstly not to become another one, and secondly to do our best (via
members) at cross-review and fertilisation. A bit of healthy competition
is not bad either. (Some people, including Ed have suggested that
openEHR does in fact become an SDO; I wonder what others think about this).
As soon as Release 1.0.1 is finalised I think we need to flesh out where
openEHR will go from here, and I imagine (hope) there will be much input
into what the roadmap should include.
- thomas beale
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [22 March 2007 17:54 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/14 "2007-03-22T17:54:34Z")
Dear Tim,
What you write is obvious to me and a small croud.
You are one of them.
Gerard
β β
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252544896
M: +31 620347088
E: [gfrer@luna.nl](mailto:gfrer@luna.nl)
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
---
### Author:  [@ognian.pishev](https://discourse.openehr.org/u/ognian.pishev)
#### Post date: [22 March 2007 19:49 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/15 "2007-03-22T19:49:40Z")
I cannot read your messages. They arrive as an attachment in the form of \*.e
file (which is the format for Eiffel).
O. Pishev
---
### Author:  [@ognian.pishev](https://discourse.openehr.org/u/ognian.pishev)
#### Post date: [22 March 2007 20:34 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/16 "2007-03-22T20:34:44Z")
I saved it, renamed it as a \*.txt file, read it and can say that I fully
agree with you.
I am the Ocean Informatics director in charge of non-health. I do believe
that the two-level methodology is generalisable. However, when dealing with
different business domains, we have to deal with different type systems. For
example, in finance we definitely need to have the ability to express money
and currency classes etc. We need rational numbers (for values quoted as 1
1/4, for example) and we definitely need to deal with different units of
measurement: troy ounces for gold, barrels for oil (when discussing futures
and forwards), interest rates and so on.
A separate issue is that of ontologies. There are multiple classification
and code systems (ISIN, etc.), ISO codes for countries and currencies (which
can be used in openEHR). The list gets bigger.
In order to have a fully archetyped environment, we need to understand the
business rules and constraints of that new business domain and to establish
the connection between the reference and the archetype model.
We may try to add these data types to the openEHR and we will need money and
currencies for admin entries and to interoperate with the accounting,
payment, etc. I beleive, however, that we need domain specific models,
rather than a single OO model. The industry (Microsoft for example) is
talking about domain-specific languages; what we need is domain-specific
reference models and data types.
I can see a common core that is invariant irrespective of the business
domain and we should definitely try to reuse the models that have already
been created and tested.
Ogi Pishev
Ocean Informatics
P.S. The first business implementation of the archetype concept was in the
Mandate Compliance System for the largest fund manager in Australia.
---
### Author:  [@Tim\_Cook3](https://discourse.openehr.org/u/Tim_Cook3)
#### Post date: [23 March 2007 12:40 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/17 "2007-03-23T12:40:41Z")
...
> I am the Ocean Informatics director in charge of non-health. I do believe
> that the two-level methodology is generalisable. However, when dealing with
> different business domains, we have to deal with different type systems.
It seems to me that, in these two sentences, saying that either the
openEHR approach could be but isn't yet generalized. Or, you are saying
that a "type system" exists for each different business domain. Could
you clarify what you meant?
> For
> example, in finance we definitely need to have the ability to express money
> and currency classes etc.
Types of currencies are not part of a "type system" the same way types
of lab requests aren't.
> We need rational numbers (for values quoted as 1
> 1/4, for example)
I believe you'll find this true in almost all business domains and it
certainly is in medicine. Can you explain any need that is not covered
by the DV\_PROPORTION data type?
> and we definitely need to deal with different units of
> measurement: troy ounces for gold, barrels for oil (when discussing futures
> and forwards), interest rates and so on.
Again I believe these are fully accommodated in the reference model.
> A separate issue is that of ontologies. There are multiple classification
> and code systems (ISIN, etc.), ISO codes for countries and currencies (which
> can be used in openEHR). The list gets bigger.
>
> In order to have a fully archetyped environment, we need to understand the
> business rules and constraints of that new business domain and to establish
> the connection between the reference and the archetype model.
I contend that there is already a very strong connection between the
reference model and the archetype model. The ontology issue is fully
abstracted and for any domain (or even subdomains) you would have to
select the appropriate ontologies.
> We may try to add these data types to the openEHR and we will need money and
> currencies for admin entries and to interoperate with the accounting,
> payment, etc. I beleive, however, that we need domain specific models,
> rather than a single OO model.
This is where I believe you are correct. You do need an information
model for each domain (and / or subdomain as appropriate). There is a
nice little block diagram on the front page of each of the openEHR
documents that demonstrated the modularity and generalizable nature of
the approach. I also believe that the openEHR Architecture document
describes this quite well.
> The industry (Microsoft for example) is
> talking about domain-specific languages; what we need is domain-specific
> reference models and data types.
\
Yes! Let's fragment application development and software engineers even
more so than now. This way they will become completely industrialized
and specialized to the point that no one understands the basics any
longer. This is kind of like the way dialects of SQL are taught instead
of the relational model. Then they call it RDBMs data modeling.
\
> I can see a common core that is invariant irrespective of the business
> domain and we should definitely try to reuse the models that have already
> been created and tested.
Good. This sounds like a good approach. π
> Ogi Pishev
> Ocean Informatics
>
> P.S. The first business implementation of the archetype concept was in the
> Mandate Compliance System for the largest fund manager in Australia.
Great; did you have to add new data types to the RM?
Cheers,
---
### Author:  [@Tim\_Cook3](https://discourse.openehr.org/u/Tim_Cook3)
#### Post date: [23 March 2007 15:22 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/18 "2007-03-23T15:22:34Z")
> Tim,
>
> I appreciate the response. The question is what do we do with the
> alternate choices to the two level openEHR model. The HL7 RIM was never
> intended to be the data model for healthcare, but a reference model. I do
> think that other m,odels, including work out of CDISC (and HL7) including
> the BRIDG model is useful and usuable. Also work by caBIG has value.
In my humble opinion these have great value in showing us the different
ways NOT to do things. This is no different than any other scientific
endeavor. More is learned from the mistakes we make than by the
successes.
> My question is is there any give in which we can blend efforts rather than
> compete. A real world model will not come pout of an abstract model. It
> will result only from and by people who are actually engaged in real world
> scenarios. We need to engage those people.
... and I believe that the people at the openEHR Foundation as well as
those (and there is crossover) working on CEN 13606 and HL7 have been
engaged and you can see a melding (where possible) of the
technologies.
As far as a real world model coming out of an abstract (do you mean just
on paper?) model I tend to disagree (as far as I understand your
statement). Any truly functional real world application must be based
on solid engineering constructs. I believe that in the near future you
will see several 'real world' clinical applications based on the openEHR
approach.
Cheers,
Tim
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [23 March 2007 17:00 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/19 "2007-03-23T17:00:53Z")
Dear all,
It is for people like Thomas to correct,
the EN13606 part 2 is a general model that defines how constraints can be expressed to any Reference Model.
Be it EN13606-1, openEHR, HL7v3 CDA, etc.
This is how we, at CEN/tc251, have tried and succeeded in defining, I think.
Part 2 of EN13606 is fully based on the openEHR specification.
It is for these reasons that I state that there is absolutely no connection between part one and part two.
Other than part 1 and 2 belong to a series of European standards that are on their way to become (or have become) ISO standards.
Gerard
β β
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252544896
M: +31 620347088
E: [gfrer@luna.nl](mailto:gfrer@luna.nl)
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [23 March 2007 17:07 UTC](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575/20 "2007-03-23T17:07:10Z")
Dear all,
Let me make a statement to be proven wrong:
**The openEHR Reference Model is so generic that it can be deployed in all sectors of businessβs that deal with dossiers and documents.**
_Perhaps specialised datatypes are needed, perhaps specialised archetypes are needed, I will not contest this, for the moment, at least._
Gerard Freriks
β β
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252544896
M: +31 620347088
E: [gfrer@luna.nl](mailto:gfrer@luna.nl)
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
[Next page](https://discourse.openehr.org/t/cis-wg-complexity-killer-apps-and-other-conundrums-of-health-information-was-cis-wg-digest-vol-37-issue-12-juliana-brixey/14575.md?page=2)