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.

···

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. :wink:

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:

  1. 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.

  1. 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:

  1. 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.
  1. 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

-----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


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.

Hi all.

I think we can note two distinctly important roles that an InfoMan can play:

  1.  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.
    
  2.  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. :wink:

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:

  1. 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.

  1. 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:

  1. 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.
  1. 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.

Hi all.

I think we can note two distinctly important roles that an InfoMan can play:

  1.  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.
    
  2.  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. :wink:

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:

  1. 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.

  1. 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:

  1. 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.
  1. 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.

Hi all,

@Derek, thanks for explaining that is details, that is precisely my understanding as well.

I have edited the save encounter diagram to help illustrate how this would work. Please let me know if you all agree with what I have described here. I have updated the save encounter page as well as attached the new image to this email.

Looking forward to your thoughts.

Cheers,

Ryan

save-enc-uml-sequence.png

···

On Thu, May 8, 2014 at 5:12 PM, Derek Ritz derek.ritz@gmail.com wrote:

Hi all.

I think we can note two distinctly important roles that an InfoMan can play:

  1.  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.
    
  1.  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. :wink:

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:

  1. 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.

  1. 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:

  1. 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.
  1. 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.


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org