TS interface for version 1

[Ryan Crichton]

Hi all,

On a community call yesterday we discovered an oversight that I think we need to address in the light that OpenHIE v1's release date is closing in. It seems that we have never firmly decided on the interface or interaction that the Interoperability Layer will have with the Terminology Service. I know there has been talk of getting FHIR into the TS but that seems to be a while out at the moment.

So, the big questions are:

• What interface can we use right now, for OpenHIE v1, to validate codes with the TS?
• Should we include an interaction with the TS in OpenHIE v1 or push that out into a subsequent release once we have a better grip on the standard to use and the type of interaction?

Some comments: I suspect with the size of CDA documents that we may incur a significant performance reduction if we check every code in  CDA documents, perhaps we could discuss some more realistic interactions? In addition some CDA profiles require us to validate some of the codes as they are specified by the profile, so the SHR is doing some of this at the moment.

Please let me know you thin of this and how we can proceed for v1.

Cheers,

Ryan

--

Ryan Crichton

Lead Developer, Jembi Health Systems |  SOUTH AFRICA

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

[Jack Bowie]

Ryan,

 

Repeating what was discussed on the TS call this morning, last year the Architecture group decided to stay with the currently implemented code validation scheme using the DTS API for OHIE V1. In a future version, we expect to use the FHIR API, which as currently-speced has a “batch”, i.e. multiple code, validation API as well as subsumption and value-set membership APIs which should improve CDA validation performance.

 

Your input on future workflows and TS capabilities are encouraged.

 

Jack

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

[Derek Ritz (ecGroup)]

Hi Jack, and everyone.

 

Because we have a long history of broad adoption to draw upon, I wanted to use Apelon’s deployment patterns in Canada to help inform what our “end game” will/should look like for OpenHIE. Canada has been using terminology services as part of its national eHealth architecture for a decade now and, helpfully, our OpenHIE architecture is very closely based on the “Infoway blueprint” so it is strongly analogous. Reflective of how the role of the TS in Canada has matured over the years, I asked Justin to describe how the Canadian national reference implementation maintained at the MEDIC lab (Mohawk) has evolved since its first version in 2007.  Justin’s description is here: https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!topic/ohie-architecture/gUFsq67Svr4.

 

My sense is that we would be very well-served to go straight to this “end game” and, for OpenHIE v1, I think we should light up 2 TS pass-thru services in the OpenHIM. The services would be pretty much identical except that one would face “the world” and be used to service DTS-based terminology requests from POS applications to the TS. The other would face the datacentre and service requests from our HIE infrastructure puzzle pieces that may need to resolve codes or populate code sets in its cache. At some future time, when there is a standards-based interface that can unseat the proprietary DTS interface, we’ll add new standards-based interfaces to the OpenHIM in the same configuration (for backward compatibility, we can leave the DTS interfaces in place, if we choose to).

 

I would favour this option over adding a trivial code validation step in our existing “save encounter” workflow. Our initial plan to do so was based being consistent with the RHEA pattern. The validation we do on the inbound RHEA messages is easy (basically: “is this a valid ICD-10 code?”) but, to be candid, it has a very low value-add. To do a proper (fulsome) validation of all codes in all inbound CDAs would be very (very!) hard, very (very!) slow, but even so it would still have a very low value-add. Frankly, I don’t think it’s worth it. I’d suggest we go straight to where we know there is value… and I’d suggest that Apelon’s experience in Canada points us to where that is.

 

What do others think of this approach?

 

DJ

 

PS: we will, I think, develop new uses for the TS as part of the ICP work that ecGroup and CDC are jointly doing during this IHE QRPH technical committee cycle. My sense is that we can and should wait for OpenHIE v2 to reflect what these new TS-focused use cases might be.

 

 

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

 

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.
--------------------------------------------------------------------------------
Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s'adressent exclusivement au destinataire mentionné ci-dessus. L'expéditeur ne renonce pas aux droits et privilèges qui s'y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m'en informer.

--
You received this message because you are subscribed to the Google Groups "Interoperability Layer (OpenHIE)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperabil...@googlegroups.com.

[Shaun Grannis]

Thanks Derek.

In Justin's document, does a "line of business system" translate into an OpenHIE Point of Service, or one of the 7 OpenHIE components?

----
Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)      
(317) 274-9305 (Fax) 

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

[Derek Ritz (ecGroup)]

Hi Shaun.

 

I think line-of-business could mean either kind of application. (sorry, I don’t know what Justin means, specifically, by Erl nomenclature…@Justin, what is this?).

 

DJ

 

 

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

 

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.
--------------------------------------------------------------------------------
Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s'adressent exclusivement au destinataire mentionné ci-dessus. L'expéditeur ne renonce pas aux droits et privilèges qui s'y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m'en informer.

 

[Justin Fyfe]

You're correct Derek.. Apologies, a line of business application is any application participating within a SOA (a provider or consumer) that performs some sort of business function. In OpenHIE this could be infrastructure or clients ;)

Sent from my Windows Phone

---

From: Derek Ritz (ecGroup)
Sent: ‎2015-‎02-‎11 10:36 PM
To: Shaun Grannis

Cc: Jack Bowie; terminolog...@googlegroups.com; openhie-interop...@googlegroups.com; openhie-shr; ohie-arc...@googlegroups.com; Ryan Crichton; Justin Fyfe

[Shaun Grannis]

Thanks for that clarification Justin.

To be sure I'm reading Justin's Google doc correctly, is it advocating (in short) that the TS should support 1) code validation, 2) translation, and enhancement for systems both above and below the HIAL?

(not disagreeing, just wanting to be sure I'm interpreting the doc correctly)

----
Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)      
(317) 274-9305 (Fax) 

[Justin Fyfe]

Well.. I was just sharing some of the experiences we've had in our HIAL RI. Basically there is no requirement of a TS in our HIAL from a transactional processing standpoint. It is merely provided as a service if systems within the SOA deem it necessary to use, and for configuration purposes. It is like a bonus feature rather than keystone functionality for transaction processing.

Sent from my Windows Phone

---

From: Shaun Grannis
Sent: ‎2015-‎02-‎11 10:48 PM
To: Justin Fyfe
Cc: Derek Ritz (ecGroup); Jack Bowie; terminolog...@googlegroups.com; openhie-interop...@googlegroups.com; openhie-shr; ohie-arc...@googlegroups.com; Ryan Crichton

[Paul Biondich]

Hi Derek,

It seems like you're advocating for additional scope for V1 of OpenHIE.  Can you restate it differently, so that we can work through that?

From what I understand, we have agreed to TS's engagement as being against *1* workflow, and that is focused on code validation inside the save encounter workflow.

There are clearly additional things that the TS will need to do, both internally and externally.  Are we going to push on doing that now for V1, or extend this conversation to our next release?

You are suggesting we extend the scope of V1, I believe.

-Paul

On Wed, Feb 11, 2015 at 8:25 PM, Derek Ritz (ecGroup) <derek...@ecgroupinc.com> wrote:

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

[Derek Ritz (ecGroup)]

Hi Paul.

What I am really saying is that including a “code check” as part of the transaction processing of each inbound message is ill-advised and we should omit it from v1.

Informed by Apelon’s evolution to a mature use case in Canada, I’ve suggested we enable a pass-thru on the HIM that supports application access to the underlying TS (one interface for POS access and a separate one for above-the-HIM access). Respectful of the fact that the TS community does not (yet) have consensus on a standards-based interface, I suggested we expose DTS as the connection point.

I’m sorry that this is sounding like advocating for additional scope. What I wanted to do was include TS interface support in v1 in a strong, value-adding way. You’re right; the 2 new interfaces could certainly be part of a v1.x roll-out.

My core recommendation is that we omit the code-checking from the save encounter workflow in v1.

Warmest regards,

Derek.

 

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

 

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.
--------------------------------------------------------------------------------
Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s'adressent exclusivement au destinataire mentionné ci-dessus. L'expéditeur ne renonce pas aux droits et privilèges qui s'y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m'en informer.

 

From: Paul Biondich [mailto:pbio...@regenstrief.org]

Sent: Thursday, February 12, 2015 2:28 PM
To: Derek Ritz (ecGroup)

[r.fri...@mindspring.com]

Hi Derek, Paul, everyone.  Sorry not to have been able to participate more, doubt my ability to participate well now, but this seems to implicate decisions about a couple of basic goals of OHIE that maybe people haven't agreed to.

 

First, there is the question of pre-coordination v. post-coordination.  Originally, one role for the interface layer was to handle code translation in a post-coordinated way, in which case code validation is only a step on the road to code normalization.  If one is working in a pre-coordinated way, then simple code validation does add very little value, especially in an automated data entry environment.

 

Second, there is the question of whether the SHR is supposed to be a mere collection of HRs from multiple sites, or whether it is supposed to represent a longitudinal health record.  I know the steps cancer registries take to make sure that data from multiple reporting sites is harmonized into a single internally consistent record.  I also know how deep the validation steps go into the substance of medical practice (so that surgery is an invalid treatment for a blood cancer, or that particular cancers are found at particular body sites).  So if we are talking about mere shared access to facility data, validation again doesn't add very much value.

HTH, Roger

-----Original Message-----
From: "Derek Ritz (ecGroup)"

Sent: Feb 12, 2015 2:46 PM
To: 'Paul Biondich'
Cc: 'Jack Bowie' , terminolog...@googlegroups.com, openhie-interop...@googlegroups.com, openh...@googlegroups.com, ohie-arc...@googlegroups.com, 'Ryan Crichton' , 'Justin Fyfe'
Subject: RE: TS interface for version 1

* What interface can we use right now, for OpenHIE v1, to validate codes with the TS?
* Should we include an interaction with the TS in OpenHIE v1 or push that out into a subsequent release once we have a better grip on the standard to use and the type of interaction?

[Derek Ritz]

Hi Roger.

Thanks for the (as always) insightful and astute comments. Re: your first point -- GOOD CATCH -- yes, we are expecting that OpenHIE will operate in a pre-coordination environment. That is the case in RW and in ZA and (for the BID project, at least) in TZ. The expectation that there will be a national eHealth standards framework of some sort is somewhat a "couched pre-supposition"  for any jurisdiction implementing OpenHIE. I think that is why Canada's use of Apelon, for example, has evolved the way it has. There is, generally, an expectation that POS systems will abide the content, coding and communications standards spec'd by the jurisdiction in which they operate.

Re: your second point -- there is very much an expectation that the SHR will represent a longitudinal health record for each client. The present OpenSHR design pulls discrete data out of inbound CDAs and maps these to coded concepts in an OpenMRS database (level 3 CDA processing). Where a level 2 CDA is submitted, or where the SHR doesn't understand the CDA section that has been posted, it persists the CDA at the section level (level 2). Because of the pre-coordination of content specs, at present we don't expect the HIE to receive inbound CDAs that it isn't expecting or doesn't know how to process. (that may change, someday... but it is a very safe assumption for the near term at least). Going the other way, a POS system's request for patient level information is satisfied by an on-demand-document (IHE's XDS.b-ODD option) that builds a real-time CDA from the content in the SHR. This CDA is constructed to the degree of precision supported by the data in the repository (level 3, or 2). Source attribution is maintained right down to the data element level in the ODD CDA, but it does not do any clinical validity checking in the SHR beyond the rules codified in the CDA structure itself. I don't foresee adding a degree of complexity to the processing of inbound CDAs to do the kind of checking you're talking about doing for the CDC's cancer registries... but then again, we will learn a lot about what is reasonable and doable after the present ICP exploration yields its results.

Warmest regards,

Derek.

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

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

--
You received this message because you are subscribed to the Google Groups "Interoperability Layer (OpenHIE)" group.

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

[Jack Bowie]

Thanks for the comments. I have one (hopeful) clarification and one question.

 

Code Validation – In my current understanding “code validation” means “is the code in the input message a valid code in its documented target code system/value set/profile context?”. This means that some well-defined code system/value set/profile context must have already been defined and available in the TS. I would not expect that this meaning of validation would necessarily include “that surgery is an invalid treatment for a blood cancer, or that particular cancers are found at particular body sites” unless there are previously-defined value sets that encompass these clinical decisions.

 

Pre-versus post-coordination – Pre-coordination is a function of the underlying code system: SNOMED contains some, but certainly not all possible, pre-coordinated codes. SNOMED also offers a syntax for post-coordination of elemental SNOMED codes into expressions. Post-coordination is a quite complicated process and typically performed (produced) by edge systems (EMRs) and some interface-terminologies. Are you asking if we would expect the IL/SHR to perform post-coordination? Perhaps I don’t understand what you mean by “handle code translation in a post-coordinated way”.

 

Best,

Jack

[Jack Bowie]

Thanks for the comments. I have one (hopeful) clarification and one question.

 

Code Validation – In my current understanding “code validation” means “is the code in the input message a valid code in its documented target code system/value set/profile context?”. This means that some well-defined code system/value set/profile context must have already been defined and available in the TS. I would not expect that this meaning of validation would necessarily include “that surgery is an invalid treatment for a blood cancer, or that particular cancers are found at particular body sites” unless there are previously-defined value sets that encompass these clinical decisions.

 

Pre-versus post-coordination – Pre-coordination is a function of the underlying code system: SNOMED contains some, but certainly not all possible, pre-coordinated codes. SNOMED also offers a syntax for post-coordination of elemental SNOMED codes into expressions. Post-coordination is a quite complicated process and typically performed (produced) by edge systems (EMRs) and some interface-terminologies. Are you asking if we would expect the IL/SHR to perform post-coordination? Perhaps I don’t understand what you mean by “handle code translation in a post-coordinated way”.

 

Best,

Jack

[Ryan Crichton]

Hi all,

The Interoperability layer community had a great call about this earlier this week. We have also requested that we discuss this on the architecture call so that we can get a full spectrum of opinions on this.

On the call we challenged the save encounter workflow's assumptions that we would be validating every code in a CDA document with the TS while actively processing each transaction. This is because we see a few problems with this method:

1. In OpenHIE implementations we are the ones defining the standards and we are asking client to pre-coordinate their code sets with us there is little value in per transaction validation.
2. CDAs are large documents and the sorting through then and pulling out codes while a transaction is being processing is every expensive in terms of performance.
3. The IL isn't the expert system and doesn't always know the context of when a code is used and if it is used correctly, a system such as the SHR (or other clinical repositories) would be much better on knowing this information.
4. From implementation experience this approach has been shown to not work very well for the above reasons.

Now, the TS is still highly valuable as the keeper of all terminology used in an HIE, however, we are proposing that the interactions with the TS be altered to better fit our use cases. Here is what we envisaged on the call:

• The IL should provide a pass through to the TS's API (a new TS workflow) to enable:
• PoC systems to query for updated sets of terminology that they can use and/or to resolve codes
• Infrastructure services such as the SHR to be able to keep its internal cache of terminology codes up to date and to perform any transformation or resolution of codes that it needs to perform, if required.

We feel this fits the problem much better, but would of course like other opinions on this. We are happy to discuss this in this thread or on the next architecture call.

In the mean time we are halting work on incorporating the validation of terminology codes in the save encounter workflow and are hoping that our other suggestion for the new TS workflow is agreeable. Please let us know if anyone has any objection to this.

We'd be very interested in hearing your thoughts.

Cheers,

Ryan (on behalf of the IL community)

[Shaun Grannis]

Ryan,

Thank you for this excellent synopsis.

We've included this topic on the next architecture call agenda.

Looking forward to hearing people's perspectives!

Best,

Shaun

----
Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)      
(317) 274-9305 (Fax) 

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

[Scott Teesdale]

Hi All, 

Interesting thread.  We have a similar ongoing discussion in the FR community around this part of your comments Ryan. 

• The IL should provide a pass through to the TS's API (a new TS workflow) to enable:  PoC systems to query for updated sets of terminology that they can use and/or to resolve code

Although we would hope to expand the PoC's need for this functionality to include HIE components as well.  Our primary use case has emerged out of needing to manage routine updates to an administrative hierarchy that often occur in countries.  Happy to expand more if it would be helpful.

- Scott 

--
You received this message because you are subscribed to the Google Groups "Shared Health Record (OpenHIE)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr...@googlegroups.com.

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

--

Scott Teesdale

Project Manager - InSTEDD

Email: stee...@instedd.org 

Skype: scott.teesdale 

Social: Twitter / LinkedIn