Hi All,
Below is a thread from the openEHR lists regarding terminology
binding. It should be read by all addressed here.
I have considered these issues in the past and since I am presenting
MLHIM to a US company in two weeks with a focus on just this problem.
I wanted to let you all know what I am 'planning' to put in the MLHIM
draft specs.
The problem that is most vexing is one of post-coordinated binding.
This problem is closely related to what I am talked with some of you
about before. The complexity and counter-intuitiveness of slots in
concept constraint definitions (CCDs aka. archetypes).
Given: an archetype is defined as being a "complete representation of
a single clinical concept".
Then: Why archetype slots? Everything for that concept SHOULD be a
part of that CCD/archetype.
Therefore: A CCD should be a complete clinical concept. If/when the
concept is too broad to utilize pre-coordinated terminology, then it
should be marked as ABSTRACT (in the object-oriented sense of the
word). This allows a CCD to be created and then subclassed from (aka.
archetype specialization) but it prevents that specific abstract CCD
from being instantiated.
Of course in the specs this will be expanded on so it makes more sense
to new readers. But I wanted to pass this by knowledgeable people to
get feedback. The concept of abstract schemas is support in XML schemas.
Regards,
Tim
---------- Forwarded message ----------
From: *Seabury Tom (NHS Connecting for Health)* <tom.seabury@xxxxxxx
<mailto:tom.seabury@xxxxxxx>>
Date: Thu, May 6, 2010 at 11:32 AM
Subject: RE: IHTSDO meeting - term binding presentation available
To: For openEHR clinical discussions <openehr-clinical@xxxxxxxxxxxxxxx
<mailto:openehr-clinical@xxxxxxxxxxxxxxx>>
Hi Mikael, Thomas
There are certainly instances of sets being generated by authorities
other than national release centres, ones that conform to the SNOMED
CT guidance, which requires their identifiers include a recognised
namespace.
Two aspects of this topic are 1) that you need access to tools which
allocate unique identifiers, in accord with the standard and 2) that
the allocation of namespace identifiers cannot be assumed to be a
free-for-all although at last count there were in the region of 110,
some of which were allocated to individuals. To use a Namespace you
are obliged to conform to the SNOMED CT licence conditions and similar
good behaviour.
Those with an interest in this topic may wish to join, for example,
the SNOMED CT Implementation Special Interest Group via this link:-
http://www.ihtsdo.org/join-us/help-improve-snomed-ct/
To join an established Special Interest Group mail to:
info(at)ihtsdo.org <http://ihtsdo.org/> stating which group you wish
to join,
‘Special Interest Groups (SIGs) are open and ongoing bodies that
examine issues related to specified topics that are relevant to the
IHTSDO and its members.’
Tom Seabury
IHTSDO
*From:* openehr-clinical-bounces@xxxxxxxxxxxxxxx
<mailto:openehr-clinical-bounces@xxxxxxxxxxxxxxx>
[mailto:openehr-clinical-bounces@xxxxxxxxxxxxxxx
<mailto:openehr-clinical-bounces@xxxxxxxxxxxxxxx>] *On Behalf Of
*Mikael Nyström
*Sent:* 06 May 2010 16:51
*To:* 'For openEHR clinical discussions'
*Subject:* RE: IHTSDO meeting - term binding presentation available
Hi Thomas,
As another member of IHTSDO Technical Committee I would like to ask
from where you have got your impression that RefSets should mainly be
maintained by the national release centers, because that is not at all
my impression. Some of the national release centers, like NHS in UK,
maintain Subsets/RefSets, but I have never heard anything about that
only the national release centers should create and maintain RefSets.
My impression is that whoever that find it useful to create and
maintain an own RefSet should be able to do it.
The only requirement to create a RefSet is the technical requirement
to have an own namespace to create the RefSet into. However, all
organizations and persons with a valid SNOMED CT license can get an
own namespace.
(I have my own namespace, so if I would I could immediately produce
and release as many RefSets that I want.)
Greetings,
Mikael
*From:* openehr-clinical-bounces@xxxxxxxxxxxxxxx
<mailto:openehr-clinical-bounces@xxxxxxxxxxxxxxx>
[mailto:openehr-clinical-bounces@xxxxxxxxxxxxxxx
<mailto:openehr-clinical-bounces@xxxxxxxxxxxxxxx>] *On Behalf Of
*Thomas Beale
*Sent:* den 6 maj 2010 12:15
*To:* openehr-clinical@xxxxxxxxxxx <mailto:openehr-clinical@xxxxxxxxxxx>
*Subject:* Re: IHTSDO meeting - term binding presentation available
On 06/05/2010 08:48, Sebastian Garde wrote:
Hi Thomas,
do you know if there is a formal way of how RefSets (=the resulting
Snomed CT codes etc.) and the RefSet query (=the query on Snomed CT to
get to the RefSet) are expressed and shared?
the ref set results are defined by Snomed RF2 ref set specs, now in
draft. I don't know whether they are allowed to be shared outside
IHTSDO, but will find out. The query language is still an open question.
Similar to what is described here but based on RefSets:
http://www.openehr.org/wiki/display/term/Ocean+Terminology+Query+Language+%28TQL%29
I agree that RefSets are a good way forward, but they need to be
available, reusable and sharable, etc.
they do. The current IHTSDO thinking is that ref sets will mainly be
defined by national release centres and maintained in the national
extensions, with some major refsets being in the international
release. I think this is far too restrictive a view, and that in
future they will be defined and maintained in health care facilities,
regional information centres and anywhere else that needs them. The
IHTSDO representation and extension mechanism should be usable at all
these levels. How it could be used for openEHR I have yet to find out,
but am making enquiries as a member of the IHTSDO Technical Committee).
- thomas
********************************************************************************************************************
This message may contain confidential information. If you are not the
intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail
or take any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.
Thank you for your co-operation.
NHSmail is the secure email and directory service available for all
NHS staff in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive
information with NHSmail and GSI recipients
NHSmail provides an email address for your career in the NHS and can
be accessed anywhere
For more information and to find out how you can switch, visit
www.connectingforhealth.nhs.uk/nhsmail
<http://www.connectingforhealth.nhs.uk/nhsmail>
********************************************************************************************************************
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@xxxxxxxxxxx <mailto:openEHR-clinical@xxxxxxxxxxx>
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
--
Esta mensagem foi verificada pelo sistema de antiv�rus e
acredita-se estar livre de perigo.
------------------------------------------------------------------------
_______________________________________________
Mailing list: https://launchpad.net/~oship-dev
Post to : oship-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~oship-dev
More help : https://help.launchpad.net/ListHelp
