Thanks for the useful response.
In (1), I was referring to situations where the same site had multiple IDs, in fact multiple records, coming from multiple sources of truth. If, for a given site, every field present in any source has the same value in every source, there is no conflict and it should be possible to assign all of them the same ID from the InfoMan context with their original IDs becoming alternate IDs in the source’s context. If there are field value conflicts, then there needs to be a workflow to get them resolved. (Of course, this applies to all 4 objects, not just facilities.)
In (2), this is what I expected the answer to be. We have the same problem in the FR community. I think I see something new in Carl’s CSD which follows the ITI-74 loop with a resolution procedure. Maybe Shaun can give some HIE workflows with error queues as an example.
In (3), I was looking for way to synchronize registries without back-propagation. So suppose two registries send each other ITI-74s (not at the same time). One polls the other and receives back its own and the other source’s records, as identified by the source field. It compares what it has with what it receives and applies data governance rules to determine which changes it will accept. Later it is polled and returns all the unaccepted changes (as restorations to previous values for edits, deletes to unaccepted adds, and adds to unaccepted deletes). But in the interim, the unaccepted change may have been changed yet again; or some innocent bystander app may have requested something from the previous state and found only the unacceptable edited state.
The question of where the registry CRUD operations go needs attention. I think a good case could be made that an InfoMan that is serving the cross-referencing function should be a source of truth for all the data it provides, leaving the federation/resolution/backporting/synchronization issues to be handled between the InfoMan and its subscribing registries.
···
-----Original Message-----
From: Derek Ritz
Sent: May 9, 2014 12:16 PM
To: Roger Friedman
Subject: Re: Fwd: Save encounter workflow - Validating a facility
Hi Roger.
You are pointing to core issues that we grappled with when scoping the CSD profile. Here are my comments regarding your points. To be clear, however, these are not “definitive” comments. There is nothing to prevent systems from implementing functionality BEYOND the scope of the CSD profile – in fact, it is encouraged and, frankly, is the basis of how different products compete with each other. My comments only apply as regards what is “conformant” under the present CSD spec.
(1) Is there a way to dedupe InfoMan’s cache?
On page 67 of the CSD spec, in section 3.74.4.2.3 “Expected Actions”, the required actions on the part of an InfoMan are described when the InfoMan receives an ITI-74 response. This is where deduping is “flagged”. The required actions (to be conformant with the CSD spec) are described in detail on pages 67 and 68; I won’t bother repeating them here. Specifically regarding dupes, the required actions are described in section 3.74.4.2.4.2 “Duplicate Unique IDs”. The specified actions are:
A Care Services InfoManager shall ensure that all directory records in its content cache have
unique IDs. This means that no two Care Services Directory actors may submit a directory
record with the same oid attribute. A Care Services InfoManager that contains cached directory
records with duplicate IDs shall remain offline until this situation has been remediated. Care
Services InfoManagers in an offline state shall respond to all inbound Find Matching Services
[ITI-73] messages with an error message 422 plus appropriate message text indicating its fault
condition (duplicate IDs). IHE does not define the remedial actions to address this fault
condition.
Roger – IHE does not specify how de-duping is to be done. It does require, however, that an InfoMan with dupes in the cache remains in an offline state until these are resolved. My position regarding this topic is that the issue should be genuinely resolved at the underlying directories and that the cache should be refreshed. I think it would be very inappropriate for the InfoMan to “fix” its cache while the underlying problems – which are real and potentially impactful problems – remain unresolved in the source directories.
(2) Are CRUD operations on the underlying registries supposed to be done by editing InfoMan’s cache with the changes then back-propagating to the source registry, or is the modifying app supposed to communicate directly with the source registry about changes, which are then ITI-74’ed into the InfoMan?
It is the latter. We are finding, in deployment situations, that there are often multiple source directories which already have their own management applications and – even more importantly – their own data governance. There is not, in the CSD spec, support for CRUD operations against the InfoMan cache except through ITI-74. The posture of the CSD spec is that all data maintenance should happen at the source directory. Where this becomes interesting is in an InfoMan-as-directory situation. Now what? This is a topic the HWR community has discussed on its calls and this is an area where the software “product” may go beyond the CSD spec; such as to explore support for CRUD on the HWR-InfoMan cache using the presently balloted extensions to XQuery.
(3) An ITI-74 overwrites the InfoMan cache. Is there any way to resolve conflicting data rather than just overwrite? What is the value of source when data from one registry is replicated in another? What is the value of source when the replicate is edited?
As described above, the expectation is that the directories will be “definitive” sources of data. The CSD spec actually requires that “conformant” directories are able to be definitive sources of truth. On page 22 of the CSD spec, the requirements that apply to directories are described:
In order for the Care Services InfoManager’s cached content to be able to serve its role as an
interlinked data source, the following conditions shall be met by Care Services Directory actors
who maintain directory content.
- Implementing jurisdictions may mandate code sets for Organization Type, Service Type,
Facility Type, Facility Status, Provider Type, Provider Status, Contact Point Type,
Credential Type, Specialization Code, and language code. Care Services Directory actors
shall be configurable to use these code sets, where mandated.
- Implementing jurisdictions may mandate conventions regarding the types, components
and formatting of Name, Address and AddressLine elements. Care Services Directory
actors shall be configurable to use these formatting conventions, where mandated.
- Implementing jurisdictions may mandate the source of truth regarding organization ID,
service ID, facility ID and provider ID. Care Services Directory actors shall ensure that
all cross referenced IDs match corresponding directory records in the jurisdictionally
mandated sources of truth.
Roger, when directories were signing up to participate in the Chicago Connectathon I advocated for every “directory” to also support ITI-73 (the Find Matching Services transaction). In my view, any HWR that is referencing a facilityID must be able to access the “source of truth” regarding that ID… and this source of truth is the InfoMan’s cache. So, for a HWR to correctly make references to facilityIDs it must be able to execute an ITI-73 to search for the “correct” ID value it should reference. In a nutshell – we need to be able to eat our own cooking; every source directory should also be able to be a consumer of the InfoMan when it needs to reference the ID of another directory.
I hope this is helpful.
Warmest regards,
Derek.
On Fri, May 9, 2014 at 11:13 AM, r.friedman@mindspring.com wrote:
Derek, thanks for the response. It pointed me to the right places in the doc.
(1) Is there a way to dedupe InfoMan’s cache?
(2) Are CRUD operations on the underlying registries supposed to be done by editing InfoMan’s cache with the changes then back-propagating to the source registry, or is the modifying app supposed to communicate directly with the source registry about changes, which are then ITI-74’ed into the InfoMan?
(3) An ITI-74 overwrites the InfoMan cache. Is there any way to resolve conflicting data rather than just overwrite? What is the value of source when data from one registry is replicated in another? What is the value of source when the replicate is edited?
-----Original Message-----
From: Derek Ritz
Sent: May 8, 2014 11:12 AM
To: “ohie-architecture@googlegroups.com” , facility-registry@googlegroups.com
Subject: Fwd: Save encounter workflow - Validating a facility
Hi all.
I think we can note two distinctly important roles that an InfoMan can play:
-
An InfoMan can aggregate federated directories of the same type (e.g. multiple underlying “health worker registry” datasources). Each of these federated directories must support the ITI-74 transaction.
-
An InfoMan can cross-index 4 different types of directories: facilities, health workers, organizations, services. Each of these directories must support ITI-74.
In a situation where there are multiple health worker directories-of-record in a country, an InfoMan may be employed to create a definitive national HWR by leveraging role #1. This InfoMan would invoke ITI-74 to collect content from multiple datasources and cache it. This cache is now a definitive national HWR. For this cache to participate as a directory in its own right, it must itself expose ITI-74.
In Chicago in January the OpenHIE IL certified its ability to be an InfoMan. If the IL-InfoMan is playing role #2, it may now cross-index content from any directory that exposes an ITI-74 interface. The OpenHIE HWR exposes just such an interface. So do both the OpenHIE FRs (InSTEDD and DHIS).
How many InfoMan instances do we need? To be blunt, TECHNICALLY we only need one. But this is a sociotechnical problem, too. In truth, we are well-served to be able to leverage the community of practice around health worker management to ensure that the definitive national HWR is appropriately de-duped, and that conflicts between the underlying directories-of-record can be worked out and fixed at their origin (not just at the cache). This means having a HWR-InfoMan playing role #1 is probably a pretty good idea if it affords us a ready way to do that… but TECHNICALLY, it is a matter of convenience for us to have multiple InfoMan instances.
Now… to Ryan’s question. Let’s assume the IL “contains” an InfoMan playing role #2. The IL has proven (in Chicago) that it can be so configured. To validate a health work + facility combination, a call (using ITI-73) can be made against the IL-InfoMan. This call would immediately get its result from the IL-InfoMan’s cache. (This IL-InfoMan cache is refreshed on whatever cycle has been determined for the implementation).
To be sure, at some future time we may choose not to continue to have a notion of a separate, definitive national HWR or FR. Things could evolve to the point where, someday, the underlying directories-of-record for health workers and facilities (and organizations and services) would all be directly polled by the IL-InfoMan using ITI-74 to populate its cache and this single IL-InfoMan would sort out all the de-dupe issues, etc. For now, however, it seems a better sociotechnical solution to “cascade” our InfoMan instances – with some, albeit, only playing role #1.
Separately, I believe the notion that we need to develop a RESTful version of ITI-74 needs a strong case before it warrants the effort to develop a CP (change proposal) for submission to the IHE IT Infrastructure technical committee. I want everyone to understand: this was what Carl and I first proposed to them over a year ago. There was pushback from committee members and compelling arguments were made for the present SOAP-based version of ITI-74. This is what we wrote into the CSD spec and this is what was passed by the IHE.
Today, all of our OpenHIE participants support this SOAP-based ITI-74 and, today, the CSD specification has been supported by the international IHE ITI committee because it can work within the broad range of contexts where health IT systems are presently deployed. This includes the ecosystems in Europe and North America where many legacy health IT systems exist. My point is that, if we deem that this is our burning issue, we should look at introducing a RESTful option for ITI-74, but leave the existing SOAP transaction as the default. Personally, I think there are other issues which are more deserving of our dev efforts and, to be honest, I worry that adding complexity to the CSD specification has its own dangers – but this is just an opinion. A RESTful option for ITI-74 certainly could be developed and brought to ballot (and I would vote in favour of it, if that turned out to be what our communities thought was the best course).
I hope this has been helpful,
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 r.friedman@mindspring.com
Sent: Thursday, May 8, 2014 9:02 AM
To: facility-registry@googlegroups.com; Carl Leitner
Cc: facility-registry@googlegroups.com; Carl Leitner; openhie-interoperability-layer@googlegroups.com; Derek Ritz (ecGroup); Bob Jolliffe
Subject: Re: Save encounter workflow - Validating a facility
I am still trying to understand this stuff, hopefully clarifying my confusion will lead to a solution.
So it seems to me that this issue arises because the FR and the HWR almost inevitably end up as separate data stores with separate management software, with the InfoMan being a facade to hide that fact because the CSD conceptual data model relies on them both. The other two objects in CSD, services and organizations, can end up anywhere as well, so their operations should also be incorporated into the InfoMan repertoire. The InfoMan then acts as an orchestrator of the four object stores to perform the full repertoire of CSD functions. However, in our case, we already have the IL to act as an orchestrator. It can either work directly with the four underlying datastores or it can delegate to another InfoMan (perhaps one packaged with the FR); in any event, it should implement InfoMan.
As I understand Carl, and I may not yet, he envisions the possibility of multiple HWRs feeding the HIE’s HWR, with InfoMan also handling the mutual updating of participating registries. Ways in which this might come about are (1) cadre-specific HWRs, such as physician, nurse, lab tech; (2) care organization-specific HWRs, such as MOH, Armed Forces, Prisons, NGOs, private practices; (3) trans-national HWRs; (4) edge EMRs implementing HWR messaging as a means of accessing local HW data. This also creates the possibility of conflicts between the component registries. (I understand Carl not to be suggesting that InfoMan perform federated queries across HWRs.) This is the same problem as that faced in creating a patient registry from multiple intermittently-connected EMRs, leading to similar messages I would think.
But so as not to digress too far from Ryan’s issue, I think a request message like getHealthWorkerById with a returned representation that includes the health worker’s affiliated facilities would be a basic query. (I don’t know enough about SOAP to say whether there is an equivalent to REST representations.) That should meet the need for validation. Should the endpoint for that message be in HWR or InfoMan or IL? That depends on our conceptual data model for HW; does it include a set of affiliated facilities, or does that not arise until one goes to the higher level (HPD or CSD) of InfoMan or IL? Who owns the join table between FR and HWR – InfoMan/IL or FR/HWR? Should there be a separate join table in each registry, e.g. getHealthWorkerById with a returned representation that includes facilities with which the health worker is affiliated would use a join table in the HWR, while getFacilityById with a returned representation that includes the health workers affiliated with the facility would use a join table in the FR? Note that this join table carries information because changes in it represent personnel actions.
Sorry to answer a question with several questions.
-----Original Message-----
From: Ryan Crichton
Sent: May 8, 2014 2:54 AM
To: Carl Leitner
Cc: “facility-registry@googlegroups.com” , Carl Leitner , “openhie-interoperability-layer@googlegroups.com” , “Derek Ritz (ecGroup)” , Bob Jolliffe
Subject: Re: Save encounter workflow - Validating a facility
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.
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
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
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
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
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
–
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.
–
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
–
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 “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
–
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.
–
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.
–
Derek Ritz
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.
–
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.
–
Derek Ritz
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.
Hi Roger.
Re: your scenario #1 – one of the things we should hold onto is that there cannot be multiple ELIDs (enterprise location IDs) for a single facility. By definition, there will be a SINGLE source of truth regarding a facility (or a provider, organization or service) that will be the “keeper of the flame” regarding that entity’s ID and its correct/definitive attribute set. I even think this rule should apply to the potential “aliases” for this facility (or P,O, or S). It is a matter of opinion, of course, but I just don’t think a cross-propagation pattern is a supportable architectural design.
Re: #3 – I actually think that the directory-as-InfoMan-consumer pattern (where a directory uses ITI-73 to access definitive information it wants to cross-reference) gives us a managed way to propagate definitive IDs and other important attribute info. This helps us avoid the many-to-many pattern of registry-to-registry communication (even if they are using ITI-74). One of the most important roles of the InfoMan is to change this pattern to one that can be managed, albeit through the addition of intermediary actor. If the cardinal rule for everyone who isn’t a directory is that “the InfoMan is the source of truth”, then this becomes a solvable problem. 
hope this helps…
Derek.
···
On Fri, May 9, 2014 at 1:41 PM, r.friedman@mindspring.com wrote:
Thanks for the useful response.
In (1), I was referring to situations where the same site had multiple IDs, in fact multiple records, coming from multiple sources of truth. If, for a given site, every field present in any source has the same value in every source, there is no conflict and it should be possible to assign all of them the same ID from the InfoMan context with their original IDs becoming alternate IDs in the source’s context. If there are field value conflicts, then there needs to be a workflow to get them resolved. (Of course, this applies to all 4 objects, not just facilities.)
In (2), this is what I expected the answer to be. We have the same problem in the FR community. I think I see something new in Carl’s CSD which follows the ITI-74 loop with a resolution procedure. Maybe Shaun can give some HIE workflows with error queues as an example.
In (3), I was looking for way to synchronize registries without back-propagation. So suppose two registries send each other ITI-74s (not at the same time). One polls the other and receives back its own and the other source’s records, as identified by the source field. It compares what it has with what it receives and applies data governance rules to determine which changes it will accept. Later it is polled and returns all the unaccepted changes (as restorations to previous values for edits, deletes to unaccepted adds, and adds to unaccepted deletes). But in the interim, the unaccepted change may have been changed yet again; or some innocent bystander app may have requested something from the previous state and found only the unacceptable edited state.
The question of where the registry CRUD operations go needs attention. I think a good case could be made that an InfoMan that is serving the cross-referencing function should be a source of truth for all the data it provides, leaving the federation/resolution/backporting/synchronization issues to be handled between the InfoMan and its subscribing registries.
-----Original Message-----
From: Derek Ritz
Sent: May 9, 2014 12:16 PM
To: Roger Friedman
Subject: Re: Fwd: Save encounter workflow - Validating a facility
Hi Roger.
You are pointing to core issues that we grappled with when scoping the CSD profile. Here are my comments regarding your points. To be clear, however, these are not “definitive” comments. There is nothing to prevent systems from implementing functionality BEYOND the scope of the CSD profile – in fact, it is encouraged and, frankly, is the basis of how different products compete with each other. My comments only apply as regards what is “conformant” under the present CSD spec.
(1) Is there a way to dedupe InfoMan’s cache?
On page 67 of the CSD spec, in section 3.74.4.2.3 “Expected Actions”, the required actions on the part of an InfoMan are described when the InfoMan receives an ITI-74 response. This is where deduping is “flagged”. The required actions (to be conformant with the CSD spec) are described in detail on pages 67 and 68; I won’t bother repeating them here. Specifically regarding dupes, the required actions are described in section 3.74.4.2.4.2 “Duplicate Unique IDs”. The specified actions are:
A Care Services InfoManager shall ensure that all directory records in its content cache have
unique IDs. This means that no two Care Services Directory actors may submit a directory
record with the same oid attribute. A Care Services InfoManager that contains cached directory
records with duplicate IDs shall remain offline until this situation has been remediated. Care
Services InfoManagers in an offline state shall respond to all inbound Find Matching Services
[ITI-73] messages with an error message 422 plus appropriate message text indicating its fault
condition (duplicate IDs). IHE does not define the remedial actions to address this fault
condition.
Roger – IHE does not specify how de-duping is to be done. It does require, however, that an InfoMan with dupes in the cache remains in an offline state until these are resolved. My position regarding this topic is that the issue should be genuinely resolved at the underlying directories and that the cache should be refreshed. I think it would be very inappropriate for the InfoMan to “fix” its cache while the underlying problems – which are real and potentially impactful problems – remain unresolved in the source directories.
(2) Are CRUD operations on the underlying registries supposed to be done by editing InfoMan’s cache with the changes then back-propagating to the source registry, or is the modifying app supposed to communicate directly with the source registry about changes, which are then ITI-74’ed into the InfoMan?
It is the latter. We are finding, in deployment situations, that there are often multiple source directories which already have their own management applications and – even more importantly – their own data governance. There is not, in the CSD spec, support for CRUD operations against the InfoMan cache except through ITI-74. The posture of the CSD spec is that all data maintenance should happen at the source directory. Where this becomes interesting is in an InfoMan-as-directory situation. Now what? This is a topic the HWR community has discussed on its calls and this is an area where the software “product” may go beyond the CSD spec; such as to explore support for CRUD on the HWR-InfoMan cache using the presently balloted extensions to XQuery.
(3) An ITI-74 overwrites the InfoMan cache. Is there any way to resolve conflicting data rather than just overwrite? What is the value of source when data from one registry is replicated in another? What is the value of source when the replicate is edited?
As described above, the expectation is that the directories will be “definitive” sources of data. The CSD spec actually requires that “conformant” directories are able to be definitive sources of truth. On page 22 of the CSD spec, the requirements that apply to directories are described:
In order for the Care Services InfoManager’s cached content to be able to serve its role as an
interlinked data source, the following conditions shall be met by Care Services Directory actors
who maintain directory content.
- Implementing jurisdictions may mandate code sets for Organization Type, Service Type,
Facility Type, Facility Status, Provider Type, Provider Status, Contact Point Type,
Credential Type, Specialization Code, and language code. Care Services Directory actors
shall be configurable to use these code sets, where mandated.
- Implementing jurisdictions may mandate conventions regarding the types, components
and formatting of Name, Address and AddressLine elements. Care Services Directory
actors shall be configurable to use these formatting conventions, where mandated.
- Implementing jurisdictions may mandate the source of truth regarding organization ID,
service ID, facility ID and provider ID. Care Services Directory actors shall ensure that
all cross referenced IDs match corresponding directory records in the jurisdictionally
mandated sources of truth.
Roger, when directories were signing up to participate in the Chicago Connectathon I advocated for every “directory” to also support ITI-73 (the Find Matching Services transaction). In my view, any HWR that is referencing a facilityID must be able to access the “source of truth” regarding that ID… and this source of truth is the InfoMan’s cache. So, for a HWR to correctly make references to facilityIDs it must be able to execute an ITI-73 to search for the “correct” ID value it should reference. In a nutshell – we need to be able to eat our own cooking; every source directory should also be able to be a consumer of the InfoMan when it needs to reference the ID of another directory.
I hope this is helpful.
Warmest regards,
Derek.
–
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.
–
Derek Ritz
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.
On Fri, May 9, 2014 at 11:13 AM, r.friedman@mindspring.com wrote:
Derek, thanks for the response. It pointed me to the right places in the doc.
(1) Is there a way to dedupe InfoMan’s cache?
(2) Are CRUD operations on the underlying registries supposed to be done by editing InfoMan’s cache with the changes then back-propagating to the source registry, or is the modifying app supposed to communicate directly with the source registry about changes, which are then ITI-74’ed into the InfoMan?
(3) An ITI-74 overwrites the InfoMan cache. Is there any way to resolve conflicting data rather than just overwrite? What is the value of source when data from one registry is replicated in another? What is the value of source when the replicate is edited?
-----Original Message-----
From: Derek Ritz
Sent: May 8, 2014 11:12 AM
To: “ohie-architecture@googlegroups.com” , facility-registry@googlegroups.com
Subject: Fwd: Save encounter workflow - Validating a facility
Hi all.
I think we can note two distinctly important roles that an InfoMan can play:
-
An InfoMan can aggregate federated directories of the same type (e.g. multiple underlying “health worker registry” datasources). Each of these federated directories must support the ITI-74 transaction.
-
An InfoMan can cross-index 4 different types of directories: facilities, health workers, organizations, services. Each of these directories must support ITI-74.
In a situation where there are multiple health worker directories-of-record in a country, an InfoMan may be employed to create a definitive national HWR by leveraging role #1. This InfoMan would invoke ITI-74 to collect content from multiple datasources and cache it. This cache is now a definitive national HWR. For this cache to participate as a directory in its own right, it must itself expose ITI-74.
In Chicago in January the OpenHIE IL certified its ability to be an InfoMan. If the IL-InfoMan is playing role #2, it may now cross-index content from any directory that exposes an ITI-74 interface. The OpenHIE HWR exposes just such an interface. So do both the OpenHIE FRs (InSTEDD and DHIS).
How many InfoMan instances do we need? To be blunt, TECHNICALLY we only need one. But this is a sociotechnical problem, too. In truth, we are well-served to be able to leverage the community of practice around health worker management to ensure that the definitive national HWR is appropriately de-duped, and that conflicts between the underlying directories-of-record can be worked out and fixed at their origin (not just at the cache). This means having a HWR-InfoMan playing role #1 is probably a pretty good idea if it affords us a ready way to do that… but TECHNICALLY, it is a matter of convenience for us to have multiple InfoMan instances.
Now… to Ryan’s question. Let’s assume the IL “contains” an InfoMan playing role #2. The IL has proven (in Chicago) that it can be so configured. To validate a health work + facility combination, a call (using ITI-73) can be made against the IL-InfoMan. This call would immediately get its result from the IL-InfoMan’s cache. (This IL-InfoMan cache is refreshed on whatever cycle has been determined for the implementation).
To be sure, at some future time we may choose not to continue to have a notion of a separate, definitive national HWR or FR. Things could evolve to the point where, someday, the underlying directories-of-record for health workers and facilities (and organizations and services) would all be directly polled by the IL-InfoMan using ITI-74 to populate its cache and this single IL-InfoMan would sort out all the de-dupe issues, etc. For now, however, it seems a better sociotechnical solution to “cascade” our InfoMan instances – with some, albeit, only playing role #1.
Separately, I believe the notion that we need to develop a RESTful version of ITI-74 needs a strong case before it warrants the effort to develop a CP (change proposal) for submission to the IHE IT Infrastructure technical committee. I want everyone to understand: this was what Carl and I first proposed to them over a year ago. There was pushback from committee members and compelling arguments were made for the present SOAP-based version of ITI-74. This is what we wrote into the CSD spec and this is what was passed by the IHE.
Today, all of our OpenHIE participants support this SOAP-based ITI-74 and, today, the CSD specification has been supported by the international IHE ITI committee because it can work within the broad range of contexts where health IT systems are presently deployed. This includes the ecosystems in Europe and North America where many legacy health IT systems exist. My point is that, if we deem that this is our burning issue, we should look at introducing a RESTful option for ITI-74, but leave the existing SOAP transaction as the default. Personally, I think there are other issues which are more deserving of our dev efforts and, to be honest, I worry that adding complexity to the CSD specification has its own dangers – but this is just an opinion. A RESTful option for ITI-74 certainly could be developed and brought to ballot (and I would vote in favour of it, if that turned out to be what our communities thought was the best course).
I hope this has been helpful,
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 r.friedman@mindspring.com
Sent: Thursday, May 8, 2014 9:02 AM
To: facility-registry@googlegroups.com; Carl Leitner
Cc: facility-registry@googlegroups.com; Carl Leitner; openhie-interoperability-layer@googlegroups.com; Derek Ritz (ecGroup); Bob Jolliffe
Subject: Re: Save encounter workflow - Validating a facility
I am still trying to understand this stuff, hopefully clarifying my confusion will lead to a solution.
So it seems to me that this issue arises because the FR and the HWR almost inevitably end up as separate data stores with separate management software, with the InfoMan being a facade to hide that fact because the CSD conceptual data model relies on them both. The other two objects in CSD, services and organizations, can end up anywhere as well, so their operations should also be incorporated into the InfoMan repertoire. The InfoMan then acts as an orchestrator of the four object stores to perform the full repertoire of CSD functions. However, in our case, we already have the IL to act as an orchestrator. It can either work directly with the four underlying datastores or it can delegate to another InfoMan (perhaps one packaged with the FR); in any event, it should implement InfoMan.
As I understand Carl, and I may not yet, he envisions the possibility of multiple HWRs feeding the HIE’s HWR, with InfoMan also handling the mutual updating of participating registries. Ways in which this might come about are (1) cadre-specific HWRs, such as physician, nurse, lab tech; (2) care organization-specific HWRs, such as MOH, Armed Forces, Prisons, NGOs, private practices; (3) trans-national HWRs; (4) edge EMRs implementing HWR messaging as a means of accessing local HW data. This also creates the possibility of conflicts between the component registries. (I understand Carl not to be suggesting that InfoMan perform federated queries across HWRs.) This is the same problem as that faced in creating a patient registry from multiple intermittently-connected EMRs, leading to similar messages I would think.
But so as not to digress too far from Ryan’s issue, I think a request message like getHealthWorkerById with a returned representation that includes the health worker’s affiliated facilities would be a basic query. (I don’t know enough about SOAP to say whether there is an equivalent to REST representations.) That should meet the need for validation. Should the endpoint for that message be in HWR or InfoMan or IL? That depends on our conceptual data model for HW; does it include a set of affiliated facilities, or does that not arise until one goes to the higher level (HPD or CSD) of InfoMan or IL? Who owns the join table between FR and HWR – InfoMan/IL or FR/HWR? Should there be a separate join table in each registry, e.g. getHealthWorkerById with a returned representation that includes facilities with which the health worker is affiliated would use a join table in the HWR, while getFacilityById with a returned representation that includes the health workers affiliated with the facility would use a join table in the FR? Note that this join table carries information because changes in it represent personnel actions.
Sorry to answer a question with several questions.
-----Original Message-----
From: Ryan Crichton
Sent: May 8, 2014 2:54 AM
To: Carl Leitner
Cc: “facility-registry@googlegroups.com” , Carl Leitner , “openhie-interoperability-layer@googlegroups.com” , “Derek Ritz (ecGroup)” , Bob Jolliffe
Subject: Re: Save encounter workflow - Validating a facility
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.
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
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
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
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
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
–
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.
–
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
–
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 “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
–
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.
–
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.
–
Derek Ritz
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.
–
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.
–
Derek Ritz
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.