(Brining this discussion to the provider registry mailing list.)
Ryan, yes I think it is fair that we can put this onto the HWR + cronjob. I do like your diagram better. Do by any chance have the source to copy/paste into the workflow wiki page:
https://wiki.ohie.org/display/documents/Merge+Federated+Health+Worker+Directories
If not, I don’t mind updating the diagram.
I don’t think that we would technically be breaking the profile, it is just that the pair (IL,HWR) is the InfoManager rather than the HWR. Actually, even with your diagram I think it technically still be the pair that is the InfoManager as the message is passing through the IL, but I am perhaps splitting hairs 
Where do you think the logging would go? Just after arrows [3]? Or [2] and [3]?
Cheers,
-carl
···
On Tue, Feb 25, 2014 at 4:53 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Sorry for being the slow one in your class… and thank you for being so patient with me. J
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: Carl Leitner [mailto:litlfred@gmail.com]
Sent: Tuesday, February 25, 2014 9:28 AM
To: Derek Ritz (ecGroup)
Cc: Ryan Crichton; Hannes Venter
Subject: Re: federated health worker directory workflow
Yep, that would be it
Cheers,
-carl
On Feb 25, 2014, at 1:53 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Carl – thank you! The penny dropped and a gumball came out of my mouth! J
OK… so to tell this back to you… the HWR (InfoMan) “cache” is not only a cache of data from source directories. It may also be the actual managed HW “directory” in cases where there is not a separate underlying source directory that maintains this information. In such a scenario, the Xquery CRUD is maintaining the “source directory” for this content… which is the InfoMan cache.
Gumball, anyone?
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: Carl Leitner [mailto:litlfred@gmail.com]
Sent: Monday, February 24, 2014 11:20 AM
To: Derek Ritz (ecGroup)
Cc: Ryan Crichton; Hannes Venter
Subject: Re: federated health worker directory workflow
Hi Derek,
No worries, you haven’t hit a nerve at all. Sorry if you got that impression, and sorry because of the miscommunication.
First the easy question. There are two InfoManagers because we have a HWR and a FR. The OpenHIE HWR leverages the architecture for the design of the HWR, but is is not the "full CSD Registry.” We could have just have easily based the OpenHIE HWE on a traditional relational database. I definitely don’t want to bring the CRUD required to support OpenInfoMan as a data store to ITI.
I am going to repeat my understanding a bit with some references to CSD.
Looking at the Issue CSD010 we have: "Data administration issues such as data reconciliation, data validation, data integrity etc. associated with the Add/Update/Delete operations are considered back-end processes for the purpose of this profile and proposed to be addressed by the policies and procedures of the organization managing the HPD” (there are a few places with language to this effect).
What I am talking about for the HWR is strictly within these “back-end” considerations. I have decided to leverage the CSD actors for the development of a back-end HWR registry. There are three main situations I think we need to deal with.
Situation 1) Typically you will an individual HWs represented in two distinct systems:
- A professional council system = SD1
- A typical HRIS system at a MOH = SD2
Because of this, we will pretty much always end up in a fault state if we try to merge health workers in SD1 and SD2 and are thus subject to 3.74.4.2.4 Error Handling. The exact mechanism for resolving these duplicates is again out of scope of the IHE profile. We are left to defining the back-end process (which I have been generally calling the data governance policy). In general, this is what I expect to happen:
- existing certifications from a council system (SD1) are updated in the cache (HWRDS) against the CSD document received SD1
- deployment information from an HRIS system (SD2) are updated in the cache (HWRDS)
The InfoMan in general is going to make it’s updated information available to any system acting as a service finder. It may well be the case that a SD2 system asks the infoman for the certification information coming from SD1. However, I don’t think we are ever going to assume that this is the case and shouldn’t build this.
Situation 2) In the case of a federation, such as State 1:
- State 1 = SD3
- State 2 = SD4
The overlap in data is going to be a bit less. But as people move across states, we will end up in a fault state for that record. Again we need to specify out the "back-end” processes for updating the HWR. Something like “update deployment for facilities in State 1 only from SD3. update deployment for facilities in State 2 only for SD3”
Situation 3) There is no actively managed back-end system to deal with a subset of health workers. In which case the HWR UI can be used to add/update information on these HWS (think of the CHWs in Rwanda). At the face of it, this leaves open the possibility for a user of the HWR UI to change data coming from one of the source directories that are actively managed. Again, what to do here comes down to the data governance issue for the country. I can see several possible scenarios that the stockholders may want:
- Do not allow changes in the cache/HWRDS to be made to data coming from trusted source systems (which is what I think you are recommending)
- Allow changes to the cacheHWRDS but provide an appropriate mechanism for the trusted source systems (or users there of) to view those change. Here maybe ATNA logging could be leveraged for this. It could also be that the responsibility of user of the HWR is to also inform the SD to make the requested changes.
And yes, it could be that if a SD makes a change that will end up overwriting any manual changes made to the cache/HWRDS. I don’t know that this is a bad thing and may have been prompted by a feedback mechanism from the HWR UI to the SD per the second bullet just above.
Cheers,
-carl
On Feb 24, 2014, at 2:55 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Hi Carl.
Sorry… sorry because I think I must be misunderstanding and sorry because I don’t mean to at all hit a nerve on this topic.
My worry is that it looked like we are planning to support, via Xquery update (which is CSD-legal, I agree), the updating of the InfoMan cache. I would have thought that updating the cache would put it out of sync with the underlying SDs and, so, we would need to percolate updates from the cache to the SDs.
I had also understood that we were thinking of bringing this CRUD idea to ITI as a CP. If we’re not planning to do that then the challenges of building consensus around this idea is one we don’t need to worry about.
The two InfoMan design is still not one I fully grasp, and I’m embarrassed about that. I have attached a websequencediagram to try to get my head around it. Please, can you let me know if I’m on the right track with this? The part that I don’t “get” is in the first section: transactions [1] and [2]. It would appear, on the surface of it, that this would put the HWRDS cache out step with the data in the underlying service directories. Furthermore, the HWRDS cache would be in danger of being overwritten (wiping out the impact of trans [1] and [2]) the next time a refresh was done (transactions [4] and [5]).
<image001.jpg>
Am I missing something obvious? Again, sorry if I am.
Thanks and warmest regards,
Derek.
PS: the pseudocode is here:
participant “service finder”
participant infoman
participant HWRUI
participant HWRDS
participant “service dir”
alt CRUD transactions against HWRDS
parallel [
note over HWRUI: as service finder
note over HWRDS: as infoman
}
HWRUI → HWRDS: [1] ITI-73 \nCRUD in Xquery
HWRDS → HWRDS: update cache
HWRDS → HWRUI: [2] ITI-73 \nXquery response
end
alt refresh HWRDS cache
HWRUI → HWRDS: [3] initiate refresh
loop for each service dir
note over HWRDS: as infoman
HWRDS → service dir: [4] ITI-74 \nSOAP refresh trans
service dir → HWRDS: [5] ITI-74 \nSOAP response
HWRDS → HWRDS: update cache
end
HWRDS → HWRUI: [6] response
end
loop xref content from org, facility, HWR, service dirs
alt if HWR refresh
note over HWRDS: as service dir
infoman → HWRDS: [7] ITI-74 \nSOAP refresh trans
HWRDS → infoman: [8] ITI-74 \nSOAP response
else if other directory
infoman → service dir: [7] ITI-74 \nSOAP refresh trans
service dir → infoman: [8] ITI-74 \nSOAP response
end
infoman → infoman: update cache
end
service finder → infoman: [9] ITI-73 Xquery
infoman → service finder: [10] ITI-73 Xquery response
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: Carl Leitner [mailto:litlfred@gmail.com]
Sent: Monday, February 24, 2014 8:57 AM
To: Derek Ritz (ecGroup)
Cc: Ryan Crichton; Hannes Venter
Subject: Re: federated health worker directory workflow
Hi Derek,
For your PS….
I am not sure what you mean about the cascading from the SF->InfoMan->SD. In the case that we are talking about we have:
- Health Worker Registry User Interface:
- acts as a Service Finder against OpenInfoMan HWR Data Store (performing CRUD operations via a careServicesRequest)
- initiates “queries for update services” transactions against a number of source Service Directories
- OpenInfoMan HWR Data Store:
- acts as an InfoMan for the HWRUI
- acts as Provider Service Directory for another InfoManager which merges Facilities, Services, Providers and Orgs
I am not suggesting in this setup that there is some mechanism for a HWR UI to permit modification of data in any of the source Service Directories themselves.
More generally, I am not sure what this has to do with the ITI committee. An InfoMan can support any number of stored queries by defining a careServicesFunction (which contains the UUID, the XQuery, description, and query parameters). It would be up to the implementation as to what types of queries that it would support – if they want to include updating ones or not. There is nothing in CSD that implicitly or explicitly restricts the types of xqueries being executed. The only constraint I see is “must support XQuery 1.0" but that doesn’t mean you couldn’t use XQuery 3.0, or the XQuery Update Facility.
Cheers,
-carl
On Feb 24, 2014, at 1:33 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Hi all.
The question of ATNA logging is a good one. I know that IHE generally saves ATNA as a required profile only for cases where there is PHI being accessed. One of the things we should consider, tho, is that ATNA affords us a defined way to do ALL of our audit logging. I know that the Mohawk folks have got into audit log mining for all sorts of other purposes besides just PHI access tracking. They use it for general “management” and are able to leverage tools such as the visualizer in useful ways to do that.
Should we just decide that ATNA is the “horse for the course” and use it all the time everywhere? Or maybe just the AT part since we won’t necessarily always use the NA part if we’re communicating inside our own datacentre.
Just a thought…
DJ
PS: I think we should seriously consider what are the implications of supporting more than just read-only transactions against an InfoMan. My gut instinct (my STRONG gut instinct) is that the cascading of “updates” or “inserts” or “deletes” from a Service Finder to an InfoMan to a Service Directory would be nightmarish – and unlikely to be supported by the ITI committee. Their reticence would be understandable; this is a degree of complexity that would be really hard to manage, and I don’t know how it could be worth the grief.
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: Carl Leitner [mailto:litlfred@gmail.com]
Sent: Monday, February 24, 2014 6:21 AM
To: Ryan Crichton
Cc: Derek Ritz (ecGroup); Hannes Venter
Subject: Re: federated health worker directory workflow
Hi,
The loop was really looping over the set of the SDs. I have removed the loop and put in SD1, SD2,…SDN. Hopefully the intention is clearer.
Are there any implications to monitoring/logging of the polling if we move away from the IL to a cronjob to initiate the transactions? It seems then we would need to have the HWR to send a log message to the ATNA logging facility rather than have the IL do it…. That functionality isn’t there.
Which bring us to a larger question: should we putting the ATNA logging in these workflows.
Cheers,
-carl
On Feb 24, 2014, at 8:41 AM, Ryan Crichton ryan@jembi.org wrote:
Hi Carl,
I agree for [1] this is how it happens for the OpenHIM’s OpenInfoMan implementation, but I don’t think the IL needs to initiate the merge for the HWR. This is something the HWR should be responsible for. At least in the logical workflow. In practice this could be a cron job or similar.
The rest seems good to me. I just wonder if both [1] and [5] should also be in the loop. For this workflow it seems to me that everything happens in a loop really.
Cheers,
Ryan
On Thu, Feb 20, 2014 at 3:02 PM, Carl Leitner litlfred@gmail.com wrote:
I meant to say that I am open to changing things. I was more documenting what is happening now.
(In any case, there isn’t a good way to setup a polled thing from within the BaseX database itself, as far as I see. We would still need to have something act to initiate the polling, whether that is a cronjob or the OpenHIM Orchestrator)
Cheers,
-carl
On Feb 20, 2014, at 7:59 AM, Carl Leitner litlfred@gmail.com wrote:
Hi All,
What I am trying to reflect in this diagram is the OpenInfoMan Orchestrator:
The Orchestrator is part of OpenHIM and it hits the OpenInfoMan. It is what is controlling the polling behavior.
I guess, really, in this instance the pair of (OpenHIM,OpenInfoMan) are serving the Info Manager role.
Cheers,
-carl
On Feb 20, 2014, at 6:10 AM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Hi Carl.
Like Hannes, I’m not clear on the role of message 1. It kinda looks like the IL and the HWR are both InfoMan actors and that the IL InfoMan is telling the HWR InfoMan that it (the IL) is going to do a refresh (ITI-74) on the HWR’s behalf… and then send it the results (which it does in message [4] – but in a non-standard communication since this is a response to a message the HWR did not ever initiate).
Cannot the ITI-74 be executed directly by the HWR to its underlying data sources? The SOAP interaction can be secured using ATNA so there is not a worry of these data sources “talking to a stranger”. I think I’m missing the role of the cascading InfoMan pattern.
I apologise, with some embarrassment, if this is something obvious that everyone gets except me… L
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: Hannes Venter [mailto:hannes@jembi.org]
Sent: Thursday, February 20, 2014 3:15 AM
To: Carl Leitner
Cc: Derek Ritz (ecGroup); Ryan Crichton
Subject: Re: federated health worker directory workflow
Hi Carl,
This looks good to me, it’s actually very similar to the flow for the CR-SHR reconciliation in RHEA (patient merge updates)
where we also use the IL to periodically trigger updates between registries (and seems to be a convenient solution).
To only thing that wasn’t clear to me was the link between transaction #1 and #2.
After the trigger, does the IL create the message for 2 (in which case, what’s 1’s purpose?), or does the HWR do that after being “woken up” by the IL (and then send it via the IL)?
Cheers
Hannes
On 19 February 2014 18:12, Carl Leitner litlfred@gmail.com wrote:
Hey, here is an initial stab. Would appreciate your comments.
https://wiki.ohie.org/display/documents/Merge+Federated+Health+Worker+Directories
Cheers,
-carl
–
Hannes Venter
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org