[GPCG_TALK] Archetype Maintenance

[Tim_Churches]

Tim Churches wrote:

There is another issue buried here - and that is what happens when a
supplier of a
commercial EHR goes 'belly up' etc and stops serving the requisite
information for a
stored archetype to be interpreted from.

Yes, and copies of the archetypes managed by this "reference source"
need to be automatically replicated or mirrored to dozens of other
sites run by independent entities, so that the world doesn't end if
the host of "reference source" goes down the gurgler - someone else
can take over.

Thinking about this a bit more, it occurs to me that simply having
archetype definitions mirrrored at lots of sites is a start, but it
isn't really enough. An archetype (and the reference model it relies
upon) is essential metadata without which the data stored in the
database back-end of an openEHR system is meaningless, or at best rather
hard to interpret.

Thus, archetypes need to be stored, permanently, with the data. This
implies that each and every openEHR/archetypes storage system must be
able to permanently cache (that is, archive) each version of every
archetype definition it has ever used to store any data.

Caching of archetype definitions is only sensible anyway, as it would be
too slow to have to look them up in a remote repository every time they
needed to be used - but the cache must be permanent, and older versions
must never be overwritten (no matter what the stated version in the
actual archetype definition says - one cannot rely on the archetype
authors to update the version information correctly).

Of course, such replication or mirroring implies that all the
archetypes in that "reference source" are licensed in a way that
makes such automatic copying legal. The openEHR ones all are
(although they need to state that in the body of the archetype
definition).

If the argument above - that there is a need to permanent cache or
archive copies of archetype definitions with the data which relies on
them - then all archetype definitions need to be licensed in a manner
which permits users to keep permanent copies of them. My (limited)
understanding of copyright law is that such rights are not automatically
or implicitly granted - thus an explicit license to keep permanent
copies of archetype definitions will always be needed on every archetype
definition. Furthermore, if an end user wants to transfer
his/her data which happens to be stored using an archetype definition
for which the copyright is held by someone else (which will usually be
the case, since end users will rarely author their own archetype
definitions, especially de novo ones), then the archetype definition
used to store the end user's data must be licensed in a way that permits
the end user to redistribute that archetype definition to third parties,
without the need to ask permission from the copyright holder of that
archetype definition.

Furthermore, if you want to add to your data, you will need to be able
to modify the archetype definition used to store it. Thus, you will need
that right granted to you from the outset, in an explicit license, by
the copyright holder of the archetype definition - otherwise you will
need to beg their permission just to be able to modify how you store
your data.

Sorry for the long-winded exposition, but these are the implications of
moving most of the metadata and other "smarts" out from where it
traditionally lies, which is in the back-end database schema and in
middleware software layer, into archetype definition files. Note that
even if the back-end database and the openEHR kernel/engine software are
open source, if the data stored by them is done so using an archetype
definition which does not have a suitable license, then your data is
well and truly locked in to that archetype definition - whomsoever holds
the copyright to the archetype definition will have your data by the
short and curlies - just as much, if not more so, than traditional
closed-source software does.

So to re-iterate, the moral is never, ever use an archetype definition
which was not made available under a perpetual, inalienable license
which permits you to both modify the archetype and to freely distribute
it to others, without needing the copyright holder's permission to do so
- in other words, a free, open source-style license.

Interestingly, whether the openEHR engine/kernel (that is, the
middleware software layer which interprets and enforces the archetype
definitions), or the back-end database, are open source or not doesn't
matter nearly so much as it does with traditional software. Certainly
open source openEHR engines/kernels and other sofwtare components are
highly desirable, but it is the open source licensing of the archetype
definitions which really matters.

Am I correct or is my logic or understanding flawed?

Tim C

[thomas.beale]

I presume this was posted here to get a reaction from someone in openEHR, so I will briefly react...overall, Tim has given a pretty reasonable airing of some of the important points for the future. To my mind his claim of the possible lock-in of data is slightly exaggerated....but in any case, read on...

Tim Churches wrote:

Tim Churches wrote:

There is another issue buried here - and that is what happens when a supplier of a
commercial EHR goes 'belly up' etc and stops serving the requisite information for a
stored archetype to be interpreted from.
     
Yes, and copies of the archetypes managed by this "reference source"
need to be automatically replicated or mirrored to dozens of other
sites run by independent entities, so that the world doesn't end if
the host of "reference source" goes down the gurgler - someone else
can take over.
   
Thinking about this a bit more, it occurs to me that simply having
archetype definitions mirrrored at lots of sites is a start, but it
isn't really enough. An archetype (and the reference model it relies
upon) is essential metadata without which the data stored in the
database back-end of an openEHR system is meaningless, or at best rather
hard to interpret.

Thus, archetypes need to be stored, permanently, with the data. This
implies that each and every openEHR/archetypes storage system must be
able to permanently cache (that is, archive) each version of every
archetype definition it has ever used to store any data.

This is about the right technical solution, and the one we describe in presentations on the topic. You need an archetype cache, or what we call a local archetype service, and local archetype repository anyway for various reasons:
- any given site is likely to use only a small number of the total available archetypes, e.g. 50 of 2000 or whatever it might be. The local cache only needs this number not the 2000.
- it is sensible to have archetypes converted from ADL to runtime-ready form, which will vary in each institution's case.
- your system needs to run if you lose network connectivity with teh archetype library server (or it goes down).
- you may not want archetypes in raw parse form such as ADL or XML, since there might not be any guarantee that they will all parse at runtime, e.g. due to mistaken changes to archetypes, introduction of non-parsing archetypes, or software changes. Pre-conversion to runtime form guards against this.

Part of the story is that archetypes have to be governed properly. This is starting to be set up in Australia and openEHR has created an open Clinical Revoew Board for archetypes served from openEHR.org. Some of the features of good governance will be:
- guaranteed public availability of any non-local archetype, in ADL form on one or more internet archetype library sites
- quality assurance process which guarantees technical & clinical well-formedness, as well as compatibility with existing archetypes (i.e. minimise/avoid overlap).

To get a feel for one possible interface to an archetype library server, see http://www.dualitysystems.com.au/archetypefinder/archetypefinder. This is basic but gives an idea of the functionality. Note that the GUI is not a static form, but is built dynamically from categories in a Protege ontology.

Caching of archetype definitions is only sensible anyway, as it would be
too slow to have to look them up in a remote repository every time they
needed to be used - but the cache must be permanent, and older versions
must never be overwritten (no matter what the stated version in the
actual archetype definition says - one cannot rely on the archetype
authors to update the version information correctly).

this is one of the reasons that archetype libraries have to enforce agreed lifecycle and version control, so that archetypes do not exist in the wild. Eventually the tools will be available so that institutions wanting to develop their own archetypes rather than just use the existing ones (e.g. defined by RACGP, NeHTA, or whomever) can actually implement such controls inside their own walls.

Of course, such replication or mirroring implies that all the archetypes in that "reference source" are licensed in a way that
makes such automatic copying legal. The openEHR ones all are
(although they need to state that in the body of the archetype
definition).
   

correct. What is more, to guarantee that archetypes that you use in production - ones that claim to be certified - really are the same content that was certified, they will need a digital checksum of some kind.

If the argument above - that there is a need to permanent cache or
archive copies of archetype definitions with the data which relies on
them - then all archetype definitions need to be licensed in a manner
which permits users to keep permanent copies of them. My (limited)
understanding of copyright law is that such rights are not automatically
or implicitly granted - thus an explicit license to keep permanent
copies of archetype definitions will always be needed on every archetype
definition. Furthermore, if an end user wants to transfer
his/her data which happens to be stored using an archetype definition
for which the copyright is held by someone else (which will usually be
the case, since end users will rarely author their own archetype
definitions, especially de novo ones), then the archetype definition
used to store the end user's data must be licensed in a way that permits
the end user to redistribute that archetype definition to third parties,
without the need to ask permission from the copyright holder of that
archetype definition.

that is certainly the intention. openEHR currently has a number of licenses for various artefacts it makes available(see http://www.openehr.org/about_openehr/t_licensing.htm). It is developing a suitable license for archetypes.

Furthermore, if you want to add to your data, you will need to be able
to modify the archetype definition used to store it. Thus, you will need

you cannot modify the definition of a released archetype. Well obviously physically you could, but the checksum will no longer be correct, and the tools won't use it. Instead you have to create new version(s) and submit them to whatever is the appropriate level of QA process. (BTW - the tools and ADL don't yet support the checksum, but it is coming, and is technically relatively simple).

that right granted to you from the outset, in an explicit license, by
the copyright holder of the archetype definition - otherwise you will
need to beg their permission just to be able to modify how you store
your data.

What is needed is the right to a) create new versions, and b) to create dependent specialisations.

Sorry for the long-winded exposition, but these are the implications of
moving most of the metadata and other "smarts" out from where it
traditionally lies, which is in the back-end database schema and in
middleware software layer, into archetype definition files. Note that
even if the back-end database and the openEHR kernel/engine software are
open source, if the data stored by them is done so using an archetype
definition which does not have a suitable license, then your data is
well and truly locked in to that archetype definition - whomsoever holds
the copyright to the archetype definition will have your data by the
short and curlies - just as much, if not more so, than traditional
closed-source software does.

well, I don't know that I would go that far. It is pretty hard to claim that data in a standardised, open format rather than a closed commercial format is more locked into vendors. I would see it instead as about the same problem as the re-usability of data that contains e.g. snomed-ct codes or similar - the use of which are licensed by the CAP (currently, but that should change in the future).

So to re-iterate, the moral is never, ever use an archetype definition
which was not made available under a perpetual, inalienable license
which permits you to both modify the archetype and to freely distribute
it to others, without needing the copyright holder's permission to do so
- in other words, a free, open source-style license.

Interestingly, whether the openEHR engine/kernel (that is, the
middleware software layer which interprets and enforces the archetype
definitions), or the back-end database, are open source or not doesn't
matter nearly so much as it does with traditional software. Certainly
open source openEHR engines/kernels and other sofwtare components are
highly desirable, but it is the open source licensing of the archetype
definitions which really matters.

actually, we would argue that it is essential to have open source kernels (plural because you need one in each of the main languages it seems...) - otherwise the temptation will be for vendor orgs to produce slightly different "versions" of the standard, a la Microsoft HTML/functionality in Explorer. We just don't need that happening...

- thomas beale

[Tim_Churches]

Thomas Beale wrote:

Tim Churches wrote:

Furthermore, if you want to add to your data, you will need to be able
to modify the archetype definition used to store it. Thus, you will need

you cannot modify the definition of a released archetype. Well obviously
physically you could, but the checksum will no longer be correct, and
the tools won't use it. Instead you have to create new version(s) and
submit them to whatever is the appropriate level of QA process. (BTW -
the tools and ADL don't yet support the checksum, but it is coming, and
is technically relatively simple).

that right granted to you from the outset, in an explicit license, by
the copyright holder of the archetype definition - otherwise you will
need to beg their permission just to be able to modify how you store
your data.

What is needed is the right to a) create new versions, and b) to create
dependent specialisations.

Yes, by "modify" I meant create new versions of archetype definitions
which are owned by someone else.

Sorry for the long-winded exposition, but these are the implications of
moving most of the metadata and other "smarts" out from where it
traditionally lies, which is in the back-end database schema and in
middleware software layer, into archetype definition files. Note that
even if the back-end database and the openEHR kernel/engine software are
open source, if the data stored by them is done so using an archetype
definition which does not have a suitable license, then your data is
well and truly locked in to that archetype definition - whomsoever holds
the copyright to the archetype definition will have your data by the
short and curlies - just as much, if not more so, than traditional
closed-source software does.

well, I don't know that I would go that far. It is pretty hard to claim
that data in a standardised, open format rather than a closed commercial
format is more locked into vendors.

Yes, fair enough. But the issue I was hinting at is that although the
openEHR technological developments aim to make systems which are
"future-proof" or at least more readily upgradable to meet future needs,
that promise will only be realised if end users have the necessary
freedoms to do so, and those freedoms depend crucially on the
appropriate licensing of archetype definitions. Perhaps this is obvious,
but it had not fully dawned on me.

I would see it instead as about the
same problem as the re-usability of data that contains e.g. snomed-ct
codes or similar - the use of which are licensed by the CAP (currently,
but that should change in the future).

Yes, I would agree with that. As I have opined before, SNOMED CT concept
IDs should not be adopted as a lingua franca unless there is a perpetual
license to use it freely available to everyone (at at least a national
level).

Tim C

[Tim_Churches]

David More wrote:

See short comments below.

Thinking about this a bit more, it occurs to me that simply having
archetype definitions mirrrored at lots of sites is a start, but it
isn't really enough. An archetype (and the reference model it relies
upon) is essential metadata without which the data stored in the
database back-end of an openEHR system is meaningless, or at best rather
hard to interpret.

Thus, archetypes need to be stored, permanently, with the data. This
implies that each and every openEHR/archetypes storage system must be
able to permanently cache (that is, archive) each version of every
archetype definition it has ever used to store any data.

You have now got what I have been worried about - and the issue is amplified by every
variation that is permitted. Governance of all this I am not sure is actually do-able -
what do you think with say 5 different GP systems, 1000 different path and radiology tests
etc etc..

No, David, I never mentioned governance in my post, and although I agree
that careful governance is needed, I do think it is doable. Rather, I'm
worried that people will use archetype definitions which are licensed in
a way that restrict their freedom to manipulate or transfer their own
data (or that of their patients) to others.

I think you have got it quite close - and open-source does not save the day - its the
information management of the archetypes that may save it

As I said, I agreee that management of archetype definitions is
important, but I think that open source-style licensing of archetype
definitions will prevent lock-in/control problems.

- but the openEHR people seem to
be in denial about establishing the infrastructure to do it....Until this ongoing
Governance is nailed, certain and ongoing over decades this idea won't work IMVHO.

We'll have to disagree - the openEHR people do seem to be thinking
carefully about governance, but not in a heavy-handed way. Show me the
governance of anything which is certain and nailed decades into the
future - that's an unrealistic expectation. Personally I am much more
concerned about the possibility of totalitarian lock-in of data and/or
complete dependence on proprietary archetype definitions than I am about
an anarchistic confusion of incompatible archetype definitions (although
both scenarios are undesirable).

Tim C

[Tim_Churches]

David More wrote:

See short comments below.

Thinking about this a bit more, it occurs to me that simply having
archetype definitions mirrrored at lots of sites is a start, but it
isn't really enough. An archetype (and the reference model it relies
upon) is essential metadata without which the data stored in the
database back-end of an openEHR system is meaningless, or at best rather
hard to interpret.

Thus, archetypes need to be stored, permanently, with the data. This
implies that each and every openEHR/archetypes storage system must be
able to permanently cache (that is, archive) each version of every
archetype definition it has ever used to store any data.

You have now got what I have been worried about - and the issue is amplified by every
variation that is permitted. Governance of all this I am not sure is actually do-able -
what do you think with say 5 different GP systems, 1000 different path and radiology tests
etc etc..

No, David, I never mentioned governance in my post, and although I agree
that careful governance is needed, I do think it is doable. Rather, I'm
worried that people will use archetype definitions which are licensed in
a way that restrict their freedom to manipulate or transfer their own
data (or that of their patients) to others.

I think you have got it quite close - and open-source does not save the day - its the
information management of the archetypes that may save it

As I said, I agreee that management of archetype definitions is
important, but I think that open source-style licensing of archetype
definitions will prevent lock-in/control problems.

- but the openEHR people seem to
be in denial about establishing the infrastructure to do it....Until this ongoing
Governance is nailed, certain and ongoing over decades this idea won't work IMVHO.

We'll have to disagree - the openEHR people do seem to be thinking
carefully about governance, but not in a heavy-handed way. Show me the
governance of anything which is certain and nailed decades into the
future - that's an unrealistic expectation. Personally I am much more
concerned about the possibility of totalitarian lock-in of data and/or
complete dependence on proprietary archetype definitions than I am about
an anarchistic confusion of incompatible archetype definitions (although
both scenarios are undesirable).

Tim C

[Tim_Churches]

David More wrote:

See short comments below.

Thinking about this a bit more, it occurs to me that simply having
archetype definitions mirrrored at lots of sites is a start, but it
isn't really enough. An archetype (and the reference model it relies
upon) is essential metadata without which the data stored in the
database back-end of an openEHR system is meaningless, or at best rather
hard to interpret.

Thus, archetypes need to be stored, permanently, with the data. This
implies that each and every openEHR/archetypes storage system must be
able to permanently cache (that is, archive) each version of every
archetype definition it has ever used to store any data.

You have now got what I have been worried about - and the issue is amplified by every
variation that is permitted. Governance of all this I am not sure is actually do-able -
what do you think with say 5 different GP systems, 1000 different path and radiology tests
etc etc..

No, David, I never mentioned governance in my post, and although I agree
that careful governance is needed, I do think it is doable. Rather, I'm
worried that people will use archetype definitions which are licensed in
a way that restrict their freedom to manipulate or transfer their own
data (or that of their patients) to others.

I think you have got it quite close - and open-source does not save the day - its the
information management of the archetypes that may save it

As I said, I agreee that management of archetype definitions is
important, but I think that open source-style licensing of archetype
definitions will prevent lock-in/control problems.

- but the openEHR people seem to
be in denial about establishing the infrastructure to do it....Until this ongoing
Governance is nailed, certain and ongoing over decades this idea won't work IMVHO.

We'll have to disagree - the openEHR people do seem to be thinking
carefully about governance, but not in a heavy-handed way. Show me the
governance of anything which is certain and nailed decades into the
future - that's an unrealistic expectation. Personally I am much more
concerned about the possibility of totalitarian lock-in of data and/or
complete dependence on proprietary archetype definitions than I am about
an anarchistic confusion of incompatible archetype definitions (although
both scenarios are undesirable).

Tim C

[system]

What XML DTD’s or XML-schema’s are for characters/text
are
Archetypes for Information.
Therefore both Information and the Archetype much be stored locally.

Gerard

[system]

Information is exchanged in communities.
All clinical information belongs to the healthcare domain.

When clinical concept models (Archetypes) are expressed using an Open International Standard like the CEN/tc251 Archetypes,
both the Archetype expression and the constituting clinical concept models are not owned in a commercial sense.

Gerard

– –

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

[Tim_Churches]

Gerard Freriks wrote:

Information is exchanged in communities.
All clinical information belongs to the healthcare domain.

When clinical concept models (Archetypes) are expressed using an Open
International Standard like the CEN/tc251 Archetypes,
both the Archetype expression and the constituting clinical concept
models are not owned in a commercial sense.

Certainly most of us would like that to be true. I was just wondering
aloud whether it was true in a strict legal sense. I suspect that it is
an issue which requires expert legal advice, and the situation may be
subtely different in each country due to differences in copyright law.
It just seems like a good idea to investigate such issues when adopting
a new paradigm for storing and communicating data.

Tim C

[system]

If enough Archetypes are produced by scientific communities and associations and published IP free,
then what is the problem?

Gerard

– –

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

[Tim_Churches]

If enough Archetypes are produced by scientific communities and
associations and published IP free,
then what is the problem?

By "IP free" I assume that you mean published under a suitably permissive "open source" license. If that is the case, then I agree, no problem. The issue is that there needs to be strong end user awareness of this issue, and thus an insistence by end users that archetype definitions are licensed in such a way, and a refusal to use ones that aren't.

Tim C

[thomas.beale]

Tim Churches wrote:

Yes, fair enough. But the issue I was hinting at is that although the

openEHR technological developments aim to make systems which are
"future-proof" or at least more readily upgradable to meet future needs,
that promise will only be realised if end users have the necessary
freedoms to do so, and those freedoms depend crucially on the
appropriate licensing of archetype definitions. Perhaps this is obvious,
but it had not fully dawned on me.

well it is reasonable to bring it up. We have not talked about it previously in any great details because a) we don't have nay fantasy of private ownership of clinical archetypes and b) all the bodies and people currently talking about archetype governance have been talking in a government / public mode. But there is no getting out of the fact that legal impediments on use of archetypes (just like on say snomed or ICD10) could seriously limit the ability to achieve the collective goal of open, future-proof data and systems. We live with that all the time, and simply have to keep it in mind.

I would see it instead as about the
same problem as the re-usability of data that contains e.g. snomed-ct
codes or similar - the use of which are licensed by the CAP (currently,
but that should change in the future).
   
Yes, I would agree with that. As I have opined before, SNOMED CT concept
IDs should not be adopted as a lingua franca unless there is a perpetual
license to use it freely available to everyone (at at least a national
level).

from our point of view, they cannot be adopted as a lingua-franca for openEHR anyway, since they are a) not all there (we have never designed a single archetype where snomed had suitable codes for all, or even most nodes) and b) to get meanings of certain words correctly related to the area of interest (e.g. perinatology, public health etc), snomed has to either find a meaning which seems to roughly fit all users' needs, or else use precoordination to separate out shades of meaning. The encapsulation effect of archetypes gets around this (just like class as encapsulations for groups of properties in an OO model). So from our point of view, snomed has to be kept at one jump away from archetypes, which is where the archetype binding semantics come in. Of course, if Australia, or even the whole world decides to "go snomed-ct" (whatever that means), we will have the ability to connect to it. It is just that we don't want to be locked into it semantically, and we want to be able to go elsewhere at the same time or later.

- thomas

[thomas.beale]

Tim Churches wrote:

- but the openEHR people seem to be in denial about establishing the infrastructure to do it....Until this ongoing Governance is nailed, certain and ongoing over decades this idea won't work IMVHO.
   
We'll have to disagree - the openEHR people do seem to be thinking
carefully about governance, but not in a heavy-handed way. Show me the
governance of anything which is certain and nailed decades into the
future - that's an unrealistic expectation. Personally I am much more
concerned about the possibility of totalitarian lock-in of data and/or
complete dependence on proprietary archetype definitions than I am about
an anarchistic confusion of incompatible archetype definitions (although
both scenarios are undesirable).

I don't think anyone is in denial of the need for govenance. We have been talking about this for some years now. Our concerns are:
- not to own the whole thing. openEHR has somthing to contribute, and we believe we can set up some mechanisms that will support the needed infrastructure.
- to engage appropriate institutions. We have talked to most parts of the Australian government - DoHA, AIHW, NCCH, and others. You have to realise that it takes a long time to educate these people on what we are talking about (actually NCCH are pretty good - they understand the general idea, since they are already working in terminology).
- whatever the solution to governance is, it has to be credible, open and trusted by its users, i.e. clinical professionals (and their provider enterprises). Putting up such an edifice and getting everyone to come along for the ride is not a quick task - it also takes time.

We have made presentations, initiated discussions at HL7 Australia meetings, HIC conferences, and had many private discussions with NCCH, DoHA, NeHTA etc. openEHR has just announced its clinical review board (CRB). Not much may be in evidence today, but I believe we are a fair way along the educational / advocacy path, as well as the technical path to have a solution within the next 18 months.

- thomas beale

[Tim_Cook6 (Tim Cook)]

I agree as I believe Tim is simply saying that it is prudent to be
explicit instead of implicit regarding the legal status of the
archetypes, from the very beginning.

Cheers,

[Karsten_Hilbert]

Most definitely, Tim.

Karsten

[system]

Dear William,

My answer is:

The moment clinical concepts as defined by groups of clinicians are proprietary it will be impossible to have any conversation.
The moment clinical concepts as defined by groups of clinicians using archetypes it will be impossible to have any semantic interoperability between computer systems.
Proprietary archetypes used in computer systems are the same as words for concepts used in daily life in discussions between persons.
Since the EHR is about documenting by a healthcare provider in ones own words what has happened, they must be able to use all concepts and words, that express them, used in normal speech.

You refer to machine computer system interfaces and that these might be proprietary. Yes they could and will.
But when the holy grail is about plug-and-play interoperability then these interfaces (archetypes) must be free to use.

In my mind users must pay for the use of the machine and demand completely open system interfaces.

Information (entered, stored, retrieved and exchanged) must be freed from any influence by the IT industry.
Information must be owned and controlled by the users.

Information must never be expressed as code in software.
Information must never be exchanged in proprietary ways.
Without this, generic semantic interoperability between computer systems never will be possible.

Gerard

– –

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 653 108732

[system]

You refer to machine computer system interfaces and that these might
be proprietary. Yes they could and will.
But when the holy grail is about plug-and-play interoperability then
these interfaces (archetypes) must be free to use.

Gerard, how about SNOMED-tables, they are expensive, and many other
terminology-tables?
Will there be free replacement for that?

This question is also relevant for third world countries, or
health-information-systems used by poor organisations, f.e. free health care
systems for illegal immigrants in Europe and the USA.

They may be able to read messages, because messages probably have beside the
code, also the description, but they cannot produce messages, because they
will not be able to code their content

Thanks
Bert

[system]

Bert,

The example of SNOMED is a good one.

Looking at SNOMED we must ask the question:
Are words in a dictionary proprietary?
Do we have to pay for the use of these words in our conversations?

Of course the answer is: NO.
We have to pay for the medium: the book, the CD-ROM, the application.

The maintenance of the words used in any language is most often paid for by the State.
Language is a free commodity.

SNOMED is a Reference Terminology.
When local users map their local codes to SNOMED codes only the Terminology Server that does translations using SNOMED needs a licence.
In its proposed pricing scheme SNOMED will ask more money from rich countries (millions) and very small amounts (ten-hundred Euro;'s) from poor countries.
The are very sensible and indexed to the Gross National Product.

Gerard

– –

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 653 108732

[thomas.beale]

Bert Verhees wrote:

You refer to machine computer system interfaces and that these might
be proprietary. Yes they could and will.
But when the holy grail is about plug-and-play interoperability then
these interfaces (archetypes) must be free to use.
    
Gerard, how about SNOMED-tables, they are expensive, and many other terminology-tables?
Will there be free replacement for that?

One of the design aims for archetypes, from years ago, is that they had to work _with no external terminology_ if need be. They do this, and you can have an archetyped system that works perfectly well, even if you have no access to Snomed or ICD10. Mappings to such terminologies can be included in the archetypes, and if you don't have the terminologies locally available, you can keep working, even though you might well enter something that is not conformant to the terminology in a value field. However, in the future, I foresee archetypes being pre-processed into "operational archetypes" that include the value sets extracted from various terminologies in the archetype, so that if you don't have ICD10 say, the operational form of the archetype will include the relevant value sets (e.g. infectious respiritory diseases).

This question is also relevant for third world countries, or health-information-systems used by poor organisations, f.e. free health care systems for illegal immigrants in Europe and the USA.

They may be able to read messages, because messages probably have beside the code, also the description, but they cannot produce messages, because they will not be able to code their content
  

the above approach would allow this, but I agree that the legality and licensing is not clear at this stage. However, I believe that if small extracted value sets (with no structure) cannot be used for free from Snomed, ICD, LOINC etc, then there is little long term future for the use of these terminologies outside rich countries (and even there, they won't work unless national level licensing is used, since otherwise you are up for some ridiculous micro-licensing model based on your use of 28 snomed terms in one of your archetypes).

Hopefully common sense will prevail here...

- thomas