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.
···
On Wed, Feb 11, 2015 at 10:43 PM, Justin Fyfe justin.fyfe@ecgroupinc.com wrote:
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; terminology-services@googlegroups.com; openhie-interoperability-layer@googlegroups.com; openhie-shr; ohie-architecture@googlegroups.com; Ryan Crichton; Justin Fyfe
Subject: RE: TS interface for version 1
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
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-interoperability-layer@googlegroups.com [mailto:openhie-interoperability-layer@googlegroups.com] On Behalf Of Shaun Grannis
Sent: Wednesday, February 11, 2015 9:42 PM
To: Derek Ritz (ecGroup)
Cc: Jack Bowie; terminology-services@googlegroups.com; openhie-interoperability-layer@googlegroups.com; openhie-shr; ohie-architecture@googlegroups.com; Ryan Crichton; Justin Fyfe
Subject: Re: TS interface for version 1
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)
On Wed, Feb 11, 2015 at 8:25 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
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
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-interoperability-layer@googlegroups.com [mailto:openhie-interoperability-layer@googlegroups.com] On Behalf Of Jack Bowie
Sent: Wednesday, February 11, 2015 11:20 AM
To: terminology-services@googlegroups.com; openhie-interoperability-layer@googlegroups.com; openhie-shr@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
From: terminology-services@googlegroups.com [mailto:terminology-services@googlegroups.com] On Behalf Of Ryan Crichton
Sent: Wednesday, February 11, 2015 2:29 AM
To: terminology-services@googlegroups.com; openhie-interoperability-layer@googlegroups.com; openhie-shr@googlegroups.com
Subject: TS interface for version 1
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: ryan@jembi.org
–
You received this message because you are subscribed to the Google Groups “Terminology Services” group.
To unsubscribe from this group and stop receiving emails from it, send an email to terminology-services+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
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.
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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)