The Role of the TR as the source of truth, and syncing against OpenMRS (POC / SHR) concept dictionaries

[Roger_Friedman]

I would like to hear more about where concept mapping occurs. Are we saying that the SHR and TS will support only a single terminology, or that it will handle multiple mapped terminologies? Are we saying that the POS will have to convert messages from its preferred terminology to and from a single terminology? Or is it the responsibility of the IL to convert from and to one of a number of accepted terminologies so that the SHR uses a single terminology but the POS can communicate in any of the accepted terminologies? Can we implement these capabilities in a staged manner and achieve them all?

I would rather not rely on the seemingly more centralized administration of the health care systems in the countries in which we work. Participation of NGOs, need to communicate data to international health organizations, weak central management, and the existence of a private sector are just a few of the reasons why a single terminology is unlikely to be achieved. Nor would I want to make a single terminology a prerequisite for using the HIE; the advantages of being able to handle information on which there is agreement as to terminology should not be lost due to the long timespans involved in achieving consensus and official approval of a 100% harmonized terminology. Concept mapping is much easier to achieve than consensus.

···

I believe we will be well-served by a core premise of our HIE – that we will not allow “strangers” on our network. This has an implication: a POS will need to go thru a conformance testing process before it will be “allowed” to exchange messages with our IL. This conformance testing process can, and should, include requirements regarding the appropriate use of terminologies. Paul is right… there may be times when a local code set is used. But that will ONLY happen when the HIE decides that it will support that local code set (and there may be expedient reasons to do this). It will, however, NEVER be the case that a POS will send whatever it wants and the IL and TS have to try to make sense of it as best they can.

Most of the jurisdictions we will be working in have a stronger ability to exert central control than is typically the case in the US system. We should expect that this control will enforce adherence to norms and standards that are operationalized by the national eHealth infrastructure (the HIE). I think we should also expect that this adherence will have been “proven” (thru mandatory conformance testing) before a POS ever sends its first message to our IL.

My $0.02…

DJ

On Monday, March 3, 2014 3:18:34 PM UTC-5, Jeremy Keiper wrote:

We see a standard of using enterprise-level IDs (e.g. ECID, ELID, etc) with the SHR, and believe the same should be done with terminology. We could say, for instance, that LOINC is our version of ETID, but is it? Paul Biondich’s reaction to that suggestion was that it would be a bad move to rely on something like LOINC as the enterprise identification of terminology for an entire HIE, and that the TS should be able to recognize “local” dictionaries (from a POC, for instance) and the IOL should be replacing terminology in the incoming message with enterprise identifiers before it gets to the SHR.

I agree that we have an implicit trust that the IOL has vetted any incoming terminology, and that it seems only right to populate the SHR’s concept dictionary with those terms, but how do we know the concepts from one POC don’t overlap concepts from another, unless we have some form of mapping? It seems the TS should be responsible for this, and the SHR should only need to understand one set of terms.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

On Mon, Mar 3, 2014 at 2:37 PM, Ryan Crichton ry...@jembi.org wrote:

Hi Suranga,

Thanks for bringing this up. With the SHR developments at the moment we have been considering creating concept as they are needed in the SHR. We would then not need to keep a complex concept dictionary in sync. We would trust the CDA messages that we received from the OpenHIM would be well formed and contain terminology that has been validated and/or normalised by the TS.

What do you think about this? Syncing with a POC system on the other hand is something we can discuss.

Cheers,

Ryan

On Mon, Mar 3, 2014 at 5:37 AM, Suranga Kasthurirathne suran...@gmail.com wrote:

Hi,

I’m writing this to open a discussion on the role of the TR as the source of truth for OpenHIE terminologies, and its role in syncing our OpenMRS based concept dictionaries.

At this point, requests sent to the SHR via the HIM are validated against the TR before being passed on.

However, if for some reason these concepts don’t exist in the SHR, an error is thrown. The SHR does NOT attempt to create the missing concepts (which are clearly valid, as they have been checked against the TR)

Plus, the current process to update the POC and SHR concept dictionaries against the TR are manual, and hence, it can be quite difficult to accomplish.

I’d like to propose the development of an OpenMRS module which can be triggered to communicate with the HIM/TR interface, and sync the POC / SHR concept dictionary by creating / updating based on the source of truth (TR).

Suranga

I would love to hear your comments on this topic. I’d also say that this sounds like an interesting GSOC project, with an appropriate scope / difficulty level to match.

Best Regards,

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.

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

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

E-mail: ry...@jembi.org

–

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.

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

-----Original Message-----

From: Derek Ritz

Sent: Mar 4, 2014 8:51 AM

To: ohie-architecture@googlegroups.com

Cc: Ryan Crichton , Suranga Kasthurirathne

Subject: Re: The Role of the TR as the source of truth, and syncing against OpenMRS (POC / SHR) concept dictionaries

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

[bobj]

I would like to hear more about where concept mapping occurs. Are we
saying that the SHR and TS will support only a single terminology, or that
it will handle multiple mapped terminologies? Are we saying that the POS
will have to convert messages from its preferred terminology to and from a
single terminology? Or is it the responsibility of the IL to convert from
and to one of a number of accepted terminologies so that the SHR uses a
single terminology but the POS can communicate in any of the accepted
terminologies? Can we implement these capabilities in a staged manner and
achieve them all?

I would rather not rely on the seemingly more centralized administration
of the health care systems in the countries in which we work.
Participation of NGOs, need to communicate data to international health
organizations, weak central management, and the existence of a private
sector are just a few of the reasons why a single terminology is unlikely
to be achieved. Nor would I want to make a single terminology a
prerequisite for using the HIE; the advantages of being able to handle
information on which there is agreement as to terminology should not be
lost due to the long timespans involved in achieving consensus and official
approval of a 100% harmonized terminology. Concept mapping is much easier
to achieve than consensus.

Roger you are spot on here!

···

On 4 March 2014 14:16, <r.friedman@mindspring.com> wrote:

-----Original Message-----
From: Derek Ritz
Sent: Mar 4, 2014 8:51 AM
To: ohie-architecture@googlegroups.com
Cc: Ryan Crichton , Suranga Kasthurirathne
Subject: Re: The Role of the TR as the source of truth, and syncing
against OpenMRS (POC / SHR) concept dictionaries

I believe we will be well-served by a core premise of our HIE -- that we
will not allow "strangers" on our network. This has an implication: a POS
will need to go thru a conformance testing process before it will be
"allowed" to exchange messages with our IL. This conformance testing
process can, and should, include requirements regarding the appropriate use
of terminologies. Paul is right... there may be times when a local code set
is used. But that will ONLY happen when the HIE decides that it will
support that local code set (and there may be expedient reasons to do
this). It will, however, NEVER be the case that a POS will send whatever it
wants and the IL and TS have to try to make sense of it as best they can.

Most of the jurisdictions we will be working in have a stronger ability to
exert central control than is typically the case in the US system. We
should expect that this control will enforce adherence to norms and
standards that are operationalized by the national eHealth infrastructure
(the HIE). I think we should also expect that this adherence will have been
"proven" (thru mandatory conformance testing) before a POS ever sends its
first message to our IL.

My $0.02...

DJ

On Monday, March 3, 2014 3:18:34 PM UTC-5, Jeremy Keiper wrote:

We see a standard of using enterprise-level IDs (e.g. ECID, ELID, etc)
with the SHR, and believe the same should be done with terminology. We
could say, for instance, that LOINC is our version of ETID, but is it?
Paul Biondich's reaction to that suggestion was that it would be a bad
move to rely on something like LOINC as the enterprise identification of
terminology for an entire HIE, and that the TS should be able to recognize
"local" dictionaries (from a POC, for instance) and the IOL should be
replacing terminology in the incoming message with enterprise identifiers
before it gets to the SHR.

I agree that we have an implicit trust that the IOL has vetted any
incoming terminology, and that it seems only right to populate the SHR's
concept dictionary with those terms, but how do we know the concepts from
one POC don't overlap concepts from another, unless we have some form of
mapping? It seems the TS should be responsible for this, and the SHR
should only need to understand one set of terms.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

On Mon, Mar 3, 2014 at 2:37 PM, Ryan Crichton <ry...@jembi.org> wrote:

Hi Suranga,

Thanks for bringing this up. With the SHR developments at the moment we
have been considering creating concept as they are needed in the SHR. We
would then not need to keep a complex concept dictionary in sync. We would
trust the CDA messages that we received from the OpenHIM would be well
formed and contain terminology that has been validated and/or normalised by
the TS.

What do you think about this? Syncing with a POC system on the other
hand is something we can discuss.

Cheers,
Ryan

On Mon, Mar 3, 2014 at 5:37 AM, Suranga Kasthurirathne < >>> suran...@gmail.com> wrote:

Hi,

I'm writing this to open a discussion on the role of the TR as the
source of truth for OpenHIE terminologies, and its role in syncing our
OpenMRS based concept dictionaries.
At this point, requests sent to the SHR via the HIM are validated
against the TR before being passed on.

However, if for some reason these concepts don't exist in the SHR, an
error is thrown. The SHR does NOT attempt to create the missing concepts
(which are clearly valid, as they have been checked against the TR)
Plus, the current process to update the POC and SHR concept
dictionaries against the TR are manual, and hence, it can be quite
difficult to accomplish.

I'd like to propose the development of an OpenMRS module which can be
triggered to communicate with the HIM/TR interface, and sync the POC / SHR
concept dictionary by creating / updating based on the source of truth (TR).

I would love to hear your comments on this topic. I'd also say that
this sounds like an interesting GSOC project, with an appropriate scope /
difficulty level to match.

--
Best Regards,
Suranga

--
You received this message because you are subscribed to the Google
Groups "OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ohie-architect...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org

--
You received this message because you are subscribed to the Google
Groups "OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ohie-architect...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

You received this message because you are subscribed to the Google Groups
"OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups
"OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[derek.ritz]

I also think Roger is spot on. But we differ re: the role of the central authority. I’d like to use Rwanda as an example. For the content stored in the HIE, the agreement was that ICD-10 would be used to code certain elements, LOINC would be used to code others and there is a “hovering” expectation that ICHI will eventually be used for interventions (and I don’t think we’re using anything right now for this… or if we are, it is likely CPT). I like this approach of leveraging existing terminologies that are well-suited to their purpose and well-understood by the users. I don’t think we should expect that these various coding systems will all be mapped to a single uber-terminology (it would likely have to be SNOMED-CT… and that is a monster I fear).

Could there be other terminologies that some POS systems are using; some NGO that is using ICD-9 or some private sector hospital that is using SNOMED? Sure there could be. But it would be the job of the TS to map these to the code sets and terminologies that Rwanda has specified for the HIE. That is the role of the central authority – to require that, when it is expedient, the TS will map codes from the wild to those that will be saved to the SHR – or to require that national codes be abided before transactions from the POS will be accepted by the HIE. It will undoubtably be a mix of both of these mechanisms, depending on the situation.

Re: the saving of the inbound message – yes, it should be logged. Just to be clear, in many Canadian jurisdictions, it is logged in the audit database in whatever form it was in when it was submitted (BEFORE it was massaged to map to ECIDs, EPIDs, cardinal terminologies, etc.). A subsequent retrieval of the content fetches the “standardized” version. If we are going to save the massaged document, as a document (CDA for example), we must be honest with ourselves that this massaged version might be unusable by the original submitter. If all they understand is ICD-9, sending them back the mapped ICD-10 codes may be of no value to them. There will need to be a lingua franca for this to work.

The concept of interoperability without change management is a siren song. As folks may recall, following a siren song leads to tears… and ruin. The HIE will not achieve interoperability between disparate systems if there is not some degree of consensus regarding codes, terminologies, message formats, etc. It cannot be otherwise.

···

On Tue, Mar 4, 2014 at 9:46 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On 4 March 2014 14:16, r.friedman@mindspring.com wrote:

I would like to hear more about where concept mapping occurs. Are we saying that the SHR and TS will support only a single terminology, or that it will handle multiple mapped terminologies? Are we saying that the POS will have to convert messages from its preferred terminology to and from a single terminology? Or is it the responsibility of the IL to convert from and to one of a number of accepted terminologies so that the SHR uses a single terminology but the POS can communicate in any of the accepted terminologies? Can we implement these capabilities in a staged manner and achieve them all?

I would rather not rely on the seemingly more centralized administration of the health care systems in the countries in which we work. Participation of NGOs, need to communicate data to international health organizations, weak central management, and the existence of a private sector are just a few of the reasons why a single terminology is unlikely to be achieved. Nor would I want to make a single terminology a prerequisite for using the HIE; the advantages of being able to handle information on which there is agreement as to terminology should not be lost due to the long timespans involved in achieving consensus and official approval of a 100% harmonized terminology. Concept mapping is much easier to achieve than consensus.

Roger you are spot on here!

-----Original Message-----

From: Derek Ritz

Sent: Mar 4, 2014 8:51 AM

To: ohie-architecture@googlegroups.com

Cc: Ryan Crichton , Suranga Kasthurirathne

Subject: Re: The Role of the TR as the source of truth, and syncing against OpenMRS (POC / SHR) concept dictionaries

I believe we will be well-served by a core premise of our HIE – that we will not allow “strangers” on our network. This has an implication: a POS will need to go thru a conformance testing process before it will be “allowed” to exchange messages with our IL. This conformance testing process can, and should, include requirements regarding the appropriate use of terminologies. Paul is right… there may be times when a local code set is used. But that will ONLY happen when the HIE decides that it will support that local code set (and there may be expedient reasons to do this). It will, however, NEVER be the case that a POS will send whatever it wants and the IL and TS have to try to make sense of it as best they can.

Most of the jurisdictions we will be working in have a stronger ability to exert central control than is typically the case in the US system. We should expect that this control will enforce adherence to norms and standards that are operationalized by the national eHealth infrastructure (the HIE). I think we should also expect that this adherence will have been “proven” (thru mandatory conformance testing) before a POS ever sends its first message to our IL.

My $0.02…

DJ

On Monday, March 3, 2014 3:18:34 PM UTC-5, Jeremy Keiper wrote:

We see a standard of using enterprise-level IDs (e.g. ECID, ELID, etc) with the SHR, and believe the same should be done with terminology. We could say, for instance, that LOINC is our version of ETID, but is it? Paul Biondich’s reaction to that suggestion was that it would be a bad move to rely on something like LOINC as the enterprise identification of terminology for an entire HIE, and that the TS should be able to recognize “local” dictionaries (from a POC, for instance) and the IOL should be replacing terminology in the incoming message with enterprise identifiers before it gets to the SHR.

I agree that we have an implicit trust that the IOL has vetted any incoming terminology, and that it seems only right to populate the SHR’s concept dictionary with those terms, but how do we know the concepts from one POC don’t overlap concepts from another, unless we have some form of mapping? It seems the TS should be responsible for this, and the SHR should only need to understand one set of terms.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

On Mon, Mar 3, 2014 at 2:37 PM, Ryan Crichton ry...@jembi.org wrote:

Hi Suranga,

Thanks for bringing this up. With the SHR developments at the moment we have been considering creating concept as they are needed in the SHR. We would then not need to keep a complex concept dictionary in sync. We would trust the CDA messages that we received from the OpenHIM would be well formed and contain terminology that has been validated and/or normalised by the TS.

What do you think about this? Syncing with a POC system on the other hand is something we can discuss.

Cheers,

Ryan

On Mon, Mar 3, 2014 at 5:37 AM, Suranga Kasthurirathne suran...@gmail.com wrote:

Hi,

I’m writing this to open a discussion on the role of the TR as the source of truth for OpenHIE terminologies, and its role in syncing our OpenMRS based concept dictionaries.

At this point, requests sent to the SHR via the HIM are validated against the TR before being passed on.

However, if for some reason these concepts don’t exist in the SHR, an error is thrown. The SHR does NOT attempt to create the missing concepts (which are clearly valid, as they have been checked against the TR)

Plus, the current process to update the POC and SHR concept dictionaries against the TR are manual, and hence, it can be quite difficult to accomplish.

I’d like to propose the development of an OpenMRS module which can be triggered to communicate with the HIM/TR interface, and sync the POC / SHR concept dictionary by creating / updating based on the source of truth (TR).

Suranga

I would love to hear your comments on this topic. I’d also say that this sounds like an interesting GSOC project, with an appropriate scope / difficulty level to match.

Best Regards,

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.

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

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

E-mail: ry...@jembi.org

–

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

[pbiondich]

Hi.

The terminology services community has wrestled with this issue, and I believe has a way forward here. I’d wait to hear from them before redesigning alternative solutions.

-Paul

···

On Tue, Mar 4, 2014 at 10:22 AM, Derek Ritz derek.ritz@gmail.com wrote:

I also think Roger is spot on. But we differ re: the role of the central authority. I’d like to use Rwanda as an example. For the content stored in the HIE, the agreement was that ICD-10 would be used to code certain elements, LOINC would be used to code others and there is a “hovering” expectation that ICHI will eventually be used for interventions (and I don’t think we’re using anything right now for this… or if we are, it is likely CPT). I like this approach of leveraging existing terminologies that are well-suited to their purpose and well-understood by the users. I don’t think we should expect that these various coding systems will all be mapped to a single uber-terminology (it would likely have to be SNOMED-CT… and that is a monster I fear).

Could there be other terminologies that some POS systems are using; some NGO that is using ICD-9 or some private sector hospital that is using SNOMED? Sure there could be. But it would be the job of the TS to map these to the code sets and terminologies that Rwanda has specified for the HIE. That is the role of the central authority – to require that, when it is expedient, the TS will map codes from the wild to those that will be saved to the SHR – or to require that national codes be abided before transactions from the POS will be accepted by the HIE. It will undoubtably be a mix of both of these mechanisms, depending on the situation.

Re: the saving of the inbound message – yes, it should be logged. Just to be clear, in many Canadian jurisdictions, it is logged in the audit database in whatever form it was in when it was submitted (BEFORE it was massaged to map to ECIDs, EPIDs, cardinal terminologies, etc.). A subsequent retrieval of the content fetches the “standardized” version. If we are going to save the massaged document, as a document (CDA for example), we must be honest with ourselves that this massaged version might be unusable by the original submitter. If all they understand is ICD-9, sending them back the mapped ICD-10 codes may be of no value to them. There will need to be a lingua franca for this to work.

The concept of interoperability without change management is a siren song. As folks may recall, following a siren song leads to tears… and ruin. The HIE will not achieve interoperability between disparate systems if there is not some degree of consensus regarding codes, terminologies, message formats, etc. It cannot be otherwise.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

On Tue, Mar 4, 2014 at 9:46 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

–

Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On 4 March 2014 14:16, r.friedman@mindspring.com wrote:

I would like to hear more about where concept mapping occurs. Are we saying that the SHR and TS will support only a single terminology, or that it will handle multiple mapped terminologies? Are we saying that the POS will have to convert messages from its preferred terminology to and from a single terminology? Or is it the responsibility of the IL to convert from and to one of a number of accepted terminologies so that the SHR uses a single terminology but the POS can communicate in any of the accepted terminologies? Can we implement these capabilities in a staged manner and achieve them all?

I would rather not rely on the seemingly more centralized administration of the health care systems in the countries in which we work. Participation of NGOs, need to communicate data to international health organizations, weak central management, and the existence of a private sector are just a few of the reasons why a single terminology is unlikely to be achieved. Nor would I want to make a single terminology a prerequisite for using the HIE; the advantages of being able to handle information on which there is agreement as to terminology should not be lost due to the long timespans involved in achieving consensus and official approval of a 100% harmonized terminology. Concept mapping is much easier to achieve than consensus.

Roger you are spot on here!

-----Original Message-----

From: Derek Ritz

Sent: Mar 4, 2014 8:51 AM

To: ohie-architecture@googlegroups.com

Cc: Ryan Crichton , Suranga Kasthurirathne

Subject: Re: The Role of the TR as the source of truth, and syncing against OpenMRS (POC / SHR) concept dictionaries

I believe we will be well-served by a core premise of our HIE – that we will not allow “strangers” on our network. This has an implication: a POS will need to go thru a conformance testing process before it will be “allowed” to exchange messages with our IL. This conformance testing process can, and should, include requirements regarding the appropriate use of terminologies. Paul is right… there may be times when a local code set is used. But that will ONLY happen when the HIE decides that it will support that local code set (and there may be expedient reasons to do this). It will, however, NEVER be the case that a POS will send whatever it wants and the IL and TS have to try to make sense of it as best they can.

Most of the jurisdictions we will be working in have a stronger ability to exert central control than is typically the case in the US system. We should expect that this control will enforce adherence to norms and standards that are operationalized by the national eHealth infrastructure (the HIE). I think we should also expect that this adherence will have been “proven” (thru mandatory conformance testing) before a POS ever sends its first message to our IL.

My $0.02…

DJ

On Monday, March 3, 2014 3:18:34 PM UTC-5, Jeremy Keiper wrote:

We see a standard of using enterprise-level IDs (e.g. ECID, ELID, etc) with the SHR, and believe the same should be done with terminology. We could say, for instance, that LOINC is our version of ETID, but is it? Paul Biondich’s reaction to that suggestion was that it would be a bad move to rely on something like LOINC as the enterprise identification of terminology for an entire HIE, and that the TS should be able to recognize “local” dictionaries (from a POC, for instance) and the IOL should be replacing terminology in the incoming message with enterprise identifiers before it gets to the SHR.

I agree that we have an implicit trust that the IOL has vetted any incoming terminology, and that it seems only right to populate the SHR’s concept dictionary with those terms, but how do we know the concepts from one POC don’t overlap concepts from another, unless we have some form of mapping? It seems the TS should be responsible for this, and the SHR should only need to understand one set of terms.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

On Mon, Mar 3, 2014 at 2:37 PM, Ryan Crichton ry...@jembi.org wrote:

Hi Suranga,

Thanks for bringing this up. With the SHR developments at the moment we have been considering creating concept as they are needed in the SHR. We would then not need to keep a complex concept dictionary in sync. We would trust the CDA messages that we received from the OpenHIM would be well formed and contain terminology that has been validated and/or normalised by the TS.

What do you think about this? Syncing with a POC system on the other hand is something we can discuss.

Cheers,

Ryan

On Mon, Mar 3, 2014 at 5:37 AM, Suranga Kasthurirathne suran...@gmail.com wrote:

Hi,

I’m writing this to open a discussion on the role of the TR as the source of truth for OpenHIE terminologies, and its role in syncing our OpenMRS based concept dictionaries.

At this point, requests sent to the SHR via the HIM are validated against the TR before being passed on.

However, if for some reason these concepts don’t exist in the SHR, an error is thrown. The SHR does NOT attempt to create the missing concepts (which are clearly valid, as they have been checked against the TR)

Plus, the current process to update the POC and SHR concept dictionaries against the TR are manual, and hence, it can be quite difficult to accomplish.

I’d like to propose the development of an OpenMRS module which can be triggered to communicate with the HIM/TR interface, and sync the POC / SHR concept dictionary by creating / updating based on the source of truth (TR).

Suranga

I would love to hear your comments on this topic. I’d also say that this sounds like an interesting GSOC project, with an appropriate scope / difficulty level to match.

Best Regards,

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.

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

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

E-mail: ry...@jembi.org

–

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

[Jeremy_Keiper1]

I am just trying to get to the bottom of what the responsibility is of the SHR to manage its own terminologies, and I really do not want the SHR to have two terms that should be mapped to one another, but are not because we did not get that from the TS. If the SHR should have at its disposal the terminology dictionary exactly matching the TS, and always be aware of updates to the TS, what is the point of involving the TS in the transactions if the SHR can make that judgment call itself? It makes sense to me, that the TS should be used as not only a vetting service (verifying the terminology coming from a POC), but also as a provider for enterprise level identification of those terms in a way that the SHR can either blindly accept or at least hold a single dictionary with that authority as its focus.

I do not think we would expect to use something like SNOMED-CT as the basis. Rather, I would expect an internal authority for that HIE to provide unique identifiers for each term, that can be mapped back into “appropriate” or “preferred” terms when leaving the SHR and heading back to a POC (based on that POC’s acceptable authorities, e.g. LOINC or SNOMED), or DHIS2, etc.

···

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

On Tue, Mar 4, 2014 at 10:22 AM, Derek Ritz derek.ritz@gmail.com wrote:

I also think Roger is spot on. But we differ re: the role of the central authority. I’d like to use Rwanda as an example. For the content stored in the HIE, the agreement was that ICD-10 would be used to code certain elements, LOINC would be used to code others and there is a “hovering” expectation that ICHI will eventually be used for interventions (and I don’t think we’re using anything right now for this… or if we are, it is likely CPT). I like this approach of leveraging existing terminologies that are well-suited to their purpose and well-understood by the users. I don’t think we should expect that these various coding systems will all be mapped to a single uber-terminology (it would likely have to be SNOMED-CT… and that is a monster I fear).

Could there be other terminologies that some POS systems are using; some NGO that is using ICD-9 or some private sector hospital that is using SNOMED? Sure there could be. But it would be the job of the TS to map these to the code sets and terminologies that Rwanda has specified for the HIE. That is the role of the central authority – to require that, when it is expedient, the TS will map codes from the wild to those that will be saved to the SHR – or to require that national codes be abided before transactions from the POS will be accepted by the HIE. It will undoubtably be a mix of both of these mechanisms, depending on the situation.

Re: the saving of the inbound message – yes, it should be logged. Just to be clear, in many Canadian jurisdictions, it is logged in the audit database in whatever form it was in when it was submitted (BEFORE it was massaged to map to ECIDs, EPIDs, cardinal terminologies, etc.). A subsequent retrieval of the content fetches the “standardized” version. If we are going to save the massaged document, as a document (CDA for example), we must be honest with ourselves that this massaged version might be unusable by the original submitter. If all they understand is ICD-9, sending them back the mapped ICD-10 codes may be of no value to them. There will need to be a lingua franca for this to work.

The concept of interoperability without change management is a siren song. As folks may recall, following a siren song leads to tears… and ruin. The HIE will not achieve interoperability between disparate systems if there is not some degree of consensus regarding codes, terminologies, message formats, etc. It cannot be otherwise.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

On Tue, Mar 4, 2014 at 9:46 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

–

Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On 4 March 2014 14:16, r.friedman@mindspring.com wrote:

I would like to hear more about where concept mapping occurs. Are we saying that the SHR and TS will support only a single terminology, or that it will handle multiple mapped terminologies? Are we saying that the POS will have to convert messages from its preferred terminology to and from a single terminology? Or is it the responsibility of the IL to convert from and to one of a number of accepted terminologies so that the SHR uses a single terminology but the POS can communicate in any of the accepted terminologies? Can we implement these capabilities in a staged manner and achieve them all?

I would rather not rely on the seemingly more centralized administration of the health care systems in the countries in which we work. Participation of NGOs, need to communicate data to international health organizations, weak central management, and the existence of a private sector are just a few of the reasons why a single terminology is unlikely to be achieved. Nor would I want to make a single terminology a prerequisite for using the HIE; the advantages of being able to handle information on which there is agreement as to terminology should not be lost due to the long timespans involved in achieving consensus and official approval of a 100% harmonized terminology. Concept mapping is much easier to achieve than consensus.

Roger you are spot on here!

-----Original Message-----

From: Derek Ritz

Sent: Mar 4, 2014 8:51 AM

To: ohie-architecture@googlegroups.com

Cc: Ryan Crichton , Suranga Kasthurirathne

Subject: Re: The Role of the TR as the source of truth, and syncing against OpenMRS (POC / SHR) concept dictionaries

I believe we will be well-served by a core premise of our HIE – that we will not allow “strangers” on our network. This has an implication: a POS will need to go thru a conformance testing process before it will be “allowed” to exchange messages with our IL. This conformance testing process can, and should, include requirements regarding the appropriate use of terminologies. Paul is right… there may be times when a local code set is used. But that will ONLY happen when the HIE decides that it will support that local code set (and there may be expedient reasons to do this). It will, however, NEVER be the case that a POS will send whatever it wants and the IL and TS have to try to make sense of it as best they can.

Most of the jurisdictions we will be working in have a stronger ability to exert central control than is typically the case in the US system. We should expect that this control will enforce adherence to norms and standards that are operationalized by the national eHealth infrastructure (the HIE). I think we should also expect that this adherence will have been “proven” (thru mandatory conformance testing) before a POS ever sends its first message to our IL.

My $0.02…

DJ

On Monday, March 3, 2014 3:18:34 PM UTC-5, Jeremy Keiper wrote:

We see a standard of using enterprise-level IDs (e.g. ECID, ELID, etc) with the SHR, and believe the same should be done with terminology. We could say, for instance, that LOINC is our version of ETID, but is it? Paul Biondich’s reaction to that suggestion was that it would be a bad move to rely on something like LOINC as the enterprise identification of terminology for an entire HIE, and that the TS should be able to recognize “local” dictionaries (from a POC, for instance) and the IOL should be replacing terminology in the incoming message with enterprise identifiers before it gets to the SHR.

I agree that we have an implicit trust that the IOL has vetted any incoming terminology, and that it seems only right to populate the SHR’s concept dictionary with those terms, but how do we know the concepts from one POC don’t overlap concepts from another, unless we have some form of mapping? It seems the TS should be responsible for this, and the SHR should only need to understand one set of terms.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

On Mon, Mar 3, 2014 at 2:37 PM, Ryan Crichton ry...@jembi.org wrote:

Hi Suranga,

Thanks for bringing this up. With the SHR developments at the moment we have been considering creating concept as they are needed in the SHR. We would then not need to keep a complex concept dictionary in sync. We would trust the CDA messages that we received from the OpenHIM would be well formed and contain terminology that has been validated and/or normalised by the TS.

What do you think about this? Syncing with a POC system on the other hand is something we can discuss.

Cheers,

Ryan

On Mon, Mar 3, 2014 at 5:37 AM, Suranga Kasthurirathne suran...@gmail.com wrote:

Hi,

I’m writing this to open a discussion on the role of the TR as the source of truth for OpenHIE terminologies, and its role in syncing our OpenMRS based concept dictionaries.

At this point, requests sent to the SHR via the HIM are validated against the TR before being passed on.

However, if for some reason these concepts don’t exist in the SHR, an error is thrown. The SHR does NOT attempt to create the missing concepts (which are clearly valid, as they have been checked against the TR)

Plus, the current process to update the POC and SHR concept dictionaries against the TR are manual, and hence, it can be quite difficult to accomplish.

I’d like to propose the development of an OpenMRS module which can be triggered to communicate with the HIM/TR interface, and sync the POC / SHR concept dictionary by creating / updating based on the source of truth (TR).

Suranga

I would love to hear your comments on this topic. I’d also say that this sounds like an interesting GSOC project, with an appropriate scope / difficulty level to match.

Best Regards,

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.

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

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

E-mail: ry...@jembi.org

–

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

[jack.bowie]

Speaking on behalf of the TS community, I shudder to think about an HIE authority defining, much less maintaining, yet another terminology model (enterprise identifiers). I would suggest that the authority specify which standard Reference Terminologies (SNOMED LOINC, ICD-10, etc.) are to be used for each content domain: lab results, procedures, etc. Then the IL manages the “translation” of incoming messages by extracting coded entries from the message and
querying the TS to either (1) validate incoming Reference Terminology codes, or (2) translate incoming Interface Terminology codes to the authorized enterprise standard Reference Terminology code. Note that step 2 requires that the appropriate interface->reference mappings have previously been developed. This map development is an “off-line”, set-up activity that must be provided (and maintained on an ongoing-basis) by the authority (or designee, sometimes a “commercial” Interface Terminology comes with Reference mappings and HIE authority intervention is not required). Incoming codes without existing maps (which will always occur) should fire “alerts” to a background process for subsequent remediation. One common process question is whether the offending transaction should be passed on without standard codes or queued for future processing when the mappings have been resolved.

Addressing one of the other points, our recommendation is that the IL ADD reference/standardized codes to the incoming message, not REPLACE interface/local codes with reference codes. This maintains clinical integrity.

Jack

[Jeremy_Keiper1]

Jack, thank you for your perspective, as I think we really should have started with yours from the beginning.

The question in this thread that most interests me is not necessarily how the codes are represented but how the SHR is meant to understand when one code is mapped to another. Should the SHR be asking the TS (via the IL) for mappings whenever it receives a new-to-the-SHR code, and are we saying this should happen asynchronously? Would it be better for the TS to send any updated codes and mappings out ahead of time so we can guarantee the SHR is up to date? I understand mappings can be complex, as we’ve modeled a hierarchy of relationships for concept mappings in OpenMRS, so I’m eager to see how you understand the interaction between the TS and SHR should be handled.

Thanks again!

···

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

On Fri, Mar 7, 2014 at 10:53 AM, Jack Bowie jack.bowie@gmail.com wrote:

Speaking on behalf of the TS community, I shudder to think about an HIE authority defining, much less maintaining, yet another terminology model (enterprise identifiers). I would suggest that the authority specify which standard Reference Terminologies (SNOMED LOINC, ICD-10, etc.) are to be used for each content domain: lab results, procedures, etc. Then the IL manages the “translation” of incoming messages by extracting coded entries from the message and
querying the TS to either (1) validate incoming Reference Terminology codes, or (2) translate incoming Interface Terminology codes to the authorized enterprise standard Reference Terminology code. Note that step 2 requires that the appropriate interface->reference mappings have previously been developed. This map development is an “off-line”, set-up activity that must be provided (and maintained on an ongoing-basis) by the authority (or designee, sometimes a “commercial” Interface Terminology comes with Reference mappings and HIE authority intervention is not required). Incoming codes without existing maps (which will always occur) should fire “alerts” to a background process for subsequent remediation. One common process question is whether the offending transaction should be passed on without standard codes or queued for future processing when the mappings have been resolved.

Addressing one of the other points, our recommendation is that the IL ADD reference/standardized codes to the incoming message, not REPLACE interface/local codes with reference codes. This maintains clinical integrity.

Jack

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

[jack.bowie]

Jeremy, unfortunately I’m not that knowledgeable with the internal workings of the IL and SHR. My simplistic view is that the IL is the “interface engine” that takes potentially ill-structured, uncodified messages and normalizes them (both structurally and semantically) for standardized processing (inputting) in the SHR. For ongoing reporting and decision support activities, the SHR should only work with the standardized codes. The local codes just get “carried along” for potential subsequent use (re-display) in edge applications.

Now there is a (primarily performance-related) consideration as to whether the IL actually queries the TS in real-time or maintains an internal table of the mappings (from the TS). This is an architectural decision. IMHO, the TS is required as a central “source of truth” for terminological artifacts. There must be a component (the TS) whose responsibility is to maintain the versions of terminology artifacts (code systems, mappings, etc.) and can provide the associated content-specific management tools, but the actual artifacts can always be distributed to consuming applications as required for throughput or other architectural issues (for example, use of an existing interface engine that only supports mapping “tables”). The artifact “snapshots” can be distributed (push or pull?) hourly, daily, weekly or whatever depending on HIE policy.

[Jeremy_Keiper1]

Thanks, Jack. I assume the TS maintains mappings of local codes to “official” codes. Are those mappings based on certain relationship types (e.g. IS_A, NARROWER_THAN, etc)? Does it make sense for an SHR to request those mappings, or can they be somehow embedded in the forwarded message by the IL based on a response from the TS? These are the things that would keep us from maintaining a dictionary in the SHR that is out of sync with the TS.

···

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support

On Fri, Mar 7, 2014 at 11:22 AM, Jack Bowie jack.bowie@gmail.com wrote:

Jeremy, unfortunately I’m not that knowledgeable with the internal workings of the IL and SHR. My simplistic view is that the IL is the “interface engine” that takes potentially ill-structured, uncodified messages and normalizes them (both structurally and semantically) for standardized processing (inputting) in the SHR. For ongoing reporting and decision support activities, the SHR should only work with the standardized codes. The local codes just get “carried along” for potential subsequent use (re-display) in edge applications.

Now there is a (primarily performance-related) consideration as to whether the IL actually queries the TS in real-time or maintains an internal table of the mappings (from the TS). This is an architectural decision. IMHO, the TS is required as a central “source of truth” for terminological artifacts. There must be a component (the TS) whose responsibility is to maintain the versions of terminology artifacts (code systems, mappings, etc.) and can provide the associated content-specific management tools, but the actual artifacts can always be distributed to consuming applications as required for throughput or other architectural issues (for example, use of an existing interface engine that only supports mapping “tables”). The artifact “snapshots” can be distributed (push or pull?) hourly, daily, weekly or whatever depending on HIE policy.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

[jack.bowie]

The TS supports mappings between any two terminologies. And a Reference Terminology could be a terminology defined by the HIE authority. What is an Interface and what is a Reference Terminology is a policy (not technical) decision.

The semantics of a mapping are generally use-case dependent. And there can potentially be many mappings between the same two terminologies: one for reimbursement purposes and one for public health reporting, for example. As a couple other examples, SNOMED CT’s SNOMED to ICD-9 mapping adds a qualifier on the single “SNOMED CT to ICD-9 Map” association type of “Narrow to Broad”, “Broad to Narrow”, “Exact”, etc., to provide additional information. But the SNOMED to ICD-10 mapping is “rule-based”: there are multiple “associations” and the correct one is dependent on context (the other codes in the clinical encounter). Mappings can be one-to-one, one-to-many or many-to-one.

I’m afraid that “mapping” is a very complex topic and can only be adequately addressed by understanding the specific use-cases that are to be supported by the SHR (IL). There are simply too many variables in the general case. From an interface engine point of view, one usually just tries to find “single best match” (one-to-one) and leave it at that. How are you looking to use a “mapping” in the SHR? Have you defined the use-cases that are to be supported?

[derek.ritz]

ooops… replied only to Jack… fwd’ing to architecture group…

···

On Fri, Mar 7, 2014 at 1:20 PM, Jack Bowie jack.bowie@gmail.com wrote:

The TS supports mappings between any two terminologies. And a Reference Terminology could be a terminology defined by the HIE authority. What is an Interface and what is a Reference Terminology is a policy (not technical) decision.

The semantics of a mapping are generally use-case dependent. And there can potentially be many mappings between the same two terminologies: one for reimbursement purposes and one for public health reporting, for example. As a couple other examples, SNOMED CT’s SNOMED to ICD-9 mapping adds a qualifier on the single “SNOMED CT to ICD-9 Map” association type of “Narrow to Broad”, “Broad to Narrow”, “Exact”, etc., to provide additional information. But the SNOMED to ICD-10 mapping is “rule-based”: there are multiple “associations” and the correct one is dependent on context (the other codes in the clinical encounter). Mappings can be one-to-one, one-to-many or many-to-one.

I’m afraid that “mapping” is a very complex topic and can only be adequately addressed by understanding the specific use-cases that are to be supported by the SHR (IL). There are simply too many variables in the general case. From an interface engine point of view, one usually just tries to find “single best match” (one-to-one) and leave it at that. How are you looking to use a “mapping” in the SHR? Have you defined the use-cases that are to be supported?

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[ryan]

Hi all,

Great discussion here. Here is my point of view:

I believe that the SHR should be ‘dumb’, it doesn’t have to know much about terminology. Its job is to store information that is send and to regurgitate information when it is asked. The IL has the responsibility of providing the SHR with information in the canonical form, which includes terminology. So, the IL should be responsible for validating terminology and querying about the mapping of terminology that comes from the clinical content that it receives. It should replace any terminology that is not in the canonical (standardised) form with canonical terminology that is retrieved from a query to the TS. This will free the SHR of the complexity of knowing anything about TS or how to map terminology. When clinical content is queried from the SHR, the IL could again replace the canonical terminology with the local terminology by querying the TS.

As a separate point, I am left wondering how this approach fit in with our decisions to use IHE patient care coordination profiles of CDA. In these profiles the particular terminology is pre-specified and fixed (as far as I know). Are we saying that it is possible that a PoC application can send us messages/documents that don’t conform to these profiles? From previous discussions we have talked about supporting, say HL7v2, from the PoC. Are these the instances where we would be required to do terminology mapping in order to transform the received message into a profiled CDA document that we are expecting? Otherwise, if we are receiving profiled CDA documents then would we just need to perform validation of the terminology used?

Cheers,

Ryan

···

On Fri, Mar 7, 2014 at 8:37 PM, Derek Ritz derek.ritz@gmail.com wrote:

ooops… replied only to Jack… fwd’ing to architecture group…

---------- Forwarded message ----------
From: Derek Ritz derek.ritz@gmail.com

Date: Fri, Mar 7, 2014 at 1:36 PM
Subject: Re: The Role of the TR as the source of truth, and syncing against OpenMRS (POC / SHR) concept dictionaries

To: Jack Bowie jack.bowie@gmail.com

Hi all.

I worry that we might be getting a bit wrapped around the axle because we’re using an EMR as our SHR. Some of these terminology or concept-mapping issues are a “don’t care” in terms of the requirements for a shared health record repository that faithfully stores and fetches what was sent to it. I think it would be informing for us to ask the question: what if we substituted shared health record repository product “x” in place of OpenMRS? We might find that we’re over-engineering; we may be trying to replicate in our SHR work that will have already been done upstream by the IL+TS interactions.

Just a thought…

DJ

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+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

On Fri, Mar 7, 2014 at 1:20 PM, Jack Bowie jack.bowie@gmail.com wrote:

The TS supports mappings between any two terminologies. And a Reference Terminology could be a terminology defined by the HIE authority. What is an Interface and what is a Reference Terminology is a policy (not technical) decision.

The semantics of a mapping are generally use-case dependent. And there can potentially be many mappings between the same two terminologies: one for reimbursement purposes and one for public health reporting, for example. As a couple other examples, SNOMED CT’s SNOMED to ICD-9 mapping adds a qualifier on the single “SNOMED CT to ICD-9 Map” association type of “Narrow to Broad”, “Broad to Narrow”, “Exact”, etc., to provide additional information. But the SNOMED to ICD-10 mapping is “rule-based”: there are multiple “associations” and the correct one is dependent on context (the other codes in the clinical encounter). Mappings can be one-to-one, one-to-many or many-to-one.

I’m afraid that “mapping” is a very complex topic and can only be adequately addressed by understanding the specific use-cases that are to be supported by the SHR (IL). There are simply too many variables in the general case. From an interface engine point of view, one usually just tries to find “single best match” (one-to-one) and leave it at that. How are you looking to use a “mapping” in the SHR? Have you defined the use-cases that are to be supported?

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

[derek.ritz]

Hi all.
Ryan – you’ve made some really good points. There are some clarifications which might be helpful, tho. For one – I think Jack has made an excellent suggestion re: the “normalisation” of the coding. We should add to (but not replace) the codes which are present. This is important from a clarity/safety point of view. Whatever was originally SENT by the clinician should be maintained in the document. The adding of TS-mapped codes will augment this original content. It also helps us that, if this document is subsequently retrieved (including cases where it is later fetched by the sender), the original codes are still there and our mapped ones are included in addition to those.
RE: the specifications in the IHE’s profiled CDAs – it is helpful to look at an example…
IHE’s antepartum (APS/APHP etc.) profile document is attached. Starting on page 27, and following, it describes the content that must be in an antepartum summary (APS) document. This lists the template sections that are required, required if known, and optional. All the templates have template IDs, and there are definitions for these templates. For these defined templates, quite heavy use is made of LOINC-defined codes. To see how this is spec’d, we can drill down on template 1.3.6.1.4.1.19376.1.5.3.1.1.11.2, which is the antepartum summary template.
The IHE wiki for the APS template is here: http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.11.2. It lists the sections that must be in the APS… and these, in turn, have templates. We can drill down on the antepartum visit flowsheet template (1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.2) to see the specifics of what is to be collected and how it is represented. The wiki page for that template is found here: http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.2. This flowsheet can include simple observations, or a panel (which is just a collection of simple observations). You guessed it, there is a template for each of these. If we look at the template for the panel (found here: http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.11.2.3.2) we get to the heart of what specific observations are to be collected and how they are to be coded. This panel is based on the US ACOG-specified standard of care – and it is here, for example, that a national implementing body would specify what THEIR standard panel is as a country extension to the IHE profile (which is completely allowed and supported by the standard and is even recorded by IHE in a section 4 of the profile dedicated to country extensions/modifications).

As an example, tho, this is what the antepartum visit panel includes in the existing profile for APS (first 5 lines)…

LOINC Code
displayName
xsi:type
units
value set
11884-4
GESTATIONAL AGE-TIME-PT-^FETUS-QN-CLINICAL.ESTIMATED
PQ
week

11881-0
FUNDAL HEIGHT-LEN-PT-UTERUS-QN-TAPE MEASURE
PQ
cm

11876-0 (by PE)
or
11877-8 (by US)
FETAL PRESENTATION-TYPE-PT-PELVIS-NOM-PALPATION
or
FETAL PRESENTATION-TYPE-PT-PELVIS-NOM-US
CD

SNOMED CT
Vertex (70028003)
Breech (6096002)
Transverse (73161006)
Oblique (63750008)
Compound (124736009)
Brow (8014007)
Face (21882006)
11948-7
or
(xx-fetal-hr-ausc)
HEART RATE-NRAT-PT-^FETUS-QN-US.MEASURED
or
HEART RATE-NRAT-PT-^FETUS-QN-AUSCULTATION
PQ
/min

(xx-fetal-movement)
MOVEMENT-FIND-PT-^FETUS-ORD-PATIENT REPORTED
CO

SNOMED CT
fetal movement activity (finding) CID 364755008

baby kicks a lot (finding) CID 276368003

baby not moving (finding) CID 276370007

reduced fetal movement (finding) CID 276369006

fetal movements present (finding) CID 289431008

fetal movements felt (finding) CID 268470003

fetal movements seen (finding) CID 169731002

For each of these, the LOINC code is spec’d (indicating what is being observed), the data type is spec’d (in HL7v3 terms, since this is a CDA), and the units of measure for the observation is spec’d (for a number of these, ACOG specifies that SNOMED-CT is to be used for the coding – although this can be modified as a country extension).

Here is where I’m going with this: in order to achieve interoperability between disparate POS systems, the content and coding need to be “nailed down”. This nailing down, at the document level, is accomplished by the by the IHE profiles. IHE’s expectation is that an APS (for example) is a sharable document and that everyone who looks at it must be able to know what it says – in both human terms and in computable (semantically interoperable) terms.

To be conformant with an IHE profile – a POS must be able to send the profile-conformant document to the HIE. It seems we are dancing around the idea that we will support POS applications who are not able to send profile-conformant documents to the HIE, but that we will turn them into conformant documents when they arrive there. My understanding is that this is somewhat the case of Indiana’s HIE; great (and expensive) effort is put into developing the interface for each new hospital so that the “whatever it sends” can be turned into the “what the HIE needs”. We will no-doubt find that this is expedient to do in some exceptional cases (huge hospital networks with legacy applications), but for it to be rule would be disastrous, in my view. It is a fundamentally different premise to do interoperability-at-the-POS vs. interoperability-in-the-middle. The latter appears to be “easier”… unless, of course, you want to go to scale.

At scale, there is absolutely no way to take the “whatever you can send me” from 4000 clinics in TZ and expect to figure it out at the IL before sending it on its way toward the SHR. There simply isn’t enough time/money to successfully do it that way. To achieve health system-scale interoperability, POSs will need to send profile-conformant content. There are important and useful ways we can help them to do that (open source components/tools and readily-adoptable facades) but there is no way to avoid it altogether thru sheer brute effort on the HIE side.

We will be well served, I think, by turning some of our attention to how we will help hundreds, maybe thousands, of POS applications become profile-conformant. That is a big part of the logic behind adopting IHE in the first place: it has an “infrastructure” (tools, conformance-testing suites, etc.) to help enable this to happen. We are getting first-hand experience on how easy or hard this is as we work to make OpenMRS profile-conformant (as a POS… altho our present focus is on the SHR side). It is good that we are documenting our tribulations on this journey… it is one many other POSs will also need to take.

That’s my $0.02… well… maybe $0.04 (it was a bit “heavy” at the end there…)…

Warmest regards,

Derek.

···

On Wednesday, March 12, 2014 4:49:56 AM UTC-4, Ryan Crichton wrote:

Hi all,

Great discussion here. Here is my point of view:

I believe that the SHR should be ‘dumb’, it doesn’t have to know much about terminology. Its job is to store information that is send and to regurgitate information when it is asked. The IL has the responsibility of providing the SHR with information in the canonical form, which includes terminology. So, the IL should be responsible for validating terminology and querying about the mapping of terminology that comes from the clinical content that it receives. It should replace any terminology that is not in the canonical (standardised) form with canonical terminology that is retrieved from a query to the TS. This will free the SHR of the complexity of knowing anything about TS or how to map terminology. When clinical content is queried from the SHR, the IL could again replace the canonical terminology with the local terminology by querying the TS.

As a separate point, I am left wondering how this approach fit in with our decisions to use IHE patient care coordination profiles of CDA. In these profiles the particular terminology is pre-specified and fixed (as far as I know). Are we saying that it is possible that a PoC application can send us messages/documents that don’t conform to these profiles? From previous discussions we have talked about supporting, say HL7v2, from the PoC. Are these the instances where we would be required to do terminology mapping in order to transform the received message into a profiled CDA document that we are expecting? Otherwise, if we are receiving profiled CDA documents then would we just need to perform validation of the terminology used?

Cheers,

Ryan

On Fri, Mar 7, 2014 at 8:37 PM, Derek Ritz derek...@gmail.com wrote:

ooops… replied only to Jack… fwd’ing to architecture group…

---------- Forwarded message ----------
From: Derek Ritz derek...@gmail.com

Date: Fri, Mar 7, 2014 at 1:36 PM
Subject: Re: The Role of the TR as the source of truth, and syncing against OpenMRS (POC / SHR) concept dictionaries

To: Jack Bowie jack....@gmail.com

Hi all.

I worry that we might be getting a bit wrapped around the axle because we’re using an EMR as our SHR. Some of these terminology or concept-mapping issues are a “don’t care” in terms of the requirements for a shared health record repository that faithfully stores and fetches what was sent to it. I think it would be informing for us to ask the question: what if we substituted shared health record repository product “x” in place of OpenMRS? We might find that we’re over-engineering; we may be trying to replicate in our SHR work that will have already been done upstream by the IL+TS interactions.

Just a thought…

DJ

On Fri, Mar 7, 2014 at 1:20 PM, Jack Bowie jack....@gmail.com wrote:

The TS supports mappings between any two terminologies. And a Reference Terminology could be a terminology defined by the HIE authority. What is an Interface and what is a Reference Terminology is a policy (not technical) decision.

The semantics of a mapping are generally use-case dependent. And there can potentially be many mappings between the same two terminologies: one for reimbursement purposes and one for public health reporting, for example. As a couple other examples, SNOMED CT’s SNOMED to ICD-9 mapping adds a qualifier on the single “SNOMED CT to ICD-9 Map” association type of “Narrow to Broad”, “Broad to Narrow”, “Exact”, etc., to provide additional information. But the SNOMED to ICD-10 mapping is “rule-based”: there are multiple “associations” and the correct one is dependent on context (the other codes in the clinical encounter). Mappings can be one-to-one, one-to-many or many-to-one.

I’m afraid that “mapping” is a very complex topic and can only be adequately addressed by understanding the specific use-cases that are to be supported by the SHR (IL). There are simply too many variables in the general case. From an interface engine point of view, one usually just tries to find “single best match” (one-to-one) and leave it at that. How are you looking to use a “mapping” in the SHR? Have you defined the use-cases that are to be supported?

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@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: ry...@jembi.org

[derek.ritz]

Ooops… forgot to attach the APS profile document… here it is.

IHE_PCC_Suppl_AntepartumProfiles_Rev1-2_TI_2011-09-09.pdf (463 KB)

···

On Wednesday, March 12, 2014 8:21:29 AM UTC-4, Derek Ritz wrote:

Hi all.
Ryan – you’ve made some really good points. There are some clarifications which might be helpful, tho. For one – I think Jack has made an excellent suggestion re: the “normalisation” of the coding. We should add to (but not replace) the codes which are present. This is important from a clarity/safety point of view. Whatever was originally SENT by the clinician should be maintained in the document. The adding of TS-mapped codes will augment this original content. It also helps us that, if this document is subsequently retrieved (including cases where it is later fetched by the sender), the original codes are still there and our mapped ones are included in addition to those.
RE: the specifications in the IHE’s profiled CDAs – it is helpful to look at an example…
IHE’s antepartum (APS/APHP etc.) profile document is attached. Starting on page 27, and following, it describes the content that must be in an antepartum summary (APS) document. This lists the template sections that are required, required if known, and optional. All the templates have template IDs, and there are definitions for these templates. For these defined templates, quite heavy use is made of LOINC-defined codes. To see how this is spec’d, we can drill down on template 1.3.6.1.4.1.19376.1.5.3.1.1.11.2, which is the antepartum summary template.
The IHE wiki for the APS template is here: http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.11.2. It lists the sections that must be in the APS… and these, in turn, have templates. We can drill down on the antepartum visit flowsheet template (1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.2) to see the specifics of what is to be collected and how it is represented. The wiki page for that template is found here: http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.2. This flowsheet can include simple observations, or a panel (which is just a collection of simple observations). You guessed it, there is a template for each of these. If we look at the template for the panel (found here: http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.11.2.3.2) we get to the heart of what specific observations are to be collected and how they are to be coded. This panel is based on the US ACOG-specified standard of care – and it is here, for example, that a national implementing body would specify what THEIR standard panel is as a country extension to the IHE profile (which is completely allowed and supported by the standard and is even recorded by IHE in a section 4 of the profile dedicated to country extensions/modifications).

As an example, tho, this is what the antepartum visit panel includes in the existing profile for APS (first 5 lines)…

LOINC Code
displayName
xsi:type
units
value set
11884-4
GESTATIONAL AGE-TIME-PT-^FETUS-QN-CLINICAL.ESTIMATED
PQ
week

11881-0
FUNDAL HEIGHT-LEN-PT-UTERUS-QN-TAPE MEASURE
PQ
cm

11876-0 (by PE)
or
11877-8 (by US)
FETAL PRESENTATION-TYPE-PT-PELVIS-NOM-PALPATION
or
FETAL PRESENTATION-TYPE-PT-PELVIS-NOM-US
CD

SNOMED CT
Vertex (70028003)
Breech (6096002)
Transverse (73161006)
Oblique (63750008)
Compound (124736009)
Brow (8014007)
Face (21882006)
11948-7
or
(xx-fetal-hr-ausc)
HEART RATE-NRAT-PT-^FETUS-QN-US.MEASURED
or
HEART RATE-NRAT-PT-^FETUS-QN-AUSCULTATION
PQ
/min

(xx-fetal-movement)
MOVEMENT-FIND-PT-^FETUS-ORD-PATIENT REPORTED
CO

SNOMED CT
fetal movement activity (finding) CID 364755008

baby kicks a lot (finding) CID 276368003

baby not moving (finding) CID 276370007

reduced fetal movement (finding) CID 276369006

fetal movements present (finding) CID 289431008

fetal movements felt (finding) CID 268470003

fetal movements seen (finding) CID 169731002

Hi all,

Great discussion here. Here is my point of view:

I believe that the SHR should be ‘dumb’, it doesn’t have to know much about terminology. Its job is to store information that is send and to regurgitate information when it is asked. The IL has the responsibility of providing the SHR with information in the canonical form, which includes terminology. So, the IL should be responsible for validating terminology and querying about the mapping of terminology that comes from the clinical content that it receives. It should replace any terminology that is not in the canonical (standardised) form with canonical terminology that is retrieved from a query to the TS. This will free the SHR of the complexity of knowing anything about TS or how to map terminology. When clinical content is queried from the SHR, the IL could again replace the canonical terminology with the local terminology by querying the TS.

As a separate point, I am left wondering how this approach fit in with our decisions to use IHE patient care coordination profiles of CDA. In these profiles the particular terminology is pre-specified and fixed (as far as I know). Are we saying that it is possible that a PoC application can send us messages/documents that don’t conform to these profiles? From previous discussions we have talked about supporting, say HL7v2, from the PoC. Are these the instances where we would be required to do terminology mapping in order to transform the received message into a profiled CDA document that we are expecting? Otherwise, if we are receiving profiled CDA documents then would we just need to perform validation of the terminology used?

Cheers,

Ryan

On Fri, Mar 7, 2014 at 8:37 PM, Derek Ritz derek...@gmail.com wrote:

ooops… replied only to Jack… fwd’ing to architecture group…

---------- Forwarded message ----------
From: Derek Ritz derek...@gmail.com

Date: Fri, Mar 7, 2014 at 1:36 PM
Subject: Re: The Role of the TR as the source of truth, and syncing against OpenMRS (POC / SHR) concept dictionaries

To: Jack Bowie jack....@gmail.com

Hi all.

I worry that we might be getting a bit wrapped around the axle because we’re using an EMR as our SHR. Some of these terminology or concept-mapping issues are a “don’t care” in terms of the requirements for a shared health record repository that faithfully stores and fetches what was sent to it. I think it would be informing for us to ask the question: what if we substituted shared health record repository product “x” in place of OpenMRS? We might find that we’re over-engineering; we may be trying to replicate in our SHR work that will have already been done upstream by the IL+TS interactions.

Just a thought…

DJ

On Fri, Mar 7, 2014 at 1:20 PM, Jack Bowie jack....@gmail.com wrote:

The TS supports mappings between any two terminologies. And a Reference Terminology could be a terminology defined by the HIE authority. What is an Interface and what is a Reference Terminology is a policy (not technical) decision.

The semantics of a mapping are generally use-case dependent. And there can potentially be many mappings between the same two terminologies: one for reimbursement purposes and one for public health reporting, for example. As a couple other examples, SNOMED CT’s SNOMED to ICD-9 mapping adds a qualifier on the single “SNOMED CT to ICD-9 Map” association type of “Narrow to Broad”, “Broad to Narrow”, “Exact”, etc., to provide additional information. But the SNOMED to ICD-10 mapping is “rule-based”: there are multiple “associations” and the correct one is dependent on context (the other codes in the clinical encounter). Mappings can be one-to-one, one-to-many or many-to-one.

I’m afraid that “mapping” is a very complex topic and can only be adequately addressed by understanding the specific use-cases that are to be supported by the SHR (IL). There are simply too many variables in the general case. From an interface engine point of view, one usually just tries to find “single best match” (one-to-one) and leave it at that. How are you looking to use a “mapping” in the SHR? Have you defined the use-cases that are to be supported?

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@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: ry...@jembi.org

For each of these, the LOINC code is spec’d (indicating what is being observed), the data type is spec’d (in HL7v3 terms, since this is a CDA), and the units of measure for the observation is spec’d (for a number of these, ACOG specifies that SNOMED-CT is to be used for the coding – although this can be modified as a country extension).

Here is where I’m going with this: in order to achieve interoperability between disparate POS systems, the content and coding need to be “nailed down”. This nailing down, at the document level, is accomplished by the by the IHE profiles. IHE’s expectation is that an APS (for example) is a sharable document and that everyone who looks at it must be able to know what it says – in both human terms and in computable (semantically interoperable) terms.

To be conformant with an IHE profile – a POS must be able to send the profile-conformant document to the HIE. It seems we are dancing around the idea that we will support POS applications who are not able to send profile-conformant documents to the HIE, but that we will turn them into conformant documents when they arrive there. My understanding is that this is somewhat the case of Indiana’s HIE; great (and expensive) effort is put into developing the interface for each new hospital so that the “whatever it sends” can be turned into the “what the HIE needs”. We will no-doubt find that this is expedient to do in some exceptional cases (huge hospital networks with legacy applications), but for it to be rule would be disastrous, in my view. It is a fundamentally different premise to do interoperability-at-the-POS vs. interoperability-in-the-middle. The latter appears to be “easier”… unless, of course, you want to go to scale.

At scale, there is absolutely no way to take the “whatever you can send me” from 4000 clinics in TZ and expect to figure it out at the IL before sending it on its way toward the SHR. There simply isn’t enough time/money to successfully do it that way. To achieve health system-scale interoperability, POSs will need to send profile-conformant content. There are important and useful ways we can help them to do that (open source components/tools and readily-adoptable facades) but there is no way to avoid it altogether thru sheer brute effort on the HIE side.

We will be well served, I think, by turning some of our attention to how we will help hundreds, maybe thousands, of POS applications become profile-conformant. That is a big part of the logic behind adopting IHE in the first place: it has an “infrastructure” (tools, conformance-testing suites, etc.) to help enable this to happen. We are getting first-hand experience on how easy or hard this is as we work to make OpenMRS profile-conformant (as a POS… altho our present focus is on the SHR side). It is good that we are documenting our tribulations on this journey… it is one many other POSs will also need to take.

That’s my $0.02… well… maybe $0.04 (it was a bit “heavy” at the end there…)…

Warmest regards,

Derek.

On Wednesday, March 12, 2014 4:49:56 AM UTC-4, Ryan Crichton wrote:

[ryan]

Thanks Derek, this captures very well the issue that I was bringing up.

A small note on the country extension to CDA content modules; I would really like to avoid as much country extension as possible in our case as we would then have to maintain all of these extensions. I think it would be easier if we stick as close to the standard as possible.

Cheers,

Ryan

···

On Wed, Mar 12, 2014 at 2:25 PM, Derek Ritz derek.ritz@gmail.com wrote:

Ooops… forgot to attach the APS profile document… here it is.

On Wednesday, March 12, 2014 8:21:29 AM UTC-4, Derek Ritz wrote:

Hi all.
Ryan – you’ve made some really good points. There are some clarifications which might be helpful, tho. For one – I think Jack has made an excellent suggestion re: the “normalisation” of the coding. We should add to (but not replace) the codes which are present. This is important from a clarity/safety point of view. Whatever was originally SENT by the clinician should be maintained in the document. The adding of TS-mapped codes will augment this original content. It also helps us that, if this document is subsequently retrieved (including cases where it is later fetched by the sender), the original codes are still there and our mapped ones are included in addition to those.
RE: the specifications in the IHE’s profiled CDAs – it is helpful to look at an example…
IHE’s antepartum (APS/APHP etc.) profile document is attached. Starting on page 27, and following, it describes the content that must be in an antepartum summary (APS) document. This lists the template sections that are required, required if known, and optional. All the templates have template IDs, and there are definitions for these templates. For these defined templates, quite heavy use is made of LOINC-defined codes. To see how this is spec’d, we can drill down on template 1.3.6.1.4.1.19376.1.5.3.1.1.11.2, which is the antepartum summary template.
The IHE wiki for the APS template is here: http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.11.2. It lists the sections that must be in the APS… and these, in turn, have templates. We can drill down on the antepartum visit flowsheet template (1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.2) to see the specifics of what is to be collected and how it is represented. The wiki page for that template is found here: http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.2. This flowsheet can include simple observations, or a panel (which is just a collection of simple observations). You guessed it, there is a template for each of these. If we look at the template for the panel (found here: http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.11.2.3.2) we get to the heart of what specific observations are to be collected and how they are to be coded. This panel is based on the US ACOG-specified standard of care – and it is here, for example, that a national implementing body would specify what THEIR standard panel is as a country extension to the IHE profile (which is completely allowed and supported by the standard and is even recorded by IHE in a section 4 of the profile dedicated to country extensions/modifications).

As an example, tho, this is what the antepartum visit panel includes in the existing profile for APS (first 5 lines)…

LOINC Code
displayName
xsi:type
units
value set
11884-4
GESTATIONAL AGE-TIME-PT-^FETUS-QN-CLINICAL.ESTIMATED
PQ
week

11881-0
FUNDAL HEIGHT-LEN-PT-UTERUS-QN-TAPE MEASURE
PQ
cm

11876-0 (by PE)
or
11877-8 (by US)
FETAL PRESENTATION-TYPE-PT-PELVIS-NOM-PALPATION
or
FETAL PRESENTATION-TYPE-PT-PELVIS-NOM-US
CD

SNOMED CT
Vertex (70028003)
Breech (6096002)
Transverse (73161006)
Oblique (63750008)
Compound (124736009)
Brow (8014007)
Face (21882006)
11948-7
or
(xx-fetal-hr-ausc)
HEART RATE-NRAT-PT-^FETUS-QN-US.MEASURED
or
HEART RATE-NRAT-PT-^FETUS-QN-AUSCULTATION
PQ
/min

(xx-fetal-movement)
MOVEMENT-FIND-PT-^FETUS-ORD-PATIENT REPORTED
CO

SNOMED CT
fetal movement activity (finding) CID 364755008

baby kicks a lot (finding) CID 276368003

baby not moving (finding) CID 276370007

reduced fetal movement (finding) CID 276369006

fetal movements present (finding) CID 289431008

fetal movements felt (finding) CID 268470003

fetal movements seen (finding) CID 169731002

For each of these, the LOINC code is spec’d (indicating what is being observed), the data type is spec’d (in HL7v3 terms, since this is a CDA), and the units of measure for the observation is spec’d (for a number of these, ACOG specifies that SNOMED-CT is to be used for the coding – although this can be modified as a country extension).

Here is where I’m going with this: in order to achieve interoperability between disparate POS systems, the content and coding need to be “nailed down”. This nailing down, at the document level, is accomplished by the by the IHE profiles. IHE’s expectation is that an APS (for example) is a sharable document and that everyone who looks at it must be able to know what it says – in both human terms and in computable (semantically interoperable) terms.

To be conformant with an IHE profile – a POS must be able to send the profile-conformant document to the HIE. It seems we are dancing around the idea that we will support POS applications who are not able to send profile-conformant documents to the HIE, but that we will turn them into conformant documents when they arrive there. My understanding is that this is somewhat the case of Indiana’s HIE; great (and expensive) effort is put into developing the interface for each new hospital so that the “whatever it sends” can be turned into the “what the HIE needs”. We will no-doubt find that this is expedient to do in some exceptional cases (huge hospital networks with legacy applications), but for it to be rule would be disastrous, in my view. It is a fundamentally different premise to do interoperability-at-the-POS vs. interoperability-in-the-middle. The latter appears to be “easier”… unless, of course, you want to go to scale.

At scale, there is absolutely no way to take the “whatever you can send me” from 4000 clinics in TZ and expect to figure it out at the IL before sending it on its way toward the SHR. There simply isn’t enough time/money to successfully do it that way. To achieve health system-scale interoperability, POSs will need to send profile-conformant content. There are important and useful ways we can help them to do that (open source components/tools and readily-adoptable facades) but there is no way to avoid it altogether thru sheer brute effort on the HIE side.

We will be well served, I think, by turning some of our attention to how we will help hundreds, maybe thousands, of POS applications become profile-conformant. That is a big part of the logic behind adopting IHE in the first place: it has an “infrastructure” (tools, conformance-testing suites, etc.) to help enable this to happen. We are getting first-hand experience on how easy or hard this is as we work to make OpenMRS profile-conformant (as a POS… altho our present focus is on the SHR side). It is good that we are documenting our tribulations on this journey… it is one many other POSs will also need to take.

That’s my $0.02… well… maybe $0.04 (it was a bit “heavy” at the end there…)…

Warmest regards,

Derek.

On Wednesday, March 12, 2014 4:49:56 AM UTC-4, Ryan Crichton wrote:

Hi all,

Great discussion here. Here is my point of view:

I believe that the SHR should be ‘dumb’, it doesn’t have to know much about terminology. Its job is to store information that is send and to regurgitate information when it is asked. The IL has the responsibility of providing the SHR with information in the canonical form, which includes terminology. So, the IL should be responsible for validating terminology and querying about the mapping of terminology that comes from the clinical content that it receives. It should replace any terminology that is not in the canonical (standardised) form with canonical terminology that is retrieved from a query to the TS. This will free the SHR of the complexity of knowing anything about TS or how to map terminology. When clinical content is queried from the SHR, the IL could again replace the canonical terminology with the local terminology by querying the TS.

As a separate point, I am left wondering how this approach fit in with our decisions to use IHE patient care coordination profiles of CDA. In these profiles the particular terminology is pre-specified and fixed (as far as I know). Are we saying that it is possible that a PoC application can send us messages/documents that don’t conform to these profiles? From previous discussions we have talked about supporting, say HL7v2, from the PoC. Are these the instances where we would be required to do terminology mapping in order to transform the received message into a profiled CDA document that we are expecting? Otherwise, if we are receiving profiled CDA documents then would we just need to perform validation of the terminology used?

Cheers,

Ryan

On Fri, Mar 7, 2014 at 8:37 PM, Derek Ritz derek...@gmail.com wrote:

ooops… replied only to Jack… fwd’ing to architecture group…

---------- Forwarded message ----------
From: Derek Ritz derek...@gmail.com

Date: Fri, Mar 7, 2014 at 1:36 PM
Subject: Re: The Role of the TR as the source of truth, and syncing against OpenMRS (POC / SHR) concept dictionaries

To: Jack Bowie jack....@gmail.com

Hi all.

I worry that we might be getting a bit wrapped around the axle because we’re using an EMR as our SHR. Some of these terminology or concept-mapping issues are a “don’t care” in terms of the requirements for a shared health record repository that faithfully stores and fetches what was sent to it. I think it would be informing for us to ask the question: what if we substituted shared health record repository product “x” in place of OpenMRS? We might find that we’re over-engineering; we may be trying to replicate in our SHR work that will have already been done upstream by the IL+TS interactions.

Just a thought…

DJ

On Fri, Mar 7, 2014 at 1:20 PM, Jack Bowie jack....@gmail.com wrote:

The TS supports mappings between any two terminologies. And a Reference Terminology could be a terminology defined by the HIE authority. What is an Interface and what is a Reference Terminology is a policy (not technical) decision.

The semantics of a mapping are generally use-case dependent. And there can potentially be many mappings between the same two terminologies: one for reimbursement purposes and one for public health reporting, for example. As a couple other examples, SNOMED CT’s SNOMED to ICD-9 mapping adds a qualifier on the single “SNOMED CT to ICD-9 Map” association type of “Narrow to Broad”, “Broad to Narrow”, “Exact”, etc., to provide additional information. But the SNOMED to ICD-10 mapping is “rule-based”: there are multiple “associations” and the correct one is dependent on context (the other codes in the clinical encounter). Mappings can be one-to-one, one-to-many or many-to-one.

I’m afraid that “mapping” is a very complex topic and can only be adequately addressed by understanding the specific use-cases that are to be supported by the SHR (IL). There are simply too many variables in the general case. From an interface engine point of view, one usually just tries to find “single best match” (one-to-one) and leave it at that. How are you looking to use a “mapping” in the SHR? Have you defined the use-cases that are to be supported?

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@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: ry...@jembi.org

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+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

[derek.ritz]

Hi Ryan.

I agree – but I have also lobbied the PCC (IHE’s Patient Care Coordination) committee to adopt more international specifications and standards in their profile definitions. Many are VERY US-centric and, for those that are in trial implementation, I believe we should help them become more international re: their guidelines (WHO vs. American College of Gynecologists) and in their specs (ICHI vs. CPT, etc.). There is a work item underway re: family planning and they have taken this to heart and are now looking at the WHO guideline instead of the CDC guideline to inform their profile.

Also – I want to make the point that the specs that we adopt in OpenHIE are still modifiable, on a country basis, without having to abandon the profile; they are designed to be country-adapted. Even better, our TS will make such adaptations significantly easier to operationalize.

Warmest regards,

Derek.

···

On Wed, Mar 12, 2014 at 8:36 AM, Ryan Crichton ryan@jembi.org wrote:

Thanks Derek, this captures very well the issue that I was bringing up.

A small note on the country extension to CDA content modules; I would really like to avoid as much country extension as possible in our case as we would then have to maintain all of these extensions. I think it would be easier if we stick as close to the standard as possible.

Cheers,

Ryan

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

On Wed, Mar 12, 2014 at 2:25 PM, Derek Ritz derek.ritz@gmail.com wrote:

Ooops… forgot to attach the APS profile document… here it is.

On Wednesday, March 12, 2014 8:21:29 AM UTC-4, Derek Ritz wrote:

Hi all.
Ryan – you’ve made some really good points. There are some clarifications which might be helpful, tho. For one – I think Jack has made an excellent suggestion re: the “normalisation” of the coding. We should add to (but not replace) the codes which are present. This is important from a clarity/safety point of view. Whatever was originally SENT by the clinician should be maintained in the document. The adding of TS-mapped codes will augment this original content. It also helps us that, if this document is subsequently retrieved (including cases where it is later fetched by the sender), the original codes are still there and our mapped ones are included in addition to those.
RE: the specifications in the IHE’s profiled CDAs – it is helpful to look at an example…
IHE’s antepartum (APS/APHP etc.) profile document is attached. Starting on page 27, and following, it describes the content that must be in an antepartum summary (APS) document. This lists the template sections that are required, required if known, and optional. All the templates have template IDs, and there are definitions for these templates. For these defined templates, quite heavy use is made of LOINC-defined codes. To see how this is spec’d, we can drill down on template 1.3.6.1.4.1.19376.1.5.3.1.1.11.2, which is the antepartum summary template.
The IHE wiki for the APS template is here: http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.11.2. It lists the sections that must be in the APS… and these, in turn, have templates. We can drill down on the antepartum visit flowsheet template (1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.2) to see the specifics of what is to be collected and how it is represented. The wiki page for that template is found here: http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.11.2.2.2. This flowsheet can include simple observations, or a panel (which is just a collection of simple observations). You guessed it, there is a template for each of these. If we look at the template for the panel (found here: http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.11.2.3.2) we get to the heart of what specific observations are to be collected and how they are to be coded. This panel is based on the US ACOG-specified standard of care – and it is here, for example, that a national implementing body would specify what THEIR standard panel is as a country extension to the IHE profile (which is completely allowed and supported by the standard and is even recorded by IHE in a section 4 of the profile dedicated to country extensions/modifications).

As an example, tho, this is what the antepartum visit panel includes in the existing profile for APS (first 5 lines)…

LOINC Code
displayName
xsi:type
units
value set
11884-4
GESTATIONAL AGE-TIME-PT-^FETUS-QN-CLINICAL.ESTIMATED
PQ
week

11881-0
FUNDAL HEIGHT-LEN-PT-UTERUS-QN-TAPE MEASURE
PQ
cm

11876-0 (by PE)
or
11877-8 (by US)
FETAL PRESENTATION-TYPE-PT-PELVIS-NOM-PALPATION
or
FETAL PRESENTATION-TYPE-PT-PELVIS-NOM-US
CD

SNOMED CT
Vertex (70028003)
Breech (6096002)
Transverse (73161006)
Oblique (63750008)
Compound (124736009)
Brow (8014007)
Face (21882006)
11948-7
or
(xx-fetal-hr-ausc)
HEART RATE-NRAT-PT-^FETUS-QN-US.MEASURED
or
HEART RATE-NRAT-PT-^FETUS-QN-AUSCULTATION
PQ
/min

(xx-fetal-movement)
MOVEMENT-FIND-PT-^FETUS-ORD-PATIENT REPORTED
CO

SNOMED CT
fetal movement activity (finding) CID 364755008

baby kicks a lot (finding) CID 276368003

baby not moving (finding) CID 276370007

reduced fetal movement (finding) CID 276369006

fetal movements present (finding) CID 289431008

fetal movements felt (finding) CID 268470003

fetal movements seen (finding) CID 169731002

For each of these, the LOINC code is spec’d (indicating what is being observed), the data type is spec’d (in HL7v3 terms, since this is a CDA), and the units of measure for the observation is spec’d (for a number of these, ACOG specifies that SNOMED-CT is to be used for the coding – although this can be modified as a country extension).

Here is where I’m going with this: in order to achieve interoperability between disparate POS systems, the content and coding need to be “nailed down”. This nailing down, at the document level, is accomplished by the by the IHE profiles. IHE’s expectation is that an APS (for example) is a sharable document and that everyone who looks at it must be able to know what it says – in both human terms and in computable (semantically interoperable) terms.

To be conformant with an IHE profile – a POS must be able to send the profile-conformant document to the HIE. It seems we are dancing around the idea that we will support POS applications who are not able to send profile-conformant documents to the HIE, but that we will turn them into conformant documents when they arrive there. My understanding is that this is somewhat the case of Indiana’s HIE; great (and expensive) effort is put into developing the interface for each new hospital so that the “whatever it sends” can be turned into the “what the HIE needs”. We will no-doubt find that this is expedient to do in some exceptional cases (huge hospital networks with legacy applications), but for it to be rule would be disastrous, in my view. It is a fundamentally different premise to do interoperability-at-the-POS vs. interoperability-in-the-middle. The latter appears to be “easier”… unless, of course, you want to go to scale.

At scale, there is absolutely no way to take the “whatever you can send me” from 4000 clinics in TZ and expect to figure it out at the IL before sending it on its way toward the SHR. There simply isn’t enough time/money to successfully do it that way. To achieve health system-scale interoperability, POSs will need to send profile-conformant content. There are important and useful ways we can help them to do that (open source components/tools and readily-adoptable facades) but there is no way to avoid it altogether thru sheer brute effort on the HIE side.

We will be well served, I think, by turning some of our attention to how we will help hundreds, maybe thousands, of POS applications become profile-conformant. That is a big part of the logic behind adopting IHE in the first place: it has an “infrastructure” (tools, conformance-testing suites, etc.) to help enable this to happen. We are getting first-hand experience on how easy or hard this is as we work to make OpenMRS profile-conformant (as a POS… altho our present focus is on the SHR side). It is good that we are documenting our tribulations on this journey… it is one many other POSs will also need to take.

That’s my $0.02… well… maybe $0.04 (it was a bit “heavy” at the end there…)…

Warmest regards,

Derek.

On Wednesday, March 12, 2014 4:49:56 AM UTC-4, Ryan Crichton wrote:

Hi all,

Great discussion here. Here is my point of view:

I believe that the SHR should be ‘dumb’, it doesn’t have to know much about terminology. Its job is to store information that is send and to regurgitate information when it is asked. The IL has the responsibility of providing the SHR with information in the canonical form, which includes terminology. So, the IL should be responsible for validating terminology and querying about the mapping of terminology that comes from the clinical content that it receives. It should replace any terminology that is not in the canonical (standardised) form with canonical terminology that is retrieved from a query to the TS. This will free the SHR of the complexity of knowing anything about TS or how to map terminology. When clinical content is queried from the SHR, the IL could again replace the canonical terminology with the local terminology by querying the TS.

As a separate point, I am left wondering how this approach fit in with our decisions to use IHE patient care coordination profiles of CDA. In these profiles the particular terminology is pre-specified and fixed (as far as I know). Are we saying that it is possible that a PoC application can send us messages/documents that don’t conform to these profiles? From previous discussions we have talked about supporting, say HL7v2, from the PoC. Are these the instances where we would be required to do terminology mapping in order to transform the received message into a profiled CDA document that we are expecting? Otherwise, if we are receiving profiled CDA documents then would we just need to perform validation of the terminology used?

Cheers,

Ryan

On Fri, Mar 7, 2014 at 8:37 PM, Derek Ritz derek...@gmail.com wrote:

ooops… replied only to Jack… fwd’ing to architecture group…

---------- Forwarded message ----------
From: Derek Ritz derek...@gmail.com

Date: Fri, Mar 7, 2014 at 1:36 PM
Subject: Re: The Role of the TR as the source of truth, and syncing against OpenMRS (POC / SHR) concept dictionaries

To: Jack Bowie jack....@gmail.com

Hi all.

I worry that we might be getting a bit wrapped around the axle because we’re using an EMR as our SHR. Some of these terminology or concept-mapping issues are a “don’t care” in terms of the requirements for a shared health record repository that faithfully stores and fetches what was sent to it. I think it would be informing for us to ask the question: what if we substituted shared health record repository product “x” in place of OpenMRS? We might find that we’re over-engineering; we may be trying to replicate in our SHR work that will have already been done upstream by the IL+TS interactions.

Just a thought…

DJ

On Fri, Mar 7, 2014 at 1:20 PM, Jack Bowie jack....@gmail.com wrote:

The TS supports mappings between any two terminologies. And a Reference Terminology could be a terminology defined by the HIE authority. What is an Interface and what is a Reference Terminology is a policy (not technical) decision.

The semantics of a mapping are generally use-case dependent. And there can potentially be many mappings between the same two terminologies: one for reimbursement purposes and one for public health reporting, for example. As a couple other examples, SNOMED CT’s SNOMED to ICD-9 mapping adds a qualifier on the single “SNOMED CT to ICD-9 Map” association type of “Narrow to Broad”, “Broad to Narrow”, “Exact”, etc., to provide additional information. But the SNOMED to ICD-10 mapping is “rule-based”: there are multiple “associations” and the correct one is dependent on context (the other codes in the clinical encounter). Mappings can be one-to-one, one-to-many or many-to-one.

I’m afraid that “mapping” is a very complex topic and can only be adequately addressed by understanding the specific use-cases that are to be supported by the SHR (IL). There are simply too many variables in the general case. From an interface engine point of view, one usually just tries to find “single best match” (one-to-one) and leave it at that. How are you looking to use a “mapping” in the SHR? Have you defined the use-cases that are to be supported?

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

–
Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@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: ry...@jembi.org

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+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