OHIE-Terminology Service Call 12/3

Hi All,

Reminder that we are having an OHIE-Terminology Service community call Wednesday, December 3rd at 10:00am ET.

Agenda:

  • Update on Implementation Guide revision

  • Update on FHIR Connectathon

  • Status of OHIE version 1 (for background)

·
AOB

How to join the call:

US Toll-Free: 1.800.220.9875

Canada Toll-Free: 1.800.221.8656

Ireland Toll-Free: 1.800.625.002

S.A. Toll-Free: 0.800.982.555

International (Not Toll-Free): 1.302.709.8332

Access Code: 20486132#

*(see other time zones)

Also the day of the call please go to the

OHIE-TS Community call page
and select today’s meeting to sign yourself into the meeting.
(*You will also find the agenda and minutes from previous meetings.)

If you have any questions about the OpenHIE Terminology Service calls please email
jt48@regenstrief.org.

Jamie Thomas | Global Health Communications Specialist

Regenstrief Institute, Inc. |
ph: 317.274.9218 | Skype: jamie.thomas5670 |
jt48@regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s).
Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information
without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information
by anyone other than the intended recipient is strictly prohibited.

Sorry that I will not be able to attend tomorrow do to a prior commitment. My apologies! Perhaps Jonathan can given an update on where we are with the CIEL-OCL-OpenMRS Kenya EMR initiative?

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 Tuesday, December 2, 2014 12:11 PM, “Thomas, Jamie” jt48@regenstrief.org wrote:

Hi All,

Reminder that we are having an OHIE-Terminology Service community call Wednesday, December 3rd at 10:00am ET.

Agenda:

  • Update on Implementation Guide revision
  • Update on FHIR Connectathon
  • Status of OHIE version 1 (for background)
    ·
    AOB

How to join the call:

US Toll-Free: 1.800.220.9875

Canada Toll-Free: 1.800.221.8656

Ireland Toll-Free: 1.800.625.002

S.A. Toll-Free: 0.800.982.555

International (Not Toll-Free): 1.302.709.8332

Access Code: 20486132#

*(see other time zones)

Also the day of the call please go to the

OHIE-TS Community call page
and select today’s meeting to sign yourself into the meeting.
(*You will also find the agenda and minutes from previous meetings.)

If you have any questions about the OpenHIE Terminology Service calls please email
jt48@regenstrief.org.

Jamie Thomas | Global Health Communications Specialist

Regenstrief Institute, Inc. |
ph: 317.274.9218 | Skype: jamie.thomas5670 |
jt48@regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s).
Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information
without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information
by anyone other than the intended recipient is strictly prohibited.

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.

I’d also like to discuss this initiative if we have a minute (Andy, I found the raw content of that project we were looking at while in a session at AMIA):

http://omop.org/Vocabularies

-Paul

···

On Tue, Dec 2, 2014 at 1:33 PM, ‘Andrew Kanter’ via Terminology Services terminology-services@googlegroups.com wrote:

Sorry that I will not be able to attend tomorrow do to a prior commitment. My apologies! Perhaps Jonathan can given an update on where we are with the CIEL-OCL-OpenMRS Kenya EMR initiative?

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 Tuesday, December 2, 2014 12:11 PM, “Thomas, Jamie” jt48@regenstrief.org wrote:

Hi All,

Reminder that we are having an OHIE-Terminology Service community call Wednesday, December 3rd at 10:00am ET.

Agenda:

  • Update on Implementation Guide revision
  • Update on FHIR Connectathon
  • Status of OHIE version 1 (for background)
    ·
    AOB

How to join the call:

US Toll-Free: 1.800.220.9875

Canada Toll-Free: 1.800.221.8656

Ireland Toll-Free: 1.800.625.002

S.A. Toll-Free: 0.800.982.555

International (Not Toll-Free): 1.302.709.8332

Access Code: 20486132#

*(see other time zones)

Also the day of the call please go to the

OHIE-TS Community call page
and select today’s meeting to sign yourself into the meeting.
(*You will also find the agenda and minutes from previous meetings.)

If you have any questions about the OpenHIE Terminology Service calls please email
jt48@regenstrief.org.

Jamie Thomas | Global Health Communications Specialist

Regenstrief Institute, Inc. |
ph: 317.274.9218 | Skype: jamie.thomas5670 |
jt48@regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s).
Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information
without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information
by anyone other than the intended recipient is strictly prohibited.

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.

Hi all

I’ve overhauled the terminology services page in response to several functionality directed comments from this community and others, as a result if other changes in FHIR, and also to add examples. The updated version is here:

http://hl7-fhir.github.io/terminology-service.html

This is the candidate draft for the terminology services connectathon in February. It’s open for editorial comments between now and dec 7, and then it’ll be stable till end-feb. So comment away.

In terms of changes, the format of the calls changed, though since this was never well documented, that’s probably not a big change. Also, I moved some doco around. The real changes were

  1. Introduce batch validation

  2. Separate code validation and lookup into 2 properly separated operations.

Grahame

···

On Wednesday, December 3, 2014, Thomas, Jamie jt48@regenstrief.org wrote:

Hi All,

Reminder that we are having an OHIE-Terminology Service community call Wednesday, December 3rd at 10:00am ET.

Agenda:

  • Update on Implementation Guide revision
  • Update on FHIR Connectathon
  • Status of OHIE version 1 (for background)
    ·
    AOB

How to join the call:

US Toll-Free: 1.800.220.9875

Canada Toll-Free: 1.800.221.8656

Ireland Toll-Free: 1.800.625.002

S.A. Toll-Free: 0.800.982.555

International (Not Toll-Free): 1.302.709.8332

Access Code: 20486132#

*(see other time zones)

Also the day of the call please go to the

OHIE-TS Community call page
and select today’s meeting to sign yourself into the meeting.
(*You will also find the agenda and minutes from previous meetings.)

If you have any questions about the OpenHIE Terminology Service calls please email
jt48@regenstrief.org.

Jamie Thomas | Global Health Communications Specialist

Regenstrief Institute, Inc. |
ph: 317.274.9218 | Skype: jamie.thomas5670 |
jt48@regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s).
Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information
without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information
by anyone other than the intended recipient is strictly prohibited.

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

Hi all

I’ve overhauled the terminology services page in response to several functionality directed comments from this community and others, as a result if other changes in FHIR, and also to add examples. The updated version is here:

http://hl7-fhir.github.io/terminology-service.html

This is the candidate draft for the terminology services connectathon in February. It’s open for editorial comments between now and dec 7, and then it’ll be stable till end-feb. So comment away.

In terms of changes, the format of the calls changed, though since this was never well documented, that’s probably not a big change. Also, I moved some doco around. The real changes were

  1. Introduce batch validation

  2. Separate code validation and lookup into 2 properly separated operations.

Grahame

···

On Wednesday, December 3, 2014, Thomas, Jamie jt48@regenstrief.org wrote:

Hi All,

Reminder that we are having an OHIE-Terminology Service community call Wednesday, December 3rd at 10:00am ET.

Agenda:

  • Update on Implementation Guide revision
  • Update on FHIR Connectathon
  • Status of OHIE version 1 (for background)
    ·
    AOB

How to join the call:

US Toll-Free: 1.800.220.9875

Canada Toll-Free: 1.800.221.8656

Ireland Toll-Free: 1.800.625.002

S.A. Toll-Free: 0.800.982.555

International (Not Toll-Free): 1.302.709.8332

Access Code: 20486132#

*(see other time zones)

Also the day of the call please go to the

OHIE-TS Community call page
and select today’s meeting to sign yourself into the meeting.
(*You will also find the agenda and minutes from previous meetings.)

If you have any questions about the OpenHIE Terminology Service calls please email
jt48@regenstrief.org.

Jamie Thomas | Global Health Communications Specialist

Regenstrief Institute, Inc. |
ph: 317.274.9218 | Skype: jamie.thomas5670 |
jt48@regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s).
Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information
without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information
by anyone other than the intended recipient is strictly prohibited.

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,

A few responses from Apelon. Hope not too late.

1.15.6.3.1 – External Code Systems. Links to SNOMED-CT and RxNorm pages weren’t operable.

1.15.6.4 – Value Set Expansion. We could probably support paging, but may be safer to not require in the initial Connectathon.

1.15.6.5 – Concept Lookup. We’re a bit confused by “recommended display for the code”. Taking SNOMED CT as an example, would this be the “Preferred Term” and the formal Fully Specified Named (FSN) would be delegated to “Other designations”?
ICD has a only a formal Name and a lot of Entry Terms. Does the terminology service make the choice as to what name goes where?

1.15.6.6 – Validation. Is it possible to perform a validation on a code in code system? Is there an implicit way of doing this or do we need to explicitly define a ValueSet with all the codes in the code system?

1.15.6.7 – Subsumption testing. We would recommend that basic subsumption testing should NOT consider concept maps. This raises all kinds of issues that we believe are best handled in other ways (e.g., reasoners) if at all.
Mappings are simply too case and context-specific to be relied on.

1.15.6.8 – Batch Validation. Is batch validation to code systems supported?

1.15.6.9 – Translations. We believe that it is better to explicitly specify a conceptmap in a translation.

Very happy holidays,

Jack

···

I’ve overhauled the terminology services page in response to several functionality directed comments from this community and others, as a result if other changes in FHIR, and also to add examples. The updated version is here:

http://hl7-fhir.github.io/terminology-service.html

This is the candidate draft for the terminology services connectathon in February. It’s open for editorial comments between now and dec 7, and then it’ll be stable till end-feb. So comment away.

In terms of changes, the format of the calls changed, though since this was never well documented, that’s probably not a big change. Also, I moved some doco around. The real changes were

  1. Introduce batch validation

  2. Separate code validation and lookup into 2 properly separated operations.

Grahame

On Wednesday, December 3, 2014, Thomas, Jamie jt48@regenstrief.org wrote:

Hi All,

Reminder that we are having an OHIE-Terminology Service community call Wednesday, December 3rd at 10:00am ET.

Agenda:

  • Update on Implementation Guide revision
  • Update on FHIR Connectathon
  • Status of OHIE version 1 (for background)

·
AOB

How to join the call:

US Toll-Free: 1.800.220.9875

Canada Toll-Free: 1.800.221.8656

Ireland Toll-Free: 1.800.625.002

S.A. Toll-Free: 0.800.982.555

International (Not Toll-Free): 1.302.709.8332

Access Code: 20486132#

*(see other time zones)

Also the day of the call please go to the

OHIE-TS Community call page
and select today’s meeting to sign yourself into the meeting.
(*You will also find the agenda and minutes from previous meetings.)

If you have any questions about the OpenHIE Terminology Service calls please email
jt48@regenstrief.org.

Jamie Thomas | Global Health Communications Specialist

Regenstrief Institute, Inc. |
ph: 317.274.9218 | Skype: jamie.thomas5670 |
jt48@regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information
and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit
you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information
is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention,
disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.


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


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.

1. 1.15.6.3.1 – External Code Systems. Links to SNOMED-CT and
RxNorm pages weren’t operable.

fixed

2. 1.15.6.4 – Value Set Expansion. We could probably support
paging, but may be safer to not require in the initial Connectathon.

Agree not to require it in the connectathon

3. 1.15.6.5 – Concept Lookup. We’re a bit confused by “recommended

display for the code”. Taking SNOMED CT as an example, would this be the
“Preferred Term” and the formal Fully Specified Named (FSN) would be
delegated to “Other designations”? ICD has a only a formal Name and a lot
of Entry Terms. Does the terminology service make the choice as to what
name goes where?

yes, the terminology service makes the choice. It knows the terminology. Of
course, it doesn't know what the use case is, which is why it returns other
designations as well. I added this language:

The recommended display to the code is a text representation of the code
that the terminology server recommends as the default choice to show
to the user, though a client may choose out of the other designations
if it has reason to.

4. 1.15.6.6 – Validation. Is it possible to perform a validation on

a code in code system? Is there an implicit way of doing this or do we need
to explicitly define a ValueSet with all the codes in the code system?

well, we do, for other reasons, need a value set for all the codes in a
system, and the FHIR spec defines them for all the systems we've used
(actually, not true, but it needs to). However there's lots of cases where
that would be a tax, and there's no reason not to refer to a code system
directly, so I added that

5. 1.15.6.7 – Subsumption testing. We would recommend that basic

subsumption testing should NOT consider concept maps. This raises all kinds
of issues that we believe are best handled in other ways (e.g., reasoners)
if at all. Mappings are simply too case and context-specific to be relied
on.

well, the opposite of "can" is "can't". I didn't say anything about it, and
then someone wanted to know, is it allowed? well, I think there are cases
where it makes sense to allow it, though I agree that this would not be the
normal case. So hence "the server can use them".

6. 1.15.6.8 – Batch Validation. Is batch validation to code
systems supported?

same as previous answer about this.

7. 1.15.6.9 – Translations. We believe that it is better to
explicitly specify a conceptmap in a translation.

if the client knows the concept map that applies, why would it bother
asking the terminology service to perform the logic on the concept map?
it's pretty deterministic

note that my updates aren't visible yet - one more update for editorial
issues, on Friday

Grahame

Thanks as always!

Re Translations (1.15.6.9), the issue is that there could be multiple maps from code system A to code system B based on the use-case (billing, epidemiological,
etc.). Specification of the ConceptMap is primarily a specification of use-case. And it’s always better to have the official, latest, version of a map on the TS rather than being held locally.

On Behalf Of Grahame Grieve

···
  1.   1.15.6.3.1 – External Code Systems. Links to SNOMED-CT and RxNorm pages weren’t operable.
    

fixed

  1.   1.15.6.4 – Value Set Expansion. We could probably support paging, but may be safer to not require in the initial Connectathon.
    

Agree not to require it in the connectathon

  1.    1.15.6.5 – Concept Lookup. We’re a bit confused by “recommended display for the code”. Taking SNOMED CT as an example, would this be the “Preferred Term” and the formal Fully Specified Named (FSN) would be delegated
    

to “Other designations”? ICD has a only a formal Name and a lot of Entry Terms. Does the terminology service make the choice as to what name goes where?

yes, the terminology service makes the choice. It knows the terminology. Of course, it doesn’t know what the use case is, which is why it returns other designations as well. I added this language:

The recommended display to the code is a text representation of the code

that the terminology server recommends as the default choice to show

to the user, though a client may choose out of the other designations

if it has reason to.

1.15.6.6 – Validation. Is it possible to perform a validation on a code in code system? Is there an implicit way of doing this or do we need to explicitly define a ValueSet with all the codes in the code system?

well, we do, for other reasons, need a value set for all the codes in a system, and the FHIR spec defines them for all the systems we’ve used (actually, not true, but it needs to). However there’s lots of cases where that would be a tax,
and there’s no reason not to refer to a code system directly, so I added that

  1.    1.15.6.7 – Subsumption testing. We would recommend that basic subsumption testing should NOT consider concept maps. This raises all kinds of issues that we believe are best handled in other ways (e.g., reasoners)
    

if at all. Mappings are simply too case and context-specific to be relied on.

well, the opposite of “can” is “can’t”. I didn’t say anything about it, and then someone wanted to know, is it allowed? well, I think there are cases where it makes sense to allow it, though I agree that this would not be the normal case.
So hence “the server can use them”.

  1.   1.15.6.8 – Batch Validation. Is batch validation to code systems supported?
    

same as previous answer about this.

1.15.6.9 – Translations. We believe that it is better to explicitly specify a conceptmap in a translation.

if the client knows the concept map that applies, why would it bother asking the terminology service to perform the logic on the concept map? it’s pretty deterministic

note that my updates aren’t visible yet - one more update for editorial issues, on Friday

Grahame

well, we can note that the terminology server may be unable to detemine a context if you don’t provide a source value set and/or a specific mapping, and/or some services may choose not to proceed without a specific map. Would that cover it?

Grahame

···

On Thu, Dec 11, 2014 at 5:57 AM, Jack Bowie jbowie@apelon.com wrote:

Thanks as always!

Re Translations (1.15.6.9), the issue is that there could be multiple maps from code system A to code system B based on the use-case (billing, epidemiological,
etc.). Specification of the ConceptMap is primarily a specification of use-case. And it’s always better to have the official, latest, version of a map on the TS rather than being held locally.

From: grahameg@gmail.com [mailto:grahameg@gmail.com]
On Behalf Of Grahame Grieve
Sent: Tuesday, December 09, 2014 3:55 PM
To: Jack Bowie
Cc: John Carter; Carol Lim Macumber; terminology-services@googlegroups.com
Subject: Re: OHIE-Terminology Service Call 12/3

  1.   1.15.6.3.1 – External Code Systems. Links to SNOMED-CT and RxNorm pages weren’t operable.
    

fixed

  1.   1.15.6.4 – Value Set Expansion. We could probably support paging, but may be safer to not require in the initial Connectathon.
    

Agree not to require it in the connectathon

  1.    1.15.6.5 – Concept Lookup. We’re a bit confused by “recommended display for the code”. Taking SNOMED CT as an example, would this be the “Preferred Term” and the formal Fully Specified Named (FSN) would be delegated
    

to “Other designations”? ICD has a only a formal Name and a lot of Entry Terms. Does the terminology service make the choice as to what name goes where?

yes, the terminology service makes the choice. It knows the terminology. Of course, it doesn’t know what the use case is, which is why it returns other designations as well. I added this language:

The recommended display to the code is a text representation of the code

that the terminology server recommends as the default choice to show

to the user, though a client may choose out of the other designations

if it has reason to.

1.15.6.6 – Validation. Is it possible to perform a validation on a code in code system? Is there an implicit way of doing this or do we need to explicitly define a ValueSet with all the codes in the code system?

well, we do, for other reasons, need a value set for all the codes in a system, and the FHIR spec defines them for all the systems we’ve used (actually, not true, but it needs to). However there’s lots of cases where that would be a tax,
and there’s no reason not to refer to a code system directly, so I added that

  1.    1.15.6.7 – Subsumption testing. We would recommend that basic subsumption testing should NOT consider concept maps. This raises all kinds of issues that we believe are best handled in other ways (e.g., reasoners)
    

if at all. Mappings are simply too case and context-specific to be relied on.

well, the opposite of “can” is “can’t”. I didn’t say anything about it, and then someone wanted to know, is it allowed? well, I think there are cases where it makes sense to allow it, though I agree that this would not be the normal case.
So hence “the server can use them”.

  1.   1.15.6.8 – Batch Validation. Is batch validation to code systems supported?
    

same as previous answer about this.

1.15.6.9 – Translations. We believe that it is better to explicitly specify a conceptmap in a translation.

if the client knows the concept map that applies, why would it bother asking the terminology service to perform the logic on the concept map? it’s pretty deterministic

note that my updates aren’t visible yet - one more update for editorial issues, on Friday

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.


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

That would work for me.

Jack

On Behalf Of Grahame Grieve

···

well, we can note that the terminology server may be unable to detemine a context if you don’t provide a source value set and/or a specific mapping, and/or some services may choose not to proceed without a specific map. Would that cover
it?

Grahame

On Thu, Dec 11, 2014 at 5:57 AM, Jack Bowie jbowie@apelon.com wrote:

Thanks as always!

Re Translations (1.15.6.9), the issue is that there could be multiple maps from code system A to code
system B based on the use-case (billing, epidemiological, etc.). Specification of the ConceptMap is primarily a specification of use-case. And it’s always better to have the official, latest, version of a map on the TS rather than being held locally.

From:
grahameg@gmail.com [mailto:grahameg@gmail.com]
On Behalf Of Grahame Grieve
Sent: Tuesday, December 09, 2014 3:55 PM
To: Jack Bowie
Cc: John Carter; Carol Lim Macumber;
terminology-services@googlegroups.com
Subject: Re: OHIE-Terminology Service Call 12/3

  1.   1.15.6.3.1 – External Code Systems. Links to SNOMED-CT and RxNorm pages weren’t operable.
    

fixed

  1.   1.15.6.4 – Value Set Expansion. We could probably support paging, but may be safer to not require in the initial Connectathon.
    

Agree not to require it in the connectathon

  1.    1.15.6.5 – Concept Lookup. We’re a bit confused by “recommended display for the code”. Taking SNOMED CT as an example, would this be the “Preferred Term” and the formal Fully Specified Named (FSN) would be delegated
    

to “Other designations”? ICD has a only a formal Name and a lot of Entry Terms. Does the terminology service make the choice as to what name goes where?

yes, the terminology service makes the choice. It knows the terminology. Of course, it doesn’t know what the use case is, which is why it returns other designations as well. I added
this language:

The recommended display to the code is a text representation of the code

that the terminology server recommends as the default choice to show

to the user, though a client may choose out of the other designations

if it has reason to.

1.15.6.6 – Validation. Is it possible to perform a validation on a code in code system? Is there an implicit way of doing this or do we need to explicitly define a ValueSet with all the codes in the code system?

well, we do, for other reasons, need a value set for all the codes in a system, and the FHIR spec defines them for all the systems we’ve used (actually, not true, but it needs to).
However there’s lots of cases where that would be a tax, and there’s no reason not to refer to a code system directly, so I added that

  1.    1.15.6.7 – Subsumption testing. We would recommend that basic subsumption testing should NOT consider concept maps. This raises all kinds of issues that we believe are best handled in other ways (e.g., reasoners)
    

if at all. Mappings are simply too case and context-specific to be relied on.

well, the opposite of “can” is “can’t”. I didn’t say anything about it, and then someone wanted to know, is it allowed? well, I think there are cases where it makes sense to allow
it, though I agree that this would not be the normal case. So hence “the server can use them”.

  1.   1.15.6.8 – Batch Validation. Is batch validation to code systems supported?
    

same as previous answer about this.

1.15.6.9 – Translations. We believe that it is better to explicitly specify a conceptmap in a translation.

if the client knows the concept map that applies, why would it bother asking the terminology service to perform the logic on the concept map? it’s pretty deterministic

note that my updates aren’t visible yet - one more update for editorial issues, on Friday

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
.


http://www.healthintersections.com.au /
grahame@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.