Re: Templates for application form development

[Erik Sundvall]

Hi!

I have also updated the
https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets
wikipage to include

   - references to some previous GUI discussions and
   - Region Östergötlands current use case and initial
   Ethercis-OPT-introspector+Angular-based design plans (See heading "OPT form
   renderer needed for pilot testing of surgery process supporting system"
   near the end of the page.

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se)
http://www.regionostergotland.se/cmit/
Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/

On Mon, Mar 12, 2018 at 11:48 PM, Pablo Pazos 
wrote:

> Thanks Thomas, I added a paragraph about the UI generation modes at the
> end, I forgot to mention that yesterday.
>
> On Mon, Mar 12, 2018 at 9:40 AM, Thomas Beale 
> wrote:
>
>> Pablo,
>>
>> Good work - I've included a reference to this doc in the original wiki
>> page
>> ,
>> and added a few ideas about how to use it. It is very close to what I was
>> thinking of.
>>
>> - thomas
>>
>> On 12/03/2018 07:31, Pablo Pazos wrote:
>>
>> Hi all,
>>
>> I manage to translate / update part of the work we did some years ago in
>> terms of UI definition and generation for the openEHR stack.
>>
>> Here is the doc, feedback is very welcome!
>>
>> https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe
>> -_T9H6UMsGNkiZoU7Iw/edit?usp=sharing
>>
>>
>>
>> --
>> Thomas Beale
>> Principal, Ars Semantica 
>> Consultant, ABD Team, Intermountain Healthcare
>> 
>> Management Board, Specifications Program Lead, openEHR Foundation
>> 
>> Chartered IT Professional Fellow, BCS, British Computer Society
>> 
>> Health IT blog  | Culture blog
>> 
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145 <+598%2099%20043%20145>
> skype: cabolabs
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Pablo Pazos]

Thanks Thomas, I added a paragraph about the UI generation modes at the
end, I forgot to mention that yesterday.

On Mon, Mar 12, 2018 at 9:40 AM, Thomas Beale 
wrote:

> Pablo,
>
> Good work - I've included a reference to this doc in the original wiki
> page
> ,
> and added a few ideas about how to use it. It is very close to what I was
> thinking of.
>
> - thomas
>
> On 12/03/2018 07:31, Pablo Pazos wrote:
>
> Hi all,
>
> I manage to translate / update part of the work we did some years ago in
> terms of UI definition and generation for the openEHR stack.
>
> Here is the doc, feedback is very welcome!
>
> https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_
> T9H6UMsGNkiZoU7Iw/edit?usp=sharing
>
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

[Pablo Pazos]

In Latin America is all the contrary, more countries are becoming SNOMED
members and adopting SNOMED at the govt level.

On Mon, Mar 12, 2018 at 10:18 AM, Philippe Ameline  wrote:

> Le 12/03/2018 à 01:38, Pablo Pazos a écrit :
>
> > IMO we should focus on SNOMED.
>
> Hi,
>
> There is currently some kind of interesting momentum against Snomed.
>
> It can come from governments that refuse to pay for it (current mood in
> France), of from practitioners who, after having been asked by their gov
> to "sort out their Snomed subset" came to the conclusion that it doesn't
> exist.
>
> Some also predict that the most certain result of keeping up
> trying to build systems using such shitty fully endemic components is to
> have medical doctors disappear from missing the "information society"
> turn.
>
> Have some of you been aware of the Meriterm (European) project?
>
> Best,
>
> Philippe
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: [Troll] Terminology bindings ... again

[Birger Haarbrandt]

Please never underestimate the Germans...

Am 12.03.2018 um 14:54 schrieb Mikael Nyström:

Hi,

Have anybody ever heard about  a health-it-project that hadn't a smaller or 
larger group of sceptic people that try to build momentum against the project? 
:-)

For SNOMED CT the trend at least seems to be that fewer and fewer people 
belongs to the sceptic group, and about half of the European Union member 
countries seems to be member in SNOMED International 
(https://www.snomed.org/members).

Will France as usual be the last country that adopt something that originate 
from Great Britain? :-)

Regards
Mikael


-Ursprungligt meddelande-
Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Philippe Ameline
Skickat: den 12 mars 2018 14:19
Till: openehr-technical@lists.openehr.org
Ämne: [Troll] Terminology bindings ... again

Le 12/03/2018 à 01:38, Pablo Pazos a écrit :


IMO we should focus on SNOMED.

Hi,

There is currently some kind of interesting momentum against Snomed.

It can come from governments that refuse to pay for it (current mood in France), of from 
practitioners who, after having been asked by their gov to "sort out their Snomed 
subset" came to the conclusion that it doesn't exist.

Some also predict that the most certain result of keeping up trying to build 
systems using such shitty fully endemic components is to have medical doctors disappear from 
missing the "information society"
turn.

Have some of you been aware of the Meriterm (European) project?

Best,

Philippe


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
*Birger Haarbrandt, M. Sc.
Peter L. Reichertz Institut for Medical Informatics (PLRI)
Technical University Braunschweig and Hannover Medical School
Software Architect HiGHmed Project *
Tel: +49 176 640 94 640, Fax: +49 531/391-9502
birger.haarbra...@plri.de
www.plri.de
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development - should probably explain our EtherCIS/QEWDjs/PulseTile stack here

[Tony Shannon]

ok thanks Tom
T

On 12 March 2018 at 13:46, Thomas Beale  wrote:

> Tony,
> this post was very useful; I've referenced it and copied bits of it to the 
> wiki
> page
> 
> .
>
> - thomas
>
> On 18/02/2018 18:34, Tony Shannon wrote:
>
> Hi all,
>
> This might be a useful time to briefly explain why we are supporting 3
> open source components in our "showcase" stack
>
> EtherCIS - open source implementation of openEHR Clinical Data Repository
> http://ethercis.org/
> QewdJS - nodeJS based middleware for varied purposes - inc microservices
> between UI & CDR
> PulseTile- frontend UX/UI framework for healthcare
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

SV: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi,

Have anybody ever heard about  a health-it-project that hadn't a smaller or 
larger group of sceptic people that try to build momentum against the project? 
:-)

For SNOMED CT the trend at least seems to be that fewer and fewer people 
belongs to the sceptic group, and about half of the European Union member 
countries seems to be member in SNOMED International 
(https://www.snomed.org/members).

Will France as usual be the last country that adopt something that originate 
from Great Britain? :-)

Regards
Mikael


-Ursprungligt meddelande-
Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Philippe Ameline
Skickat: den 12 mars 2018 14:19
Till: openehr-technical@lists.openehr.org
Ämne: [Troll] Terminology bindings ... again

Le 12/03/2018 à 01:38, Pablo Pazos a écrit :

> IMO we should focus on SNOMED.

Hi,

There is currently some kind of interesting momentum against Snomed.

It can come from governments that refuse to pay for it (current mood in 
France), of from practitioners who, after having been asked by their gov to 
"sort out their Snomed subset" came to the conclusion that it doesn't exist.

Some also predict that the most certain result of keeping up trying to 
build systems using such shitty fully endemic components is to have medical 
doctors disappear from missing the "information society"
turn.

Have some of you been aware of the Meriterm (European) project?

Best,

Philippe


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development - should probably explain our EtherCIS/QEWDjs/PulseTile stack here

[Thomas Beale]

Tony,

this post was very useful; I've referenced it and copied bits of it to 
the wiki page 
.


- thomas

On 18/02/2018 18:34, Tony Shannon wrote:

Hi all,

This might be a useful time to briefly explain why we are supporting 3 
open source components in our "showcase" stack


EtherCIS - open source implementation of openEHR Clinical Data 
Repository http://ethercis.org/
QewdJS - nodeJS based middleware for varied purposes - inc 
microservices between UI & CDR

PulseTile- frontend UX/UI framework for healthcare



--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

[Troll] Terminology bindings ... again

[Philippe Ameline]

Le 12/03/2018 à 01:38, Pablo Pazos a écrit :

> IMO we should focus on SNOMED.

Hi,

There is currently some kind of interesting momentum against Snomed.

It can come from governments that refuse to pay for it (current mood in
France), of from practitioners who, after having been asked by their gov
to "sort out their Snomed subset" came to the conclusion that it doesn't
exist.

Some also predict that the most certain result of keeping up
trying to build systems using such shitty fully endemic components is to
have medical doctors disappear from missing the "information society"
turn.

Have some of you been aware of the Meriterm (European) project?

Best,

Philippe


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development

[Thomas Beale]

Pablo,

Good work - I've included a reference to this doc in the original wiki 
page 
, 
and added a few ideas about how to use it. It is very close to what I 
was thinking of.


- thomas


On 12/03/2018 07:31, Pablo Pazos wrote:

Hi all,

I manage to translate / update part of the work we did some years ago 
in terms of UI definition and generation for the openEHR stack.


Here is the doc, feedback is very welcome!

https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_T9H6UMsGNkiZoU7Iw/edit?usp=sharing




--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Terminology bindings ... again

[Michael.Lawley]

Yes, it wasn’t part of STU3 (aka 3.0.1) but is now in the R4 spec - see 
http://build.fhir.org/snomedct.html#implicit

Michael

Sent from my iPhone

On 12 Mar 2018, at 8:39 pm, Diego Boscá 
> 
wrote:https://www.hl7.org/fhir/snomedct.html#implicit
Interesting to know, although I don't see that as an option in latest FHIR spec
https://www.hl7.org/fhir/snomedct.html#implicit

2018-03-12 11:15 GMT+01:00 
>:
FHIR also supports the expression language in the URL with, for example, 
http://snomed.info/sct?fhir_vs=ecl/<<123464:474748=<<84848484

But note that these URIs (the above and your isa/ one below) are defined by HL7 
FHIR, not SNOMED International. Technically they identify FHIR ValueSets that 
expand to the set of codes you want.

You could do a lot worse than adopting the FHIR ValueSet mechanism for binding. 
There are some excellent terminology servers out there (full disclosure, one of 
them, Ontoserver, is mine).

Michael


Sent from my iPhone

On 12 Mar 2018, at 7:00 pm, Diego Boscá 
> wrote:

Probably we should have a look at 
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
FHIR also uses the same base uri, but builds the URI using a custom syntax such 
as http://snomed.info/sct?fhir_vs=isa/138875005
But looking at the Snomed URI standard I assume they will just go with that in 
the future

2018-03-12 1:38 GMT+01:00 Pablo Pazos 
>:
Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.

About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.

I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:


term_bindings = <
["snomed_ct"] = <
["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<
target =  -- Apgar score at 
1 minute
notes = <"some notes">
min_version = <"2017-02-01">
etc = <"etc">
>
["id26"] = (CONSTRAINT_BINDING) <
target = <"71388002 |Procedure| : 405815000 |Procedure device|  
=  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian structure|">
   min_version = <"2017-04-01">
notes = <"some notes">
etc = <"etc">
>
>
>

I noted that the right hand side of a binding can be a few different things, 
each of which would be accompanied by various meta-data, including:

  *   a single concept code
  *   a single code or other id referring to an external value set in an 
external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is 
no standard that I know of)
  *   a composition expression that refers to a more refined concept
  *   possible a constraint expression that locally determines a value set 
intensionally, to be resolved by application to the Terminology service.

I'd rather avoid the last, because of the brittleness of intensional ref-set 
query syntax expressions. In any case, we need a better idea of what meta-data 
are needed. E.g.:

  *   something to do with (min) version of terminology required for the 
reference to be valid
  *   something to do with purpose?
  *   other notes - a tagged list of basic types?

I would like to get a 

Re: Terminology bindings ... again

[Michael.Lawley]

FHIR also supports the expression language in the URL with, for example, 
http://snomed.info/sct?fhir_vs=ecl/<<123464:474748=<<84848484

But note that these URIs (the above and your isa/ one below) are defined by HL7 
FHIR, not SNOMED International. Technically they identify FHIR ValueSets that 
expand to the set of codes you want.

You could do a lot worse than adopting the FHIR ValueSet mechanism for binding. 
There are some excellent terminology servers out there (full disclosure, one of 
them, Ontoserver, is mine).

Michael


Sent from my iPhone

On 12 Mar 2018, at 7:00 pm, Diego Boscá 
> wrote:

Probably we should have a look at 
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
FHIR also uses the same base uri, but builds the URI using a custom syntax such 
as http://snomed.info/sct?fhir_vs=isa/138875005
But looking at the Snomed URI standard I assume they will just go with that in 
the future

2018-03-12 1:38 GMT+01:00 Pablo Pazos 
>:
Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.

About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.

I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:


term_bindings = <
["snomed_ct"] = <
["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<
target =  -- Apgar score at 
1 minute
notes = <"some notes">
min_version = <"2017-02-01">
etc = <"etc">
>
["id26"] = (CONSTRAINT_BINDING) <
target = <"71388002 |Procedure| : 405815000 |Procedure device|  
=  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian structure|">
   min_version = <"2017-04-01">
notes = <"some notes">
etc = <"etc">
>
>
>

I noted that the right hand side of a binding can be a few different things, 
each of which would be accompanied by various meta-data, including:

  *   a single concept code
  *   a single code or other id referring to an external value set in an 
external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is 
no standard that I know of)
  *   a composition expression that refers to a more refined concept
  *   possible a constraint expression that locally determines a value set 
intensionally, to be resolved by application to the Terminology service.

I'd rather avoid the last, because of the brittleness of intensional ref-set 
query syntax expressions. In any case, we need a better idea of what meta-data 
are needed. E.g.:

  *   something to do with (min) version of terminology required for the 
reference to be valid
  *   something to do with purpose?
  *   other notes - a tagged list of basic types?

I would like to get a better idea of the requirements.

- thomas


--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain 
Healthcare
Management Board, Specifications Program Lead, openEHR 
Foundation
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog | Culture 
blog

Re: Terminology bindings ... again

[Diego Boscá]

Probably we should have a look at
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
FHIR also uses the same base uri, but builds the URI using a custom syntax
such as http://snomed.info/sct?fhir_vs=isa/138875005
But looking at the Snomed URI standard I assume they will just go with that
in the future

2018-03-12 1:38 GMT+01:00 Pablo Pazos :

> Now that I have more experience with SNOMED expressions, I like the idea
> of doing the binding with an expression, also I think an expression
> includes the single code binding, if that is correct there is no need of
> defining a different notation for single code binding, just use a simple
> expression formed by one specific concept code. Also the expression being
> something processable and very versatile, we can express complex concepts
> with a few codes, which will help on adding knowledge to the archetype and
> serve to a better and simpler CDS.
>
> About the metadata, there should be expressed against which SNOMED release
> this expression was created. We can't be sure only with min version. I
> should be responsibility of the user to check if the expression works on a
> different version/release of SNOMED. Another metadata is if the version is
> a local extension, some countries have their own extensions.
>
> I don't know if we need to support other terminologies (technically) and
> if doing that is useful (strategically). Terminology services can do SNOMED
> to ICD, and ICD is not clinical relevant. LOINC is useful, but there is a
> SNOMED-LOINC collaboration, so we might expect an official mapping in the
> future (https://loinc.org/collaboration/snomed-international/). IMO we
> should focus on SNOMED.
>
> On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
>
>> Recently we discussed terminology bindings. We probably still have not
>> got them right, but we don't have a model of what we think they should be.
>> I posted a quick idea of a possible more structured version:
>>
>> term_bindings = <
>> ["snomed_ct"] = <
>> ["/data[id3]/events[id4]/data[id2]/items[id26]"] = 
>> (SIMPLE_BINDING)  
>> -- Apgar score at 1 minute notes = <"some notes">
>>  min_version = <"2017-02-01">
>>  etc = <"etc">
>>  >
>> ["id26"] = (CONSTRAINT_BINDING) > <"71388002 |Procedure| : 405815000 |Procedure device|  =  122456005 |Laser 
>> device| , 260686004 |Method|  =  129304002 |Excision - action| ,405813007 
>> |Procedure site - direct|  =  1549700l6 |Ovarian structure|">
>> min_version = <"2017-04-01">
>>  notes = <"some notes">
>>  etc = <"etc">
>>  >
>> >
>> >
>>
>>
>> I noted that the right hand side of a binding can be a few different
>> things, each of which would be accompanied by various meta-data, including:
>>
>>- a single concept code
>>- a single code or other id referring to an external value set in an
>>external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there
>>is no standard that I know of)
>>- a composition expression that refers to a more refined concept
>>- possible a constraint expression that locally determines a value
>>set intensionally, to be resolved by application to the Terminology 
>> service.
>>
>> I'd rather avoid the last, because of the brittleness of intensional
>> ref-set query syntax expressions. In any case, we need a better idea of
>> what meta-data are needed. E.g.:
>>
>>- something to do with (min) version of terminology required for the
>>reference to be valid
>>- something to do with purpose?
>>- other notes - a tagged list of basic types?
>>
>> I would like to get a better idea of the requirements.
>>
>> - thomas
>>
>>
>> --
>> Thomas Beale
>> Principal, Ars Semantica 
>> Consultant, ABD Team, Intermountain Healthcare
>> 
>> Management Board, Specifications Program Lead, openEHR Foundation
>> 
>> Chartered IT Professional Fellow, BCS, British Computer Society
>> 
>> Health IT blog  | Culture blog
>> 
>>
>> ___
>> openEHR-clinical mailing list
>> openehr-clini...@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_
>> lists.openehr.org
>>
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145 <+598%2099%20043%20145>
> skype: cabolabs
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
> 

SV: Terminology bindings ... again

[Mikael Nyström]

Hi,

It depends on what you mean by scope … There is an agreement between SNOMED 
International and Regenstrief Institute to not batch include concepts that 
directly match LOINC codes in SNOMED CT. However, in general SNOMED CT can have 
concepts that represent the same or similar ideas as LOINC codes.

 Regards
 Mikael



Från: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] För 
GF
Skickat: den 12 mars 2018 08:54
Till: For openEHR clinical discussions 
Kopia: Thomas Beale 
Ämne: Re: Terminology bindings ... again

The scope of LOINC is NOT the same as the scope of SNOMED.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands


On 12 Mar 2018, at 08:39, Mikael Nyström 
> wrote:

Hi,

I do that too. It seems like more and more people are moving away from the 
position that SNOMED CT is complex and expensive to a position that SNOMED CT 
is manageable and an affordable way of getting rid of local terminologies and 
add value.

 Regards
 Mikael


Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Pablo Pazos
Skickat: den 12 mars 2018 08:28
Till: For openEHR clinical discussions 
>
Kopia: Openehr-Technical 
>
Ämne: Re: Terminology bindings ... again

Thanks Mikael, that's what I suspected. I'm seeing a convergence in terms of 
clinical terminology towards SNOMED CT.

On Mon, Mar 12, 2018 at 3:57 AM, Mikael Nyström 
> wrote:
Hi,

Yes, it is correct that expressions include single code binding. Those kinds of 
bindings are just the simplest variants of expressions. :-)

I think that in a few years’ time nearly all implementations of SNOMED CT not 
only implement the international version, but also one are a few international, 
national or local extensions, so this use case is probably the normal use case 
and not the exceptional use case.

 Regards
 Mikael
 (Among other things SNOMED CT Implementation 
Advisor)

Från: openEHR-clinical 
[mailto:openehr-clinical-boun...@lists.openehr.org]
 För Pablo Pazos
Skickat: den 12 mars 2018 01:39
Till: For openEHR clinical discussions 
>
Kopia: Openehr-Technical 
>
Ämne: Re: Terminology bindings ... again

Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.
About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.
I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:

term_bindings = <

["snomed_ct"] = <

["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<

 target =  -- Apgar score at 1 
minute

 notes = <"some notes">

 min_version = <"2017-02-01">

 etc = <"etc">

  >

["id26"] = (CONSTRAINT_BINDING) <

   target = <"71388002 

Re: Terminology bindings ... again

[GF]

The scope of LOINC is NOT the same as the scope of SNOMED.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 12 Mar 2018, at 08:39, Mikael Nyström  wrote:
> 
> Hi,
>  
> I do that too. It seems like more and more people are moving away from the 
> position that SNOMED CT is complex and expensive to a position that SNOMED CT 
> is manageable and an affordable way of getting rid of local terminologies and 
> add value.
>  
>  Regards
>  Mikael
>  
>  
> Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org 
> ] För Pablo Pazos
> Skickat: den 12 mars 2018 08:28
> Till: For openEHR clinical discussions 
> Kopia: Openehr-Technical 
> Ämne: Re: Terminology bindings ... again
>  
> Thanks Mikael, that's what I suspected. I'm seeing a convergence in terms of 
> clinical terminology towards SNOMED CT.
>  
> On Mon, Mar 12, 2018 at 3:57 AM, Mikael Nyström  > wrote:
> Hi,
>  
> Yes, it is correct that expressions include single code binding. Those kinds 
> of bindings are just the simplest variants of expressions. :-)
>  
> I think that in a few years’ time nearly all implementations of SNOMED CT not 
> only implement the international version, but also one are a few 
> international, national or local extensions, so this use case is probably the 
> normal use case and not the exceptional use case.
>  
>  Regards
>  Mikael
>  (Among other things SNOMED CT Implementation 
> Advisor)
>  
> Från: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org 
> ] För Pablo Pazos
> Skickat: den 12 mars 2018 01:39
> Till: For openEHR clinical discussions  >
> Kopia: Openehr-Technical  >
> Ämne: Re: Terminology bindings ... again
>  
> Now that I have more experience with SNOMED expressions, I like the idea of 
> doing the binding with an expression, also I think an expression includes the 
> single code binding, if that is correct there is no need of defining a 
> different notation for single code binding, just use a simple expression 
> formed by one specific concept code. Also the expression being something 
> processable and very versatile, we can express complex concepts with a few 
> codes, which will help on adding knowledge to the archetype and serve to a 
> better and simpler CDS.
> 
> About the metadata, there should be expressed against which SNOMED release 
> this expression was created. We can't be sure only with min version. I should 
> be responsibility of the user to check if the expression works on a different 
> version/release of SNOMED. Another metadata is if the version is a local 
> extension, some countries have their own extensions.
> 
> I don't know if we need to support other terminologies (technically) and if 
> doing that is useful (strategically). Terminology services can do SNOMED to 
> ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
> SNOMED-LOINC collaboration, so we might expect an official mapping in the 
> future (https://loinc.org/collaboration/snomed-international/ 
> ). IMO we should focus 
> on SNOMED.
>  
> On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale  > wrote:
> Recently we discussed terminology bindings. We probably still have not got 
> them right, but we don't have a model of what we think they should be. I 
> posted a quick idea of a possible more structured version:
> 
> term_bindings = <
> ["snomed_ct"] = <
> ["/data[id3]/events[id4]/data[id2]/items[id26]"] = 
> (SIMPLE_BINDING) <
>  target =  > -- Apgar score at 1 minute
>  notes = <"some notes">
>  min_version = <"2017-02-01">
>  etc = <"etc">
>   >
> ["id26"] = (CONSTRAINT_BINDING) <
>target = <"71388002 |Procedure| : 405815000 |Procedure device| 
>  =  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
> action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian 
> structure|">
>   min_version = <"2017-04-01">
>notes = <"some notes">
>etc = <"etc">
>>
> >
> >
> 
> I noted that the right hand side of a binding can be a few different things, 
> each of which would be accompanied by 

SV: Terminology bindings ... again

[Mikael Nyström]

Hi,

I do that too. It seems like more and more people are moving away from the 
position that SNOMED CT is complex and expensive to a position that SNOMED CT 
is manageable and an affordable way of getting rid of local terminologies and 
add value.

 Regards
 Mikael


Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Pablo Pazos
Skickat: den 12 mars 2018 08:28
Till: For openEHR clinical discussions 
Kopia: Openehr-Technical 
Ämne: Re: Terminology bindings ... again

Thanks Mikael, that's what I suspected. I'm seeing a convergence in terms of 
clinical terminology towards SNOMED CT.

On Mon, Mar 12, 2018 at 3:57 AM, Mikael Nyström 
> wrote:
Hi,

Yes, it is correct that expressions include single code binding. Those kinds of 
bindings are just the simplest variants of expressions. :-)

I think that in a few years’ time nearly all implementations of SNOMED CT not 
only implement the international version, but also one are a few international, 
national or local extensions, so this use case is probably the normal use case 
and not the exceptional use case.

 Regards
 Mikael
 (Among other things SNOMED CT Implementation 
Advisor)

Från: openEHR-clinical 
[mailto:openehr-clinical-boun...@lists.openehr.org]
 För Pablo Pazos
Skickat: den 12 mars 2018 01:39
Till: For openEHR clinical discussions 
>
Kopia: Openehr-Technical 
>
Ämne: Re: Terminology bindings ... again

Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.
About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.
I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:

term_bindings = <

["snomed_ct"] = <

["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<

 target =  -- Apgar score at 1 
minute

 notes = <"some notes">

 min_version = <"2017-02-01">

 etc = <"etc">

  >

["id26"] = (CONSTRAINT_BINDING) <

   target = <"71388002 |Procedure| : 405815000 |Procedure device|  
=  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian structure|">

  min_version = <"2017-04-01">

   notes = <"some notes">

   etc = <"etc">

   >

>

>

I noted that the right hand side of a binding can be a few different things, 
each of which would be accompanied by various meta-data, including:

  *   a single concept code
  *   a single code or other id referring to an external value set in an 
external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is 
no standard that I know of)
  *   a composition expression that refers to a more refined concept
  *   possible a constraint expression that locally determines a value set 
intensionally, to be resolved by application to the Terminology service.
I'd rather avoid the last, because of the brittleness of intensional ref-set 
query syntax expressions. In any case, we need 

Re: Templates for application form development

[Pablo Pazos]

Hi all,

I manage to translate / update part of the work we did some years ago in
terms of UI definition and generation for the openEHR stack.

Here is the doc, feedback is very welcome!

https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_T9H6UMsGNkiZoU7Iw/edit?usp=sharing




On Wed, Feb 21, 2018 at 12:13 PM, A Verhees  wrote:

> Well, this sounds very good, so I can forget my babble about dependency
> circles, concerning this part of the specs
>
> I hope this will be in stable release very soon, because I need to have a
> stable definition for a project
>
> Thanks
> Bert
>
> Op 21 feb. 2018 3:21 p.m. schreef "Thomas Beale"  >:
>
>
>>
>> On 21/02/2018 13:00, Bert Verhees wrote:
>>
>>> On 20-02-18 20:09, Thomas Beale wrote:
>>>

> The terminology service also has dependencies to rm data types, only
> because of codephrase. Wouldn't it be possible to avoid that?
>

 Yes, there is a new class TERMINOLOGY_CODE that is used in BASE instead
 of CODE_PHRASE; eventually, the RM should just use that. If you found any
 use of CODE_PHRASE in BASE, please let us know.

>>>
>>> This is of course a good thing.
>>>
>>>
>>> But now the question, how do I know which definition to use.
>>>
>>> I always looked at this URL: http://www.openehr.org/program
>>> s/specification/workingbaseline
>>>
>>> There I found "Support", which brings me to:
>>>
>>> http://www.openehr.org/releases/RM/latest/docs/support/support.html
>>>
>>> In that, there is CODE_PHRASE still used in TERMINOLOGY_ACCESS.
>>>
>>
>> yes - we are still working on this - to find the cleanest way to separate
>> it out without breaking current code.
>>
>>
>>>
>>> Now I read that there is a new class in BASE, I found the link:
>>> http://www.openehr.org/releases/BASE/latest/docs/index
>>>
>>> And I found Terminology_Code: http://www.openehr.org/release
>>> s/BASE/latest/docs/base_types/base_types.html#_terminology_code_class
>>>
>>> Which is a real improvement, exactly what I was hoping for, it did not
>>> only remove the CODE_PHRASE from datatypes, but also TERMINOLOGY_ID class
>>> from SUPPORT
>>>
>>> It has a property/field which is named terminology_id and is of type
>>> string
>>>
>>>
>>> Is this what is going to be the new standard?
>>>
>>> And when will this be like that?
>>>
>>
>> Well it will be the new standard for BASE classes very soon. Over time,
>> we will start either replacing CODE_PHRASE in the upper models with
>> TERMINOLOGY_CODE, or possibly adding some sort of mapping / conversion
>> logic. But we'll only do that based on input from implementers - we need to
>> find a way to update the models without breaking existing systems.
>>
>>
>>>
>>> When looking further, I also see that there is still a TERMINOLOGY_ID
>>> class in that document which is the old support terminology which is
>>> derived from OBJECT_ID
>>>
>>> http://www.openehr.org/releases/BASE/latest/docs/base_types/
>>> base_types.html#_terminology_id_class
>>>
>>>
>>> Is this confusing, or am I missing something stupid? Am I the only
>>> person asking this kind of questions? If yes, where do others get their
>>> information from?
>>>
>>> Please help me, because, I think, this is very important.
>>>
>>
>> you should consider the classes you see in BASE today as being what will
>> be issued, unless anyone finds a problem with them. In the near future, we
>> will continue the cleanup around terminology. One reason we have not
>> cleaned it up yet is because noone in industry agrees on what standard or
>> tools to use. Noone faithfully implements CTS2 for example, except a
>> non-maintained server from Mayo (LexGrid from memory). IHTSDO did something
>> different, and FHIR did something else.  All have good and bad points, but
>> there has been no clear specification.
>>
>> I am inclined to think that the specification of the future is a kind of
>> stripped down CTS2 that gets rid of XML/XSD, and can be used with multiple
>> serialisation formats, and cleaner models, but semantically, more or less
>> the same. But we have to be practical too. Maybe the FHIR terminology
>> service will evolve in the most appropriate way; they already have the same
>> URI representation of terms as our BASE classes now have.
>>
>> All input on this welcome, as usual.
>>
>> - thomas
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 

Re: Terminology bindings ... again

[Pablo Pazos]

Thanks Mikael, that's what I suspected. I'm seeing a convergence in terms
of clinical terminology towards SNOMED CT.

On Mon, Mar 12, 2018 at 3:57 AM, Mikael Nyström 
wrote:

> Hi,
>
>
>
> Yes, it is correct that expressions include single code binding. Those
> kinds of bindings are just the simplest variants of expressions. :-)
>
>
>
> I think that in a few years’ time nearly all implementations of SNOMED CT
> not only implement the international version, but also one are a few
> international, national or local extensions, so this use case is probably
> the normal use case and not the exceptional use case.
>
>
>
>  Regards
>
>  Mikael
>
>  (Among other things SNOMED CT Implementation
> Advisor)
>
>
>
> *Från:* openEHR-clinical [mailto:openehr-clinical-
> boun...@lists.openehr.org] *För *Pablo Pazos
> *Skickat:* den 12 mars 2018 01:39
> *Till:* For openEHR clinical discussions  openehr.org>
> *Kopia:* Openehr-Technical 
> *Ämne:* Re: Terminology bindings ... again
>
>
>
> Now that I have more experience with SNOMED expressions, I like the idea
> of doing the binding with an expression, also I think an expression
> includes the single code binding, if that is correct there is no need of
> defining a different notation for single code binding, just use a simple
> expression formed by one specific concept code. Also the expression being
> something processable and very versatile, we can express complex concepts
> with a few codes, which will help on adding knowledge to the archetype and
> serve to a better and simpler CDS.
>
> About the metadata, there should be expressed against which SNOMED release
> this expression was created. We can't be sure only with min version. I
> should be responsibility of the user to check if the expression works on a
> different version/release of SNOMED. Another metadata is if the version is
> a local extension, some countries have their own extensions.
>
> I don't know if we need to support other terminologies (technically) and
> if doing that is useful (strategically). Terminology services can do SNOMED
> to ICD, and ICD is not clinical relevant. LOINC is useful, but there is a
> SNOMED-LOINC collaboration, so we might expect an official mapping in the
> future (https://loinc.org/collaboration/snomed-international/). IMO we
> should focus on SNOMED.
>
>
>
> On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
>
> Recently we discussed terminology bindings. We probably still have not got
> them right, but we don't have a model of what we think they should be. I
> posted a quick idea of a possible more structured version:
>
>
> *term_bindings* = <
>
> ["snomed_ct"] = <
>
> ["/data[id3]/events[id4]/data[id2]/items[id26]"] = 
> (SIMPLE_BINDING) <
>
>  target =  *-- Apgar score at 
> 1 minute*
>
>  notes = <"some notes">
>
>  min_version = <"2017-02-01">
>
>  etc = <"etc">
>
>   >
>
> ["id26"] = (CONSTRAINT_BINDING) <
>
>target = <"71388002 |Procedure| : 405815000 |Procedure device| 
>  =  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
> action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian 
> structure|">
>
>   min_version = <"2017-04-01">
>
>notes = <"some notes">
>
>etc = <"etc">
>
>>
>
> >
>
> >
>
>
> I noted that the right hand side of a binding can be a few different
> things, each of which would be accompanied by various meta-data, including:
>
>- a single concept code
>- a single code or other id referring to an external value set in an
>external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there
>is no standard that I know of)
>- a composition expression that refers to a more refined concept
>- possible a constraint expression that locally determines a value set
>intensionally, to be resolved by application to the Terminology service.
>
> I'd rather avoid the last, because of the brittleness of intensional
> ref-set query syntax expressions. In any case, we need a better idea of
> what meta-data are needed. E.g.:
>
>- something to do with (min) version of terminology required for the
>reference to be valid
>- something to do with purpose?
>- other notes - a tagged list of basic types?
>
> I would like to get a better idea of the requirements.
>
> - thomas
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British 

SV: Terminology bindings ... again

[Mikael Nyström]

Hi,

Yes, it is correct that expressions include single code binding. Those kinds of 
bindings are just the simplest variants of expressions. :-)

I think that in a few years’ time nearly all implementations of SNOMED CT not 
only implement the international version, but also one are a few international, 
national or local extensions, so this use case is probably the normal use case 
and not the exceptional use case.

 Regards
 Mikael
 (Among other things SNOMED CT Implementation 
Advisor)

Från: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] För 
Pablo Pazos
Skickat: den 12 mars 2018 01:39
Till: For openEHR clinical discussions 
Kopia: Openehr-Technical 
Ämne: Re: Terminology bindings ... again

Now that I have more experience with SNOMED expressions, I like the idea of 
doing the binding with an expression, also I think an expression includes the 
single code binding, if that is correct there is no need of defining a 
different notation for single code binding, just use a simple expression formed 
by one specific concept code. Also the expression being something processable 
and very versatile, we can express complex concepts with a few codes, which 
will help on adding knowledge to the archetype and serve to a better and 
simpler CDS.
About the metadata, there should be expressed against which SNOMED release this 
expression was created. We can't be sure only with min version. I should be 
responsibility of the user to check if the expression works on a different 
version/release of SNOMED. Another metadata is if the version is a local 
extension, some countries have their own extensions.
I don't know if we need to support other terminologies (technically) and if 
doing that is useful (strategically). Terminology services can do SNOMED to 
ICD, and ICD is not clinical relevant. LOINC is useful, but there is a 
SNOMED-LOINC collaboration, so we might expect an official mapping in the 
future (https://loinc.org/collaboration/snomed-international/). IMO we should 
focus on SNOMED.

On Mon, Jul 17, 2017 at 11:19 AM, Thomas Beale 
> wrote:
Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:



term_bindings = <

["snomed_ct"] = <

["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<

 target =  -- Apgar score at 1 
minute

 notes = <"some notes">

 min_version = <"2017-02-01">

 etc = <"etc">

  >

["id26"] = (CONSTRAINT_BINDING) <

   target = <"71388002 |Procedure| : 405815000 |Procedure device|  
=  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian structure|">

  min_version = <"2017-04-01">

   notes = <"some notes">

   etc = <"etc">

   >

>

>

I noted that the right hand side of a binding can be a few different things, 
each of which would be accompanied by various meta-data, including:

  *   a single concept code
  *   a single code or other id referring to an external value set in an 
external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is 
no standard that I know of)
  *   a composition expression that refers to a more refined concept
  *   possible a constraint expression that locally determines a value set 
intensionally, to be resolved by application to the Terminology service.
I'd rather avoid the last, because of the brittleness of intensional ref-set 
query syntax expressions. In any case, we need a better idea of what meta-data 
are needed. E.g.:

  *   something to do with (min) version of terminology required for the 
reference to be valid
  *   something to do with purpose?
  *   other notes - a tagged list of basic types?
I would like to get a better idea of the requirements.

- thomas

--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain 
Healthcare
Management Board, Specifications Program Lead, openEHR 
Foundation
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog | Culture 
blog

___
openEHR-clinical mailing list
openehr-clini...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org



--
Ing. Pablo Pazos Gutiérrez