Skip to Navigation | Skip to Content

openEHR-Technical mailing list archives

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

RE: IHTSDO meeting - term binding presentation available


Yes, the workflow stuff is just a tool feature.  The RF2 spec is merely 
a file format and the spec has nothing to say about how such files 
may/should be generated.

Regarding the clinical metadata elements you mention, these are not 
defined as part of RF2, but it should be possible to represent them 
using RF2 as it was designed to be an extensible format.

michael

----
Dr Michael Lawley
Principal Research Scientist
The Australia e-Health Research Centre http://aehrc.com/
+61 7 3253 3609; 0432 832 067

________________________________________
From: openehr-technical-bounces@chime.ucl.ac.uk 
[openehr-technical-bounces@chime.ucl.ac.uk] On Behalf Of Ian McNicoll 
[Ian.McNicoll@oceaninformatics.com]
Sent: Thursday, 6 May 2010 11:16 PM
To: For openEHR technical discussions
Cc: openehr-clinical@openehr.org; openehr-clinical@chime.ucl.ac.uk; 
openehr-technical@openehr.org
Subject: Re: IHTSDO meeting - term binding presentation available

Thanks Michael,

Can I ask if the workflow/process elements of the Workbench are 
regarded as separate from the Refset 2 specifications, or within other 
offical IHTSDO specs? Or is this just intended as a local feature of 
the workbench?

Although the Refset2 sepcifications define a greate deal of 'metadata', 
as far as I can tell , other than Refset name, this is almost wholly 
technical in nature and clinical metadata elements e.g use, misuse, 
purpose, authoring details are not defined - is this correct?

Ian

Dr Ian McNicoll
office / fax  +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com<mailto:ian.mcnicoll@oceaninformatics.com>
ian@mcmi.co.uk<mailto:ian@mcmi.co.uk>

Clinical Analyst  Ocean Informatics openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group 
www.phcsg.org<http://www.phcsg.org> / BCS Health Scotland



On 6 May 2010 13:22, <Michael.Lawley@csiro.au> wrote:

I would add to Eric's point 3 that (based on the content of an IHTSDO 
webinar) the workflow/process implemented in the IHTSDO workbench 
involves an explicit manual approval step for every item in the 
generated "static" refset.  I don't know how/if there is any special 
support for dealing with re-generating the refset based on a new SNOMED 
release or a modified set of specification queries.

m

----
Dr Michael Lawley
Principal Research Scientist
The Australia e-Health Research Centre http://aehrc.com/
+61 7 3253 3609; 0432 832 067

________________________________________
From: 
openehr-technical-bounces@chime.ucl.ac.uk<mailto:openehr-technical-bounces@chime.ucl.ac.uk>
 
[openehr-technical-bounces@chime.ucl.ac.uk<mailto:openehr-technical-bounces@chime.ucl.ac.uk>]
 On Behalf Of Eric Browne 
[eric.browne@montagesystems.com.au<mailto:eric.browne@montagesystems.com.au>]
Sent: Thursday, 6 May 2010 9:20 PM
To: For openEHR clinical discussions
Cc: For openEHR clinical discussions; Openehr-Technical
Subject: Re: IHTSDO meeting - term binding presentation available

Hi Sebastian,

If I can give my own perspective on this, having been peripherally 
involved for some time..

1. Unfortunately, the IHTSDO (www.ihtsdo.org<http://www.ihtsdo.org>), 
who is responsible for the ongoing management and development of SNOMED 
CT, is still a somewhat closed and traditional standards development 
organisation. It has no publicly accessible wiki of resources à la 
openEHR. It does, however, have a substantial community of individuals 
from member countries and affiliate organisations and several 
collaborative websites and mailing lists where ideas, contributions, 
new specifications etc. are documented and evolve. I would guess that 
the majority of participants are either active in other standards 
development organisations, or staff/affiliates of member nation health 
informatics programs such as the UK's NHS Connecting for Health 
Program, Canada's Infoway, Australia's National E-Health Transition 
Authority, etc.

2. For many years prior to IHTSDO taking over SNOMED CT from the 
College of American Pathologists, SNOMED CT embraced a mechanism and 
format for producing "subsets" of SNOMED CT. About 18 months ago, 
proposals for a new  SNOMED release format and a new Reference Set 
format (to replace the old subset mechanism) emerged and evolved. These 
two proposals morphed into a single umbrella specification called 
Release Format 2, which has now reached Draft for Trial Use status 
within the IHTSDO. One of the specification documents covers Reference 
Set formats and is available in part 2 of RF2 at: 
http://www.ihtsdo.org/publications/draft-for-review-and-trial-use/ .  
This draft specification includes support for "language refsets", which 
may be of particular interest to you. Access to the collaborative space 
where these documents are made available is described at: 
http://www.ihtsdo.org/about-ihtsdo/collaborative-space/ .

3. To my knowledge there is no formal IHTSDO proposal for a query 
language to express Refset membership specifications. However, the 
IHTSDO Terminology Workbench does incorporate quite a sophisticated 
mechanism for building refsets using an underlying ( and evolving) 
query-based expression language. Note: these refsets do not necessarily 
need to be specific to SNOMED. The refset specifications, however, are 
currently designed to  construct  static files for distribution 
alongside the SNOMED core and national extension files, rather than for 
producing dynamically evaluated termsets for  local needs, as might be 
supported for openEHR templates, say.

eric
----

On 2010-05-06, at 5:48 PM, 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?
> 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.
>
> Sebastian
>
> Thomas Beale wrote:
>>
>> I attended the IHTSDO meeting just finished in Copenhagen. Things 
>> look pretty good for where SNOMED CT is going generally - the RF2 
>> technical infrastructure seems relatively well designed. There is a 
>> lot of activity in content modeling, the IHTSDO workbench and many 
>> other areas relevant to openEHR. Converely, I believe openEHR will 
>> be very important to make SNOMED CT work in many places, since it 
>> will be via archetypes, templates and associated ref sets that 
>> information systems will be able to connect to terminology in a 
>> disciplined way. I believe that ref sets are the future of SNOMED CT 
>> (and any terminology for that matter) in use in real systems.
>>
>> I was asked to present a view from openEHR about 'terminology 
>> binding', i.e. connecting terminology and information models. My 
>> presentation is on this page 
>> http://www.openehr.org/wiki/display/term/Terminology+Binding
>> or see the following direct links:
>>      • PDF - 
>> http://www.openehr.org/wiki/download/attachments/5997267/openEHR_term_binding_IHTSDO_april_2010.pdf
>>      • PPTX - 
>> http://www.openehr.org/wiki/download/attachments/5997267/openEHR_term_binding_IHTSDO_april_2010.pptx
>> I hope this is useful.  I will continue to document IHTSDO-related 
>> thoughts on the openEHR wiki, and I encourage others to do the same.
>>
>> - thomas beale
>>
>>
>> _______________________________________________
>> openEHR-technical mailing list
>>
>> openEHR-technical@openehr.org<mailto:openEHR-technical@openehr.org>
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>>
>>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical@openehr.org<mailto:openEHR-clinical@openehr.org>
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical


_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org<mailto:openEHR-technical@openehr.org>
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org<mailto:openEHR-technical@openehr.org>
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical