Interoperability with HL7

Technical (archive)
21

Dear All,

I think that the discussion should be guided by the following assumptions:

* Society demands standardization organizations to develop
interoperability standards rather than reusability standards.
* Society demands that these standards are applicable now.
* Society does not demand perfect standards, but standards
sufficiently to allow the representation of clinical knowledge to the care
continuum.
* This should not be a story of winners and losers, it's the wrong
approach.

Today our hospitals lack semantic interoperability, companies are afraid of
being wrong about which option to choose, and doctors do not have all the
information to make the best decisions about the health of their patients.
       
        Without this perspective all the work loses its meaning
       
        As the Spanish proverb, "ni quito ni pongo rey pero sirvo a mi
señor".

Carlos Parra.

22

Dear Andrew,

See some reactions in the text below.

Gerard
as former chairman of CEN/tc251 wg1, responsible for the EN13606

The biggest issues with inter-operability relate to the use of Semantic attributes in both HL7 and openEHR.

They are not really semantic in the SNOMED-CT sense in either format, and because they are different, inter-operability between openEHR and HL7 is difficult. OpenEHR has attributes such as “data”, “state” etc and HL7 has Act Relationships that are supposed to be semantic rather than just compositional. OpenEHR also has a lot of specific CLUSTERS such as ITEM_TREE and subclasses of ENTRY such as “EVALUATION” which have semantics that are in the implicit in the model, rather than pure clinical knowledge.

Yes. HL7 RIM based messages and EN13606 extract are different.
No. Both transport the same clinical information from a proprietary system A to B.

The clinical information is expressed in a limited set of expressions.
Each semantic expression has one specific pattern using HL7 and another specific one using EN13606.

When we think about looking at the differences between HL7 CDA and EN 13606 than we see a lot of similarities since CDA (at the semantic level) is a subset of the EN13606 part one. As chair of CENtc251 I was part of that process.

This makes a DCM (Detailed Clinical Models) format that both agree on a difficult proposition. There are other differences, such as the ability of HL7 Observations to have both a value and child acts via Act Relationships, where as openEHR does not have CLUSTERS with values.

I disagree?

Each DCM is expressing a limited set of semantic constructs that can be represented using a DCM reference model.
This DCM Reference Model uses the same classes as EN13606/CDA to indicate the structure.
And per class possible semantic constructs (also called documentation patterns)

A complete DCM model defines ‘MEDSPEAK’.
A controlled language. Examples in other fields are AIRPSEAK (air trafiic) and SEASPEAK (sea traffic).
An other terms I use is: Model of USE, Model of Documentation/Archiving, and DCM ONTOLOGY.

The best way to resolve these is to accept that openEHR and HL7 cannot use the same models without adding extra information to the format ie extending ADL or adding attributes to the RMIM.

If the clinical knowledge was modelled in ISO-13606 there are only compositional attributes ie “items” and only one of them and the data structures defined require the terminology to impart the meaning and not semantic attributes. This could be translated into openEHR and HL7 in a loss less way. There are obviously some issues with the 13606 reference model, but the pure clinical content is then representable with a tree of Name=Value pairs, with the meaning in the terminology rather than the attribute names. It is also an international standard that gives a degree of certainty and stability to the format, even if its not a perfect fit for every system.

Perhaps we do not disagree after all.

One of the issues is the fact that EN13606 and therefor openEHR allows too many degrees of freedom to express the same semantic construct.
The next version of EN13606 must be designed such that these degrees of freedom are reduced to none.

The way to do this is via an additional accepted Model of Use (DCM Model) that defines all semantic constructs plus one mapping to the EN13606 or CDA.

I think in most cases the demographic content is able to be mapped, as people have a lot of practice at that. A bigger issue is things like Medication, which has specific classes in HL7 V2 and 3. However the ability to model clinical knowledge outside the contentious areas and represent the clinical knowledge in a standards based format that can be adapted to other formats would be a huge leap forward. It is even possible to represent this in a loss less way in HL7 v2. For things like Medication and Allergies an archetype that can be mapped to HL7 V2 and V3 Segments/classes is needed for interoperability.

The use of Semantic or “named” attributes specific to a format is the major barrier to a common DCM format. The HL7 V3 assessments and scales RMIM is and example of a HL7 V3 format that is adaptable to an archetype, although it does have a cluster with a value, which would have to be mapped to the “value” ELEMENT of an archetype.

The formula for calculated values is also undefined, but GELLO, which is a standard could be used for this and this is what we use with ISO-13606 archetypes.

I cannot see how openEHR archetypes can be used for a general DCM format, but ISO Archetypes could, as long as they were modelled in a fashion that is neutral to final implementation format.

It is imperative that DCM’s are absolutely free to use and in the public domain. CEN/ISO and ANSI assure that with the standardisation IP rules in general.
DCM’s must be absolutely free from IP problems, well maintained in a formal, flexible, organisation, owned and controlled by all that use them.
OpenEHR as we know it today is a private company. (See under Status: http://www.openehr.org/about/foundation.html)

A common format would require both sides to either map the generic structures into their own specific classes or adopt a more generic model with the semantics in the terminology. The overlap between the information model and the terminology model is probably at the heart of the conflict.

I produced (but not published) a draft document with the DCM Ontology as addition to the EN13606 and my thoughts about the next version of EN13606.
But also with my thoughts about the Boundary problem with coding systems and ontologies.

In collaboration with the Technical University in Valencia we started a project to think about the next version of EN13606.
For this purpose a website is created as focus point for discussions: www.EN13606.EU

Andrew McIntyre

Gerard Freriks

Electronic Record Services B.V.

Ditlaar 7

NL-1066 EE Amsterdam
PO Box: 376, NL-2300AJ Leiden

the Netherlands

M: +31 620347088
E: g.freriks@e-RecordServices.EU
W: www.e-recordservices.eu

Gerard Freriks
+31 620347088
gfrer@luna.nl

23

Hi Gerard,

I agree that we need a DCM model that is free of association with a
specific messaging/document specification, but is transformable into
the desired one in a reliable manner.

Currently EN 13606-2 is the closest to this, but because it is linked
to its own EHR reference model, is not free of issues. While
transformation to CDA is possible, using CDA with compositional Act
Relationships, the reverse is not always possible. eg CDA, in the form
of CCD as an example, uses semantic ACT relationships in places, rather
than compositional ones and EN-13606-2 uses only compositional ones
(ie items) The semantic Act Relationships would need to become
?CLUSTERS in EN13606-2.

I think a DCM format should exclude the administrative attributes,
such as Author and Observation Time and leave those to the Information
model. Drawing that line is potentially tricky, but needs to be done
in order to allow each Information model to do it the way it wants to.
Things like order numbers and links to orders should also stay out of
the DCM model.

In the end we want the pure clinical hierarchical structure that does
not conflict with the information model and ideally does not conflict
with the Terminology Model.

The line between the DCM and terminology is also hard to draw as it
varies depending on the ability of the terminology. eg SNOMED-CT is
quite rich wrt its models and ICD-X is quite poor. A DCM optimised for
SNOMED-CT will be inadequate if the only coding system is ICD-10. I
guess including SNOMED-CT context structures with the option to use
them for ICD-10 and move them to the terminology for SNOMED-CT is one
possibility? 2 similar DCMs (?archetypes) with stated terminology
affinity would be another.

wrt a "DCM Format"

I am sure OWL could provide what's needed, but is not a format that
widely understood and optimised for uptake. An Archetype with a DCM
Reference model would also be possible. That reference model would not
try and be a full EHR model, but the glue to join an information Model
to the terminology Model and the gaps to the information models would
be filled differently in different information Models. The DCM
elements may well be represented in a specific way, but they would
need to be transformable back to the DCM model. DCM models in UML and
mindmaps/spreadsheets capture pieces of the puzzle but are all
inadequate in some way or lack adequate constraints.

There is a project in the HL7 Patient Care committee to try and work
on a DCM format.

Are you suggesting something like this? We have been using EN-13606-2 to
structure HL7 V2 messages in Australia, and that works, but you have
to design the archetypes in a neutral way. In HL7 V2 we have managed
to create the EN13606-2 ENTRY/CLUSTER-ELEMENT hierarchy within OBX segments
and there are no Semantic attributes available (ie Act Relationships)
so it fits well with the EN13606-2 Model. All the EN13606 reference
model outside the COMPOSITION/ENTRY/CLUSTER/ELEMENT relationships has
to be mapped, so we are in effect using EN13606-2 as a DCM format. A
true DCM format would in my view not have those other attributes, but
allow the information model to specify how to do Author, Observation
date, Attestation, Patient etc etc.

As a clinician I think I can identify what the clinical model is, ie
"MEDSPEAK" is. It should be possible to transform that into any
information model which then added the administrative attributes about
the patient, the author and Observation date etc in its own specific
way.

I appreciate this is an openEHR list, and maybe this discussion should
be transferred to a DCM list, but I don't think there are enough
resources to model every clinical concept in every information model
and there is enormous value in a neutral DCM format. The archetype
concept is a good way to achieve this, but perhaps a generic "DCM only"
Reference Model that does not try and be a EHR model would help?

Andrew McIntyre

Wednesday, February 10, 2010, 8:37:08 PM, you wrote:

24

Hi Gerard,

What has happened? For years and years you have been the initiator of many disputes between 13606/openEHR and HL7 and! now all to have become the ‘enemy’.

OpenEHR is a not-for profit organisation and it’s knowlegde is in the open domain. If you had Googled around a litte bit you could have found the following:

A company limited by guarantee is an alternative type of incorporation used primarily for non-profit organisations that require corporate status. A guarantee company does not have a [share capital](http://www!
.ukincorp
are-capital.html), but has members who are guarantors instead of shareholders. The guarantors give an undertaking to contribute a nominal amount towards the winding up of the company in the event of a shortfall upon cessation of business. It cannot distribute its profits to its members, and is therefore eligible to apply for charitable status if necessary.&n! bsp;

So I would like you to withdraw this unfunded accusation or provide some solid facts to prove the contrary. This really doesn’t help the discussion.

I do like the fact that you’ve turned around and see opportunities to harmonize HL7, 13606 and openEHR, so let’s keep working on that track.

Cheers,

Stef

25

For one or another reason a part of the text in my reply is ‘meshed’ up when I receive it back via the mailinglist. The first sentence of my reply was intended to be:

What has happened? For years and years you have been the initiator of many disputes between 13606/openEHR and HL7 and now all over sudden openEHR seems to have become the ‘enemy’.

I hope it shows up correctly this time. Does anybody know why/how this ‘mesh-up’ happens?

Begin doorgestuurd bericht:

26

It is imperative that DCM’s are absolutely free to use and in the public domain. CEN/ISO and ANSI assure that with the standardisation IP rules in general.
DCM’s must be absolutely free from IP problems, well maintained in a formal, flexible, organisation, owned and controlled by all that use them.
OpenEHR as we know it today is a private company. (See under Status: http://www.openehr.org/about/foundation.html)

It is not the juridical status of a company that makes the difference for the IP-status of something. If an organization is not-for-profit or for-profit, both can issue all kinds of IP-licenses.
The company form has nothing to do with the licenses it issues

Bert

27

Dear Stef,

It is simple.
Customers demand Archetypes that are completely free ti use in a commercial product.
All openEHR artifacts have an IP owned by a a not-for-profit company with two owners.
For academic use it is free. But for commercial use things are not free.

Archetypes/Templates and Detailed Clinical Models must be completely public, owned democratically by all.

The present situation is not good for business at all.

I’m as a fervent supporter of the ideas behind EN13606 as ever.
We need requirements for DCM’s (and Archetypes) that go beyond the present ones.

With regards,

Gerard

28

Bert,

There is only one answer.
Hospitals we talk with have problems with the way IP is handled by openEHR.
IP owned by two organisations (One UCL and the other Ocean Informatics) they consider not PUBLIC.

I agree that the form of the company is not the issue.
What is important who controls the IP.
All Archetypes/Templates/ DCM’s must be in the public domain, as is language, as is HL7 CDA, as is EN13606, as are ISO standards, XML, etc, etc.

Gerard

29

I agree, but the way Gerard puts it, seems to imply it does.

About the IP licenses. The OpenEHR board issued an e-mail on Okt 2nd 2099 in which they announce that:

'… We have discussed the issues set out above, at length, and they cannot be quickly decided upon, safely. We view it as our role, at this stage, to publish here an interim statement of the policy issues we have identified and the direction of travel we are following, for the Foundation, which is as follows:

  1. To meet immediate needs, we are minded to publish archetypes managed at http://www.openEHR.org/knowledge from the Foundation under the Creative Commons license – specifically the Attribute and ShareAlike (CC-BY-SA). This is the same license that Wikipedia is using.
  2. We also propose, at a minimum, that the copyright of all archetypes managed at http://www.openEHR.org/knowledge should be assigned to the Foundation. This is needed to ensure that the Foundation can give permission to others to adapt the work (see the CC license for details).

We will continue to listen and consult on the wider issues discussed in this interim statement. We must align the Foundation’s approach with the requirements and plans of our partners in IHTSDO and EuroRec and with the development of the new governance framework and business plan now needed for the Foundation.

We will keep the plan under close review over the period ahead, as we work with EuroRec, IHTSDO and others to fund a major experimental and clinically driven project for clinical content quality assurance, embracing archetypes and terminology.

This interim statement is now on the wiki at http://www.openehr.org/wiki/display/oecom/Archetypes±+Copyright+and+Licensing. Subject to any necessary rethinking as a Board, arising from responses we receive before December 1st 2009, we plan that it will become official openEHR Foundation policy from January 1st 2010, when a set of rules covering its implementation will also be published. We will also consider whether and in what form we might usefully propose guidelines for how copyright in archetypes might best be managed in other contexts, such as a) when managed by governments on national or regional servers, b) when managed privately by healthcare organisations, professional bodies or companies, and c) when managed experimentally, eg in research programmes.’

As far as I’m aware the above has become openEHR foundation policy as of January 1st 2010. I have to admit that these changes in the IP status can’t be found on the openEHR homepage at this moment. Can somebody please place the renewed ‘Statement on Copyright and Licensing of Archetypes’ at a prominent place at the openEHR website.

Cheers,

Stef

30

Gerard,

It is possible to reject non-free archetypes and replace them by free
archetypes.

We have seen this mechanism many times, mostly the open standard wins,
even when it is technically slightly inferior, the openness is much more
important.
Than the non-free-snake will often byte its own tail, and the open
standard will become the market-standard.

There is no need for discussing this issue, anyone can start immediately
with creating free archetypes.

But is it really the case that the published archetypes are non-free?
Because the company-form cannot indicate this, we need to read the
accompanying licenses.
In the Netherlands IP-free materials must have a positive indication.
Everything which has no indication must be regarded as non-free IP.

Anyone have a clue about the archetypes form the OpenEHR-website?

Op 10-02-10 14:26, Gerard Freriks schreef:

Dear Stef,

It is simple.
Customers demand Archetypes that are completely free ti use in a
commercial product.
All openEHR artifacts have an IP owned by a a not-for-profit company
with two owners.
For academic use it is free. But for commercial use things are not free.

Can you give a link the the license which says so?

Bert

31

Op 10-02-10 14:32, Gerard Freriks schreef:

Bert,

There is only one answer.
Hospitals we talk with have problems with the way IP is handled by
openEHR.
IP owned by two organisations (One UCL and the other Ocean
Informatics) they consider not PUBLIC.

What is the problem, and on what is the problem. On the archetypes?

Many come from NHS, as I remember, are they also a problem?

We must specify this problem before discussing it.

I agree that the form of the company is not the issue.
What is important who controls the IP.

Not who controls the IP is important, but first the IP-license, and
eventually (if not free licensed), second, who.

It is an important issue you bring up Gerard, i am glad you did. I think
clarity in this is very important.

But it is also late that you bring it up, why not two years ago? Has
something changed?

Bert

32

If you read my reply to Bert, which probably crossed your response, you can see that all archetypes are available under CC-BY-SA license. Unofficially since Okt 2009 and officially since Jan 1th 2010

Do you agree that this means that all openEHR archetypes are in the public domain and that since these archetypes fall under the CC license is really doesn't matter who controls them?

Cheers,

Stef

33

Stef,

It is a good step.
But not sufficient.

That OpenEHR artifacts are published with such a Creative Commons License policy attached to it is a good thing, I agree.
But when a new Reference Model, Archetype Model, Template models change and are published that decision is made by the owners because they own the IP and can issue any new License policy they wish.

Our customers do not want to be held hostage when they invest in the exiting new technology based on En13606/openEHR.
They are taking enough risks already, they feel.

Gerard

34

Op 10-02-10 15:35, Gerard Freriks schreef:

Stef,

It is a good step.
But not sufficient.


That OpenEHR artifacts are published with such a Creative Commons License policy attached to it is a good thing, I agree.
But when a new Reference Model, Archetype Model, Template models change and are published that decision is made by the owners because they own the IP and can issue any new License policy they wish.

Our customers do not want to be held hostage when they invest in the exiting new technology based on En13606/openEHR.
They are taking enough risks already, they feel.

Then minutes ago you did not now about this, you were talking about the organization-model which would impose IP?
No that is proven wrong and still you know it is not sufficient?
How do you know what you customers feel about this new knowledge you just (ten minutes ago) heard of?

I come back to this later, because your remarks do raise questions.

Anyone considering using OpenEHR, read carefully

It looks to me that you misunderstand IP-laws.

It is also impossible to attach IP to an RM-implementation. It is not patented, so anyone can build an implementation.
Same story for the Archetype Model.

You can only protect an idea by patents, on no other way. You can protect an implementation of an (ICT) idea by copyright on sourcecode, but that only applies to the specific implementation.
Is there a patenting application? Do you know, does it seem likely?

To me it does not.
Let me explain:

As soon as the OpenEhR foundation would consider that, it would be a big problem because many people volunteered, and I think OpenEHR would be quickly out of business.
In my opinion it is impossible to patent it because many people volunteered, and a lot can be considered as “prior art”

So if it is not patented, anyone can build an implementation without considering any IP. That is very sure. I have dealt a lot with patents.

Anyone who does business with me can go to a lawyer to check, and if it is not true what I write in here, I pay the lawyer-bill.

Conclusion: OpenEHR-foundation has no IP on implementations.
Maybe there is IP on the published archetypes, IP in the form of copyright. I don’t know. But if that is the case anyone is free to create his own archetypes, IP-free.

end of subject

It looks to me as if you are looking for ways to publicly discouraging hospitals to use OpenEHR. Why is that?

What is the matter Gerard? You used OpenEHR for years, you invested lots of time and money, even build your own implementation, and now you discovered that you cannot use it? That you have to pay?
Where you sleeping that you did not think about these urgent IP-questions you bring up here?

A strange story.

regards
Bert Verhees

35

Please consider the previous as not being send. Thank you

Op 10-02-10 15:35, Gerard Freriks schreef:

Stef,

It is a good step.
But not sufficient.


That OpenEHR artifacts are published with such a Creative Commons License policy attached to it is a good thing, I agree.
But when a new Reference Model, Archetype Model, Template models change and are published that decision is made by the owners because they own the IP and can issue any new License policy they wish.

Our customers do not want to be held hostage when they invest in the exiting new technology based on En13606/openEHR.
They are taking enough risks already, they feel.

Then minutes ago you did not now about this, you were talking about the organization-model which would impose IP?
No that is proven wrong and still you know it is not sufficient?
How do you know what you customers feel about this new knowledge you just (ten minutes ago) heard of?

I come back to this later, because your remarks do raise questions.

(IP = intellectual property)

Anyone considering using OpenEHR, read carefully

It is impossible to attach IP to an RM-implementation to build. It is not patented, so anyone can build an implementation.
Same story for the Archetype Model.
The only thing that can carry IP is a RM-implementation (copyright) but that is as with any software-product you license.

You can only protect an idea by patents, there is no other way. You can protect an implementation of an (ICT) idea by copyright on sourcecode, but that only applies to the specific implementation.

So we must ask: Is there a patenting application? Do you know, does it seem likely?

To me it does not.
Let me explain:

As soon as the OpenEhR foundation would consider that, it would be a big problem because many people volunteered, and I think OpenEHR would be quickly out of business.
In my opinion it is impossible to patent it because many people volunteered, and a lot can be considered as “prior art”.
We also have the lache-doctrine. You cannot patent anything which you let people use for years.

I think an patent-application on the OpenEHR: RM or AOM is impossible.

So if it is not patented, anyone can build an implementation without considering any IP. That is very sure. I have dealt a lot with patents.

Anyone who does business with me can go to a lawyer to check, and if it is not true what I write in here, I pay the lawyer-bill.

Conclusion: OpenEHR-foundation has no IP on implementations.
Maybe there is IP on the published archetypes, IP in the form of copyright. I don’t know. But if that is the case anyone is free to create his own archetypes, IP-free.

end of subject

It looks to me as if you are looking for ways to publicly discouraging hospitals to use OpenEHR. Why is that?

What is the matter Gerard? You used OpenEHR for years, you invested lots of time and money, even build your own implementation, and now you discovered that you cannot use it? That you have to pay?
Where you sleeping that you did not think about these urgent IP-questions you bring up here?

A strange story.

regards
Bert Verhees

36

Op 10-2-2010 17:24, Bert Verhees schreef:

37

I wrote it confusing, so I try again, it is because English is not my first language and the subject is a bit complicated to explain in another language..

There is no IP-claim on any part of the kernel-concept, except from on the literally text of the specification (copyright)
So anyone building a kernel can license it to his customers as he wants, open source, closed source, whatever. There is no payment at all required to the OpenEHR-foundation.
When using sourcecode trom the OpenEHR-website, one must comply to the terms agreed when using that sourcecode. That can differ. But one can always (without any payment done to who-ever) write a kernel from scratch and sell it to who-ever he wants for any price which seems reasonable.

I hope it is clear now.

If someone disagrees please report this.
Also if Gerard Freriks disagrees I would like him to report this, and discuss this.

Thanks
Bert Verhees

Op 10-2-2010 17:24, Bert Verhees schreef:

38

Hi All, interesting discussions but I am afraid it does not take use anywhere…

Yes we all need (we=all of us) some better means to develop health information systems; not only limited to EHR space but the whole continuum including the long waited clinical applications which would help doctors and other healthcare professionals make informed decisions etc. etc.

I think what we are all up to is first a solid methodology to build better systems – no brainer ha?

OK look at other domains, well technical mostly, Telecom, Tourism, Marine, even Entertainment and eGovt. As far as I know (I may be slightly wrong though) neither of these is based on “special home delivery” standards, BUT have adopted development methodologies which worked for everybody – ultimately benefiting the consumer. Why on earth we are going down this pathway? It is absolutely silly to have all these standards in same direction with slight differences. I don’t understand how public money is spent so irresponsibly….

Why don’t we just build systems with what we have and then drive the standardisation process with real evidence…an evolutionary rather than regulatory path. As a developer myself when I see ISO, CEN etc. imposing constraints on me just because they are strong and have powers I feel offended. How many of those people have really built systems, or let alone sat at the same table with clinicians to talk about what they need, gone through procurement processes with RFP’s that don’t even mention about interoperability? I wonder…

Having said these, I will soon publish the results of my research on software maintainability of openEHR based vs. classical OO/Procedural with RDMS model by building a full working application with C# .Net. The implementation is almost complete and I am expecting to have initial results by March. So let’s see if openEHR really works and future-proof! These will be quantitative evaluation results by employing formal software measurement.

We need evidence gentlemen, why don’t we focus on that first. IP is nonsense wrt. Archetypes and openEHR and everybody knows that.

So what are the vendors and governments waiting for??? EVIDENCE!!!

Cheers,

-koray

39 
I think a DCM format should exclude the administrative attributes,
such as Author and Observation Time

Andrew,

I could agree in principle, but how could Observation time be an ‘adiministrative’ attribute?

and leave those to the Information
model. Drawing that line is potentially tricky, but needs to be done
in order to allow each Information model to do it the way it wants to.
Things like order numbers and links to orders should also stay out of
the DCM model.

In the end we want the pure clinical hierarchical structure that does
not conflict with the information model and ideally does not conflict
with the Terminology Model.

is DCM now trying to be totally model-agnostic?

The line between the DCM and terminology is also hard to draw as it
varies depending on the ability of the terminology. eg SNOMED-CT is
quite rich wrt its models and ICD-X is quite poor.

well… sometimes. Have a look here for SNomed’s context model - it is in poor shape… http://www.openehr.org/wiki/display/term/Information+Model±+Terminology+Equivalence

 A DCM optimised for
SNOMED-CT will be inadequate if the only coding system is ICD-10. I
guess including SNOMED-CT context structures with the option to use
them for ICD-10 and move them to the terminology for SNOMED-CT is one
possibility? 2 similar DCMs (?archetypes) with stated terminology
affinity would be another.

many countries are using things like ICD9 or 10, ICPC+, vocabularies for nursing, procedures, devices, prostheses and drugs. Snomed actually doesn’t figure that highly in the list of currently used terminologies - i.e. actually in production. Re-imbursement-related terminologies and vocabularies are far more important right now. So optimising DCM (whatever DCM now is) for Snomed would be quite wrong-headed, unless DCM is also destined for ‘in 5y+’ time.

I appreciate this is an openEHR list, and maybe this discussion should
be transferred to a DCM list, but I don't think there are enough
resources to model every clinical concept in every information model
and there is enormous value in a neutral DCM format. The archetype
concept is a good way to achieve this, but perhaps a generic "DCM only"
Reference Model that does not try and be a EHR model would help?

I am still interested to see what the concrete objections to the openEHR reference model classes as the basis forDCM archetypes are.

  • thomas beale