# aus health it

**URL:** <https://discourse.openehr.org/t/aus-health-it/14607>\
**Category:** Clinical (archive)\
**Created:** [21 January 2007 23:42 UTC](https://discourse.openehr.org/t/aus-health-it/14607 "2007-01-21T23:42:36Z")\
**Posts on this page:** 19\
**Page:** 2

<div class="post-metadata">

**Author:** ![williamtfgoossen](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/w/aca169/32.png) [@williamtfgoossen](https://discourse.openehr.org/u/williamtfgoossen)\
**Post date:** [23 January 2007 08:16 UTC](https://discourse.openehr.org/t/aus-health-it/14607/21 "2007-01-23T08:16:29Z")

</div>

Of course it is bad news in this community if the same principles of 13606 / Open EHR are applied in HL7 v3 Patient Care and that it works.

I think the debate of either or standard is the scientific debate of last century. The work of this century is to standardise clinical content in small discrete archetypes to be used in any IT solution.

Lot of work goes in sorting out the clinical stuff and an appropriate binding to vocabulary and determination of appropriate datatypes. See earlier points made by Cecil Lynch

Then an agnostic modeling serves very well to facilitate implementation in several technical systems, either EHR or message.

Breakthrugh work in this sence is the linkage of HL7 v2 messages and OpenEHR archetype identifiers in the message that specify the clinical content.  
This methodology can be used in HL7 v3 messages in a similar way (refer in the XML tags to the appropriate archetype / template).  
Tooling is underway. Transformation form standard A to B or B to A a piece of cake if all hard clinical consensusbuilding and specification has been done.

Since we have so many ( I envision in the tenth of thousands, even up to hundreds of thousands discrete and small molecular archetypes, given experiences in about a dozen of projects involving clinicians, having dealt with about 10.000 discrite variables, organised in every possible grouping), the most dramatic problem to be solved is the repository of these things called GPICs, CMETs, archetypes, R-MIM, care information models, detailed clinical models, templates.

It is nice to have a big book of all kinds of requirements for archetypes specification such as the Iso 13606-2 archetype language, but if nobody worries about the content itself it is waste of time and effort of 10 years of research in both CEN / OpenEHR and HL7 v.3  
Finding a way to organise, maintain and update archetypes/templates/care information models is the real challenge.

So I think this community should re-read the blog by David More carefully and see similar worries that I have given 3 years of submitting content to both standards organisations, all acknowledging that it is important and all asap ignoring it.

So what we need is a repository of clinical templates, maintained well, that basically ignores the specific technical implementation in either OpenEHR or HL7 CDA or v3 messages. We can apply similar systems as the ISO OID registry to identify sources and content.

William Goossen

---

<div class="post-metadata">

**Author:** ![Koray\_Atalag](https://discourse.openehr.org/user_avatar/discourse.openehr.org/koray_atalag/32/70_2.png) [@Koray\_Atalag](https://discourse.openehr.org/u/Koray_Atalag)\
**Post date:** [23 January 2007 11:06 UTC](https://discourse.openehr.org/t/aus-health-it/14607/22 "2007-01-23T11:06:50Z")

</div>

Tim Churches wrote:

> > Yes indeed. But two (or more) wrongs (or absences of evidence) don't  
> > make a right. My view is that the practice of health informatics needs,  
> > desperately, to become evidence-based, otherwise we will continue to see  
> > hundreds of millions or billions of dollars being poured into the  
> > deployment of health information systems based on what is in the sales  
> > brochure, or based on tender responses, which tend to be just more  
> > elaborate versions of the sales brochures.  
> > &nbsp;&nbsp;

I want to point out a more unfortunate situation still happening in  
Medicine: Not even in such an established and trusted profession has  
truly embraced so called Evidence Based Medicine (EBM) or even Problem  
Based Learning in their medical education curricula! I had been taught  
that the facts (Science of Medicine) in some thousand page terrifying  
textbooks/boring journals or the "Art of Medicine" as taught in clinical  
wards by word of mouth or mostly stored in brains of older clinicians. I  
strongly disagree that Medicine is an "artistic" profession in essence;  
I hope that it is truly "Scientific". This is some philosophic part of  
my research but shortly I found out that there are two sources of  
knowledge in Medicine: Research LABs and Clinical Wards. And most of  
this knowledge is generated in the latter by digesting and discovering  
new knowledge from years of accumulated information from patient  
encounters. Why it is kept unstructured? Mainly because they don't  
really materialize these and they become "insights". Or not infrequently  
of course most do not need to formalize and disseminate it as it  
professionally brings him some strategic advantage. Maybe write some  
papers giving pinpoint part of it but never expressing the "whole  
picture" as needed. And believe me these are not bad people at all; it  
is how they are trained. Well I guess an extensive IS capturing  
structured and sharable data from these wards will make most of this  
information available for processing and this will yield vast amount of  
new knowledge I very much hope. Apart from pratical purposes of sharing  
health data, I am much more interested in this aspect.

Although I agree with the idea of evidence based health informatics, I  
feel sorry that my life span won't be good to see that ☹ However a  
realistic and medium term solution might be first having of course the  
"essential" standardization work finalized, digested and implemented.  
But more important is making sure that people/industry "obey" these. And  
this can only happen (by free-will of course) if health informatics  
becomes a "real" profession by implying some sort of control over  
practice and education. Hehe very practically, even though I am in love  
with what I do, I have hard time to explain to my Mom or other  
"normal/ordinary" people what I do 😃 She keeps on saying: Oh my son you  
have studied medicine and now this computer thing, what are you waiting  
to be a real successful (moneywise) man?? Funny ha...

One criticism I want to make for long time is that, for openEHR and  
possibly other innovations in the open source domain, it shouln't take  
sooo much time to see "real" reference implementations publicly  
accessible somewhere. As time goes by, this is unfortunately the case  
for cutting-edge R&D that they start "loosing-blood" because there are  
many other sharks out there...I guess the patient has not died, or even  
near to that but I know that it will take much longer now to fully  
recover. Also one important warning is that, being open source/spec is  
not a complete protection as in many cases of FOSS products, propriety  
products are still preferred for mainly three reasons: 1) There is a  
switching-cost, 2) Integration issues with other apps around 3) In most  
cases total cost of ownership is lower in propriety products in short to  
medium term. Of course these are my ideas again.

As a last comment and a wish, I really think the main body of industry  
will jump into openEHR based products after seeing for themselves some  
big reference implementations; not just R&D projects. I don't think the  
end-users or buying organizations will have much influence on their  
decision. Because an openEHR based system is expected to do "at least"  
what is currently being done and "plus" more...And this plus will take  
some time to materialize in people's mind. So the users will not see  
much change when using their Hospital IS. An important "buying point" is  
that I am sure openEHR will let most of these vendors do these things  
more consistently and cheaper and also offer totally new features (such  
as on the fly translation, or provide context sensitive decision  
assistance) So to cut short: High impact industrial "reference"  
implementations are needed.

Well I hope I did not bore you all....

Best regards,

Koray Atalag, M.D.

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [23 January 2007 11:39 UTC](https://discourse.openehr.org/t/aus-health-it/14607/23 "2007-01-23T11:39:12Z")

</div>

David,

I won’t argue about the standards thing. The openEHR Foundation is not a standards body, and does not offer its specifications to standards bodies. If anything is heading towards ISO, it is because people in CEN and ISO groups decided that it would be a good idea - it’s not in any way an outcome of openEHR processes.

The question of relative utility of decision support versus interoperability is an interesting one. I am far from competent to answer properly (not being a clinical professional), but my experience over the last 13 years of being involved in this area is this:

- proper decision support is almost non-existent
- this is because there are almost no longitudinal patient-centred records available for inspection - which most medical decision support needs to make any kind of safe inferences
- the key to getting longitudinal patient-centric records (or constructed views that have the same effect) is interoperability - being able to share, convert, integrate data, or to be able to computationally construct views from heterogeous data that has the equivalent effect
- interoperability that is not “semantic intoperability” is of no use to computers, only to humans, and therefore cannot support decision support

So interoperability doesn’t just serve the needs of shared care, but is crucial for decision support. In recent years it has become clear that health authorities would like something else before they get decision support - they would like patient workflow, i.e. care pathways to be managed by the IT. This means being able to managed distributed, heterogeneous data in such a way that the software knows where the patient is, what the last medications were, and what the next scheduled steps are. This all requires an interoperability basis as well.

I can’t argue about the relative importance of clinical decision support (you may well be right), but I can say this: it won’t happen without interoperable systems - to put it concretely, if my CDS software can’t read the blood pressures in the EHR in a standardised way, how is it going to be able to infer hypertension?

- thomas

David More wrote:

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [23 January 2007 11:44 UTC](https://discourse.openehr.org/t/aus-health-it/14607/24 "2007-01-23T11:44:40Z")

</div>

Tim Churches wrote:

> ```auto
> I also think that semantic precision and, related to that, semanic interoperabilty is a sine qua non for a generalised clinical decision support system infrastructure or ecosystem - otherwise we are doomed to forever creating one-off, specific decision support systems which only work with specific health information system installations. But whether openEHR is the answer, or a sufficient answer, to the problem of semantic interoperability remains to be demonstrated, from my perspective. It looks promising, but more experience with it in real-life and pilot situations on a wider range of clinical problems is needed, and that experience needs to be formally assessed and evaluated and reported if at all possible. Again, perhaps it is just a matter of time.
> 
> Tim C
> 
> ```

for those interested at a technical level, making CDS work requires two things:  
a) interoperable systems, so as to get a standardised view of the data  
b) a way of querying the data.

In openEHR, we have done something called archetypes + templates to help the first.Ocean Informatics has also developed a query language based on SQL + archetype paths to intelligently query the data. This will be published in MedInfo 2007, and will be offered to openEHR as a candidate for an openEHR query language. Other approaches to solving the problem exist at UCL and elsewhere, and choosing among proposed solutions we hope will be done in a similar process to OMG.

- thomas

---

<div class="post-metadata">

**Author:** ![Dipak\_Kalra](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/d/e8c25b/32.png) [@Dipak\_Kalra](https://discourse.openehr.org/u/Dipak_Kalra)\
**Post date:** [23 January 2007 12:50 UTC](https://discourse.openehr.org/t/aus-health-it/14607/25 "2007-01-23T12:50:08Z")

</div>

Dear Colleagues,

It has been suggested that I should cross-cost my long reply to David  
More on this list, so here it is. There has been a little further  
correspondence between us on the blog site since.

Dear David,

Thank you for setting up this blog as a window through which to air  
your concerns. As the primary author of the section of prEN13606-2  
that you quote, I am surprised and a little disappointed to find that  
you are so critical of something which rather transparently admits  
its limitations and points to the wider challenge of which it is a part.

The goal of defining data structures to represent key clinical  
information in systematic ways is an old one, going back decades, and  
is vigorously being accelerated now in many national eHealth  
programmes such as yours (Data Groups etc.). These bodies are finding  
many of the challenges you describe: how to contain the number of  
data structures whilst catering for as much of real clinical  
diversity as is wise, how to bind record structures with new-  
generation large terminology such as SNOMED-CT, how to define  
editorial and governance policies and publishing infrastructures for  
these data structures and data sets, how to maintain them in the  
light of evolving practice, and how to deliver a coherent set of  
distributed knowledge services to support authorship and EHR systems.  
Despite these many challenges, it is recognised that this kind of  
approach is necessary if we are to aspire towards even modest  
semantic interoperability of health records.

One key problem is that all such sets of defintions internationally  
use rather ad hoc representation formalisms. Part 2 of 13606 is  
therefore an important stepping-stone contribution towards  
harmonisation in this area, drawing as it does on the openEHR  
Archetype approach. The ability to foster an international standard  
for how such data structures can be represented and shared has been  
widely supported by many of the nations who are already building up  
such data structure libraries (including the UK and Australia, voting  
positively for 13606-2 in historic ballots). It is recognised that  
the challenge of building up content needs to be internationally  
shared, and that vendors (often being global) wishing to exploit such  
knowledge artefacts would in general prefer a single standarised  
representation.

The truth is that this is an area in which research, standardisation  
and productisation need to proceed hand in hand. The solutions cannot  
be found by waiting for research alone to finish, because research  
needs to learn from wide scale practical experience and vice versa.

You will know, I am sure, that 13606 Part 1 does not require the use  
of archetypes i.e. it is recognised that much useful EHR sharing can  
and will take place before archetypes become widely used. Part 2 is  
seeking to standardise that part of the archetype approach that is  
reasonably well established (a comprehensive representation of what  
needs to be specified when a data structure is defined). Future  
standards will be able to address most of the other areas you raise,  
but we are not yet at a point where best practice is established for  
those areas. The openEHR Foundation and its Clinical Review Board,  
and a new Detailed Clincial Models Collaborative of openEHR plus HL7,  
are seeking to build up an understanding of best practice in these  
other areas. There are also many running systems (some research and  
some commercial products) that have adopted an archetype-like  
approach from which we can learn. And there are substantial national  
efforts, such as the Dutch work that William refers to, which are  
identifying important issues and solutions.

I hope therefore that you can use your efforts, given that you have  
taken the trouble to study the field, to help contribute to the  
future learning we still need to make. If you do have specific  
rewordings to propose to 13606 Part 2 I am very happy to receive  
them, and to put them into the consensus standardisation process for  
consideration.

I hope that you and your readers can recognise that the various  
organisations, be it a national effort like the Australian or Dutch,  
a standard like 13606 or HL7 Templates, or research like openEHR's or  
our own at UCL, are all working rather unusually closely and  
harmoniously towards tackling these difficult challenges. I hope you  
will also find that, as a community, we are open to constructive  
critique and to fresh inputs from others.

I look forward to your reply.

With best wishes,

Dipak

---

<div class="post-metadata">

**Author:** ![Nandalal\_Gunaratne](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/n/57b2e6/32.png) [@Nandalal\_Gunaratne](https://discourse.openehr.org/u/Nandalal_Gunaratne)\
**Post date:** [23 January 2007 17:29 UTC](https://discourse.openehr.org/t/aus-health-it/14607/26 "2007-01-23T17:29:23Z")

</div>

Indeed Semantic interoperability is crucial to develop  
really useful IT based systems. It is not possible to  
make safe healthcare IT systems unless we work in a  
way that computers work and make use of that ability.  
Computers are far more accurate than our brain and is  
not affected by extraneous factors, does not lie and  
does not tire etc. Therfore they have a place in safe  
medicine.

Decision support is never going to be simple as it is  
based on EBM and CPG (Clinical Practice Guidelines)  
and will have multiple algorithms even for the same  
conditions. Their integration into the system of care  
can only be attained if there is semantic  
interoperability. The process of the audit cycle will  
also depend on the above and patient care pathways and  
again, needs interoperability to work - audit should  
show if we are following clinical practice guidelines,  
and if not, put this information into processing to be  
researched into depending on patient outcomes by  
comparison of the deviated practice as opposed to the  
evidece-based pathway.

OpenEMR archetypes is the only way I can see that will  
make the above possible.

Theories are always incomplete and need to be tested  
and improved and the OpenEMR allows for this. The work  
is tedious and long drawn, but not stupid and  
impractical. It is best to use it now and improve it  
until we get what we want from it, rather than wait  
until somebody uses it and proves it is impractical or  
brilliant!

I too have studied it but not used it, yet. Therefore  
I am not qualified to call it stupid or anything. But  
i have some faith in the underlying reasons for its  
development.

Nandalal

Nandalal Gunaratne MS FRCS(Eng.) MRACS(Aus.)  
Urological Surgeon  
Sri Lanka  
--- Thomas Beale \<Thomas.Beale@OceanInformatics.biz\>  
wrote:

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [23 January 2007 22:57 UTC](https://discourse.openehr.org/t/aus-health-it/14607/27 "2007-01-23T22:57:49Z")

</div>

Dear William,

You write:

> Interesting view Gerard,  
> …  
> My point is: again: we are arguing the wrong case, namely that of the ‘best’ standard. None is the best, both work depending on the goal.

My reaction:  
We are having the wrong discussion.

I’m NOT talking about the ‘best’ standard.  
My argument was/is that standards are much more peer-reviewed than many papers in journals.  
And in the case of OpenEHR implementable specifications have been produced and peer-reviewed, including working software that ism published.  
So what more proof can you get.  
That was my argument.

The discussion of what is the best standard and standardisation process, is futile.  
We both know our own answers and will not change opinions.  
So be it. That is a discussion I’m not interested in.

With regards,

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

---

<div class="post-metadata">

**Author:** ![David\_More](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/d/d07c76/32.png) [@David\_More](https://discourse.openehr.org/u/David_More)\
**Post date:** [23 January 2007 23:39 UTC](https://discourse.openehr.org/t/aus-health-it/14607/28 "2007-01-23T23:39:34Z")

</div>

Hi Tom,

My quoting seems to misbehave, so I will put comments in the text.

See below

Cheers

David

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [24 January 2007 13:52 UTC](https://discourse.openehr.org/t/aus-health-it/14607/29 "2007-01-24T13:52:44Z")

</div>

David More wrote:

> > - this is because there are almost no longitudinal patient-centred records available for inspection - which most medical decision support needs to make any  
> > kind of safe inferences
> > - the key to getting longitudinal patient-centric records (or constructed views that have the same effect) is interoperability - being able to share,  
> > convert, integrate data, or to be able to computationally construct views from heterogeous data that has the equivalent effect
> > - interoperability that is not “semantic intoperability” is of no use to computers, only to humans, and therefore cannot support decision support
> 
> This is where I part company - taking a purist view you are dead right..but there are a set of middle steps that can be taken that can make a substantial difference. (e.g. within one well designed client providing effective basic prescribing decision support based on some basic information and a little history etc).

well, that is more or less what products like Prodigy do. Prodigy only works because a) it knows that the target system is EMIS (a heavily used GP system in the UK), and b) that READ2 coding is used throughout. This is an example where sufficient (defacto) standardisation and longitudinal data exist to support safe-ish inferencing. And in the UK, this situation only exists because a) the government was smart enough to financially encourage MDs to get computerised b) the solution providers like EMIS actually build pretty good systems, and c) patients have to stick to one GP here in the UK. Elsewhere, in general, none of these factors hold. You couldn’t run Prodigy with Medical Director in Australia for example because the notes are not coded, mostly narrative, not structured, and in general are too arbitrary to do computing with. And that’s assuming the GP uses MD to write her notes anyway. And then there is the problem that any person in Australia (like many other countries) has fragmentary clinical records in multiple GP sites (not to mention hospital records).

One thing that could be achieved fairly soon is medication decision support based on a current medications list. But just obtaining that is hard in many places. So what we are doing in openEHR is making it possible for this sort of information to be standardised and shared. We are not trying to do this kind of decision support - there is nothing standing in the way of it being done, assuming the data can be obtained. That is for other people, products etc. We see our job as making the data available.

> I believe your completed solutions are a good few years off and I see it as being worthwhile to take some small interim pragmatic steps and get some basics going.

well, actually, deployments are a good deal closer than you realise…

> Trying to “boil the ocean” has typically proved both slow and ultimately maybe impossible - but we could make a difference to ordinary practice with simpler approaches I believe.

It is undoubtedly true that some tools not being used today could be used in today’s practices. E.g. medication checking could probably be used now with applications like Medical Director - we are not preventing that at all. But it is a lot harder than you think. Just consider the obstacles to making a hypertension evaluatable against Medical Director data…

> > So interoperability doesn’t just serve the needs of shared care, but is crucial for decision support. In recent years it has become clear that health  
> > authorities would like something else before they get decision support - they would like patient workflow, i.e. care pathways to be managed by the IT. This  
> > means being able to managed distributed, heterogeneous data in such a way that the software knows where the patient is, what the last medications were, and  
> > what the next scheduled steps are. This all requires an interoperability basis as well.
> 
> We could start using things like the CCR (ASTM) and then, having learned, do more.

CCR is a kind of mega-template for everything that could go in an encounter note. We have already modelled much of this in archetypes, and in fact the entirety of the CCR can be done in archetypes. The reason to do this is that while the CCR is a reasonable clinical statement of information to be captured, it is not in a useful deployment form (single XLM schema). This provides little or no componentisation, ability to mix and match various pieces of information captured in different settings, ability to dynamically include items not currently in the CCR, ability to use the same definitions as the basis for GUI forms and query expressions and many other things. XML-schema also doesn’t allow the kinds of rich constraints to be expressed that can be done in archetypes.

> > I can’t argue about the relative importance of clinical decision support (you may well be right), but I can say this: it won’t happen without interoperable  
> > systems - to put it concretely, if my CDS software can’t read the blood pressures in the EHR in a standardised way, how is it going to be able to infer  
> > hypertension?
> 
> See above…we can get along the way by basic information capture within a simple system and a simple rules based system and then improving incrementally. We can save lots of lives before we reach the point of true incompatible system interoperation I believe

David, we have been doing “basic information capture” within “simple systems” for 40 years now. What we can do with today’s data is minimal. That’s because none of the content has a semantic definition or common record model. If this weren’t the case, you would see working decision support systems all through clinical practice.

- thomas

---

<div class="post-metadata">

**Author:** ![Tim\_Churches](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/839c29/32.png) [@Tim\_Churches](https://discourse.openehr.org/u/Tim_Churches)\
**Post date:** [24 January 2007 21:10 UTC](https://discourse.openehr.org/t/aus-health-it/14607/30 "2007-01-24T21:10:03Z")

</div>

Thomas Beale wrote:

> David More wrote:
> 
> > See above...we can get along the way by basic information capture within a  
> > simple system and a simple rules based system and then improving  
> > incrementally. We can save lots of lives before we reach the point of true  
> > incompatible system interoperation I believe
> 
> David, we have been doing "basic information capture" within "simple systems"  
> for 40 years now. What we can do with today's data is minimal.

Well, what computers can do automatically with today's  
("computerised"/electronic) health data is minimal.

Humans can do a lot with it, but then humans are very good at resolving  
semantic ambiguities and imprecision and incompatibilties, on-the-fly,  
without even having to think about it most of the time.

Also, computers can do things automatically with existing data, but they  
need to have their semantic hands held by a human on a case-by-case  
basis. This is waht happens when, say, a researcher analyses clinical  
data collected from heterogenous (or even one) health information  
systems - the human needs to put in a lot of effort to resolve and  
smooth over the semantic problems in the parts of the data in which they  
are interested for their analysis.

> That's because  
> none of the content has a semantic definition or common record model. If this  
> weren't the case, you would see working decision support systems all through  
> clinical practice.

I think the problem is that building good, safe and sufficiently capable  
clinical decision support systems is very hard and needs a lot of input  
and effort from a lot of parties, and thus is expensive. Much of the  
effort will be in resolving semantic problems within each system, on a  
one-off and specific basis. This means that small-to-medium-sized  
vendors/developers of health information systems never have enough  
resources to build good DSS for \*their\* particular product. And of  
course the large health system vendors typically don't sell a single  
system, rather they sell frameworks on which customised systems can be  
built or configured. If you look at how data is captured and represented  
in two different, say, CERNER systems in two different countries, or  
even two different states of Australia, you will find significant  
differences in how data is captured and represented. So again, it is  
difficult to achieve the necessary economies of scale to enable good DSS  
to be developed.

openEHR archetypes provide a promising technical basis for achieving  
shared semantic definition and common record models, but as everyone  
agrees, only if a viable and sustainable mechanism for maintaining a  
unified set of archetypes definitions (including the terminologies to  
which they are bound), can be achieved. It must also allow for the  
necessary specialisation of archetypes for local needs. Building such a  
mechanism is a politico-sociological endeavour far more than a  
technological one. It is achievable, I think, but won't be easy and will  
never be as neat and clean as anyone would like. That's life, and is not  
a reason not to try.

But I feel that far more evidence that openEHR is the best technical  
vehicle for this endeavour is needed before large scale engagement by  
lots of parties will occur.

Tim C

---

<div class="post-metadata">

**Author:** ![Tim\_Churches](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/839c29/32.png) [@Tim\_Churches](https://discourse.openehr.org/u/Tim_Churches)\
**Post date:** [24 January 2007 21:33 UTC](https://discourse.openehr.org/t/aus-health-it/14607/31 "2007-01-24T21:33:04Z")

</div>

Tim Churches wrote:

> Also, computers can do things automatically with existing data, but they  
> need to have their semantic hands held by a human on a case-by-case  
> basis.

Sorry, that should have read:

Also, computers can do things with existing data, but they need to have  
their semantic hands held by a human on a case-by-case basis.

Tim C

---

<div class="post-metadata">

**Author:** ![David\_More](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/d/d07c76/32.png) [@David\_More](https://discourse.openehr.org/u/David_More)\
**Post date:** [24 January 2007 22:14 UTC](https://discourse.openehr.org/t/aus-health-it/14607/32 "2007-01-24T22:14:09Z")

</div>

All,

Just a few points.

Regarding doing some simple things before moving on…the evidence from Australia is (from MJA this year) that only 21% or practitioners are properly using the fully electronic capabilities of existing software. Getting this up to some much higher figure would be a good first step.

Generic point is to get what we can do now fully deployed will make a substantial difference.

Also I wonder how many reading here have fully reviewed CERNER’s more advanced capabilities. They do have a pretty decent (flat I know) data model that does allow for quite useful rule based decision support based on clinical information held on the individual patient in the repository. Using this fully could also make a difference while waiting for the advanced system to arrive.

I agree with Tim’s points and while waiting for the enormous change he recognises is needed for practical archetype implementation there is useful stuff we can do today. A dual track approach (do what we can fully while developing the next generation) seems smarter and lower risk to me.

Cheers

David

---

<div class="post-metadata">

**Author:** ![Tim\_Churches](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/839c29/32.png) [@Tim\_Churches](https://discourse.openehr.org/u/Tim_Churches)\
**Post date:** [24 January 2007 22:31 UTC](https://discourse.openehr.org/t/aus-health-it/14607/33 "2007-01-24T22:31:49Z")

</div>

David More wrote:

> All,
> 
> Just a few points.
> 
> Regarding doing some simple things before moving on...the evidence from Australia is (from  
> MJA this year) that only 21% or practitioners are properly using the fully electronic  
> capabilities of existing software. Getting this up to some much higher figure would be a  
> good first step.
> 
> Generic point is to get what we can do now fully deployed will make a substantial  
> difference.
> 
> Also I wonder how many reading here have fully reviewed CERNER's more advanced  
> capabilities. They do have a pretty decent (flat I know) data model that does allow for  
> quite useful rule based decision support based on clinical information held on the  
> individual patient in the repository. Using this fully could also make a difference while  
> waiting for the advanced system to arrive.

Where can one review the CERNER data model, David? Especially if one is  
not a CERNER customer? Or even if one works for a large organisation  
which is a CERNER customer? Where do we look or whom does one need to  
approach to get access to what you describe?

> I agree with Tim's points and while waiting for the enormous change he recognises is  
> needed for practical archetype implementation there is useful stuff we can do today. A  
> dual track approach (do what we can fully while developing the next generation) seems  
> smarter and lower risk to me.

Yes, and a multi-pronged approach is exactly what will happen because we  
are not discussing a centrally-planned-and-commanded economy here, nor a  
single corporate entity. Each R&D group will basically do what they  
think best and/or what they can get funds to do. Thus people working on  
and promoting openEHR should and will continue to do so, and yes, others  
should and will work on more simple-minded short terms stuff.

Tim C

---

<div class="post-metadata">

**Author:** ![David\_More](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/d/d07c76/32.png) [@David\_More](https://discourse.openehr.org/u/David_More)\
**Post date:** [24 January 2007 23:36 UTC](https://discourse.openehr.org/t/aus-health-it/14607/34 "2007-01-24T23:36:16Z")

</div>

Hi Tim and all

My exposure to the Cerner Data Model has been via 2 evaluations for various international and local clients where I have had it shown to me in the sense of how it is used to build their system during imlementation and how data-elements are found to be incorporated in decision support rules - using their Arden Syntax Engine.

I believe it is available to all those involved in building the various applications Cerner provides in a particular implementation and is, as you would appreciate the key to their application integration. It is designed to be provided as a stable core of “data concepts” and there is capability to add specific data elements locally and while customising for different countries etc.

While I don’t have a copy to walk away with or give you (I am pretty sure Cerner sees it as a core part of their IP - the design especially) I am sure any of the major sites in NSW Health would be able to tell you a great deal more and indeed show you how it is used.

Cheers

David.

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [24 January 2007 23:56 UTC](https://discourse.openehr.org/t/aus-health-it/14607/35 "2007-01-24T23:56:15Z")

</div>

David More wrote:

> All,
> 
> Also I wonder how many reading here have fully reviewed CERNER’s more advanced capabilities. They do have a pretty decent (flat I know) data model that does allow for quite useful rule based decision support based on clinical information held on the individual patient in the repository. Using this fully could also make a difference while waiting for the advanced system to arrive.

Hmmm. How many GP surgeries will be getting Cerner soon I wonder…

- thomas

---

<div class="post-metadata">

**Author:** ![David\_More](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/d/d07c76/32.png) [@David\_More](https://discourse.openehr.org/u/David_More)\
**Post date:** [25 January 2007 00:02 UTC](https://discourse.openehr.org/t/aus-health-it/14607/36 "2007-01-25T00:02:40Z")

</div>

Hi Tom,

> Hmmm. How many GP surgeries will be getting Cerner soon I wonder…
> 
> - thomas

That is hardly the point - not that it is not being used in a range of ambulatory care environments and that Cerner does not have a GP offering. The point is this actually exists today, works and has literature evaluating it (albiet with a variety or outcomes). The consensus view is that CPOE can save lives and improve quality and has been shown to do so in Hospitals - trouble is only 3-4% currently have it, its is not cheap and hard to implement - due in part to clinician resistance. Get that figure up and we would also save more lives.

Cheers

David

---

<div class="post-metadata">

**Author:** ![Tim\_Churches](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/839c29/32.png) [@Tim\_Churches](https://discourse.openehr.org/u/Tim_Churches)\
**Post date:** [25 January 2007 00:47 UTC](https://discourse.openehr.org/t/aus-health-it/14607/37 "2007-01-25T00:47:12Z")

</div>

David More wrote:

> Hi Tim and all
> 
> My exposure to the Cerner Data Model has been via 2 evaluations for various international  
> and local clients where I have had it shown to me in the sense of how it is used to build  
> their system during imlementation and how data-elements are found to be incorporated in  
> decision support rules - using their Arden Syntax Engine.
> 
> I believe it is available to all those involved in building the various applications  
> Cerner provides in a particular implementation and is, as you would appreciate the key to  
> their application integration. It is designed to be provided as a stable core of "data  
> concepts" and there is capability to add specific data elements locally and while  
> customising for different countries etc.

Perhaps this is a bit off-topic, but what David describes in CERNER  
sounds somewhat akin to the "concept dictionary" which is implemented in  
OpenMRS (see [http://openmrs.org/wiki/OpenMRS](http://openmrs.org/wiki/OpenMRS) and  
[http://openmrs.org/wiki/Data\_Model](http://openmrs.org/wiki/Data_Model) and  
[http://openmrs.org/wiki/Concept\_dictionary](http://openmrs.org/wiki/Concept_dictionary) and  
[http://openmrs.org/wiki/Dictionary\_101](http://openmrs.org/wiki/Dictionary_101) ), which I believe is based on  
the Regenstrief Clinic data model which has been used in their systems  
for several decades. At its core it uses an EAV (entity-attribute-value)  
type of representation, where entities are patients etc, and  
"attributes" defined in the second, "soft-coded" level of the data model  
have "concept" metadata and constraints associated with them. Thus it is  
a typical two-level model. Not nearly as sophisticated as openEHR, but  
it has been in the field at Regenstrief for decades and is now in the  
field in Africa in several OpenMRS implementations.

I know that Regenstrief has several decision support systems built on  
top of this, and there are plans to do the same with OpenMRS.

My view is that openEHR is an attempt at the next generation of  
Regenstrief/OpenMRS-style two-level information systems (or  
meta-systems, or system frameworks).

Tim C

---

<div class="post-metadata">

**Author:** ![Ole\_Jorgen\_Anfindsen](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/o/f0a364/32.png) [@Ole\_Jorgen\_Anfindsen](https://discourse.openehr.org/u/Ole_Jorgen_Anfindsen)\
**Post date:** [25 January 2007 09:10 UTC](https://discourse.openehr.org/t/aus-health-it/14607/38 "2007-01-25T09:10:30Z")

</div>

Where can I get an electronic copy of _Health informatics — Electronic health record communication — Part 2: Part 2: Archetype interchange specification_? I have searched for it, but thus far with no luck.

- Ole Jørgen Anfindsen

Andrew Patterson wrote:

---

<div class="post-metadata">

**Author:** ![Dipak\_Kalra](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/d/e8c25b/32.png) [@Dipak\_Kalra](https://discourse.openehr.org/u/Dipak_Kalra)\
**Post date:** [25 January 2007 11:19 UTC](https://discourse.openehr.org/t/aus-health-it/14607/39 "2007-01-25T11:19:10Z")

</div>

Dear Ole,

You can download the latest version of all 13606 drafts here:

[http://www.chime.ucl.ac.uk/~rmhidxk/13606/13606\_2006\_Drafts.zip](http://www.chime.ucl.ac.uk/~rmhidxk/13606/13606_2006_Drafts.zip)

This zip file contains all the parts, and a Readme.

With best wishes,  
Dr Dipak Kalra  
CHIME, UCL

[Previous page](https://discourse.openehr.org/t/aus-health-it/14607.md?page=1)