# openEHR in 2009 and beyond.. a view of the way forward

**Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153)
**Created:** 2009-01-23 11:44 UTC
**Views:** 5
**Replies:** 17
**URL:** https://discourse.openehr.org/t/openehr-in-2009-and-beyond-a-view-of-the-way-forward/14873

---

## Post #1 by @tonyshannon

Dear Stef,

Many thanks for the kick into action\. Apologies for the long radio
silence\. I have a tendency to listen>talk>write, been quiet for long
enough while delving into the issues the clinical community have raised
\(inc\. exploring your own issue\) while preparing a draft of this email
for some time now\.

You asked for my view on how developments in openEHR may unfold in 2009
and beyond \(inc archetype governance etc\)\. I'm still not sure this email
is quite ready \(some of these ideas are works in progress\) but as you've
politely pushed\.\. here goes\.

I hope that some/many of the issues in this email will resonate with
people, while I'm aware my views may make others feel uncomfortable\.
Feedback from both camps welcome\.

\(NB Long\+ email to follow\.\.\.\(dare I say this may be easier to print and
digest\)\.\.\. the bottom line of which is that I believe the key answer to
Stefs question may require an open source clinical reference
application, as an important next step for the openEHR clinical community\)

---

## Post #2 by @system

Dear Tony,

Thanks for sharing your thoughts\. I welcome the idea of an open source
clinical User Interface \(UI\) project\. The current open source
implementation projects, e\.g\. Java & Eiffel have good coverage of the
openEHR design specification with a strong focus on tooling and
authoring\. These reference projects do help to validate/clarify the
design specifications and facilitate implementations\. But we still
lack a layer of software to be able to involve the clinical community
more efficiently\.

Thilo, Helma and others have already done very interesting work in
this area \(MIE, Medinfo papers\) from a research perspective\. It seems
there are several independent ongoing UI projects \(e\.g Ocean, Cambio,
Linköping, Chalmers etc\) in the same area\. Maybe it's time for the
openEHR community to share these experiences,  agree on a set of
design approaches and create a reference implementation?

The results from the UI project will be directly useful for EHR
developers\. The mini archetype\-based application you mentioned will be
an excellent way of involving clinicians and explaining the benefits
of using openEHR\. I think it's definitely a good idea and a necessary
step for openEHR\.

Best regards,
Rong

---

## Post #3 by @system

> Dear Tony,
>
\.\.\.
>
> Thilo, Helma and others have already done very interesting work in
> this area \(MIE, Medinfo papers\) from a research perspective\. It seems
> there are several independent ongoing UI projects \(e\.g Ocean, Cambio,
> Linköping, Chalmers etc\) in the same area\. Maybe it's time for the
> openEHR community to share these experiences,  agree on a set of
> design approaches and create a reference implementation?
>

\+1

---

## Post #4 by @thomas.beale

The problem isn't the will, nor the way, it is the funding\. When
national programmes have a way/forum for working together on
requirements, agreeing priorities of work, and what funds they are
willing to put forward on to the work, then the work will get done\. I
think any openEHR community\-based project of the sort mentioned by Tony
can be done in far shorter time than any equivalent offering from
another organisation, due to two things: a\) the internal coherence of
openEHR and b\) the relatively open\-source mode of work\.

\- thomas beale

Roger Erens wrote:

---

## Post #5 by @Olof_Torgersson1

27 jan 2009 kl. 10.28 skrev Rong Chen:

> . It seems
> there are several independent ongoing UI projects (e.g Ocean, Cambio,
> Linköping, Chalmers etc) in the same area. Maybe it's time for the
> openEHR community to share these experiences, agree on a set of
> design approaches and create a reference implementation?

Hi,

The group I'm working with (Chalmers, Sweden), would be very much interested in taking
part in such a project.

Regards

Olof

---

## Post #6 by @Tim_Cook2

Dear Tony,

I do not usually post here but I do read every email\.

> \(NB Long\+ email to follow\.\.\.

Yep, it took me more than a week to tackle even reading it\.  :\-\)  Dare I
say it is well worth the read\.  There are several in\-line comments and I
hope that they are worthy of the original email\.  The parts I have
snipped are no less important, just not germane to my
position/offerings\.

> \(dare I say this may be easier to print and
> digest\)\.\.\. the bottom line of which is that I believe the key answer to
> Stefs question may require an open source clinical reference
> application, as an important next step for the openEHR clinical community\)

I agree\.

>  We have been through a set of requirements workshops, done the
> archetyping and templating, but what I do not have is an openEHR
> compliant application to trial/use them in, so I'm unable to refine the
> archetypes in any rapid prototyping way\.\.
>
I also agree with this\.  However, I'd also like to point out that there
are literally thousands of clinical situations that need applications
and there is no one size fits all\.  A user wants something that does
what they need it to do; do it easily without a lot of other things in
the way\.  All the way from one off research projects to enterprise level
systems\.  We should be capturing all that data in a standardized manner,
for many reasons that everyone here already knows\.

> \*\*The current health IT market
> You might ask what about our existing/current suppliers in the UK\. At
> present while some are working to explore the potential of openEHR, none
> have archetype enabled architectures and all will take some considerable
> time \(likely years\) to change\.

Very true\.  They need a competitive driver\.

> At the same time, despite championing openEHR for a couple of years now,
> I have not yet seen an archetype based solution with a user interface
> \(UI\) that would be fit for my purposes in my own hospital based
> environment, which makes it somewhat difficult to champion openEHR wider
> afield\.\.

Again, the huge volume of needs vs\. the impetus to provide them\.

> \*\*The role of openEHR
> openEHR clearly has the potential have a very significant and positive
> impact on international health IT developments\.
> For me some of the key strengths of archetypes include the transfer of
> \(some\) control to the clinical community, the fit with the complexity of
> modern healthcare and the ability to share and reuse clinical content to
> help with real savings of time and money\.

Probably  the top reason\. But as you point out below; education is key\.

> Note that I didnt put semantic interoperability at the top of the list\.
> Of course I'm aware of the potential for archetypes to help solve the
> semantic interoperability challenge\.\. but I do not think it is the sole
> advantage that we should be pursuing\. Nor do I think we can achieve
> semantic interability in one move\.

Not at all\.  We have major legacy systems to deal with and they will be
around for 15\-20 years minimum\.  That DOES NOT mean that we can't start
small \(think small office and research projects\) to prove the case\.

> Re: 4\)
> \*\*The need for better international governance of openEHR \(archetypes et al\)
> This is a big topic and one that generates much discussion, and is at
> the core of Stef's question\.

<rant>
I won't go into this too far but it is a big frustration for me \(so
standby for some ranting\) as a developer of a system to go to the
website SVN and see all those draft ADL files and if I go to
archetypes/release \.\.\. nada, nothing; not one approved archetype\. What
am I supposed to build an application on?   So where is the CRB?
http://www.openehr.org/about/crb.html The CKM is a cool idea but \(at
least on Firefox/Linux there is nothing there\.

There has been an Architecture Review Board
http://www.openehr.org/about/arb.html in place for nearly five years
that on an international basis has managed to bring to you a very stable
reference model\.  Sometimes working on difficult and contentious issues,
using the proper tools to manage the process\.  I am certain that there
are people that will teach the CRB how this can be done if the clinical
community will step up to the plate\.  You want your applications?  Then
join in the fight\. </rant>

> Another formal route for clinical governance/assurance may involve
> linkage with more traditional Standards Development Organisations
> \(SDOs\)\. David Ingram has announced to the list that discussions are
> progressing with International Health Terminology Standards Development
> Organisation \(IHTSDO\) and openHealthTools \(OHT\),

This can be very important not only from a knowledge perspective but a
publicity one as well\.

> While I am very familar with the pros and cons of a national ehealth
> programme to coordinate clinical governance, I am wary of relying on any
> international body to solve all our problems for us from the top down\.
> As you know things move very slowly at that level and are not usually
> able to keep pace with developments on the ground\.
> In addition designing the perfect set of archetypes via international
> mailing lists/committee is not the ideal/only approach that should be
> pursued\.\.\.

Again, there are tools and established processes\.  You do not have to
invent new ones\.  Maybe tweek the old ones here and there but you can
get started\.

> Re 2& 3
> \*\*What about "homegrown" archetypes\- the wisdom of the crowds?

GREAT\! They can be incorporated into the process\.

>  I'll repeat I do not believe we can design archetypes
> completely by committee, they must evolve from real time use and
> learning as with many things the greatest innovation and learning will
> come from real life experience\.

True\.  But you do have to give someone something to start with so they
can offer feedback\.

>  We also need to bear in mind the 80:20 principle, aiming
>   for "good enough" design and regular iterative development rather than
> anything like perfection\.

True\.

> Re 3\)
> \*\*Tooling & the case for an open source openEHR clinical application to
> support both top\-down and bottom\-up development\.
> So there is in my mind an increasingly strong case for a grassroots
> movement that develops a clinical "reference" application i\.e\. can
> support clinical care, that is openEHR based\.

How about a platform instead of ONE application?

> \*The need to focus this on the UI challenge for clinical engagement
> A user interface focussed openEHR project would provide several
> advantages, including the real\-time review of archetypes developed to
> date and the development and refinement of ideal/varied UIs needed to
> ensure ease of use for clinicians who want to use openEHR\.
> I also believe that it is difficult to seperate the layers of archetype
> & template design from the UI layer, as they are much more closely
> linked that most people realise\.

Absolutely\.

> Clearly there is a variety of important clinical requirements that need
> to be defined to provide a useful clinical application \(inc\. terminology
> and messaging requirements that must be addressed in due course\) but
> lets look at those in stages\.

Almost without exception, the very first archetype you use you will need
a terminology at some level\.

> My initial need is for a tool that allows me to capture the patients
> history and examination findings for 80% of those who attend my ED, as I
> was taught in med school, i\.e not addressing 99/100% of my needs, but
> something that is useful more often than not\.\.
> Note that I am not advocating the build of an open source HIS \(though I
> think there is merit in that too, see PatientOS\), but to begin with a
> very discrete application \("widget" if you like\) that begins to support
> the routine clinical documentation that I was taught at medical school\.
>
As I pointed out above\.  Small niche applications are the best place to
start\.  Especially using open source\.

> \*Again, the need to focus on clinical usability requirements
> I know I share this need for ease of use with many many clinicians\.
> There are a number of key requirements \(ease of navigation, ease of data
> entry/data review, etc\) that I am happy to elucidate & coordinate at a
> later stage, but I hope some of you will understand what I'm suggesting\.\.\.\.
> As many frustated clinicians have developed their own homegrown database
> Access/Filemaker solutions, I think openEHR could/should explore the
> development of a solution that meet their needs too, as I think there
> would be a large amount of international interest in such a solution\.
> \(NB Regarding priority no 5\.\. Decision Support\.\. this needs to be
> factored in as one of those requirements\.\.\.albeit perhaps long term\)

Your "key requirements" above are truly key\.  Now, who better knows
those requirements than the users themselves\.  As a side note; in my
previous experience with clinicians this is such an individual set of
requirements that it will drive developers crazy\.

> \*The cons/threats of this suggestion?
> Some of you will parry that openEHR should not be about providing an
> open source application and any move in this direction would put us in
> danger from the commercial world\.

No problem\.  The open source world is very familiar with being "under
threat" \(but not in danger\) from the commercial interests\. :\-\)

> Others will be concerned about the security challenges of such a solution\.

Long fought idea\.  Many case studies prove otherwise\.

> Others still may suggest that someone else needs to do this\.\. \(\*e\.g\. the
> NHS, other national programmes, the vendors etc\) \. I think all of these
> could contribute to and be a part of the solution, but I do not suggest
> we wait for their agreement before proceeding\.

I agree we shouldn't wait\.  But some of us independents could use a
little funding here and there since they will be the ones benefiting the
most\.

> \*Maybe this isnt the right time/Why now/What are we waiting for?
> Simply put I do not suggest waiting for others to solve my/our
> challenges\. I suggest we get on with it\. I'm happy to get on with
> helping to focus the initial clinical requirements of such a solution
> \(I'd already suggest generic medical documentation/medical school
> clerking may be a very good starting point\.\)  This is not quite a call
> to arms just yet\.\. though I feel myself moving in that direction\.

In addition to my above rant about the ARB I WILL issue a call to arms
NOW\!\.  Please allow me to explain\.

Within 2\-4 weeks I will be releasing the Python reference implementation
of the openEHR reference model\.  This is not just the RM itself, it is
built upon a complete application server framework\.  All of the
components are licensed under business friendly licenses so you can also
build commercial applications if you wish\.  We will in the near future
we plan to  be adding APIs for Google Health \(a CCR subset\) and
Microsoft Health Vault \(I think another CCR subset\)\. If you need, you
can also use the full CCR and CCD schemas if you purchase their
licenses\. In order to communicate with other services\.

You can read a bit about the Open Source Health Information Platform
\(OSHIP\) here:  http://www.openehr.org/wiki/display/dev/OSHIP+Developer%
27s\+Wiki as usual, wikis are sometimes a little slow  to be update so I
do not guarantee all the info there is perfect at this point\.

Some more pragmatic stats about the project can be seen on Ohloh\.net
http://www.ohloh.net/p/oship they use automated analysis routines to
examine the code\.   The first interesting thing is scroll down to the
Project Cost box on the right side\.  At the suggested rate of $55,000/yr
for developers the total cost is estimated at over $2\.7M US\.  That
includes all of the documentation that Tom Beale and others have put
together\.  If you want to see the real cost of code development \(98%
myself\) then you can select Code Only from the pulldown\. It's just over
$117,000 US\.  Funded by yours truly\.  Another interesting link is about
code quality and you can find that on the left side as "Code Analysis"\.

But this doesn't tell the whole story\.  Because remember that open
source is about re\-use of quality products\.  You also need to checkout:
http://www.ohloh.net/p/zope3   and  http://www.ohloh.net/p/grok in order
to fully appreciate what you get when you use OSHIP\.

So my point is that there is an openEHR development environment just
around the corner\.  It is a development environment though, not a
specific application\.  My thoughts are that this puts us in a much
better place than one or two reference apps\.

What's needed to build an application?  Well, the openEHR Template
Object Model isn't ready for prime time yet\.  When it is; we plan to
incorporate it\.  Right now we use HTML pages and a special data template
language called TAL\.  Generally the users mock\-up their user interface
in HTML and Python developers add the required data element calls in an
XML type markup so that the HTML can be edited by the user again if
required\.

\*\*\*SO MY CHALLENGE TO THE openEHR Clinical Community\*\*\*
If you want your UIs the way you want them; then send me \(via email\)
some HTML with your entire page layout or just one archetype\.  In the
email explain which archetypes you used\.  BTW: All required elements
from the reference model are not included in the ADL\. Therefore you will
have to look them up in hte documetation for the classes you are using
so you'll know what has to go on the page\. But on the implmenters
mailing list Tom Beale  JUST announced that within 2 weeks he'll have
the Archetype Workbench displaying those attributes\.  YEAH Tom\!

As a caution though\.  If you use MSWord, OpenOffice or any other WYSIWYG
HTML editor I probably will not use your code\.  They create far too much
cruft \(code bloat\) to make it worthwhile to add the data elements\.  Take
some time and learn to use a good HTML editor like Bluefish
http://bluefish.openoffice.nl/ \(not sure how well the MSWin users will
like the install\), or any other non\-WYSIWYG editor \(Note pad works
too :\->  \)

One caveat to this is that if you wish to pay my consulting fee of $150
US /hour you can use any HTML editor you like\.  Just deposit the first
two hours worth in my PayPal account at timothywayne\.cook@gmail\.com and
I'll bill you for any remaining hours\. :\-\)

Anyway, the pages or just snippets \(one or two archetypes\) will likely
end up as examples in OSHIP and may eventually become a shipping
application it's self\.  Please be sure and add the text in an HTML
comment that the work is licensed under a Creative Commons License\.

If some of you do not like my promotion of OSHIP here then I apologize\.
But do remember that this work has been an investment for me and I plan
to hold one week workshops "How to develop healthcare applications with
OSHIP"\.  If you have an interested group then please let me know
off\-list\.

> \*\*How does this sound\.\.\.Your reaction please
> Lets see what the reaction to this email and my suggestion of an open
> source UI oriented clinical documentation project as a next step for the
> openEHR clinical community\.

I think I've accomplished this\. ;\-\)

Kind Regards,
Tim


[details="(attachments)"]

![oe\_trick.png|800x100](upload://qjgx3uKBYyeXWsySJAXMF4JHC4w.png)

[/details]

---

## Post #7 by @system

Hi Tim

This is very impressive and a massive contribution\. I should have known you
wouldn't settle for less\.

Cheers, Sam

---

## Post #8 by @Koray_Atalag

Hi, great points thanks\!

I have two comments \(short\)

1\) I have been trying to tell that an application with which we can
demonstrate a neat UI to clinicians/decision makers with their own data
and layout is IMPORTANT\. I am happy that this is being pronounced
strongly now\.

2\) My whole involvement with openEHR started because of such a need to
create an automatic UI for an endoscopic report generator \(which started
from grass as a commercial work then became the foundation of my Ph\.D\.
thesis\)\. I have evaluated Protege \(too generic\) and openSDE before
jumping into openEHR space\. I strongly suggest that you take a good lokk
at openSDE project \- which is open source done my Erasmus University\.
Excellent knowledge on how to translate from a knowledge model \(similar
to an archetype \- but too difficult to achieve large scale
standardisation as it lacks a formal RM\)\) to GUI\. This will definitely
prevent reinventing\.\.\.

Also referring to some of the comments about interoperability not
necessarily being the most important aspect of openEHR archetypes:
Definitely not\. I think clinical usability, rapid prototyping and
MAINTAINABILITY is perhaps a more realistic driver\. Interoperability is
great ONLY IF you have such systems to interoperate\. The problem is that
we just do not have that many clinical applications running\. The ROI of
interoperability is hard to quantify \- but maintainability is pretty
straightforward\. I am currently researching on developing an open source
version of my original software based on openEHR archetypes\. I intend to
publish soon but to give you initial ideas \(from real requirements which
I have collected over years from a real clinical system\) the overall
maintainability gets a lot better \- perhaps more than 10 times\! That
means a lot of money\! And you get interoperability as bonus ;\)

Oh and BTW, Seref congratulations\!

Cheers,

---

## Post #9 by @Hugh_Leslie1

Hi Tim

Wasn't sure what you meant about CKM for linux and firefox???

CKM is web based and runs nicely in firefox - don't think that the OS should have anything to do with it as long as javascript works...I haven't yet tried to run it in linus though.

have you had a look at [http://www.openehr.org/knowledge](http://www.openehr.org/knowledge) ? There are archetypes that are now going through the process of publishing (although only one has been finalised to my knowledge).

regards Hugh

---

## Post #10 by @Tim_Cook2

In the past I had seen a few archetypes there\.  however now when I login
I get several error boxes that say teams cannot be loaded, archetypes
cannot be loaded, etc\.

Using Firebug I get this one site error:


[details="(attachments)"]

![oe\_trick.png|800x100](upload://qjgx3uKBYyeXWsySJAXMF4JHC4w.png)

[/details]

---

## Post #11 by @heather.leslie

Hi Tim,

It is Murphy's law at work today \- Hugh has pointed you to CKM again on
the day we have had an unexpected licencing issue \- hence the issues you
have noted\.

It is still beta, and this is clearly a notification issue we need to
iron out;\-\)

We should have it up and running again in a few hours, once European and
Australian emails can be aligned\.  Please try again then\.

Bashfully yours

Heather

Tim Cook wrote:

---

## Post #12 by @Seref

Hi,
Tony, please accept my apologies for the late response even though our work at CHIME was mentioned in the first post. I'd like to give a brief description of our work, but first let me introduce myself: I am a PhD Student in UCL CHIME working under the supervision of Professor David Ingram. I have some industry experience, and our discussions with Professor Ingram led us to the conclusion that it would be good to explore the idea of a simple clinical application built on openEHR.
After further discussions we have decided to move forward with the Java reference implementation. We have also decided to target tooling as a valuable byproduct of our work, and already having a Java based reference implementation, we chose Eclipse as the tooling platform.
At the moment we are at very early stages of our work, but basically the idea is to develop a small scale clinical application using the Java reference implementation. While doing that we would also like to produce a set of Eclipse plugins that would help us in developing our application. Tony Shannon has kindly accepted to provide clinical feedback and guidance, and as soon as we have something with a mass that is significant enough,we will be sharing it as an open source application with the community. I hope I'll be able to share with you our progress as we move forward.

Best Regards
Seref Arikan

ps: Thanks Koray, hope you are fine out there :)

---

## Post #13 by @Brandon_Ulrich

Hi Seref,

I'm glad to hear that UCL CHIME is getting involved in openEHR tooling
using the Eclipse platform\.

As you saw at the HL7 UK 2008 conference, our company \(B2
International\) has been working on tooling support for HL7 v3
modeling\. The underlying architecture is standards agnostic and
focused on building a logical model to generate code for model
creation, serialization, validation, and graphical editing\. We used
technology standards \(Eclipse, Ecore/EMOF, EMF, GMF, GEF, oAW, ANTLR,
etc\.\) to express healthcare standards \(HL7 v3 meta\-model, MIF\-
serialized RIM, datatypes, vocab, etc\.\) so that the API could be used
by anyone with a general informatics background\.

Since you'll be working with the Eclipse framework, I suspect that
you'll also be working with more or less the same technology stack\. In
fact, I believe that you could keep the technical architecture that
we've developed in place and focus on the higher\-value openEHR domain
model\.

As our work was sponsored by CfH and will soon be released as an open\-
source OHT project, we'd be happy to go into more detail with anyone
that's interested in such an approach and its potential benefit to the
openEHR community\.

Brandon

---

## Post #14 by @tonyshannon

Dear Colleagues,

Many thanks for your feedback from my earlier post\. After a week away
and some time to digest the replies there is thankfully a consensus that
an open source clinical reference application/framework would be a
positive step forward for us as a community\.

Let me now make a single suggestion\.
Please send me via this list \( or directly to tony\.shannon@nhs\.net \)
your own view as to the top 5/10 requirements for a \*clinically usable\*
solution\.
I won't ask more than that for now, let see what that request generates\.
I am mindful of Tim's point about the huge breadth of requirements that
the clinical community can generate\. I am very familiar with that
challenge, so please allow me to channel/challenge the requirements to
ensure we end up with a highly pragmatic consensus\.

I am also interested in work that some of you have already done in this
area already\. Particularly those of you that have offered to help, I'm
interested in brief summaries/screenshots of work done to date\.
There will, no doubt, need to follow a related discussion of technical
issues but I'd like to leave that for now\.

Many thanks in advance for your help with this\.
Kind regards,

Tony

Dr\. Tony Shannon
Consultant in Emergency Medicine, Leeds Teaching Hospitals
Clinical Lead, Clinical Content Service, NHS Connecting for Health
Chair,  Clinical Review Board,  openEHR Foundation
Honorary Research Fellow, University College London
\+44\.789\.988 5068            tony\.shannon@nhs\.net

---

## Post #15 by @Seref

Hi Brandon,
I remember the impressive demo of the HL7 v3 tooling in Eclipse. Too bad I could not take a closer look, since I was running around to help Tim Benson :)
Some of the work we have in our minds will certainly make use of usual Eclipse sub-projects stack. At the moment we have a quite broad range of ideas for implementation, and we're also trying to prioritise them.
We have also determined OHT as an initiative to contribute, so I'm sure we'll have a couple of things to discuss in the very near future.
Do you have an idea for your release date?

Kind regards
Seref

---

## Post #16 by @Brandon_Ulrich

The first phase of the project was complete at the end of October; we're just waiting on an IPR issue with HL7 before the code is released at OHT. We'd be happy to set up a conference call with you and CHIME...I suspect that you'll encounter the same sets of issues and technology choices that we already researched. Hopefully we can save you some time.

Brandon

---

## Post #17 by @system

Taking into account
http://www.ehealtheurope.net/comment_and_analysis/375/eu_sets_e-health_map_for_2009

in order to obtain some possible funding, the focus should probably be
on epSOS\.

Maybe we also should get started thinking about ways for clinical
applications to achieve an 'openEHR\-certified' status\.

Regards,

Roger

---

## Post #18 by @Koray_Atalag

Hi,

I think ADL has proved to be a pretty good knowledge modelling language
and that the growing number of archetypes represents a good deal of
clinical knowledge\. What is lacking is the ability to define
relationships and their types between nodes or even nodes in other
archetypes\. I don't really know if this is possible via invariants \- but
I think this should be pretty easy with the introduction of a few
keywords and definitely would not imply any changes in the RM \(I hope\)\.

There are a number of situations where I think this might be useful:
1\) openEHR is criticised in 'other' rounds for the lack of computable
semantics inside the Archetypes and Templates and that they say
delegating all the semantics to terminology via bindings is not a safe
and sound approach\. Although I am fully aware of the power of openEHR
with regard to semantic coherence, I think there is nothing wrong to
define  some basic semantics inside the archetype\. That is actually part
of the domain knowledge\.

2\) It is possible to build a 'real' domain ontology \- say mini\-ontology
without depending on other formalisms\. Some of you might say what is the
point of building a domain ontology with ADL\.\.\.Well I can think of
better validation during data entry, processing, GUI design, querying
etc\.\-nearly all aspects\.

3\) It is one of our strongest arguments that Archetype do not need an
external terminology \- can rely on its own local codes\. External
terminology just adds more semantics into\. So far so good \- But what
happens to a mission critical DSS application when terminology server
goes down? Or, in most cases, a terminology for that concept does not
exist at all? Or exists but in another language?

The formalism is already there \- 95% of work has already been done to
make ADL a great knowledge representation language\. So why not do the 5%?
BTW I am by no means a knowledge management expert, but had some
experience with other formalisms \(especially Protege\) for clinical
modelling\.

Cheers,

\-koray

---


**Canonical:** https://discourse.openehr.org/t/openehr-in-2009-and-beyond-a-view-of-the-way-forward/14873
**Original content:** https://discourse.openehr.org/t/openehr-in-2009-and-beyond-a-view-of-the-way-forward/14873