···
---------- Forwarded message ----------
From: Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com
Date: Wed, Apr 23, 2014 at 3:33 PM
Subject: RE: Save encounter workflow - Validating a facility
To: Martin Verzilli mverzilli@manas.com.ar, Bob Jolliffe bobjolliffe@gmail.com
Cc: facility-registry@googlegroups.com, Carl Leitner cleitner@capacityplus.org, openhie-interoperability-layer@googlegroups.com
Hi all.
Martin – you have succinctly pointed out some of the genuine issues regarding interoperability. Indeed, if multiple xP’s are updating the same entity then there is a problem; it is a problem that needs to be solved and not just by having the IT system decide who’s right, either. Such issues need to be brought to the surface and addressed operationally. Even if the InfoMan does nothing more than raise the flag and enable a solution to be sorted out manually (by having issues addressed in the underlying registries and then refreshing the cache), that’s still a win, in my view.
RE: “forcing a registry to come with a HIM”… I think my main issue is wrapped up in the semantics of “registry” versus “application”. A stand-alone application likely doesn’t need a HIM. As architectural elements, however, registries are services that support system-wide interoperability. Thought of in this way, a stand-alone registry is probably quite useless without the HIM in place to orchestrate the use of the service to do some important unit of work.
I think Martin’s (and Bob’s) point is well made, though; if an xR wants to be a directory, it need do no more than expose the ITI-74 “Query for Services Update” transaction. It is the role of the other architectural elements to make good use of the exposed data. 
RE: Bob’s point about validation – I completely agree. We are, presently, doing pretty kindergarten-level validation as part of our core OpenHIE transaction design. I do think, though, that “upping the ante” would be a choice that should be made by a jurisdiction, not by us. I’m happy to see some quite helpful suggestions made about what those validation (or integrity?) checks could be; and happier still that such checks are so readily implemented by OpenInfoMan as custom stored queries.
When Carl and I were finishing the original draft, it was contemplated that we would use CPs to add inherent support for custom queries to the functionality described in the CSD profile. To “set the table” for this, Carl included the schema for such queries in the original CSD Trial Implementation package. I would like to see us, as a joint multi-community effort, move the necessary CP forward through the IHE process. My gut instinct is that the support for custom InfoMan queries will be essential to having successful implementations.
Is this something folks would support?
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: Martin Verzilli [mailto:mverzilli@manas.com.ar]
Sent: Wednesday, April 23, 2014 12:56 PM
To: Bob Jolliffe
Cc: facility-registry@googlegroups.com; Derek Ritz (ecGroup); Carl Leitner; openhie-interoperability-layer@googlegroups.com
Subject: Re: Save encounter workflow - Validating a facility
I mostly agree with everyone’s comments. Just a couple of thoughts:
- About the InfoMan becoming “the source of truth for all facility, provider, etc, info”: it sounds great but I think there are a couple of important features to address to get there.
How do we resolve versioning conflicts? Everything works nicely until two different XRs (where X is F, P, O, etc.) start updating the same entity.
What about merging entities? For example, what happens when two different FRs have different representations of the same actual facility?
Again, this is only a real issue when there are multiple registries actually writing about the same entity. If the context somehow ensures that won’t happen we’re in a happy world with a single producer and many consumers and everyone’s happy ever after. But in a federated system these kinds of conflicts are bound to arise.
- I wouldn’t force an XR to come with a HIM. They’re conceptually different boxes and that’s ok. XRs deal with x’s and HIMs deal with interop.
If your system acts as an OHIE FR and for convenience you want to also use it as an InfoMan, then great, go ahead and build it into your system. You’ll end up with an FR and a HIM which happen to be running on the same system.
But if you have an FR and just want to be interoperable in an OHIE architecture, implementing the service directory actor should be enough to enable anyone’s InfoMan to plug into your registry. Given the current CSD’s design, I don’t see why we should require more than that.
Martin
On Wed, Apr 23, 2014 at 1:25 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:
On 22 April 2014 10:17, Ryan Crichton ryan@jembi.org wrote:
Hi all,
Thanks for the comments. I agree that having the registry be an info manager when it needs to aggregate data from multiple sources makes sense. However in the case of just querying for a facility by id perhaps we don’t need to introduce that complexity. What about just querying for facility by id from a single central info manager and just have the FR feed data to the info manager as we tested at the connectathon? So, the FR wouldn’t have to respond to the read by id queries directly? That seems to be more the CSD way.
What do you guys think?
I think … I understand that the validation strategy of openhie, based on the rwanda ‘prototype’, has been to check whether identifiers exist or not but that has always seemed to me to be scraping at the very bottom of the validation barrel. Maybe you want to validate that the provider provides a service at the facility rather than just that the provider, facility and service all exist. In that case then an infoman would be your man.
Otherwise it seems like a contrived overkill to have a CSD infoman just to look up the existence of identifiers which could as easily be done on authoritative registries.
Bob
Cheers,
Ryan
On Mon, Apr 21, 2014 at 8:40 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Hi all.
I’m drawing Carl L. into this thread because of the insights I think he could provide re: the “registry as InfoMan” pattern Martin describes below (option 2). This is, I believe, the way the HWR is architected and there are some real advantages. One of the biggest, in my view, is that it allows the HWR to draw in multiple, federated provider registries (physicians, nurses, CHWs, etc.) and put a single face on them as a national HWR. Very cool.
@Carl, I know there are some drawings floating about that illustrate how this works but I can’t seem to find them. Are you able to post some of the graphics that you’ve shared with Sylvie.
Thanks and 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: openhie-interoperability-layer@googlegroups.com [mailto:openhie-interoperability-layer@googlegroups.com] On Behalf Of Martin Verzilli
Sent: Monday, April 21, 2014 2:04 PM
To: facility-registry@googlegroups.com
Cc: openhie-interoperability-layer@googlegroups.com
Subject: Re: Save encounter workflow - Validating a facility
Hi Ryan, I think it’s ok to implement this with CSD. A couple of alternatives come to mind:
- It’d be great if we could extend the standard so that CSD service directories provide a “read by id” endpoint. That way we can do without info managers for basic cases like these ones.
- If 1 isn’t possible, I guess the FR should become a CSD Info Manager. I remember during the OHIE arch meeting we discussed this possibility and there was some level of agreement in that for cases like this it would be ok to partially implement the actor (which wouldn’t be good enough to get an IHE certificate, but would still work provided that clients only consume the relevant methods).
I’d rather go with option 1, since it’s less of a hassle from the point of view of an FR and it totally makes sense for a FR to provide a “read facility by id” endpoint.
Cheers,
Martin
On Tuesday, April 1, 2014 7:24:04 AM UTC-3, ryan@jembi.org wrote:
Hi Facility Registry Community,
Do you guys have any thoughs on this? We will need to able to query for a valid facility by facility ID in some standardised way. How should this be done for the save encounter workflow? For the health worker registry we are defining a CSD function to do this, would the same be appropriate here?
Cheers,
Ryan
On Wed, Mar 12, 2014 at 3:09 PM, Ryan Crichton ry...@jembi.org wrote:
Hi all,
I’ve created this thread so that the Interoperability Layer community and the Facility Registry community can discuss the interaction with the FR as a part of the save encounter workflow.
Here is the link to the workflow: https://wiki.ohie.org/display/documents/Save+encounter+workflow (see [8] and [9])
In this workflow the IL attempts to validate that the referenced facility in the clinical document is know by the FR.
What standard makes the most sense to use for this interaction? From our discussions at the architecture meeting it seemed like using CSD to search for a facility by id would be suitable. Should we make use of the CSD profile for this communication or are there any other standards that others would like to suggest for this?
Cheers,
Ryan
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org
–
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 “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 “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.
–
Ryan Crichton
Software 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 “Facility Registry (OHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Martín Verzilli
Manas Technology Solutions
[ar.phone] 5258.5240 #MVR(687)
[us.phone] 312.612.1050 #MVR(687)
[email] mverzilli@manas.com.ar
[web] www.manas.com.ar
[blog] weblogs.manas.com.ar/mverzilli
–
Derek Ritz
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.