Save encounter workflow - Validating a facility

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: ryan@jembi.org

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 ryan@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: ryan@jembi.org


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

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.

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

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.

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

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?

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

Hi Ryan.

I completely agree. With a CSD-conformant InfoMan in the architecture, it will be the source of truth for all facility, provider, organization and service info. This will include facility ID, provider ID, organization ID, service ID. My point was that this should maybe be contemplated; maybe a standalone FR should always “come with” an InfoMan.

I think I’d even go farther, tho… I think an FR should always come with a HIM (which, of course, has an InfoMan in it).

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: Ryan Crichton [mailto:ryan@jembi.org]
Sent: Tuesday, April 22, 2014 5:17 AM
To: Derek Ritz (ecGroup)
Cc: Martin Verzilli; facility-registry@googlegroups.com; Carl Leitner; openhie-interoperability-layer@googlegroups.com
Subject: Re: Save encounter workflow - Validating a facility

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?

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.

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

forwarding to the FR group…

···

---------- Forwarded message ----------
From: Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com

Date: Tue, Apr 22, 2014 at 7:11 AM
Subject: RE: Save encounter workflow - Validating a facility
To: Ryan Crichton ryan@jembi.org
Cc: Martin Verzilli mverzilli@manas.com.ar, facility-registry@googlegroups.com, Carl Leitner cleitner@capacityplus.org, openhie-interoperability-layer@googlegroups.com, derek.ritz@gmail.com

Hi Ryan.

I completely agree. With a CSD-conformant InfoMan in the architecture, it will be the source of truth for all facility, provider, organization and service info. This will include facility ID, provider ID, organization ID, service ID. My point was that this should maybe be contemplated; maybe a standalone FR should always “come with” an InfoMan.

I think I’d even go farther, tho… I think an FR should always come with a HIM (which, of course, has an InfoMan in it).

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: Ryan Crichton [mailto:ryan@jembi.org]
Sent: Tuesday, April 22, 2014 5:17 AM
To: Derek Ritz (ecGroup)
Cc: Martin Verzilli; facility-registry@googlegroups.com; Carl Leitner; openhie-interoperability-layer@googlegroups.com
Subject: Re: Save encounter workflow - Validating a facility

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?

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.

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


Derek Ritz

This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.

Hi All,

I do like where this conversation is going. I think its important to think about CSD as identifying roles (not necessarily distinct pieces of software). So, if desired, a FR could play the two roles of a Services Directory and an Info Manager. However, that may make a certain amount of programming on the FR side. An alternative is just to have an InfoMan sit in front of the FR (acting as a Services Directory) and respond to queries like “read by id” that Martin mentions. The current OpenInfoMan support exactly this pretty much out-of-the-box :

  • deploy a FR as a Services Directory
  • light up an OpenInfoMan that points only to the FR
  • publish to the InfoMan an stored query for “Read By Id”
    Yes, there will be a cache involved, but you are free to set your poll time to whatever you wish. If you are really worried about caching, you can support CRUD operations on the InfoManager (this was how the HWR was built as an InfoMan).

At least in the context of the health workforce information systems (HWIS), having only one transaction that a Services Directory must respond to (“get updated services”) puts only a very minimal burden on existing systems. For example in Nigeria, we are looking at a HWIS being deployed for each of the states, one for the Federal MOH, as well as one for each of the councils. These could all be different systems. So I would have a preference to keep conformance to CSD from the Services Directory be as simple/stupid as possible.

Cheers,
-carl

···

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

Agree with Martin on all counts.

···

On 22 April 2014 12:21, Derek Ritz derek.ritz@gmail.com wrote:

forwarding to the FR group…

---------- Forwarded message ----------
From: Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com

Date: Tue, Apr 22, 2014 at 7:11 AM
Subject: RE: Save encounter workflow - Validating a facility
To: Ryan Crichton ryan@jembi.org
Cc: Martin Verzilli mverzilli@manas.com.ar, facility-registry@googlegroups.com, Carl Leitner cleitner@capacityplus.org, openhie-interoperability-layer@googlegroups.com, derek.ritz@gmail.com

Hi Ryan.

I completely agree. With a CSD-conformant InfoMan in the architecture, it will be the source of truth for all facility, provider, organization and service info. This will include facility ID, provider ID, organization ID, service ID. My point was that this should maybe be contemplated; maybe a standalone FR should always “come with” an InfoMan.

I think I’d even go farther, tho… I think an FR should always come with a HIM (which, of course, has an InfoMan in it).

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: Ryan Crichton [mailto:ryan@jembi.org]
Sent: Tuesday, April 22, 2014 5:17 AM
To: Derek Ritz (ecGroup)
Cc: Martin Verzilli; facility-registry@googlegroups.com; Carl Leitner; openhie-interoperability-layer@googlegroups.com

Subject: Re: Save encounter workflow - Validating a facility

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?

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


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

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

···

On 22 April 2014 10:17, Ryan Crichton <ryan@jembi.org> wrote:

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.

2) 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<https://wiki.ohie.org/display/documents/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 <%2B27845829934> | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org*

--

*Ryan Crichton*

*Software Developer, Jembi Health Systems | SOUTH AFRICA*

*Mobile: +27845829934 <%2B27845829934> | 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.

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:


Martín Verzilli
Manas Technology Solutions
[ar.phone] 5258.5240 #MVR(687)
[us.phone] 312.612.1050 #MVR(687)
[email] mverzilli@manas.com.ar

[web] www.manas.com.ar
[blog] weblogs.manas.com.ar/mverzilli

On 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

You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On 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

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

forwarding to the facility group…

···

---------- Forwarded message ----------
From: Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com

Date: Wed, Apr 23, 2014 at 3:33 PM
Subject: RE: Save encounter workflow - Validating a facility
To: Martin Verzilli mverzilli@manas.com.ar, Bob Jolliffe bobjolliffe@gmail.com

Cc: facility-registry@googlegroups.com, Carl Leitner cleitner@capacityplus.org, openhie-interoperability-layer@googlegroups.com

Hi all.

Martin – you have succinctly pointed out some of the genuine issues regarding interoperability. Indeed, if multiple xP’s are updating the same entity then there is a problem; it is a problem that needs to be solved and not just by having the IT system decide who’s right, either. Such issues need to be brought to the surface and addressed operationally. Even if the InfoMan does nothing more than raise the flag and enable a solution to be sorted out manually (by having issues addressed in the underlying registries and then refreshing the cache), that’s still a win, in my view.

RE: “forcing a registry to come with a HIM”… I think my main issue is wrapped up in the semantics of “registry” versus “application”. A stand-alone application likely doesn’t need a HIM. As architectural elements, however, registries are services that support system-wide interoperability. Thought of in this way, a stand-alone registry is probably quite useless without the HIM in place to orchestrate the use of the service to do some important unit of work.

I think Martin’s (and Bob’s) point is well made, though; if an xR wants to be a directory, it need do no more than expose the ITI-74 “Query for Services Update” transaction. It is the role of the other architectural elements to make good use of the exposed data. :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


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

If a provider is at an incorrect facility, does that mean that the HL7 message won’t get set on? I guess there are two possibilities as to why this failed:

  • the HW’s record hasn’t been updated to show that they work at the facility. in this case the source directory should be updated and then the message get reprocessed
  • the HW doesn’t actually formally work at that facility. Should the message be blocked in this case? I am not sure

Cheers,

-carl

···

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

  • 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

You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On Wed, Apr 23, 2014 at 9:33 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi all.

Martin – you have succinctly pointed out some of the genuine issues regarding interoperability. Indeed, if multiple xP’s are updating the same entity then there is a problem; it is a problem that needs to be solved and not just by having the IT system decide who’s right, either. Such issues need to be brought to the surface and addressed operationally. Even if the InfoMan does nothing more than raise the flag and enable a solution to be sorted out manually (by having issues addressed in the underlying registries and then refreshing the cache), that’s still a win, in my view.

RE: “forcing a registry to come with a HIM”… I think my main issue is wrapped up in the semantics of “registry” versus “application”. A stand-alone application likely doesn’t need a HIM. As architectural elements, however, registries are services that support system-wide interoperability. Thought of in this way, a stand-alone registry is probably quite useless without the HIM in place to orchestrate the use of the service to do some important unit of work.

I think Martin’s (and Bob’s) point is well made, though; if an xR wants to be a directory, it need do no more than expose the ITI-74 “Query for Services Update” transaction. It is the role of the other architectural elements to make good use of the exposed data. :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

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

You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

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

All of above are valid in the Philippines. In addition, at PhilHealth, there is the additional constraint that the service is allowed in that facility (eg, you can’t do an appendectomy in a health center even if the general surgeon volunteers there on weekends as a GP).

So to add another bullet:

  • the service is allowed at the facility

alvin

Alvin B. Marcelo, MD, FPCS, CGEIT

On Thu, Apr 24, 2014 at 4:34 PM, Ryan Crichton ryan@jembi.org wrote:

Hi All,

@Derek, I would definitely be in support of that. I agree our validation for the Rwandan HIE have been minimal at best and improving upon this would be highly beneficial. Perhaps we should come up with a proposal of what sort of validation we could do to make this more worth while and to help inform us of what transaction would make the most sense to perform these validations (and where we would need to create custom queries).

As a first pass, for the save encounter workflow, here is what makes sense to me:

  • When an encounter is received we validate that:
  • The facility is valid and operational
  • The provider is valid and currently practicing
  • The provider currently works at the facility
  • The provider currently provides the service requested at the facility
    Should we add logic to the save encounter workflow to enable these checks? Are there other check that makes sense? Do these ones make sense?

These validations will help us design a solution for what transaction will be needed. The above seems to fall in the ball park of CSD, however which registries provide what actors is still the question at hand. To perform any sort of cross-referencing we will need some sort of central cross-registry info manager. This doesn’t mean that other registries can’t also be info managers for their domain. For example if there are many sources of provider information the provider registry could implement a provider info manager actor that just manages merging providers information from various sources. This could then be drawn upon as the source off truth for provider information and used to provide a feed of provider information to the cross-registry info manager, where provider, facility, organisation and service information can be stored.

Are there other ways this could be done better or does this make sense?

Cheers,

Ryan

You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On Wed, Apr 23, 2014 at 9:33 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi all.

Martin – you have succinctly pointed out some of the genuine issues regarding interoperability. Indeed, if multiple xP’s are updating the same entity then there is a problem; it is a problem that needs to be solved and not just by having the IT system decide who’s right, either. Such issues need to be brought to the surface and addressed operationally. Even if the InfoMan does nothing more than raise the flag and enable a solution to be sorted out manually (by having issues addressed in the underlying registries and then refreshing the cache), that’s still a win, in my view.

RE: “forcing a registry to come with a HIM”… I think my main issue is wrapped up in the semantics of “registry” versus “application”. A stand-alone application likely doesn’t need a HIM. As architectural elements, however, registries are services that support system-wide interoperability. Thought of in this way, a stand-alone registry is probably quite useless without the HIM in place to orchestrate the use of the service to do some important unit of work.

I think Martin’s (and Bob’s) point is well made, though; if an xR wants to be a directory, it need do no more than expose the ITI-74 “Query for Services Update” transaction. It is the role of the other architectural elements to make good use of the exposed data. :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

I like the options for enabling/disabling the validation.

···

On Fri, Apr 25, 2014 at 2:38 AM, Alvin Marcelo
alvin.marcelo@gmail.com wrote:

  • When an encounter is received we validate that:
    • The facility is valid and operational
    • The provider is valid and currently practicing
    • The provider currently works at the facility
    • The provider currently provides the service requested at the facility

You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
facility-registry+unsubscribe@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout
.


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH
AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

All of above are valid in the Philippines. In addition, at PhilHealth, there is the additional constraint that the service is allowed in that facility (eg, you can’t do an appendectomy in a health center even if the general surgeon
volunteers there on weekends as a GP).

So to add another bullet:

  • the service is allowed at the facility

alvin

Alvin B. Marcelo, MD, FPCS, CGEIT

On Thu, Apr 24, 2014 at 4:34 PM, Ryan Crichton
ryan@jembi.org wrote:

Hi All,

@Derek, I would definitely be in support of that. I agree our validation for the Rwandan HIE have been minimal at best and improving upon this would be highly beneficial. Perhaps we should come up with a proposal of what sort of validation we could do
to make this more worth while and to help inform us of what transaction would make the most sense to perform these validations (and where we would need to create custom queries).

As a first pass, for the save encounter workflow, here is what makes sense to me:

  • When an encounter is received we validate that:
    • The facility is valid and operational
    • The provider is valid and currently practicing
    • The provider currently works at the facility
    • The provider currently provides the service requested at the facility
      Should we add logic to the save encounter workflow to enable these checks? Are there other check that makes sense? Do these ones make sense?

These validations will help us design a solution for what transaction will be needed. The above seems to fall in the ball park of CSD, however which registries provide what actors is still the question at hand. To perform any sort of cross-referencing
we will need some sort of central cross-registry info manager . This doesn’t mean that other registries can’t also be info managers for their domain. For example if there are many sources of provider information the provider registry could implement
a provider info manager actor that just manages merging providers information from various sources. This could then be drawn upon as the source off truth for provider information and used to provide a feed of provider information to the
cross-registry info manager, where provider, facility, organisation and service information can be stored.

Are there other ways this could be done better or does this make sense?

Cheers,

Ryan

You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
facility-registry+unsubscribe@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout
.

On Wed, Apr 23, 2014 at 9:33 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi all.

Martin – you have succinctly pointed out some of the genuine issues regarding interoperability. Indeed, if multiple xP’s are updating the same entity then
there is a problem; it is a problem that needs to be solved and not just by having the IT system decide who’s right, either. Such issues need to be brought to the surface and addressed operationally. Even if the InfoMan does nothing more than raise the flag
and enable a solution to be sorted out manually (by having issues addressed in the underlying registries and then refreshing the cache), that’s still a win, in my view.

RE: “forcing a registry to come with a HIM”… I think my main issue is wrapped up in the semantics of “registry” versus “application”. A stand-alone application
likely doesn’t need a HIM. As architectural elements, however, registries are services that support system-wide interoperability. Thought of in this way, a stand-alone registry is probably quite useless without the HIM in place to orchestrate the use of the
service to do some important unit of work.

I think Martin’s (and Bob’s) point is well made, though; if an xR wants to be a directory, it need do no more than expose the ITI-74 “Query for Services
Update” transaction. It is the role of the other architectural elements to make good use of the exposed data. :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

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


Martín Verzilli
Manas Technology Solutions
[ar.phone] 5258.5240 #MVR(687)
[us.phone] 312.612.1050 #MVR(687)
[email] mverzilli@manas.com.ar

[web] www.manas.com.ar
[blog] weblogs.manas.com.ar/mverzilli

On Fri, Apr 25, 2014 at 2:38 AM, Alvin Marcelo
alvin.marcelo@gmail.com wrote:

  • When an encounter is received we validate that:
    • The facility is valid and operational
    • The provider is valid and currently practicing
    • The provider currently works at the facility
    • The provider currently provides the service requested at the facility

You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
facility-registry+unsubscribe@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout
.


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH
AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

All of above are valid in the Philippines. In addition, at PhilHealth, there is the additional constraint that the service is allowed in that facility (eg, you can’t do an appendectomy in a health center even if the general surgeon
volunteers there on weekends as a GP).

So to add another bullet:

  • the service is allowed at the facility

alvin

Alvin B. Marcelo, MD, FPCS, CGEIT

On Thu, Apr 24, 2014 at 4:34 PM, Ryan Crichton
ryan@jembi.org wrote:

Hi All,

@Derek, I would definitely be in support of that. I agree our validation for the Rwandan HIE have been minimal at best and improving upon this would be highly beneficial. Perhaps we should come up with a proposal of what sort of validation we could do
to make this more worth while and to help inform us of what transaction would make the most sense to perform these validations (and where we would need to create custom queries).

As a first pass, for the save encounter workflow, here is what makes sense to me:

  • When an encounter is received we validate that:
    • The facility is valid and operational
    • The provider is valid and currently practicing
    • The provider currently works at the facility
    • The provider currently provides the service requested at the facility
      Should we add logic to the save encounter workflow to enable these checks? Are there other check that makes sense? Do these ones make sense?

These validations will help us design a solution for what transaction will be needed. The above seems to fall in the ball park of CSD, however which registries provide what actors is still the question at hand. To perform any sort of cross-referencing
we will need some sort of central cross-registry info manager . This doesn’t mean that other registries can’t also be info managers for their domain. For example if there are many sources of provider information the provider registry could implement
a provider info manager actor that just manages merging providers information from various sources. This could then be drawn upon as the source off truth for provider information and used to provide a feed of provider information to the
cross-registry info manager, where provider, facility, organisation and service information can be stored.

Are there other ways this could be done better or does this make sense?

Cheers,

Ryan

You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
facility-registry+unsubscribe@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout
.

On Wed, Apr 23, 2014 at 9:33 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi all.

Martin – you have succinctly pointed out some of the genuine issues regarding interoperability. Indeed, if multiple xP’s are updating the same entity then
there is a problem; it is a problem that needs to be solved and not just by having the IT system decide who’s right, either. Such issues need to be brought to the surface and addressed operationally. Even if the InfoMan does nothing more than raise the flag
and enable a solution to be sorted out manually (by having issues addressed in the underlying registries and then refreshing the cache), that’s still a win, in my view.

RE: “forcing a registry to come with a HIM”… I think my main issue is wrapped up in the semantics of “registry” versus “application”. A stand-alone application
likely doesn’t need a HIM. As architectural elements, however, registries are services that support system-wide interoperability. Thought of in this way, a stand-alone registry is probably quite useless without the HIM in place to orchestrate the use of the
service to do some important unit of work.

I think Martin’s (and Bob’s) point is well made, though; if an xR wants to be a directory, it need do no more than expose the ITI-74 “Query for Services
Update” transaction. It is the role of the other architectural elements to make good use of the exposed data. :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

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 Fri, Apr 25, 2014 at 8:33 AM, Carl Leitner cleitner@capacityplus.org wrote:

I like the options for enabling/disabling the validation.

On Apr 25, 2014 6:28 AM, Ryan Crichton ryan@jembi.org wrote:

Hi all,

@Carl L, well I guess that is for us to decide, I would say it shouldn’t get processed and rather go into an error queue. There we can resolve why it has failed. I would suggest that we have a mechanism to enable/disable these checks as in different environments
some of these may be difficult to manage.

@Alvin, thanks for the addition, that is quite helpful.

I have added this list to the
save encounter wiki page
under a section heading called discussions so we can keep track of these and discuss then further.

Do other agree with these and if so, how should message that fail these criteria be handled?

Cheers,

Ryan


Martín Verzilli
Manas Technology Solutions
[ar.phone] 5258.5240 #MVR(687)
[us.phone] 312.612.1050 #MVR(687)
[email] mverzilli@manas.com.ar

[web] www.manas.com.ar
[blog] weblogs.manas.com.ar/mverzilli

On Fri, Apr 25, 2014 at 2:38 AM, Alvin Marcelo
alvin.marcelo@gmail.com wrote:

  • When an encounter is received we validate that:
    • The facility is valid and operational
    • The provider is valid and currently practicing
    • The provider currently works at the facility
    • The provider currently provides the service requested at the facility

You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
facility-registry+unsubscribe@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout
.


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH
AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

All of above are valid in the Philippines. In addition, at PhilHealth, there is the additional constraint that the service is allowed in that facility (eg, you can’t do an appendectomy in a health center even if the general surgeon
volunteers there on weekends as a GP).

So to add another bullet:

  • the service is allowed at the facility

alvin

Alvin B. Marcelo, MD, FPCS, CGEIT

On Thu, Apr 24, 2014 at 4:34 PM, Ryan Crichton
ryan@jembi.org wrote:

Hi All,

@Derek, I would definitely be in support of that. I agree our validation for the Rwandan HIE have been minimal at best and improving upon this would be highly beneficial. Perhaps we should come up with a proposal of what sort of validation we could do
to make this more worth while and to help inform us of what transaction would make the most sense to perform these validations (and where we would need to create custom queries).

As a first pass, for the save encounter workflow, here is what makes sense to me:

  • When an encounter is received we validate that:
    • The facility is valid and operational
    • The provider is valid and currently practicing
    • The provider currently works at the facility
    • The provider currently provides the service requested at the facility
      Should we add logic to the save encounter workflow to enable these checks? Are there other check that makes sense? Do these ones make sense?

These validations will help us design a solution for what transaction will be needed. The above seems to fall in the ball park of CSD, however which registries provide what actors is still the question at hand. To perform any sort of cross-referencing
we will need some sort of central cross-registry info manager . This doesn’t mean that other registries can’t also be info managers for their domain. For example if there are many sources of provider information the provider registry could implement
a provider info manager actor that just manages merging providers information from various sources. This could then be drawn upon as the source off truth for provider information and used to provide a feed of provider information to the
cross-registry info manager, where provider, facility, organisation and service information can be stored.

Are there other ways this could be done better or does this make sense?

Cheers,

Ryan

You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
facility-registry+unsubscribe@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout
.

On Wed, Apr 23, 2014 at 9:33 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi all.

Martin – you have succinctly pointed out some of the genuine issues regarding interoperability. Indeed, if multiple xP’s are updating the same entity then
there is a problem; it is a problem that needs to be solved and not just by having the IT system decide who’s right, either. Such issues need to be brought to the surface and addressed operationally. Even if the InfoMan does nothing more than raise the flag
and enable a solution to be sorted out manually (by having issues addressed in the underlying registries and then refreshing the cache), that’s still a win, in my view.

RE: “forcing a registry to come with a HIM”… I think my main issue is wrapped up in the semantics of “registry” versus “application”. A stand-alone application
likely doesn’t need a HIM. As architectural elements, however, registries are services that support system-wide interoperability. Thought of in this way, a stand-alone registry is probably quite useless without the HIM in place to orchestrate the use of the
service to do some important unit of work.

I think Martin’s (and Bob’s) point is well made, though; if an xR wants to be a directory, it need do no more than expose the ITI-74 “Query for Services
Update” transaction. It is the role of the other architectural elements to make good use of the exposed data. :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