OHIE Terminology Services - FHIR Recommendation

As a result of our community call today, I would like to propose the following “resolution”:

The Terminology Services Community recommends that the FHIR Value Set and Concept Map Resources, along with their associated methods/APIs, be considered by the Architecture Board as the standard interfaces to be used by OHIE Communities for communication with OHIE Terminology Services.

Members of the Terminology Services Community are asked to provide their acceptance, comments, or alternate recommendations by EOB Friday, October 10.

Thanks,

Jack

hi

firstly, a brief introduction - I have been asked to join this group
to contribute to the openHIE work on terminologies. I am the lead
author/editor for the FHIR project, and directly responsible for the
terminology part of the FHIR work.

Of course I like this 'resolution'! But a couple of comments:
* from the minutes: "onathan - FHIR spec will meet primary use cases?"
- what are the primary use cases?
* the FHIR specification is not yet a standard; it's a work in
progress. So the recommendation should probably recognise this in it's
wording somehow

Grahame

···

On Thu, Oct 9, 2014 at 4:13 AM, Jack Bowie <jack.bowie@gmail.com> wrote:

As a result of our community call today, I would like to propose the
following "resolution":

The Terminology Services Community recommends that the FHIR Value Set and
Concept Map Resources, along with their associated methods/APIs, be
considered by the Architecture Board as the standard interfaces to be used
by OHIE Communities for communication with OHIE Terminology Services.

Members of the Terminology Services Community are asked to provide their
acceptance, comments, or alternate recommendations by EOB Friday, October
10.

Thanks,
Jack

--
You received this message because you are subscribed to the Google Groups
"Terminology Services" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to terminology-services+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
-----
http://www.healthintersections.com.au /
grahame@healthintersections.com.au / +61 411 867 065

Grahame,

Thanks very much for the comments. Our initial requirement is simply code validation, but a more extensive list can be found in our documents section at https://wiki.ohie.org/display/SUB/Integration+of+TS+Use+Case+Examples.

Your comment re the state of the specification is well taken. I’ll work on appropriate wording to take this into account.

Jack

···

On Wednesday, October 8, 2014 2:52:44 PM UTC-4, grahame wrote:

hi

firstly, a brief introduction - I have been asked to join this group

to contribute to the openHIE work on terminologies. I am the lead

author/editor for the FHIR project, and directly responsible for the

terminology part of the FHIR work.

Of course I like this ‘resolution’! But a couple of comments:

  • from the minutes: “onathan - FHIR spec will meet primary use cases?”
  • what are the primary use cases?
  • the FHIR specification is not yet a standard; it’s a work in

progress. So the recommendation should probably recognise this in it’s

wording somehow

Grahame

On Thu, Oct 9, 2014 at 4:13 AM, Jack Bowie jack....@gmail.com wrote:

As a result of our community call today, I would like to propose the

following “resolution”:

The Terminology Services Community recommends that the FHIR Value Set and

Concept Map Resources, along with their associated methods/APIs, be

considered by the Architecture Board as the standard interfaces to be used

by OHIE Communities for communication with OHIE Terminology Services.

Members of the Terminology Services Community are asked to provide their

acceptance, comments, or alternate recommendations by EOB Friday, October

Thanks,

Jack

You received this message because you are subscribed to the Google Groups

“Terminology Services” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to terminology-services+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

http://www.healthintersections.com.au /

gra…@healthintersections.com.au / +61 411 867 065

Thanks very much for the comments. Our initial requirement is simply code
validation, but a more extensive list can be found in our documents section
at Log In - OpenHIE Wiki.

ok - here's analysis:

Code validation: Given a source context (including version/date), return whether the source concept id is valid. Single/multiple input codes.

yes

Code normalization: Given a source and target context (including version/date), return the target concept id corresponding to a source concept id. Single/multiple input codes.

yes

Code look-up/translation: Given a source and target context (including version/date), return the concept name, optionally in a specified language, corresponding to a source concept id. Single/multiple input codes.

umm, possible, but not quite clear what single/multiple means

Search by partial phrase, begins with, partial word, including stop words

yes

Handle synonyms (return exact term user is looking for regardless of which concept it is linked to).

not sure what this means

Return all the descendants of a concept in a Code System (subsumption/decision support).

yes

Return whether a concept in a Code System is a descendant of another concept (subsumption/decision support).

yes

Return the (possibly specified) attributes associated with a concept in a Code System (permits hierarchical browsing, etc.)

not sure. this would need to be explored

> Load a file consisting of local code/target (standard) code associations.

Load a standard or local Code System/Value Set/Subset.

yes

Return all the names/codes within a Code System or named Value Set/Subset. Specify format: xml, csv, etc.

yes, though format would be a client/wrapper issue, not an API one

Return all the names/codes within a Code System or named Value Set/Subset that have changed since a specified version/date.

not currently specified, but I guess it would be possible

Return the names/codes in a named Value Set/Subset.

yes

Grahame

I accept the proposed resolution.

Thanks Jack,

David Aronow

···

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com] On Behalf Of Jack Bowie
Sent: Wednesday, October 08, 2014 1:13 PM
To: terminology-services@googlegroups.com
Subject: OHIE Terminology Services - FHIR Recommendation

As a result of our community call today, I would like to propose the following “resolution”:

The Terminology Services Community recommends that the FHIR Value Set and Concept Map Resources, along with their associated methods/APIs, be considered by the Architecture Board as the standard interfaces to be used by OHIE Communities for communication with OHIE Terminology Services.

Members of the Terminology Services Community are asked to provide their acceptance, comments, or alternate recommendations by EOB Friday, October 10.

Thanks,

Jack


You received this message because you are subscribed to the Google Groups “Terminology Services” group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminology-services+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Grahame,

I think the issues below might mean:

  1. Multiple codes mean that more than one code could return the same concept. This gets away from a single code-description-concept found in a single code system. So something like Show me all the concepts mapped to SNOMED code xxx with non-SAME-AS relationship type.

  2. Handling synonyms also addresses an interface terminology function which is that a particular description be persisted… so, if I search for Lou Gehrig’s disease, I get Lou Gehrig’s disease not Amyotrophic Lateral Sclerosis (ALS).

Andy

···

On Wednesday, October 8, 2014 2:22:34 PM UTC-5, grahame wrote:

Thanks very much for the comments. Our initial requirement is simply code

validation, but a more extensive list can be found in our documents section

at https://wiki.ohie.org/display/SUB/Integration+of+TS+Use+Case+Examples.

ok - here’s analysis:

Code validation: Given a source context (including version/date), return whether the source concept id is valid. Single/multiple input codes.

yes

Code normalization: Given a source and target context (including version/date), return the target concept id corresponding to a source concept id. Single/multiple input codes.

yes

Code look-up/translation: Given a source and target context (including version/date), return the concept name, optionally in a specified language, corresponding to a source concept id. Single/multiple input codes.

umm, possible, but not quite clear what single/multiple means

Search by partial phrase, begins with, partial word, including stop words

yes

Handle synonyms (return exact term user is looking for regardless of which concept it is linked to).

not sure what this means

Return all the descendants of a concept in a Code System (subsumption/decision support).

yes

Return whether a concept in a Code System is a descendant of another concept (subsumption/decision support).

yes

Return the (possibly specified) attributes associated with a concept in a Code System (permits hierarchical browsing, etc.)

not sure. this would need to be explored

Load a file consisting of local code/target (standard) code associations.

Load a standard or local Code System/Value Set/Subset.

yes

Return all the names/codes within a Code System or named Value Set/Subset. Specify format: xml, csv, etc.

yes, though format would be a client/wrapper issue, not an API one

Return all the names/codes within a Code System or named Value Set/Subset that have changed since a specified version/date.

not currently specified, but I guess it would be possible

Return the names/codes in a named Value Set/Subset.

yes

Grahame

1) Multiple codes mean that more than one code could return the same
concept.

I don't know what you mean by "same concept" - you mean, the codes
are synonyms?

This gets away from a single code-description-concept found in a
single code system. So something like Show me all the concepts mapped to
SNOMED code xxx with non-SAME-AS relationship type.

so this is a mapping thing? You haven't brought me any clarity yet

2) Handling synonyms also addresses an interface terminology function which
is that a particular description be persisted... so, if I search for Lou
Gehrig's disease, I get Lou Gehrig's disease not Amyotrophic Lateral
Sclerosis (ALS).

well, at present, I guess you could, though this is not specified behaviour

Grahame

Jack can correct me if I am wrong here, as I may be over-interpreting the issue. If you are only addressing pushing out functionality related to a single code system with a code + description (or descriptions) then the first issue won’t make sense. However, if you think about a code system containing CONCEPTS which have maps to other codes/concepts, then there can be more than one code/concept returned when querying through the mapping relationships.

For example, SNOMED can be mapped one-to-many to ICD and so if I want to search for all the SNOMED codes mapped to a certain ICD, I could. Another example is using IMO’s interface terminology in the server which would allow you to find an interface term which is mapped to multiple codes and the same code might be mapped to several IMO interface concepts.

Thanks for answering #2.

:slight_smile:

Andy

···

--------------------
Andrew S. Kanter, MD MPH FACMI

Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology

Columbia University
Email: andrew.kanter@dbmi.columbia.edu
Mobile: +1 (646) 469-2421
Office: +1 (212) 305-4842
Skype: akanter-ippnw
Yahoo: andy_kanter

On Thursday, October 9, 2014 3:28 PM, Grahame Grieve grahame@healthintersections.com.au wrote:

  1. Multiple codes mean that more than one code could return the same
    concept.

I don’t know what you mean by “same concept” - you mean, the codes
are synonyms?

This gets away from a single code-description-concept found in a
single code system. So something like Show me all the concepts mapped to
SNOMED code xxx with non-SAME-AS relationship type.

so this is a mapping thing? You haven’t brought me any clarity yet

  1. Handling synonyms also addresses an interface terminology function which
    is that a particular description be persisted… so, if I search for Lou
    Gehrig’s disease, I get Lou Gehrig’s disease not Amyotrophic Lateral
    Sclerosis (ALS).

well, at present, I guess you could, though this is not specified behaviour

Grahame


You received this message because you are subscribed to the Google Groups “Terminology Services” group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminology-services+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

well, then, these things are possible, but I think that it would
require additional specification to get the desired behavior nailed
down.

Grahame

···

On Fri, Oct 10, 2014 at 7:57 AM, 'Andrew Kanter' via Terminology Services <terminology-services@googlegroups.com> wrote:

Jack can correct me if I am wrong here, as I may be over-interpreting the
issue. If you are only addressing pushing out functionality related to a
single code system with a code + description (or descriptions) then the
first issue won't make sense. However, if you think about a code system
containing CONCEPTS which have maps to other codes/concepts, then there can
be more than one code/concept returned when querying through the mapping
relationships.

For example, SNOMED can be mapped one-to-many to ICD and so if I want to
search for all the SNOMED codes mapped to a certain ICD, I could. Another
example is using IMO's interface terminology in the server which would allow
you to find an interface term which is mapped to multiple codes and the same
code might be mapped to several IMO interface concepts.

Thanks for answering #2.

:slight_smile:
Andy

--------------------
Andrew S. Kanter, MD MPH FACMI

Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University
Email: andrew.kanter@dbmi.columbia.edu
Mobile: +1 (646) 469-2421
Office: +1 (212) 305-4842
Skype: akanter-ippnw
Yahoo: andy_kanter

On Thursday, October 9, 2014 3:28 PM, Grahame Grieve > <grahame@healthintersections.com.au> wrote:

1) Multiple codes mean that more than one code could return the same
concept.

I don't know what you mean by "same concept" - you mean, the codes
are synonyms?

This gets away from a single code-description-concept found in a
single code system. So something like Show me all the concepts mapped to
SNOMED code xxx with non-SAME-AS relationship type.

so this is a mapping thing? You haven't brought me any clarity yet

2) Handling synonyms also addresses an interface terminology function
which
is that a particular description be persisted... so, if I search for Lou
Gehrig's disease, I get Lou Gehrig's disease not Amyotrophic Lateral
Sclerosis (ALS).

well, at present, I guess you could, though this is not specified behaviour

Grahame

--
You received this message because you are subscribed to the Google Groups
"Terminology Services" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to terminology-services+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"Terminology Services" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to terminology-services+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
-----
http://www.healthintersections.com.au /
grahame@healthintersections.com.au / +61 411 867 065

Regarding the initial questions, the original meaning of “single/multiple input codes” was to simply address the “batching” of multiple mapping requests in a single transaction. For example, “here are 10 local lab codes from a CDA document, return the maps of each one to LOINC”. Andy does bring up a good point regarding the fact that a “map” from Concept A in Code System B to a Concept in Code System C could have multiple “target” Concepts with the same, or different, map qualifiers (“equivalent”, “broader than”, “narrower than”).

I am also confused by “handle synonyms (return exact term user is looking for regardless of which concept it is linked to)”. I believe the intent was simply to enable look up by synonyms, e.g., return the SNOMED CT Concept “Myocardial infarction (finding)” on a lookup of “heart attack”. Not sure of the use case for (or the meaning of) the parenthetical. A standard lookup into an “interface terminology” should address Andy’s “Lou Gehrig’s disease” example. The return would be whatever the preferred description is for matched term/concept.

Jack

···

On Thursday, October 9, 2014 5:03:37 PM UTC-4, grahame wrote:

well, then, these things are possible, but I think that it would

require additional specification to get the desired behavior nailed

down.

Grahame

On Fri, Oct 10, 2014 at 7:57 AM, ‘Andrew Kanter’ via Terminology > > Services terminolog...@googlegroups.com wrote:

Jack can correct me if I am wrong here, as I may be over-interpreting the

issue. If you are only addressing pushing out functionality related to a

single code system with a code + description (or descriptions) then the

first issue won’t make sense. However, if you think about a code system

containing CONCEPTS which have maps to other codes/concepts, then there can

be more than one code/concept returned when querying through the mapping

relationships.

For example, SNOMED can be mapped one-to-many to ICD and so if I want to

search for all the SNOMED codes mapped to a certain ICD, I could. Another

example is using IMO’s interface terminology in the server which would allow

you to find an interface term which is mapped to multiple codes and the same

code might be mapped to several IMO interface concepts.

Thanks for answering #2.

:slight_smile:

Andy


Andrew S. Kanter, MD MPH FACMI

Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology

Columbia University

Email: andrew…@dbmi.columbia.edu

Mobile: +1 (646) 469-2421

Office: +1 (212) 305-4842

Skype: akanter-ippnw

Yahoo: andy_kanter

On Thursday, October 9, 2014 3:28 PM, Grahame Grieve > > > gra...@healthintersections.com.au wrote:

  1. Multiple codes mean that more than one code could return the same

concept.

I don’t know what you mean by “same concept” - you mean, the codes

are synonyms?

This gets away from a single code-description-concept found in a

single code system. So something like Show me all the concepts mapped to

SNOMED code xxx with non-SAME-AS relationship type.

so this is a mapping thing? You haven’t brought me any clarity yet

  1. Handling synonyms also addresses an interface terminology function

which

is that a particular description be persisted… so, if I search for Lou

Gehrig’s disease, I get Lou Gehrig’s disease not Amyotrophic Lateral

Sclerosis (ALS).

well, at present, I guess you could, though this is not specified behaviour

Grahame

You received this message because you are subscribed to the Google Groups

“Terminology Services” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to terminology-services+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups

“Terminology Services” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to terminology-services+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

http://www.healthintersections.com.au /

gra…@healthintersections.com.au / +61 411 867 065

ok ta. the batching thing - I'll have to look into that.

Grahame

···

On Fri, Oct 10, 2014 at 10:51 AM, Jack Bowie <jack.bowie@gmail.com> wrote:

Regarding the initial questions, the original meaning of "single/multiple
input codes" was to simply address the "batching" of multiple mapping
requests in a single transaction. For example, "here are 10 local lab codes
from a CDA document, return the maps of each one to LOINC". Andy does bring
up a good point regarding the fact that a "map" from Concept A in Code
System B to a Concept in Code System C could have multiple "target" Concepts
with the same, or different, map qualifiers ("equivalent", "broader than",
"narrower than").

I am also confused by "handle synonyms (return exact term user is looking
for regardless of which concept it is linked to)". I believe the intent was
simply to enable look up by synonyms, e.g., return the SNOMED CT Concept
"Myocardial infarction (finding)" on a lookup of "heart attack". Not sure of
the use case for (or the meaning of) the parenthetical. A standard lookup
into an "interface terminology" should address Andy's "Lou Gehrig's disease"
example. The return would be whatever the preferred description is for
matched term/concept.

Jack

On Thursday, October 9, 2014 5:03:37 PM UTC-4, grahame wrote:

well, then, these things are possible, but I think that it would
require additional specification to get the desired behavior nailed
down.

Grahame

On Fri, Oct 10, 2014 at 7:57 AM, 'Andrew Kanter' via Terminology >> Services <terminolog...@googlegroups.com> wrote:
> Jack can correct me if I am wrong here, as I may be over-interpreting
> the
> issue. If you are only addressing pushing out functionality related to a
> single code system with a code + description (or descriptions) then the
> first issue won't make sense. However, if you think about a code system
> containing CONCEPTS which have maps to other codes/concepts, then there
> can
> be more than one code/concept returned when querying through the mapping
> relationships.
>
> For example, SNOMED can be mapped one-to-many to ICD and so if I want to
> search for all the SNOMED codes mapped to a certain ICD, I could.
> Another
> example is using IMO's interface terminology in the server which would
> allow
> you to find an interface term which is mapped to multiple codes and the
> same
> code might be mapped to several IMO interface concepts.
>
> Thanks for answering #2.
>
> :slight_smile:
> Andy
>
> --------------------
> Andrew S. Kanter, MD MPH FACMI
>
> Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
> Columbia University
> Email: andrew...@dbmi.columbia.edu
> Mobile: +1 (646) 469-2421
> Office: +1 (212) 305-4842
> Skype: akanter-ippnw
> Yahoo: andy_kanter
>
>
> On Thursday, October 9, 2014 3:28 PM, Grahame Grieve >> > <gra...@healthintersections.com.au> wrote:
>
>
>
>> 1) Multiple codes mean that more than one code could return the same
>> concept.
>
> I don't know what you mean by "same concept" - you mean, the codes
> are synonyms?
>
>> This gets away from a single code-description-concept found in a
>> single code system. So something like Show me all the concepts mapped
>> to
>> SNOMED code xxx with non-SAME-AS relationship type.
>
> so this is a mapping thing? You haven't brought me any clarity yet
>
>> 2) Handling synonyms also addresses an interface terminology function
>> which
>> is that a particular description be persisted... so, if I search for
>> Lou
>> Gehrig's disease, I get Lou Gehrig's disease not Amyotrophic Lateral
>> Sclerosis (ALS).
>
> well, at present, I guess you could, though this is not specified
> behaviour
>
> Grahame
>
> --
> You received this message because you are subscribed to the Google
> Groups
> "Terminology Services" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an
> email to terminology-services+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups
> "Terminology Services" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an
> email to terminology-services+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
-----
http://www.healthintersections.com.au /
gra...@healthintersections.com.au / +61 411 867 065

--
You received this message because you are subscribed to the Google Groups
"Terminology Services" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to terminology-services+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
-----
http://www.healthintersections.com.au /
grahame@healthintersections.com.au / +61 411 867 065

Just a reminder that today is the final day to provide acceptance, comments, or alternate recommendations for Jack’s proposal below.

Have a great weekend,

Jamie Thomas

On Behalf Of Jack Bowie

···

As a result of our community call today, I would like to propose the following “resolution”:

** The Terminology Services Community recommends that the FHIR Value Set and Concept Map Resources, along with their associated methods/APIs, be considered by the Architecture Board as the standard interfaces to be used by OHIE Communities
for communication with OHIE Terminology Services.**

Members of the Terminology Services Community are asked to provide their acceptance, comments, or alternate recommendations by EOB Friday, October 10.

Thanks,

Jack


You received this message because you are subscribed to the Google Groups “Terminology Services” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
terminology-services+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.