Storing units in the TS

ryan · May 20, 2014, 1:20pm

Hi all,

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

···

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

ryan · May 20, 2014, 1:21pm

Hi all,

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

···

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

ryan · May 20, 2014, 1:23pm

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

···

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

Andrew_Kanter1 · May 20, 2014, 1:29pm

Ryan,

Not sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department, internal medicine floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–

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.

ryan · May 20, 2014, 1:34pm

Hi Andy,

Sorry for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

···

On Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com wrote:

Ryan,

Not sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department, internal medicine floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

–

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 “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.

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

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

Andrew_Kanter1 · May 20, 2014, 1:50pm

We have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly interoperable. So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly mapped to reference terms.

So, again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Andy,

Sorry for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com wrote:

Ryan,

Not sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department, internal medicine floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

–

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 “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.

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

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

Jack_Bowie · May 20, 2014, 2:08pm

UCUM is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes operational (conversion)
information. We have prepared extracts of units of measure for certain clients wishing to represent units in their TS.

Jack

···

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Tuesday, May 20, 2014 9:50 AM
To: Ryan Crichton
Cc: terminology-services@googlegroups.com; openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

We have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly
interoperable. So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly
mapped to reference terms.

So, again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Andy,

Sorry for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com >
wrote:

Ryan,

Not sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department, internal medicine
floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the
units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile:
+27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–

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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–
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.

Daniel_Vreeman · May 20, 2014, 3:15pm

I agree. For concepts that represent quantitative measurements, you’ve got to have units in the TS. LOINC codes, for example, represent measurements consistent with a particular set of units (e.g. mass concentrations). What I’ve observed is that the “degree of binding” of concepts to particular units varies across sites. Maybe you’ve discussed this.

Sometimes systems allow conversions from one unit to another, say only if it’s a power of ten. Other systems don’t allow any conversions except literal synonyms. In the INPC we tried some simple conversions for a while, but then got cold feet. In the Regenstrief Dictionary we do store units as “coded concepts”.

Of course I agree that UCUM is the best reference standard for units and is growing in popularity as units become “the next frontier” of standardization in some contexts. To help de-mystify UCUM for newbies, the LOINC team (with the majority of the work being done by NLM and Intermountain) have curated a list of common UCUM units for use in clinical data messages:

For
most of the common units, the UCUM representation is pretty straightforward and familiar. Then once you understand the {}, it’s not that bad. Not that you’d want to necessarily show these to clinicians, but for computer-to-computer transmission they’re golden.Jack Bowie wrote:

···

http://loinc.org/usage/units

–
Thanks,

Daniel J. Vreeman, PT, DPT, MSc

Assistant Research Professor, Indiana University School of
Medicine

Research Scientist, Regenstrief Institute, Inc

UCUM
is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes operational (conversion)
information. We have prepared extracts of units of measure for certain clients wishing to represent units in their TS.

Jack

From:

Tuesday, May 20, 2014 9:50 AM
Ryan Crichton
; Re: Storing units in the TS

We
have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly
interoperable. So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly
mapped to reference terms.

So,
again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton <ryan@jembi.org >
wrote:

Hi
Andy,

Sorry
for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On
Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com >
wrote:

Ryan,

Not
sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department, internal medicine
floor? Or do you mean something else?

Most
of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton <ryan@jembi.org >
wrote:

Hi
all,

(Apologies
all if you get multiple email from me. I was having trouble with the list serv.)

In
some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the
units of clinical encounters along with their terminology. We wanted to
check with this community if information about units is often stored in
a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are
there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan
Crichton*

Software
Developer, Jembi Health Systems | SOUTH AFRICA*

Mobile:
+27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–

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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

–

Ryan
Crichton*

Software
Developer, Jembi Health Systems | SOUTH AFRICA*

Mobile:
+27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org*

–
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.
terminology-services@googlegroups.commailto:terminology-services@googlegroups.com
Sent:
To:
**Cc:**terminology-services@googlegroups.comopenhie-interoperability-layer@googlegroups.com
Subject:

David_Aronow · May 21, 2014, 6:58am

Greetings from Kigutu, Burundi!

Just to clarify – Andy, are you saying that units should be precoordinated with the concepts they are units for, or that there must be a specification, either in Fully Specified Name or some form of metadata, of what has been defined as the standard unit for the base concept?

Local systems will be sending an completely unpredictable array of units with lab results which (by whatever architecture is implemented) will need to be normalized to the defined standard.

David

···

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com] On Behalf Of Jack Bowie
Sent: Tuesday, May 20, 2014 10:09 AM
To: terminology-services@googlegroups.com; Ryan Crichton
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

UCUM is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes operational (conversion) information. We have prepared extracts of units of measure for certain clients wishing to represent units in their TS.

Jack

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Tuesday, May 20, 2014 9:50 AM
To: Ryan Crichton
Cc: terminology-services@googlegroups.com; openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

We have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly interoperable. So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly mapped to reference terms.

So, again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Andy,

Sorry for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com wrote:

Ryan,

Not sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department, internal medicine floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 * | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org*

–
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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–
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.

Andrew_Kanter1 · May 21, 2014, 11:02am

I would be interested in what others think about this. LOINC only makes a suggested unit for their concepts and SNOMED doesn’t include units at all. If we really want to be able to compare data stored in one system to another, it would seem that the units DO need to be explicitly pre coordinated with the concept.

Thoughts?

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 Wednesday, May 21, 2014 2:59 AM, David Aronow david.aronow@comcast.net wrote:

Greetings from Kigutu, Burundi!

Just to clarify – Andy, are you saying that units should be precoordinated with the concepts they are units for, or that there must be a specification, either in Fully Specified Name or some form of metadata, of what has been defined as the standard unit for the base concept?

Local systems will be sending an completely unpredictable array of units with lab results which (by whatever architecture is implemented) will need to be normalized to the defined
standard.

David

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com] On Behalf Of Jack Bowie
Sent: Tuesday, May 20, 2014 10:09 AM
To: terminology-services@googlegroups.com; Ryan Crichton
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the
TS

UCUM is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes operational (conversion) information. We have prepared extracts of units of measure for certain clients wishing to represent units in their TS.

Jack

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Tuesday, May 20, 2014 9:50 AM
To: Ryan Crichton
Cc: terminology-services@googlegroups.com; openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

We have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly interoperable. So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly mapped to reference terms.

So, again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Andy,

Sorry for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com wrote:

Ryan,

Not sure what you mean by units of clinical encounters.
Do you mean units like mg, ml, in or units like surgery suite, emergency department, internal medicine floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple
email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any
implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 * | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org*

–
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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–
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.

John_Carter · May 21, 2014, 11:54am

I would argue against a policy of pre-coordination of units into the terminology for orders, procedures, etc.

Consider a hopefully simple internationalizable example: patient weight. The order to do a weight, the result, etc., are all exactly the same regardless of
which units are used to express the clinical measurement… which means that pre-coordination of units would have a denormalizing effect on the terminology and actually pose a burden to interoperability. If you had precoordinated expressions for weight in pounds,
weight in kilos, weight in stone, you demand that some analyst keep track of all those and manage terminology relationships and math to do the conversion.

In my view

·
The names of the pieces live in the terminology service: LOINC and SNOMED codes to represent the available weight measurement orders/procedures/findings,
with appropriate local synonyms; UCUM parts with their different spellings, and so on

·
Jurisdictional bindings (e.g., pounds → USA; kilos → elsewhere; stones → UK, sometimes) probably also live in the terminology service

·
The model for saying that a patient weight measurement observation consists of a label (The LOINC code for weight measurement), a quantity including
units of measure (“162 lb”), and perhaps a qualifier (“first thing in AM”) lives in the specification of the message or document (CDA, FHIR, HL7v2 message). Advanced work on this notion, under various flavors of “detailed clinical models” continues at HL7,
Intermountain, the VA, and many other places.

·
The calculation required to convert units on an instance of a weight measurement from one jurisdiction to another (based on bindings in the terminology
service) lives in a rules engine that runs UCUM.

In that scenario, the data are interoperable when they need to be, at the time of transmission from one system to another or the execution of a query, rather
than being forced into an interoperable box at the time of data capture, which places a heavy maintenance burden on the back end parts of the system.

JSC

···

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 7:02 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

I would be interested in what others think about this. LOINC only makes a suggested unit for their concepts and SNOMED doesn’t include
units at all. If we really want to be able to compare data stored in one system to another, it would seem that the units DO need to be explicitly pre coordinated with the concept.

Thoughts?

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 Wednesday, May 21, 2014 2:59 AM, David Aronow david.aronow@comcast.net wrote:

Greetings from Kigutu, Burundi!

Just to clarify – Andy, are you saying that units should be precoordinated with the concepts they are units for, or that there must
be a specification, either in Fully Specified Name or some form of metadata, of what has been defined as the standard unit for the base concept?

Local systems will be sending an completely unpredictable array of units with lab results which (by whatever architecture is implemented)
will need to be normalized to the defined standard.

David

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
On Behalf Of Jack Bowie
Sent: Tuesday, May 20, 2014 10:09 AM
To: terminology-services@googlegroups.com; Ryan Crichton
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

UCUM is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes
operational (conversion) information. We have prepared extracts of units of measure for certain clients wishing to represent units in their TS.

Jack

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Tuesday, May 20, 2014 9:50 AM
To: Ryan Crichton
Cc:
terminology-services@googlegroups.com;
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

We have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly
interoperable. So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly
mapped to reference terms.

So, again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Andy,

Sorry for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com >
wrote:

Ryan,

Not sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department,
internal medicine floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate
the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile:**+27845829934 * | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org*

–

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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–

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.

David_Aronow · May 21, 2014, 12:45pm

I agree with John’s comments, although hopefully we in the US are getting pounds closer to status of stones in the UK.

If an interface system provides a blood chemistry in mg/l and the HIE uses a LOINC concept whose unit is mg/dl, there needs to be a normalization of the numeric result to retain the clinical meaning of the local value as it translates to the LOINC code.

Interface systems will have whatever degree of unit standardization they have, enforced by whatever method they use. HIE variables that are not as specified as LOINC will need to have an explicit HIE standard unit, implemented in whatever manner we do.

David

···

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com] On Behalf Of John Carter
Sent: Wednesday, May 21, 2014 7:54 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

I would argue against a policy of pre-coordination of units into the terminology for orders, procedures, etc.

Consider a hopefully simple internationalizable example: patient weight. The order to do a weight, the result, etc., are all exactly the same regardless of which units are used to express the clinical measurement… which means that pre-coordination of units would have a denormalizing effect on the terminology and actually pose a burden to interoperability. If you had precoordinated expressions for weight in pounds, weight in kilos, weight in stone, you demand that some analyst keep track of all those and manage terminology relationships and math to do the conversion.

In my view

· The names of the pieces live in the terminology service: LOINC and SNOMED codes to represent the available weight measurement orders/procedures/findings, with appropriate local synonyms; UCUM parts with their different spellings, and so on

· Jurisdictional bindings (e.g., pounds → USA; kilos → elsewhere; stones → UK, sometimes) probably also live in the terminology service

· The model for saying that a patient weight measurement observation consists of a label (The LOINC code for weight measurement), a quantity including units of measure (“162 lb”), and perhaps a qualifier (“first thing in AM”) lives in the specification of the message or document (CDA, FHIR, HL7v2 message). Advanced work on this notion, under various flavors of “detailed clinical models” continues at HL7, Intermountain, the VA, and many other places.

· The calculation required to convert units on an instance of a weight measurement from one jurisdiction to another (based on bindings in the terminology service) lives in a rules engine that runs UCUM.

In that scenario, the data are interoperable when they need to be, at the time of transmission from one system to another or the execution of a query, rather than being forced into an interoperable box at the time of data capture, which places a heavy maintenance burden on the back end parts of the system.

JSC

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 7:02 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

I would be interested in what others think about this. LOINC only makes a suggested unit for their concepts and SNOMED doesn’t include units at all. If we really want to be able to compare data stored in one system to another, it would seem that the units DO need to be explicitly pre coordinated with the concept.

Thoughts?

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 Wednesday, May 21, 2014 2:59 AM, David Aronow david.aronow@comcast.net wrote:

Greetings from Kigutu, Burundi!

Just to clarify – Andy, are you saying that units should be precoordinated with the concepts they are units for, or that there must be a specification, either in Fully Specified Name or some form of metadata, of what has been defined as the standard unit for the base concept?

Local systems will be sending an completely unpredictable array of units with lab results which (by whatever architecture is implemented) will need to be normalized to the defined standard.

David

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com] On Behalf Of Jack Bowie
Sent: Tuesday, May 20, 2014 10:09 AM
To: terminology-services@googlegroups.com; Ryan Crichton
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

UCUM is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes operational (conversion) information. We have prepared extracts of units of measure for certain clients wishing to represent units in their TS.

Jack

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Tuesday, May 20, 2014 9:50 AM
To: Ryan Crichton
Cc: terminology-services@googlegroups.com; openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

We have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly interoperable. So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly mapped to reference terms.

So, again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Andy,

Sorry for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com wrote:

Ryan,

Not sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department, internal medicine floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 * | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org*

–
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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–
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.

Andrew_Kanter1 · May 21, 2014, 1:59pm

How do we ensure that end node data collection retains the specific units if we don’t pre-coordinate? I think the reality is that we won’t know what’s in those buckets if we don’t get specific. I agree that ordering a test does not require units, but resulting that test probably should.

···

--------------------
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 Wednesday, May 21, 2014 8:46 AM, David Aronow david.aronow@comcast.net wrote:

I agree with John’s comments, although hopefully we in the US are getting pounds closer to status of stones in the UK.

If an interface system provides a blood chemistry in mg/l and the HIE uses a LOINC concept whose unit is mg/dl, there needs to be a normalization of the numeric result to retain the clinical meaning of the local value as it translates to the LOINC code.

Interface systems will have whatever degree of unit standardization they have, enforced by
whatever method they use. HIE variables that are not as specified as LOINC will need to have an explicit HIE standard unit, implemented in whatever manner we do.

David

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com] On Behalf Of John Carter
Sent: Wednesday, May 21, 2014 7:54 AM
To: terminology-services@googlegroups.com;
‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

I would argue against a policy of pre-coordination of units into the terminology for orders, procedures, etc.

Consider a hopefully simple internationalizable example: patient weight. The order to do a weight, the result, etc., are all exactly the same regardless of which units are used to express the clinical measurement… which means that pre-coordination of units would have a denormalizing effect on the terminology and actually pose a burden to interoperability. If you had precoordinated
expressions for weight in pounds, weight in kilos, weight in stone, you demand that some analyst keep track of all those and manage terminology relationships and math to do the conversion.

In my view

· The names of the pieces live in the terminology service: LOINC and SNOMED codes to represent the available weight measurement orders/procedures/findings, with appropriate local synonyms; UCUM parts with their different
spellings, and so on

· Jurisdictional bindings (e.g., pounds → USA; kilos → elsewhere; stones → UK, sometimes) probably also live in the terminology service

· The model for saying that a patient weight measurement observation consists of a label (The LOINC code for weight measurement), a quantity including units of measure (“162 lb”), and perhaps a qualifier (“first thing in
AM”) lives in the specification of the message or document (CDA, FHIR, HL7v2 message). Advanced work on this notion, under various flavors of “detailed clinical models” continues at HL7, Intermountain, the VA, and many other places.

· The calculation required to convert units on an instance of a weight measurement from one jurisdiction to another (based on bindings in the terminology service) lives in a rules engine that runs UCUM.

In that scenario, the data are interoperable when they need to be,
at the time of transmission from one system to another or the execution of a query, rather than being forced into an interoperable box at the time of data capture, which places a heavy maintenance burden on the back end parts of the system.

JSC

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 7:02 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

I would be interested in what others think about this. LOINC only makes a suggested unit for their concepts and SNOMED doesn’t include units at all. If we really want to be able to compare data stored in one system to another, it would seem that the units DO need to be explicitly pre coordinated with the concept.

Thoughts?

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 Wednesday, May 21, 2014 2:59 AM, David Aronow david.aronow@comcast.net wrote:

Greetings from Kigutu, Burundi!

Just to clarify – Andy, are you saying that units should be precoordinated with the concepts they are units for, or that there must be a specification, either in Fully Specified Name or some form of metadata, of what has been defined as the standard unit for the base concept?

Local systems will be sending an completely unpredictable array of units with lab results which (by whatever architecture is implemented) will need to be normalized to the defined standard.

David

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com] On Behalf Of Jack Bowie
Sent: Tuesday, May 20, 2014 10:09 AM
To: terminology-services@googlegroups.com; Ryan Crichton
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

UCUM is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes operational (conversion) information. We have prepared extracts of units of measure for certain clients wishing to represent units in their TS.

Jack

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Tuesday, May 20, 2014 9:50 AM
To: Ryan Crichton
Cc: terminology-services@googlegroups.com; openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

We have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly interoperable. So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly mapped to reference terms.

So, again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Andy,

Sorry for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com wrote:

Ryan,

Not sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department, internal medicine floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the
terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 * | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org*

–
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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–
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.

–
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.

–

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.

John_Carter · May 21, 2014, 2:48pm

I’m only thinking about the terminology service in the HIE, so maybe my view is narrow on this point, but I’d argue that any function of “ensuring end node
data collection” is out of scope for the HIE. It seems to me that all you can really do is ensure that the end node is able to send a valid message / document into the HIE space and then work with what they send. On the one hand, I suppose it all amounts to
the same thing, but to me it’s useful to separate functions at boundaries, as in

Inside the Enterprise System = EMR

Crossing System Boundaries = HIE

Translated to an action that the HIE can take, the HIE would publish a profile or implementation guide saying something like “For lab results to be included
in the HIE data, you have to send HL7v2 messages (or CCDA or FHIR or any of those) that are valid according to a schema published at (some website). In that message, you must fill SegmentXX1 with a valid unit of measure code from the UCUM code system (available
at (some terminology server)).”

JSC

···

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 10:00 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

How do we ensure that end node data collection retains the specific units if we don’t pre-coordinate? I think
the reality is that we won’t know what’s in those buckets if we don’t get specific. I agree that ordering a test does not require units, but resulting that test probably should.

--------------------
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 Wednesday, May 21, 2014 8:46 AM, David Aronow david.aronow@comcast.net wrote:

I agree with John’s comments, although hopefully we in the US are getting pounds closer to status of stones in the UK.

If an interface system provides a blood chemistry in mg/l and the HIE uses a LOINC concept whose unit is mg/dl, there needs to be a
normalization of the numeric result to retain the clinical meaning of the local value as it translates to the LOINC code.

Interface systems will have whatever degree of unit standardization they have, enforced by whatever method they use. HIE variables
that are not as specified as LOINC will need to have an explicit HIE standard unit, implemented in whatever manner we do.

David

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
On Behalf Of John Carter
Sent: Wednesday, May 21, 2014 7:54 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

I would argue against a policy of pre-coordination of units into the terminology for orders, procedures, etc.

Consider a hopefully simple internationalizable example: patient weight. The order to do a weight, the result, etc., are all exactly
the same regardless of which units are used to express the clinical measurement… which means that pre-coordination of units would have a denormalizing effect on the terminology and actually pose a burden to interoperability. If you had precoordinated expressions
for weight in pounds, weight in kilos, weight in stone, you demand that some analyst keep track of all those and manage terminology relationships and math to do the conversion.

In my view

·
The names of the pieces live in the terminology service: LOINC and SNOMED codes to represent the available weight measurement orders/procedures/findings, with appropriate
local synonyms; UCUM parts with their different spellings, and so on

·
Jurisdictional bindings (e.g., pounds → USA; kilos → elsewhere; stones → UK, sometimes) probably also live in the terminology service

·
The model for saying that a patient weight measurement observation consists of a label (The LOINC code for weight measurement), a quantity including units of measure (“162
lb”), and perhaps a qualifier (“first thing in AM”) lives in the specification of the message or document (CDA, FHIR, HL7v2 message). Advanced work on this notion, under various flavors of “detailed clinical models” continues at HL7, Intermountain, the VA,
and many other places.

·
The calculation required to convert units on an instance of a weight measurement from one jurisdiction to another (based on bindings in the terminology service) lives in
a rules engine that runs UCUM.

In that scenario, the data are interoperable when they need to be, at the time of transmission from one system to another or the execution
of a query, rather than being forced into an interoperable box at the time of data capture, which places a heavy maintenance burden on the back end parts of the system.

JSC

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 7:02 AM
To:
terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc:
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

I would be interested in what others think about this. LOINC only makes a suggested unit for their concepts and SNOMED doesn’t include
units at all. If we really want to be able to compare data stored in one system to another, it would seem that the units DO need to be explicitly pre coordinated with the concept.

Thoughts?

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 Wednesday, May 21, 2014 2:59 AM, David Aronow <david.aronow@comcast.net >
wrote:

Greetings from Kigutu, Burundi!

Just to clarify – Andy, are you saying that units should be precoordinated with the concepts they are units for, or that there must
be a specification, either in Fully Specified Name or some form of metadata, of what has been defined as the standard unit for the base concept?

Local systems will be sending an completely unpredictable array of units with lab results which (by whatever architecture is implemented)
will need to be normalized to the defined standard.

David

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
On Behalf Of Jack Bowie
Sent: Tuesday, May 20, 2014 10:09 AM
To:
terminology-services@googlegroups.com; Ryan Crichton
Cc:
openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

UCUM is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes
operational (conversion) information. We have prepared extracts of units of measure for certain clients wishing to represent units in their TS.

Jack

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Tuesday, May 20, 2014 9:50 AM
To: Ryan Crichton
Cc:
terminology-services@googlegroups.com;
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

We have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly
interoperable. So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly
mapped to reference terms.

So, again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Andy,

Sorry for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com >
wrote:

Ryan,

Not sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department,
internal medicine floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate
the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile:**+27845829934 * | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org*

–

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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–

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.

Daniel_Vreeman · May 22, 2014, 2:38am

This is a good discussion. From the HIE perspective, binding units into the terminology services model is a powerful data integrity check.

In the INPC, one of the few checks the ORU processor does on incoming messages is make sure that the
units associated with the local term are consistent with the allowed set of units (primary unit, or synonyms) for the universal code that local term is mapped to. We don’t bother checking if the test name string is the same as the one we have in the mapping table (local systems often tweak their names over time), but the message processing system will throw an exception if the units don’t match (including if they are null when the test should have them).

Why is this important? Because when the units change, that is a strong signal that the source system may be doing something bad (i.e. not following good terminology practices) with their test codes…like using the same code for a different test. It is not common, but this is just about the only way you can detect it when you are not in control over what the sending systems are doing.

John Carter wrote:

···

–
Thanks,

Daniel J. Vreeman, PT, DPT, MSc

Assistant Research Professor, Indiana University School of
Medicine

Research Scientist, Regenstrief Institute, Inc

I’m
only thinking about the terminology service in the HIE, so maybe my view is narrow on this point, but I’d argue that any function of “ensuring end node
data collection” is out of scope for the HIE. It seems to me that all you can really do is ensure that the end node is able to send a valid message / document into the HIE space and then work with what they send.
On the one hand, I suppose it all amounts to
the same thing, but to me it’s useful to separate functions at boundaries, as in

Inside
the Enterprise System = EMR

Crossing
System Boundaries = HIE

Translated
to an action that the HIE can take, the HIE would publish a profile or implementation guide saying something like “For lab results to be included
in the HIE data, you have to send HL7v2 messages (or CCDA or FHIR or any of those) that are valid according to a schema published at (some website). In that message, you must fill SegmentXX1 with a valid unit of
measure code from the UCUM code system (available
at (some terminology server)).”

JSC

** John
S. Carter | VP | Apelon, Inc.**

jcarter@apelon.com
| +1 801-953-9815

From:

Wednesday, May 21, 2014 10:00 AM
; ‘Ryan Crichton’
Re: Storing units in the TS

How
do we ensure that end node data collection retains the specific units if we don’t pre-coordinate? I think
the reality is that we won’t know what’s in those buckets if we don’t get specific. I agree that ordering a test does not require units, but resulting that test probably should.

--------------------
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
Wednesday, May 21, 2014 8:46 AM, David Aronow <david.aronow@comcast.net >
wrote:

I
agree with John’s comments, although hopefully we in the US are getting
pounds closer to status of stones in the UK.

If
an interface system provides a blood chemistry in mg/l and the HIE uses
a LOINC concept whose unit is mg/dl, there needs to be a
normalization of the numeric result to retain the clinical meaning of the local value as it translates to the LOINC code.

Interface
systems will have whatever degree of unit standardization they have, enforced by whatever method they use. HIE variables
that are not as specified as LOINC will need to have an explicit HIE standard unit, implemented in whatever manner we do.

David

From:
terminology-services@googlegroups.com
[mailto:terminology-services@googlegroups.com]
On Behalf Of John Carter
Sent: Wednesday, May 21, 2014 7:54 AM
To: terminology-services@googlegroups.com ;
‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

I
would argue against a policy of pre-coordination of units into the terminology for orders, procedures, etc.

Consider
a hopefully simple internationalizable example: patient weight. The order to do a weight, the result, etc., are all exactly
the same regardless of which units are used to express the clinical measurement… which means that pre-coordination of units would have a denormalizing effect on the terminology and actually pose a burden to interoperability. If you had precoordinated expressions
for weight in pounds, weight in kilos, weight in stone, you demand that
some analyst keep track of all those and manage terminology relationships and math to do the conversion.

In
my view

·
The
names of the pieces live in the terminology service: LOINC and SNOMED codes to represent the available weight measurement orders/procedures/findings, with appropriate
local synonyms; UCUM parts with their different spellings, and so on

·
Jurisdictional
bindings (e.g., pounds → USA; kilos → elsewhere; stones → UK, sometimes) probably also live in the terminology service

·
The
model for saying that a patient weight measurement observation consists
of a label (The LOINC code for weight measurement), a quantity including units of measure (“162
lb”), and perhaps a qualifier (“first thing in AM”) lives in the specification of the message or document (CDA, FHIR, HL7v2 message). Advanced work on this notion, under various flavors of “detailed clinical models” continues at HL7, Intermountain, the VA,
and many other places.

·
The
calculation required to convert units on an instance of a weight measurement from one jurisdiction to another (based on bindings in the terminology service) lives in
a rules engine that runs UCUM.

In
that scenario, the data are interoperable when they need to be, at the time of transmission from one system to another or the execution
of a query, rather than being forced into an interoperable box at the time of data capture, which places a heavy maintenance burden on the back end parts of the system.

JSC

** John
S. Carter | VP | Apelon, Inc.**

jcarter@apelon.com
| +1 801-953-9815

From:
terminology-services@googlegroups.com
[mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 7:02 AM
To:
terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc:
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

I
would be interested in what others think about this. LOINC only makes a
suggested unit for their concepts and SNOMED doesn’t include
units at all. If we really want to be able to compare data stored in one system to another, it would seem that the units DO need to be explicitly pre coordinated with the concept.

Thoughts?

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
Wednesday, May 21, 2014 2:59 AM, David Aronow <david.aronow@comcast.net >
wrote:

Greetings
from Kigutu, Burundi!

Just
to clarify – Andy, are you saying that units should be precoordinated with the concepts they are units for, or that there must
be a specification, either in Fully Specified Name or some form of metadata, of what has been defined as the standard unit for the base concept?

Local
systems will be sending an completely unpredictable array of units with
lab results which (by whatever architecture is implemented)
will need to be normalized to the defined standard.

David

From:
terminology-services@googlegroups.com
[mailto:terminology-services@googlegroups.com]
On Behalf Of Jack Bowie
Sent: Tuesday, May 20, 2014 10:09 AM
To:
terminology-services@googlegroups.com; Ryan Crichton
Cc:
openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

UCUM
is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes
operational (conversion) information. We have prepared extracts of units of measure for certain clients wishing to represent units in their
TS.

Jack

From:
terminology-services@googlegroups.com
[mailto:terminology-services@googlegroups.com]
Sent: Tuesday, May 20, 2014 9:50 AM
To: Ryan Crichton
Cc:
terminology-services@googlegroups.com;
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

We
have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly
interoperable. So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly
mapped to reference terms.

So,
again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton <ryan@jembi.org >
wrote:

Hi
Andy,

Sorry
for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On
Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com >
wrote:

Ryan,

Not
sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department,
internal medicine floor? Or do you mean something else?

Most
of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton <ryan@jembi.org >
wrote:

Hi
all,

(Apologies
all if you get multiple email from me. I was having trouble with the list serv.)

In
some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate
the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are
there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan
Crichton*

Software
Developer, Jembi Health Systems | SOUTH AFRICA*

Mobile:+27845829934
| Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–

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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

–

Ryan
Crichton*

Software
Developer, Jembi Health Systems | SOUTH AFRICA*

Mobile:
+27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org*

–

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.

–

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.
terminology-services@googlegroups.commailto:terminology-services@googlegroups.com
Sent:
**To:**terminology-services@googlegroups.com
**Cc:**openhie-interoperability-layer@googlegroups.com
Subject:

sgrannis · May 22, 2014, 2:41am

I concur that binding units to codes would help with validation.

Do people have a sense of what level of resources, both initially and ongoing, would be needed to support this approach?

Shaun

···

Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Wed, May 21, 2014 at 10:38 PM, Daniel Vreeman dvreeman@regenstrief.org wrote:

This is a good discussion. From the HIE perspective, binding units into the terminology services model is a powerful data integrity check.

In the INPC, one of the few checks the ORU processor does on incoming messages is make sure that the
units associated with the local term are consistent with the allowed set of units (primary unit, or synonyms) for the universal code that local term is mapped to. We don’t bother checking if the test name string is the same as the one we have in the mapping table (local systems often tweak their names over time), but the message processing system will throw an exception if the units don’t match (including if they are null when the test should have them).

Why is this important? Because when the units change, that is a strong signal that the source system may be doing something bad (i.e. not following good terminology practices) with their test codes…like using the same code for a different test. It is not common, but this is just about the only way you can detect it when you are not in control over what the sending systems are doing.

–
Thanks,

Daniel J. Vreeman, PT, DPT, MSc

Assistant Research Professor, Indiana University School of
Medicine

Research Scientist, Regenstrief Institute, Inc

John Carter wrote:

I’m
only thinking about the terminology service in the HIE, so maybe my view is narrow on this point, but I’d argue that any function of “ensuring end node
data collection” is out of scope for the HIE. It seems to me that all you can really do is ensure that the end node is able to send a valid message / document into the HIE space and then work with what they send.
On the one hand, I suppose it all amounts to
the same thing, but to me it’s useful to separate functions at boundaries, as in

Inside
the Enterprise System = EMR

Crossing
System Boundaries = HIE

Translated
to an action that the HIE can take, the HIE would publish a profile or implementation guide saying something like “For lab results to be included
in the HIE data, you have to send HL7v2 messages (or CCDA or FHIR or any of those) that are valid according to a schema published at (some website). In that message, you must fill SegmentXX1 with a valid unit of
measure code from the UCUM code system (available
at (some terminology server)).”

JSC

** John
S. Carter | VP | Apelon, Inc.**

jcarter@apelon.com
| +1 801-953-9815

From:
terminology-services@googlegroups.com
[mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 10:00 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

How
do we ensure that end node data collection retains the specific units if we don’t pre-coordinate? I think
the reality is that we won’t know what’s in those buckets if we don’t get specific. I agree that ordering a test does not require units, but resulting that test probably should.

--------------------
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
Wednesday, May 21, 2014 8:46 AM, David Aronow <david.aronow@comcast.net >
wrote:

I
agree with John’s comments, although hopefully we in the US are getting
pounds closer to status of stones in the UK.

If
an interface system provides a blood chemistry in mg/l and the HIE uses
a LOINC concept whose unit is mg/dl, there needs to be a
normalization of the numeric result to retain the clinical meaning of the local value as it translates to the LOINC code.

Interface
systems will have whatever degree of unit standardization they have, enforced by whatever method they use. HIE variables
that are not as specified as LOINC will need to have an explicit HIE standard unit, implemented in whatever manner we do.

David

From:
terminology-services@googlegroups.com
[mailto:terminology-services@googlegroups.com]
On Behalf Of John Carter
Sent: Wednesday, May 21, 2014 7:54 AM
To: terminology-services@googlegroups.com ;
‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

I
would argue against a policy of pre-coordination of units into the terminology for orders, procedures, etc.

Consider
a hopefully simple internationalizable example: patient weight. The order to do a weight, the result, etc., are all exactly
the same regardless of which units are used to express the clinical measurement… which means that pre-coordination of units would have a denormalizing effect on the terminology and actually pose a burden to interoperability. If you had precoordinated expressions
for weight in pounds, weight in kilos, weight in stone, you demand that
some analyst keep track of all those and manage terminology relationships and math to do the conversion.

In
my view

·
The
names of the pieces live in the terminology service: LOINC and SNOMED codes to represent the available weight measurement orders/procedures/findings, with appropriate
local synonyms; UCUM parts with their different spellings, and so on

·
Jurisdictional
bindings (e.g., pounds → USA; kilos → elsewhere; stones → UK, sometimes) probably also live in the terminology service

·
The
model for saying that a patient weight measurement observation consists
of a label (The LOINC code for weight measurement), a quantity including units of measure (“162
lb”), and perhaps a qualifier (“first thing in AM”) lives in the specification of the message or document (CDA, FHIR, HL7v2 message). Advanced work on this notion, under various flavors of “detailed clinical models” continues at HL7, Intermountain, the VA,
and many other places.

·
The
calculation required to convert units on an instance of a weight measurement from one jurisdiction to another (based on bindings in the terminology service) lives in
a rules engine that runs UCUM.

In
that scenario, the data are interoperable when they need to be, at the time of transmission from one system to another or the execution
of a query, rather than being forced into an interoperable box at the time of data capture, which places a heavy maintenance burden on the back end parts of the system.

JSC

** John
S. Carter | VP | Apelon, Inc.**

jcarter@apelon.com
| +1 801-953-9815

From:
terminology-services@googlegroups.com
[mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 7:02 AM
To:
terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc:
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

I
would be interested in what others think about this. LOINC only makes a
suggested unit for their concepts and SNOMED doesn’t include
units at all. If we really want to be able to compare data stored in one system to another, it would seem that the units DO need to be explicitly pre coordinated with the concept.

Thoughts?

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
Wednesday, May 21, 2014 2:59 AM, David Aronow <david.aronow@comcast.net >
wrote:

Greetings
from Kigutu, Burundi!

Just
to clarify – Andy, are you saying that units should be precoordinated with the concepts they are units for, or that there must
be a specification, either in Fully Specified Name or some form of metadata, of what has been defined as the standard unit for the base concept?

Local
systems will be sending an completely unpredictable array of units with
lab results which (by whatever architecture is implemented)
will need to be normalized to the defined standard.

David

From:
terminology-services@googlegroups.com
[mailto:terminology-services@googlegroups.com]
On Behalf Of Jack Bowie
Sent: Tuesday, May 20, 2014 10:09 AM
To:
terminology-services@googlegroups.com; Ryan Crichton
Cc:
openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

UCUM
is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes
operational (conversion) information. We have prepared extracts of units of measure for certain clients wishing to represent units in their
TS.

Jack

From:
terminology-services@googlegroups.com
[mailto:terminology-services@googlegroups.com]
Sent: Tuesday, May 20, 2014 9:50 AM
To: Ryan Crichton
Cc:
terminology-services@googlegroups.com;
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

We
have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly
interoperable. So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly
mapped to reference terms.

So,
again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton <ryan@jembi.org >
wrote:

Hi
Andy,

Sorry
for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On
Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com >
wrote:

Ryan,

Not
sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department,
internal medicine floor? Or do you mean something else?

Most
of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton <ryan@jembi.org >
wrote:

Hi
all,

(Apologies
all if you get multiple email from me. I was having trouble with the list serv.)

In
some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate
the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are
there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan
Crichton*

Software
Developer, Jembi Health Systems | SOUTH AFRICA*

Mobile:+27845829934
| Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–

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 “Interoperability Layer (OpenHIE)” group.

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

openhie-interoperability-layer+unsubscribe@googlegroups.com.

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

–

Ryan
Crichton*

Software
Developer, Jembi Health Systems | SOUTH AFRICA*

Mobile:
+27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org*

–

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.

–

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 “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.

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

David_Aronow · May 22, 2014, 6:40am

My experience is that explicit units are often missing from an observation message within and from local systems. In addition to scaling observation values when explicit units differ from the central standard (we function as an HIE but do not call ourselves such at Humedica), when explicit units are embedded in result values, we parse them out into a unit field, and when units are neither explicit not parseable, we infer them by comparing the value frequency distribution without units to distributions with units. Normalization is a lot of work.

···

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com] On Behalf Of Daniel Vreeman
Sent: Thursday, May 22, 2014 4:39 AM
To: terminology-services@googlegroups.com
Cc: ‘Ryan Crichton’; openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

This is a good discussion. From the HIE perspective, binding units into the terminology services model is a powerful data integrity check.

In the INPC, one of the few checks the ORU processor does on incoming messages is make sure that the units associated with the local term are consistent with the allowed set of units (primary unit, or synonyms) for the universal code that local term is mapped to. We don’t bother checking if the test name string is the same as the one we have in the mapping table (local systems often tweak their names over time), but the message processing system will throw an exception if the units don’t match (including if they are null when the test should have them).

Why is this important? Because when the units change, that is a strong signal that the source system may be doing something bad (i.e. not following good terminology practices) with their test codes…like using the same code for a different test. It is not common, but this is just about the only way you can detect it when you are not in control over what the sending systems are doing.

–

Thanks,

Daniel J. Vreeman, PT, DPT, MSc
Assistant Research Professor, Indiana University School of Medicine
Research Scientist, Regenstrief Institute, Inc

John Carter wrote:

I’m only thinking about the terminology service in the HIE, so maybe my view is narrow on this point, but I’d argue that any function of “ensuring end node data collection” is out of scope for the HIE. It seems to me that all you can really do is ensure that the end node is able to send a valid message / document into the HIE space and then work with what they send. On the one hand, I suppose it all amounts to the same thing, but to me it’s useful to separate functions at boundaries, as in

Inside the Enterprise System = EMR

Crossing System Boundaries = HIE

Translated to an action that the HIE can take, the HIE would publish a profile or implementation guide saying something like “For lab results to be included in the HIE data, you have to send HL7v2 messages (or CCDA or FHIR or any of those) that are valid according to a schema published at (some website). In that message, you must fill SegmentXX1 with a valid unit of measure code from the UCUM code system (available at (some terminology server)).”

JSC

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 10:00 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

How do we ensure that end node data collection retains the specific units if we don’t pre-coordinate? I think the reality is that we won’t know what’s in those buckets if we don’t get specific. I agree that ordering a test does not require units, but resulting that test probably should.

--------------------
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 Wednesday, May 21, 2014 8:46 AM, David Aronow david.aronow@comcast.net wrote:

I agree with John’s comments, although hopefully we in the US are getting pounds closer to status of stones in the UK.

If an interface system provides a blood chemistry in mg/l and the HIE uses a LOINC concept whose unit is mg/dl, there needs to be a normalization of the numeric result to retain the clinical meaning of the local value as it translates to the LOINC code.

Interface systems will have whatever degree of unit standardization they have, enforced by whatever method they use. HIE variables that are not as specified as LOINC will need to have an explicit HIE standard unit, implemented in whatever manner we do.

David

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com] On Behalf Of John Carter
Sent: Wednesday, May 21, 2014 7:54 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

I would argue against a policy of pre-coordination of units into the terminology for orders, procedures, etc.

Consider a hopefully simple internationalizable example: patient weight. The order to do a weight, the result, etc., are all exactly the same regardless of which units are used to express the clinical measurement… which means that pre-coordination of units would have a denormalizing effect on the terminology and actually pose a burden to interoperability. If you had precoordinated expressions for weight in pounds, weight in kilos, weight in stone, you demand that some analyst keep track of all those and manage terminology relationships and math to do the conversion.

In my view

· The names of the pieces live in the terminology service: LOINC and SNOMED codes to represent the available weight measurement orders/procedures/findings, with appropriate local synonyms; UCUM parts with their different spellings, and so on

· Jurisdictional bindings (e.g., pounds → USA; kilos → elsewhere; stones → UK, sometimes) probably also live in the terminology service

· The model for saying that a patient weight measurement observation consists of a label (The LOINC code for weight measurement), a quantity including units of measure (“162 lb”), and perhaps a qualifier (“first thing in AM”) lives in the specification of the message or document (CDA, FHIR, HL7v2 message). Advanced work on this notion, under various flavors of “detailed clinical models” continues at HL7, Intermountain, the VA, and many other places.

· The calculation required to convert units on an instance of a weight measurement from one jurisdiction to another (based on bindings in the terminology service) lives in a rules engine that runs UCUM.

In that scenario, the data are interoperable when they need to be, at the time of transmission from one system to another or the execution of a query, rather than being forced into an interoperable box at the time of data capture, which places a heavy maintenance burden on the back end parts of the system.

JSC

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 7:02 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

I would be interested in what others think about this. LOINC only makes a suggested unit for their concepts and SNOMED doesn’t include units at all. If we really want to be able to compare data stored in one system to another, it would seem that the units DO need to be explicitly pre coordinated with the concept.

Thoughts?

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 Wednesday, May 21, 2014 2:59 AM, David Aronow david.aronow@comcast.net wrote:

Greetings from Kigutu, Burundi!

Just to clarify – Andy, are you saying that units should be precoordinated with the concepts they are units for, or that there must be a specification, either in Fully Specified Name or some form of metadata, of what has been defined as the standard unit for the base concept?

Local systems will be sending an completely unpredictable array of units with lab results which (by whatever architecture is implemented) will need to be normalized to the defined standard.

David

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com] On Behalf Of Jack Bowie
Sent: Tuesday, May 20, 2014 10:09 AM
To: terminology-services@googlegroups.com; Ryan Crichton
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

UCUM is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes operational (conversion) information. We have prepared extracts of units of measure for certain clients wishing to represent units in their TS.

Jack

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Tuesday, May 20, 2014 9:50 AM
To: Ryan Crichton
Cc: terminology-services@googlegroups.com; openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

We have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly interoperable. So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly mapped to reference terms.

So, again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Andy,

Sorry for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com wrote:

Ryan,

Not sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department, internal medicine floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 * | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org*

–
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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–
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.

John_Carter · May 22, 2014, 2:24pm

For me, there’s all the difference in the world between the notion of “binding units in the terminology service” as Dan says below and the original phrasing
that talked about “pre-coordinated expressions”. I’m certainly in support of a binding strategy that uses LOINC and UCUM to represent data points and power the validation rules. And, although I acknowledge that an implementation might well choose to pre-calculate
or cache certain common expressions, I’m still opposed to creating and maintaining a new terminology layer with pre-coordinated units.

Specifically, LOINC codes mostly include information not about a specific unit (kg, lb), but about a type of unit (mass, volume). UCUM tells us whether a given
unit is of a given type. Therefore, you can do the validation that Dan talks about by asking

a)
is this a valid unit of measure, and then

b)
is this unit of the correct type for the LOINC code it’s attached to in the message

Interoperability is achieved the same way, by noting what units are coming in, what are the desired units going out, and using UCUM rules to effect any needed
conversions (multiply by 2.2, divide by 1,000, etc.)

Of primary importance in this strategy is the recognition that the core observation is the same observation, and convertible, regardless of which (convertible)
units are used. In contrast, when the units are NOT readily convertible (as in mass vs. molar measurement, for example), LOINC provides us with different codes that are still semantically joined by a common Component.

It’s hardly my place to agree or disagree with Dan Vreeman (or most of the rest of you) on the fine points of LOINC implementation, but I appreciate the opportunity
to advocate for a decoupled, non-pre-coordinated terminology service strategy.

JSC

···

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
On Behalf Of David Aronow
Sent: Thursday, May 22, 2014 2:41 AM
To: terminology-services@googlegroups.com
Cc: ‘Ryan Crichton’; openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

My experience is that explicit units are often missing from an observation message within and from local systems. In addition to scaling observation values
when explicit units differ from the central standard (we function as an HIE but do not call ourselves such at Humedica), when explicit units are embedded in result values, we parse them out into a unit field, and when units are neither explicit not parseable,
we infer them by comparing the value frequency distribution without units to distributions with units. Normalization is a lot of work.

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
On Behalf Of Daniel Vreeman
Sent: Thursday, May 22, 2014 4:39 AM
To: terminology-services@googlegroups.com
Cc: ‘Ryan Crichton’;
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

This is a good discussion. From the HIE perspective, binding units into the terminology services model is a powerful data integrity check.

In the INPC, one of the few checks the ORU processor does on incoming messages is make sure that the units associated with the local term are consistent with the allowed set of units (primary unit, or synonyms) for the universal code that local term is mapped
to. We don’t bother checking if the test name string is the same as the one we have in the mapping table (local systems often tweak their names over time), but the message processing system will throw an exception if the units don’t match (including if they
are null when the test should have them).

Why is this important? Because when the units change, that is a strong signal that the source system may be doing something bad (i.e. not following good terminology practices) with their test codes…like using the same code for a different test. It is not
common, but this is just about the only way you can detect it when you are not in control over what the sending systems are doing.

–

Thanks,

Daniel J. Vreeman, PT, DPT, MSc
Assistant Research Professor, Indiana University School of Medicine
Research Scientist, Regenstrief Institute, Inc

John Carter wrote:

I’m only thinking about the terminology service in the HIE, so maybe my view is narrow on this point, but I’d argue that any function of “ensuring end node
data collection” is out of scope for the HIE. It seems to me that all you can really do is ensure that the end node is able to send a valid message / document into the HIE space and then work with what they send. On the one hand, I suppose it all amounts to
the same thing, but to me it’s useful to separate functions at boundaries, as in

Inside the Enterprise System = EMR

Crossing System Boundaries = HIE

Translated to an action that the HIE can take, the HIE would publish a profile or implementation guide saying something like “For lab results to be included
in the HIE data, you have to send HL7v2 messages (or CCDA or FHIR or any of those) that are valid according to a schema published at (some website). In that message, you must fill SegmentXX1 with a valid unit of measure code from the UCUM code system (available
at (some terminology server)).”

JSC

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 10:00 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

How do we ensure that end node data collection retains the specific units if we don’t pre-coordinate? I think the reality
is that we won’t know what’s in those buckets if we don’t get specific. I agree that ordering a test does not require units, but resulting that test probably should.

--------------------
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 Wednesday, May 21, 2014 8:46 AM, David Aronow david.aronow@comcast.net wrote:

I agree with John’s comments, although hopefully we in the US are getting pounds closer to status of stones in the UK.

If an interface system provides a blood chemistry in mg/l and the HIE uses a LOINC concept whose unit is mg/dl, there needs to be a normalization
of the numeric result to retain the clinical meaning of the local value as it translates to the LOINC code.

Interface systems will have whatever degree of unit standardization they have, enforced by whatever method they use. HIE variables that are not
as specified as LOINC will need to have an explicit HIE standard unit, implemented in whatever manner we do.

David

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
On Behalf Of John Carter
Sent: Wednesday, May 21, 2014 7:54 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

I would argue against a policy of pre-coordination of units into the terminology for orders, procedures, etc.

Consider a hopefully simple internationalizable example: patient weight. The order to do a weight, the result, etc., are all exactly the same regardless
of which units are used to express the clinical measurement… which means that pre-coordination of units would have a denormalizing effect on the terminology and actually pose a burden to interoperability. If you had precoordinated expressions for weight in
pounds, weight in kilos, weight in stone, you demand that some analyst keep track of all those and manage terminology relationships and math to do the conversion.

In my view

·
The names of the pieces live in the terminology service: LOINC and SNOMED codes to represent the available weight measurement orders/procedures/findings, with appropriate local synonyms;
UCUM parts with their different spellings, and so on

·
Jurisdictional bindings (e.g., pounds → USA; kilos → elsewhere; stones → UK, sometimes) probably also live in the terminology service

·
The model for saying that a patient weight measurement observation consists of a label (The LOINC code for weight measurement), a quantity including units of measure (“162 lb”), and
perhaps a qualifier (“first thing in AM”) lives in the specification of the message or document (CDA, FHIR, HL7v2 message). Advanced work on this notion, under various flavors of “detailed clinical models” continues at HL7, Intermountain, the VA, and many
other places.

·
The calculation required to convert units on an instance of a weight measurement from one jurisdiction to another (based on bindings in the terminology service) lives in a rules engine
that runs UCUM.

In that scenario, the data are interoperable when they need to be, at the time of transmission from one system to another or the execution of a
query, rather than being forced into an interoperable box at the time of data capture, which places a heavy maintenance burden on the back end parts of the system.

JSC

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 7:02 AM
To:
terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc:
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

I would be interested in what others think about this. LOINC only makes a suggested unit for their concepts and SNOMED doesn’t include units at
all. If we really want to be able to compare data stored in one system to another, it would seem that the units DO need to be explicitly pre coordinated with the concept.

Thoughts?

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 Wednesday, May 21, 2014 2:59 AM, David Aronow david.aronow@comcast.net wrote:

Greetings from Kigutu, Burundi!

Just to clarify – Andy, are you saying that units should be precoordinated with the concepts they are units for, or that there must be a specification,
either in Fully Specified Name or some form of metadata, of what has been defined as the standard unit for the base concept?

Local systems will be sending an completely unpredictable array of units with lab results which (by whatever architecture is implemented) will
need to be normalized to the defined standard.

David

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
On Behalf Of Jack Bowie
Sent: Tuesday, May 20, 2014 10:09 AM
To:
terminology-services@googlegroups.com; Ryan Crichton
Cc:
openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

UCUM is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes operational
(conversion) information. We have prepared extracts of units of measure for certain clients wishing to represent units in their TS.

Jack

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Tuesday, May 20, 2014 9:50 AM
To: Ryan Crichton
Cc:
terminology-services@googlegroups.com;
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

We have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly interoperable.
So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly mapped to
reference terms.

So, again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Andy,

Sorry for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com >
wrote:

Ryan,

Not sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department, internal
medicine floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units
of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile:**+27845829934 * | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org*

–

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 “Interoperability Layer (OpenHIE)” group.

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

openhie-interoperability-layer+unsubscribe@googlegroups.com.

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

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–

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.

–
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.

Andrew_Kanter1 · May 22, 2014, 2:44pm

I think we are highlighting the difference between an HIE strategy and a node-system terminology management strategy. With the OpenMRS implementations we frequently have issues about the units of record. Weight in Kg and Lbs for example. It is clearly necessary to know which units were used. In our case, we kept the concept as weight in Kg and had the UI do any calculations. However, I think if we simply left the concept as “body weight” and asked the user to record the units separately, we would find that many observations came in without units at all. I know this is an application design issue, but I also think the TS, acting as a terminology management tool, should help system developers and users do the right thing. Clearly we don’t want the combinatorial explosion of all the
tests with all the different units. For duration recording, it was pretty easy to specify a numeric value and have the user select the duration unit. So maybe it is possible.

Should this be included in the TS best practices documentation?

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, May 22, 2014 10:24 AM, John Carter jcarter@apelon.com wrote:

For me, there’s all the difference in the world between the notion of “binding units in the terminology service” as Dan says below and the original phrasing
that talked about “pre-coordinated expressions”. I’m certainly in support of a binding strategy that uses LOINC and UCUM to represent data points and power the validation rules. And, although I acknowledge that an implementation might well choose to pre-calculate
or cache certain common expressions, I’m still opposed to creating and maintaining a new terminology layer with pre-coordinated units.

Specifically, LOINC codes mostly include information not about a specific unit (kg, lb), but about a type of unit (mass, volume). UCUM tells us whether a given
unit is of a given type. Therefore, you can do the validation that Dan talks about by asking

a)
is this a valid unit of measure, and then

b)
is this unit of the correct type for the LOINC code it’s attached to in the message

Interoperability is achieved the same way, by noting what units are coming in, what are the desired units going out, and using UCUM rules to effect any needed
conversions (multiply by 2.2, divide by 1,000, etc.)

Of primary importance in this strategy is the recognition that the core observation is the same observation, and convertible, regardless of which (convertible)
units are used. In contrast, when the units are NOT readily convertible (as in mass vs. molar measurement, for example), LOINC provides us with different codes that are still semantically joined by a common Component.

It’s hardly my place to agree or disagree with Dan Vreeman (or most of the rest of you) on the fine points of LOINC implementation, but I appreciate the opportunity
to advocate for a decoupled, non-pre-coordinated terminology service strategy.

JSC

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
On Behalf Of David Aronow
Sent: Thursday, May 22, 2014 2:41 AM
To: terminology-services@googlegroups.com
Cc: ‘Ryan Crichton’; openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

My experience is that explicit units are often missing from an observation message within and from local systems. In addition to scaling observation values
when explicit units differ from the central standard (we function as an HIE but do not call ourselves such at Humedica), when explicit units are embedded in result values, we parse them out into a unit field, and when units are neither explicit not parseable,
we infer them by comparing the value frequency distribution without units to distributions with units. Normalization is a lot of work.

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
On Behalf Of Daniel Vreeman
Sent: Thursday, May 22, 2014 4:39 AM
To: terminology-services@googlegroups.com
Cc: ‘Ryan Crichton’;
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

This is a good discussion. From the HIE perspective, binding units into the terminology services model is a powerful data integrity check.

In the INPC, one of the few checks the ORU processor does on incoming messages is make sure that the units associated with the local term are consistent with the allowed set of units (primary unit, or synonyms) for the universal code that local term is mapped
to. We don’t bother checking if the test name string is the same as the one we have in the mapping table (local systems often tweak their names over time), but the message processing system will throw an exception if the units don’t match (including if they
are null when the test should have them).

Why is this important? Because when the units change, that is a strong signal that the source system may be doing something bad (i.e. not following good terminology practices) with their test codes…like using the same code for a different test. It is not
common, but this is just about the only way you can detect it when you are not in control over what the sending systems are doing.

–

Thanks,

Daniel J. Vreeman, PT, DPT, MSc

Assistant Research Professor, Indiana University School of Medicine

Research Scientist, Regenstrief Institute, Inc

John Carter wrote:

I’m only thinking about the terminology service in the HIE, so maybe my view is narrow on this point, but I’d argue that any function of “ensuring end node
data collection” is out of scope for the HIE. It seems to me that all you can really do is ensure that the end node is able to send a valid message / document into the HIE space and then work with what they send. On the one hand, I suppose it all amounts to
the same thing, but to me it’s useful to separate functions at boundaries, as in

Inside the Enterprise System = EMR

Crossing System Boundaries = HIE

Translated to an action that the HIE can take, the HIE would publish a profile or implementation guide saying something like “For lab results to be included
in the HIE data, you have to send HL7v2 messages (or CCDA or FHIR or any of those) that are valid according to a schema published at (some website). In that message, you must fill SegmentXX1 with a valid unit of measure code from the UCUM code system (available
at (some terminology server)).”

JSC

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 10:00 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

How do we ensure that end node data collection retains the specific units if we don’t pre-coordinate? I think the reality
is that we won’t know what’s in those buckets if we don’t get specific. I agree that ordering a test does not require units, but resulting that test probably should.

--------------------
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 Wednesday, May 21, 2014 8:46 AM, David Aronow david.aronow@comcast.net wrote:

I agree with John’s comments, although hopefully we in the US are getting pounds closer to status of stones in the UK.

If an interface system provides a blood chemistry in mg/l and the HIE uses a LOINC concept whose unit is mg/dl, there needs to be a normalization
of the numeric result to retain the clinical meaning of the local value as it translates to the LOINC code.

Interface systems will have whatever degree of unit standardization they have, enforced by whatever method they use. HIE variables that are not
as specified as LOINC will need to have an explicit HIE standard unit, implemented in whatever manner we do.

David

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
On Behalf Of John Carter
Sent: Wednesday, May 21, 2014 7:54 AM
To: terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc: openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

I would argue against a policy of pre-coordination of units into the terminology for orders, procedures, etc.

Consider a hopefully simple internationalizable example: patient weight. The order to do a weight, the result, etc., are all exactly the same regardless
of which units are used to express the clinical measurement… which means that pre-coordination of units would have a denormalizing effect on the terminology and actually pose a burden to interoperability. If you had precoordinated expressions for weight in
pounds, weight in kilos, weight in stone, you demand that some analyst keep track of all those and manage terminology relationships and math to do the conversion.

In my view

·
The names of the pieces live in the terminology service: LOINC and SNOMED codes to represent the available weight measurement orders/procedures/findings, with appropriate local synonyms;
UCUM parts with their different spellings, and so on

·
Jurisdictional bindings (e.g., pounds → USA; kilos → elsewhere; stones → UK, sometimes) probably also live in the terminology service

·
The model for saying that a patient weight measurement observation consists of a label (The LOINC code for weight measurement), a quantity including units of measure (“162 lb”), and
perhaps a qualifier (“first thing in AM”) lives in the specification of the message or document (CDA, FHIR, HL7v2 message). Advanced work on this notion, under various flavors of “detailed clinical models” continues at HL7, Intermountain, the VA, and many
other places.

·
The calculation required to convert units on an instance of a weight measurement from one jurisdiction to another (based on bindings in the terminology service) lives in a rules engine
that runs UCUM.

In that scenario, the data are interoperable when they need to be, at the time of transmission from one system to another or the execution of a
query, rather than being forced into an interoperable box at the time of data capture, which places a heavy maintenance burden on the back end parts of the system.

JSC

John S. Carter | VP | Apelon, Inc.

jcarter@apelon.com | +1 801-953-9815

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Wednesday, May 21, 2014 7:02 AM
To:
terminology-services@googlegroups.com; ‘Ryan Crichton’
Cc:
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

I would be interested in what others think about this. LOINC only makes a suggested unit for their concepts and SNOMED doesn’t include units at
all. If we really want to be able to compare data stored in one system to another, it would seem that the units DO need to be explicitly pre coordinated with the concept.

Thoughts?

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 Wednesday, May 21, 2014 2:59 AM, David Aronow david.aronow@comcast.net wrote:

Greetings from Kigutu, Burundi!

Just to clarify – Andy, are you saying that units should be precoordinated with the concepts they are units for, or that there must be a specification,
either in Fully Specified Name or some form of metadata, of what has been defined as the standard unit for the base concept?

Local systems will be sending an completely unpredictable array of units with lab results which (by whatever architecture is implemented) will
need to be normalized to the defined standard.

David

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
On Behalf Of Jack Bowie
Sent: Tuesday, May 20, 2014 10:09 AM
To:
terminology-services@googlegroups.com; Ryan Crichton
Cc:
openhie-interoperability-layer@googlegroups.com
Subject: RE: Storing units in the TS

UCUM is generally viewed as the standard “reference” for units of measure, but it is large, covers a lot more than healthcare and includes operational
(conversion) information. We have prepared extracts of units of measure for certain clients wishing to represent units in their TS.

Jack

From:
terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com]
Sent: Tuesday, May 20, 2014 9:50 AM
To: Ryan Crichton
Cc:
terminology-services@googlegroups.com;
openhie-interoperability-layer@googlegroups.com
Subject: Re: Storing units in the TS

We have discussed this a bit on the list. It is essential that concept definitions actually include units if we want them to be truly interoperable.
So weight (in kilograms) is different than weight (in pounds). But we have also recently included specific units as coded elements so that they can be included in things like orders (which are constructed segmentally) and allow them to be properly mapped to
reference terms.

So, again, I think the answer is YES to the units in the TS and Jack can confirm or deny

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, May 20, 2014 9:41 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Andy,

Sorry for not being clear. I meant units as in mg, ml, in.

Cheers,

Ryan

On Tue, May 20, 2014 at 3:29 PM, ‘Andrew Kanter’ via Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com > > > > > > wrote:

Ryan,

Not sure what you mean by units of clinical encounters. Do you mean units like mg, ml, in or units like surgery suite, emergency department, internal
medicine floor? Or do you mean something else?

Most of those things would be part of the terminology service.

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, May 20, 2014 9:23 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

(Apologies all if you get multiple email from me. I was having trouble with the list serv.)

In some of the recent discussion of the interoperability layer community we though that it would be useful to normalise and validate the units
of clinical encounters along with their terminology. We wanted to check with this community if information about units is often stored in a the terminology service. It seems like it may be out of scope but we wanted to hear your opinion about this.

Are there any implementations that store units in the terminology service or are these often stored elsewhere?

Thanks,

Ryan

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile:**+27845829934 * | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org*

–

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 “Interoperability Layer (OpenHIE)” group.

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

openhie-interoperability-layer+unsubscribe@googlegroups.com.

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

–

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

–

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.

–

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.