TS interface for version 1
Ryan Crichton
- 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?
E-mail: ry...@jembi.org
Derek Ritz (ecGroup)
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.
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: openhie-interop...@googlegroups.com [mailto:openhie-interop...@googlegroups.com] On Behalf Of Jack Bowie
Sent: Wednesday, February 11, 2015 11:20 AM
To: terminolog...@googlegroups.com; openhie-interop...@googlegroups.com; openh...@googlegroups.com
Subject: RE: TS interface for version 1
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.
--
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.
For more options, visit https://groups.google.com/d/optout.
Shaun Grannis
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)
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.
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
Sent from my Windows Phone
Shaun Grannis
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
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
--
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)
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.
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)