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