Hi all,
So to try get a feel for the consensus of this thread, does everyone agree with the following statement:
- For validating a facility and that a certain provider works at that facility during an OpenHIE save encounter workflow, a cross-registry infomanager should be queried. This infomanager will make use of the standard CSD queries where possible but will be extended with custom queries if needed.
If you don’t agree what suggestions do you have for doing this better?
Cheers,
Ryan
···
On Sat, Apr 26, 2014 at 2:08 AM, Carl Leitner litlfred@gmail.com wrote:
Hi Martin,
I agree that is a good feature to have in there. I think that this largely a policy issue for the specific MOH so we should make it flexible enough, as Ryan has suggested, to let the MOH configure it.
Just a quick comment about the custom queries. They are highly structured in XML and identified by a UUID. As the index is a UUID, rather than a URL I think that it may provide a good balance to allow for adding a new functionality to the API while preserving backward compatibility. Perhaps once drawback is that it does not allow any inherent versioning to the stored queries, which is maybe what you are thinking of. I think it should be in the standard (if it is not already) that any changes to the query (in terms of input parameters or format of the output) should require a new UUID. Do you think language to that effect would be good enough?
If you haven’t seen this yet, here are the stored queries required by CSD:
https://github.com/openhie/openinfoman/tree/master/resources/stored_query_definitions
as well as some optional ones developed to support CRUD access to the provider directory as part of the OpenHIE HWR UI:
https://github.com/openhie/openinfoman-hwr/tree/master/resources/stored_query_definitions
The .xml files are the definitions of the stored queries which do an xinclude on the corresponding .xq file containing the xquery definition.
This structure (the .xml) of a stored query is specified in the CSD document. If you think it is worthwhile to modify this with version attributes or something, I would appreciate your input.
Cheers,
-carl
On Apr 25, 2014, at 12:28 PM, Martin Verzilli mverzilli@manas.com.ar wrote:
My email processing cycle seems to be a bit slow for this thread, sorry for revisiting some “old” topics here :D.
@Derek: I’m still hesitant about custom queries. One of the main goals of having a well defined API is to be able to rapidly evolve your internal implementation while ensuring clients that certain things won’t change (whereas they’ll have to accept that to get new features they’ll probably need to upgrade to a newer version of your API). The things which you guarantee won’t change happen to be your API’s contract.
The more expressive your API, the more difficult it becomes to evolve your service without breaking your clients’ code. Custom queries do feel a little too expressive in that sense. If it becomes difficult to evolve your implementation because you may be breaking backwards compatibility against some obscure custom use of the InfoMan by any of its clients, it will likely cause that evolution to halt.
Too much expressiveness in an API also means it becomes more difficult for different implementors to comply with it in an homogeneous way. An infamous example of this are browsers, which never seem to nail implementations so that web devs can forget about thoroughly testing the same product in a wide array of browser/version/platform combinations.
I’d rather go with a more structured approach, with clear semantics and evolution through API versioning.
@Ryan: I like the idea of having “dedicated” infomans to deal with inter-registry conflicts. Those boxes would somehow embody the particular governance logic for a given instance of the architecture that Derek was talking about in his last email.
@Carl: “the HW doesn’t actually formally work at that facility. Should the message be blocked in this case? I am not sure”. From a functional point of view, I think it’d be OK to reject the message as long as we provide the PoC app with functionality that lets it handle alternate courses of action.
For example, if someone is trying to create an encounter with a provider who doesn’t work at a given facility, it may make sense for the PoC to show the user which facilities that specific provider works at or which providers work at that facility (which one of those is more appropriate will ultimately depend on the use case being addressed). Provided that the PoC can get that data from the OpenHIM, I think validating that the relationship exists is a good feature to provide.
–
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.
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
On Fri, Apr 25, 2014 at 8:33 AM, Carl Leitner cleitner@capacityplus.org wrote:
I like the options for enabling/disabling the validation.
On Apr 25, 2014 6:28 AM, Ryan Crichton ryan@jembi.org wrote:
Hi all,
@Carl L, well I guess that is for us to decide, I would say it shouldn’t get processed and rather go into an error queue. There we can resolve why it has failed. I would suggest that we have a mechanism to enable/disable these checks as in different environments
some of these may be difficult to manage.
@Alvin, thanks for the addition, that is quite helpful.
I have added this list to the
save encounter wiki page under a section heading called discussions so we can keep track of these and discuss then further.
Do other agree with these and if so, how should message that fail these criteria be handled?
Cheers,
Ryan
–
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
On Fri, Apr 25, 2014 at 2:38 AM, Alvin Marcelo
alvin.marcelo@gmail.com wrote:
- When an encounter is received we validate that:
- The facility is valid and operational
- The provider is valid and currently practicing
- The provider currently works at the facility
- The provider currently provides the service requested at the facility
–
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.
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH
AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
All of above are valid in the Philippines. In addition, at PhilHealth, there is the additional constraint that the service is allowed in that facility (eg, you can’t do an appendectomy in a health center even if the general surgeon
volunteers there on weekends as a GP).
So to add another bullet:
- the service is allowed at the facility
alvin
Alvin B. Marcelo, MD, FPCS, CGEIT
On Thu, Apr 24, 2014 at 4:34 PM, Ryan Crichton
ryan@jembi.org wrote:
Hi All,
@Derek, I would definitely be in support of that. I agree our validation for the Rwandan HIE have been minimal at best and improving upon this would be highly beneficial. Perhaps we should come up with a proposal of what sort of validation we could do
to make this more worth while and to help inform us of what transaction would make the most sense to perform these validations (and where we would need to create custom queries).
As a first pass, for the save encounter workflow, here is what makes sense to me:
- When an encounter is received we validate that:
- The facility is valid and operational
- The provider is valid and currently practicing
- The provider currently works at the facility
- The provider currently provides the service requested at the facility
Should we add logic to the save encounter workflow to enable these checks? Are there other check that makes sense? Do these ones make sense?
These validations will help us design a solution for what transaction will be needed. The above seems to fall in the ball park of CSD, however which registries provide what actors is still the question at hand. To perform any sort of cross-referencing
we will need some sort of central cross-registry info manager . This doesn’t mean that other registries can’t also be info managers for their domain. For example if there are many sources of provider information the provider registry could implement
a provider info manager actor that just manages merging providers information from various sources. This could then be drawn upon as the source off truth for provider information and used to provide a feed of provider information to the
cross-registry info manager, where provider, facility, organisation and service information can be stored.
Are there other ways this could be done better or does this make sense?
Cheers,
Ryan
–
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.
On Wed, Apr 23, 2014 at 9:33 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
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
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;
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
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 toopenhie-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
–
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