path forward / road map for FR community

[derek.ritz]

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

[Eduardo_Jezierski]

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

···

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

[amarcelo]

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

···

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

[Carl_Leitner1]

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

···

On Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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.

[amarcelo]

Thanks Carl – I’ll need some time to digest these new resources…

Should I then revise my images and put a rectangle called InfoMan between the IL and the HWR/FR? Or is the InfoMan actually embedded inside the IL (ESB) as an implementation of CSD? Sorry but can you guide me from what I understand (the OpenHIE architecture) to how it should be…

I’ll also be seeing Derek in two weeks and I can ask him for a crash course too…

Thanks!

alvin

···

On Sun, May 17, 2015 at 10:46 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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.

[Carl_Leitner1]

Hi Alvin,

The ILR does not exist inside the IL. Really, the question depends largely on the data governance policy for health worker and facility data that you are using. One option, to preserve a bit of ambiguity while these questions are clarified, is to put the HWR and the FR inside/on top of a box called ILR.

Cheers,

-carl

···

On Sun, May 17, 2015 at 3:26 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl – I’ll need some time to digest these new resources…

Should I then revise my images and put a rectangle called InfoMan between the IL and the HWR/FR? Or is the InfoMan actually embedded inside the IL (ESB) as an implementation of CSD? Sorry but can you guide me from what I understand (the OpenHIE architecture) to how it should be…

I’ll also be seeing Derek in two weeks and I can ask him for a crash course too…

Thanks!

alvin

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 10:46 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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.

[amarcelo]

Thanks Carl –

In the Philippines there are distinct governance structures for the HWR and the FR. And I think our problem is that the HWR uses a different codeset for facilities aside from the FR causing headaches. The ILR is the ideal bridge…

Pls see attachments - I have two models …

I was thinking that in our context, the ILR is more appropriate as a subset inside the HWR (2nd attachment).

alvin

···

On Mon, May 18, 2015 at 4:18 AM, Carl Leitner litlfred@gmail.com wrote:

Hi Alvin,

The ILR does not exist inside the IL. Really, the question depends largely on the data governance policy for health worker and facility data that you are using. One option, to preserve a bit of ambiguity while these questions are clarified, is to put the HWR and the FR inside/on top of a box called ILR.

Cheers,

-carl

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 3:26 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl – I’ll need some time to digest these new resources…

Should I then revise my images and put a rectangle called InfoMan between the IL and the HWR/FR? Or is the InfoMan actually embedded inside the IL (ESB) as an implementation of CSD? Sorry but can you guide me from what I understand (the OpenHIE architecture) to how it should be…

I’ll also be seeing Derek in two weeks and I can ask him for a crash course too…

Thanks!

alvin

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 10:46 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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

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

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

[derek.ritz]

Hi Alvin (and everyone).

The role of an interlinked registry (ILR) – as Carl described – is precisely to address challenges regarding code set consistency and entity relationship management between data regarding health workers, facilities, organizations and services. As defined by IHE’s Care Services Discovery (CSD) profile, the InfoManager actor supports this interlinking. By design, an InfoManager also supports federation of these many underlying directories.

Alvin, I have attached a short PPT that illustrates these points. The first slide shows the entity relationships between health workers (providers), facilities, organizations and services; it is a graphic from the CSD profile (the text of which can be found here: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_CSD.pdf). The second slide, also from the CSD profile, illustrates how the InfoManager actor refreshes it’s data cache from underlying Directory actors (FR, HWR, codes sets / services – perhaps from the TS, organization lists, etc.) using ITI-74. After the InfoManager cross referencing these data – it exposes the interlinked data to clients (Service Finder actors) who may query for it via ITI-73.

The last slide in the PPT illustrates the position of the InfoManager actor within OpenHIE’s architecture. Sadly (as it can create confusion), we typically do not explicitly show the InfoManager in our OpenHIE diagrams. I think we should probably start to show it. Not calling it out in its own right is likely why, Alvin, you asked if the ILR InfoManager is part of the Interoperability Layer. Indeed, the ILR and the IL are regularly “bundled” (as part of a country implementation); but Carl is correct: they are distinct architectural puzzle pieces.

Thank you for such excellent questions, Alvin!

Warmest regards,

Derek.

PS: slide 2 shows CSD’s freeBusy" transaction (ITI-75). Although ITI-75 is not supported in OpenHIE v1, Carl prototyped and showed this transaction at an eHealth conference in California last summer.

15-05-17 ILR illustrations.pptx (74.9 KB)

···

On Sun, May 17, 2015 at 6:18 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl –

In the Philippines there are distinct governance structures for the HWR and the FR. And I think our problem is that the HWR uses a different codeset for facilities aside from the FR causing headaches. The ILR is the ideal bridge…

Pls see attachments - I have two models …

I was thinking that in our context, the ILR is more appropriate as a subset inside the HWR (2nd attachment).

alvin

–

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.

–

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Mon, May 18, 2015 at 4:18 AM, Carl Leitner litlfred@gmail.com wrote:

Hi Alvin,

The ILR does not exist inside the IL. Really, the question depends largely on the data governance policy for health worker and facility data that you are using. One option, to preserve a bit of ambiguity while these questions are clarified, is to put the HWR and the FR inside/on top of a box called ILR.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 3:26 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl – I’ll need some time to digest these new resources…

Should I then revise my images and put a rectangle called InfoMan between the IL and the HWR/FR? Or is the InfoMan actually embedded inside the IL (ESB) as an implementation of CSD? Sorry but can you guide me from what I understand (the OpenHIE architecture) to how it should be…

I’ll also be seeing Derek in two weeks and I can ask him for a crash course too…

Thanks!

alvin

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 10:46 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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

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

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

Derek Ritz

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

[amarcelo]

Thanks Derek. Will try out the OpenHIE v1.0 now and call for help…

···

On Sun, May 17, 2015 at 6:18 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl –

In the Philippines there are distinct governance structures for the HWR and the FR. And I think our problem is that the HWR uses a different codeset for facilities aside from the FR causing headaches. The ILR is the ideal bridge…

Pls see attachments - I have two models …

I was thinking that in our context, the ILR is more appropriate as a subset inside the HWR (2nd attachment).

alvin

–

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

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

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

–
Derek Ritz

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

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Mon, May 18, 2015 at 4:18 AM, Carl Leitner litlfred@gmail.com wrote:

Hi Alvin,

The ILR does not exist inside the IL. Really, the question depends largely on the data governance policy for health worker and facility data that you are using. One option, to preserve a bit of ambiguity while these questions are clarified, is to put the HWR and the FR inside/on top of a box called ILR.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 3:26 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl – I’ll need some time to digest these new resources…

Should I then revise my images and put a rectangle called InfoMan between the IL and the HWR/FR? Or is the InfoMan actually embedded inside the IL (ESB) as an implementation of CSD? Sorry but can you guide me from what I understand (the OpenHIE architecture) to how it should be…

I’ll also be seeing Derek in two weeks and I can ask him for a crash course too…

Thanks!

alvin

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 10:46 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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.

[Scott_Teesdale]

Great conversation here. Alvin, thanks for your interest! We would love your feedback as you get into these materials and would be happy to work with you as you explore the workflow and its associated components as it relates to your FR/HWR integration.

To answer another one of your past questions, the acronym RM is referencing Resource Map, a reference facility registry tool for OpenHIE.

Lastly, for this request that you shared:

“I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.”

• The assumptions here are correct: Yes, existing data, tools, and governance, can and should be leveraged to the extent possible. It is OpenHIE’s intent to unseat existing systems, but rather look at a comparison of the existing landscape against requirements for how a registry needs to operate and then seek to address those gaps as needed.
  And then for the conditional aspect you requested, I would suggest something along the lines of:
• That the governance per existing system aligns with the requirements for your FR/HWR. Essentially, seeking to mitigate the garbage in garbage out problem by resolving the typical challenges of facility IDs, standardization, federation, etc… So as you choose systems to act as trusted partners, the aspects of both limitations / challenges and benefits are all well understood.
• Some examples to highlight the issues that have come up along these lines include:
• There is no trusted partner that covers a particular geographic (region A) or functional aspect of the health system (i.e., private/FBO facilities)
• Partner A does not update their facility list as routinely as others, or follows a different curation process as is required. or Partner B, identifies new facilities much quicker than other systems (i.e., supply chain and logistics systems)
• Partner C & D both govern a subset facilities, which may lead to a multiple master type of scenario.
• There are standardization problems across systems that need to be resolved prior to federation being successful or a national identifier needs to be implemented across systems successful.
• Also, a not trival issues… is the higher level question of alignment of goals among the multiple actors, or do trusted sources for registry data want to work together. We would recommend seeking to resolve this issue first, before getting too far into the nuts and bolts of things… but its important to have robust solutions lined up and ready.
  We were planning to have this as a theme for our upcoming FR technical conversations. We had planned to have focused time for Federation discussions as part of our community roadmap. This is a good reaffirmation that this is an important topic.

Best,

Scott

···

On Sun, May 17, 2015 at 10:00 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Derek. Will try out the OpenHIE v1.0 now and call for help…

On May 18, 2015 7:17 AM, “Derek Ritz” derek.ritz@gmail.com wrote:

Hi Alvin (and everyone).

The role of an interlinked registry (ILR) – as Carl described – is precisely to address challenges regarding code set consistency and entity relationship management between data regarding health workers, facilities, organizations and services. As defined by IHE’s Care Services Discovery (CSD) profile, the InfoManager actor supports this interlinking. By design, an InfoManager also supports federation of these many underlying directories.

Alvin, I have attached a short PPT that illustrates these points. The first slide shows the entity relationships between health workers (providers), facilities, organizations and services; it is a graphic from the CSD profile (the text of which can be found here: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_CSD.pdf). The second slide, also from the CSD profile, illustrates how the InfoManager actor refreshes it’s data cache from underlying Directory actors (FR, HWR, codes sets / services – perhaps from the TS, organization lists, etc.) using ITI-74. After the InfoManager cross referencing these data – it exposes the interlinked data to clients (Service Finder actors) who may query for it via ITI-73.

The last slide in the PPT illustrates the position of the InfoManager actor within OpenHIE’s architecture. Sadly (as it can create confusion), we typically do not explicitly show the InfoManager in our OpenHIE diagrams. I think we should probably start to show it. Not calling it out in its own right is likely why, Alvin, you asked if the ILR InfoManager is part of the Interoperability Layer. Indeed, the ILR and the IL are regularly “bundled” (as part of a country implementation); but Carl is correct: they are distinct architectural puzzle pieces.

Thank you for such excellent questions, Alvin!

Warmest regards,

Derek.

PS: slide 2 shows CSD’s freeBusy" transaction (ITI-75). Although ITI-75 is not supported in OpenHIE v1, Carl prototyped and showed this transaction at an eHealth conference in California last summer.

–

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

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

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

–

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

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

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

–

On Sun, May 17, 2015 at 6:18 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl –

In the Philippines there are distinct governance structures for the HWR and the FR. And I think our problem is that the HWR uses a different codeset for facilities aside from the FR causing headaches. The ILR is the ideal bridge…

Pls see attachments - I have two models …

I was thinking that in our context, the ILR is more appropriate as a subset inside the HWR (2nd attachment).

alvin

–

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

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

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

–
Derek Ritz

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

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Mon, May 18, 2015 at 4:18 AM, Carl Leitner litlfred@gmail.com wrote:

Hi Alvin,

The ILR does not exist inside the IL. Really, the question depends largely on the data governance policy for health worker and facility data that you are using. One option, to preserve a bit of ambiguity while these questions are clarified, is to put the HWR and the FR inside/on top of a box called ILR.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 3:26 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl – I’ll need some time to digest these new resources…

Should I then revise my images and put a rectangle called InfoMan between the IL and the HWR/FR? Or is the InfoMan actually embedded inside the IL (ESB) as an implementation of CSD? Sorry but can you guide me from what I understand (the OpenHIE architecture) to how it should be…

I’ll also be seeing Derek in two weeks and I can ask him for a crash course too…

Thanks!

alvin

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 10:46 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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.

Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

[Scott_Teesdale]

Hi all,

Sorry a bad typo here… It isn’t the intent of openhie to unseat existing systems… Sorry if that gave anyone pause.

Best,

Scott

···

On Sun, May 17, 2015 at 10:00 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Derek. Will try out the OpenHIE v1.0 now and call for help…

On May 18, 2015 7:17 AM, “Derek Ritz” derek.ritz@gmail.com wrote:

Hi Alvin (and everyone).

The role of an interlinked registry (ILR) – as Carl described – is precisely to address challenges regarding code set consistency and entity relationship management between data regarding health workers, facilities, organizations and services. As defined by IHE’s Care Services Discovery (CSD) profile, the InfoManager actor supports this interlinking. By design, an InfoManager also supports federation of these many underlying directories.

Alvin, I have attached a short PPT that illustrates these points. The first slide shows the entity relationships between health workers (providers), facilities, organizations and services; it is a graphic from the CSD profile (the text of which can be found here: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_CSD.pdf). The second slide, also from the CSD profile, illustrates how the InfoManager actor refreshes it’s data cache from underlying Directory actors (FR, HWR, codes sets / services – perhaps from the TS, organization lists, etc.) using ITI-74. After the InfoManager cross referencing these data – it exposes the interlinked data to clients (Service Finder actors) who may query for it via ITI-73.

The last slide in the PPT illustrates the position of the InfoManager actor within OpenHIE’s architecture. Sadly (as it can create confusion), we typically do not explicitly show the InfoManager in our OpenHIE diagrams. I think we should probably start to show it. Not calling it out in its own right is likely why, Alvin, you asked if the ILR InfoManager is part of the Interoperability Layer. Indeed, the ILR and the IL are regularly “bundled” (as part of a country implementation); but Carl is correct: they are distinct architectural puzzle pieces.

Thank you for such excellent questions, Alvin!

Warmest regards,

Derek.

PS: slide 2 shows CSD’s freeBusy" transaction (ITI-75). Although ITI-75 is not supported in OpenHIE v1, Carl prototyped and showed this transaction at an eHealth conference in California last summer.

–

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

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

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

–

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

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

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

–

On Sun, May 17, 2015 at 6:18 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl –

In the Philippines there are distinct governance structures for the HWR and the FR. And I think our problem is that the HWR uses a different codeset for facilities aside from the FR causing headaches. The ILR is the ideal bridge…

Pls see attachments - I have two models …

I was thinking that in our context, the ILR is more appropriate as a subset inside the HWR (2nd attachment).

alvin

–

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

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

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

–
Derek Ritz

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

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Mon, May 18, 2015 at 4:18 AM, Carl Leitner litlfred@gmail.com wrote:

Hi Alvin,

The ILR does not exist inside the IL. Really, the question depends largely on the data governance policy for health worker and facility data that you are using. One option, to preserve a bit of ambiguity while these questions are clarified, is to put the HWR and the FR inside/on top of a box called ILR.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 3:26 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl – I’ll need some time to digest these new resources…

Should I then revise my images and put a rectangle called InfoMan between the IL and the HWR/FR? Or is the InfoMan actually embedded inside the IL (ESB) as an implementation of CSD? Sorry but can you guide me from what I understand (the OpenHIE architecture) to how it should be…

I’ll also be seeing Derek in two weeks and I can ask him for a crash course too…

Thanks!

alvin

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 10:46 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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.

Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

[amarcelo]

Thanks Scott. Trust is key to getting an ILR to link the FR and HWR. From my perspective, either one is wary to‎ be dependent on the other causing the disintegration.

With an OpenHIE architecture providing solid support to the technical backend, there will be greater confidence in proceeding with (and investing on) the trust-building exercise.

In the end, is the ILR simply a relation of the FR and HWR? ‎And the IHE CSD has all the specs for it?

Lastly, has the community arrived at a maturity model that can help countries assess their readiness for OpenHIE‎ and also to monitor their progress?

These are interesting times for the community!

Alvin

Sent from my BlackBerry 10 smartphone.

···

On Sun, May 17, 2015 at 10:00 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Derek. Will try out the OpenHIE v1.0 now and call for help…

On May 18, 2015 7:17 AM, “Derek Ritz” derek.ritz@gmail.com wrote:

Hi Alvin (and everyone).

The role of an interlinked registry (ILR) – as Carl described – is precisely to address challenges regarding code set consistency and entity relationship management between data regarding health workers, facilities, organizations and services. As defined by IHE’s Care Services Discovery (CSD) profile, the InfoManager actor supports this interlinking. By design, an InfoManager also supports federation of these many underlying directories.

Alvin, I have attached a short PPT that illustrates these points. The first slide shows the entity relationships between health workers (providers), facilities, organizations and services; it is a graphic from the CSD profile (the text of which can be found here: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_CSD.pdf). The second slide, also from the CSD profile, illustrates how the InfoManager actor refreshes it’s data cache from underlying Directory actors (FR, HWR, codes sets / services – perhaps from the TS, organization lists, etc.) using ITI-74. After the InfoManager cross referencing these data – it exposes the interlinked data to clients (Service Finder actors) who may query for it via ITI-73.

The last slide in the PPT illustrates the position of the InfoManager actor within OpenHIE’s architecture. Sadly (as it can create confusion), we typically do not explicitly show the InfoManager in our OpenHIE diagrams. I think we should probably start to show it. Not calling it out in its own right is likely why, Alvin, you asked if the ILR InfoManager is part of the Interoperability Layer. Indeed, the ILR and the IL are regularly “bundled” (as part of a country implementation); but Carl is correct: they are distinct architectural puzzle pieces.

Thank you for such excellent questions, Alvin!

Warmest regards,

Derek.

PS: slide 2 shows CSD’s freeBusy" transaction (ITI-75). Although ITI-75 is not supported in OpenHIE v1, Carl prototyped and showed this transaction at an eHealth conference in California last summer.

–

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

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

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

–

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

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

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

–

On Sun, May 17, 2015 at 6:18 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl –

In the Philippines there are distinct governance structures for the HWR and the FR. And I think our problem is that the HWR uses a different codeset for facilities aside from the FR causing headaches. The ILR is the ideal bridge…

Pls see attachments - I have two models …

I was thinking that in our context, the ILR is more appropriate as a subset inside the HWR (2nd attachment).

alvin

–

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

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

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

–
Derek Ritz

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

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Mon, May 18, 2015 at 4:18 AM, Carl Leitner litlfred@gmail.com wrote:

Hi Alvin,

The ILR does not exist inside the IL. Really, the question depends largely on the data governance policy for health worker and facility data that you are using. One option, to preserve a bit of ambiguity while these questions are clarified, is to put the HWR and the FR inside/on top of a box called ILR.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 3:26 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl – I’ll need some time to digest these new resources…

Should I then revise my images and put a rectangle called InfoMan between the IL and the HWR/FR? Or is the InfoMan actually embedded inside the IL (ESB) as an implementation of CSD? Sorry but can you guide me from what I understand (the OpenHIE architecture) to how it should be…

I’ll also be seeing Derek in two weeks and I can ask him for a crash course too…

Thanks!

alvin

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 10:46 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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.

Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

[amarcelo]

I am looping in Dr Boonchai who is also heavily involved with Thailand HISPA and Drs Fazilah and Khadzir who are familiar with Malaysia’s MyHIX.

‎We’re meeting in August to talk about governance, architecture and standards for interoperability (in Manila).

Dear Drs Boonchai,‎ Fazilah, Khadzir, this is the Facility Registry community of OpenHIE. I’m learning a lot from this group and I think there are artifacts we can reuse for interoperability in ASEAN.

Alvin

Sent from my BlackBerry 10 smartphone.

···

On Sun, May 17, 2015 at 10:00 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Derek. Will try out the OpenHIE v1.0 now and call for help…

On May 18, 2015 7:17 AM, “Derek Ritz” derek.ritz@gmail.com wrote:

Hi Alvin (and everyone).

The role of an interlinked registry (ILR) – as Carl described – is precisely to address challenges regarding code set consistency and entity relationship management between data regarding health workers, facilities, organizations and services. As defined by IHE’s Care Services Discovery (CSD) profile, the InfoManager actor supports this interlinking. By design, an InfoManager also supports federation of these many underlying directories.

Alvin, I have attached a short PPT that illustrates these points. The first slide shows the entity relationships between health workers (providers), facilities, organizations and services; it is a graphic from the CSD profile (the text of which can be found here: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_CSD.pdf). The second slide, also from the CSD profile, illustrates how the InfoManager actor refreshes it’s data cache from underlying Directory actors (FR, HWR, codes sets / services – perhaps from the TS, organization lists, etc.) using ITI-74. After the InfoManager cross referencing these data – it exposes the interlinked data to clients (Service Finder actors) who may query for it via ITI-73.

The last slide in the PPT illustrates the position of the InfoManager actor within OpenHIE’s architecture. Sadly (as it can create confusion), we typically do not explicitly show the InfoManager in our OpenHIE diagrams. I think we should probably start to show it. Not calling it out in its own right is likely why, Alvin, you asked if the ILR InfoManager is part of the Interoperability Layer. Indeed, the ILR and the IL are regularly “bundled” (as part of a country implementation); but Carl is correct: they are distinct architectural puzzle pieces.

Thank you for such excellent questions, Alvin!

Warmest regards,

Derek.

PS: slide 2 shows CSD’s freeBusy" transaction (ITI-75). Although ITI-75 is not supported in OpenHIE v1, Carl prototyped and showed this transaction at an eHealth conference in California last summer.

–

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

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

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

–

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

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

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

–

On Sun, May 17, 2015 at 6:18 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl –

In the Philippines there are distinct governance structures for the HWR and the FR. And I think our problem is that the HWR uses a different codeset for facilities aside from the FR causing headaches. The ILR is the ideal bridge…

Pls see attachments - I have two models …

I was thinking that in our context, the ILR is more appropriate as a subset inside the HWR (2nd attachment).

alvin

–

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

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

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

–
Derek Ritz

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

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Mon, May 18, 2015 at 4:18 AM, Carl Leitner litlfred@gmail.com wrote:

Hi Alvin,

The ILR does not exist inside the IL. Really, the question depends largely on the data governance policy for health worker and facility data that you are using. One option, to preserve a bit of ambiguity while these questions are clarified, is to put the HWR and the FR inside/on top of a box called ILR.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 3:26 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl – I’ll need some time to digest these new resources…

Should I then revise my images and put a rectangle called InfoMan between the IL and the HWR/FR? Or is the InfoMan actually embedded inside the IL (ESB) as an implementation of CSD? Sorry but can you guide me from what I understand (the OpenHIE architecture) to how it should be…

I’ll also be seeing Derek in two weeks and I can ask him for a crash course too…

Thanks!

alvin

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 10:46 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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.

Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

[Carl_Leitner1]

Hi Alvin,

Yes, the ILR is simply the joining of the FR and HWR according to the common CSD standard.

Cheers.

-carl

···

On Mon, May 18, 2015 at 9:26 PM, alvin.marcelo@gmail.com wrote:

Thanks Scott. Trust is key to getting an ILR to link the FR and HWR. From my perspective, either one is wary to‎ be dependent on the other causing the disintegration.

With an OpenHIE architecture providing solid support to the technical backend, there will be greater confidence in proceeding with (and investing on) the trust-building exercise.

In the end, is the ILR simply a relation of the FR and HWR? ‎And the IHE CSD has all the specs for it?

Lastly, has the community arrived at a maturity model that can help countries assess their readiness for OpenHIE‎ and also to monitor their progress?

These are interesting times for the community!

Alvin

Sent from my BlackBerry 10 smartphone.

From: Scott Teesdale

Sent: Tuesday, May 19, 2015 00:48

To: facility-registry@googlegroups.com

Reply To: facility-registry@googlegroups.com

Cc: Shaun Grannis; charityltan@gmail.com

Subject: Re: path forward / road map for FR community

Great conversation here. Alvin, thanks for your interest! We would love your feedback as you get into these materials and would be happy to work with you as you explore the workflow and its associated components as it relates to your FR/HWR integration.

To answer another one of your past questions, the acronym RM is referencing Resource Map, a reference facility registry tool for OpenHIE.

Lastly, for this request that you shared:

“I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.”

• The assumptions here are correct: Yes, existing data, tools, and governance, can and should be leveraged to the extent possible. It is OpenHIE’s intent to unseat existing systems, but rather look at a comparison of the existing landscape against requirements for how a registry needs to operate and then seek to address those gaps as needed.
  And then for the conditional aspect you requested, I would suggest something along the lines of:
• That the governance per existing system aligns with the requirements for your FR/HWR. Essentially, seeking to mitigate the garbage in garbage out problem by resolving the typical challenges of facility IDs, standardization, federation, etc… So as you choose systems to act as trusted partners, the aspects of both limitations / challenges and benefits are all well understood.
• Some examples to highlight the issues that have come up along these lines include:
• There is no trusted partner that covers a particular geographic (region A) or functional aspect of the health system (i.e., private/FBO facilities)
• Partner A does not update their facility list as routinely as others, or follows a different curation process as is required. or Partner B, identifies new facilities much quicker than other systems (i.e., supply chain and logistics systems)
• Partner C & D both govern a subset facilities, which may lead to a multiple master type of scenario.
• There are standardization problems across systems that need to be resolved prior to federation being successful or a national identifier needs to be implemented across systems successful.
• Also, a not trival issues… is the higher level question of alignment of goals among the multiple actors, or do trusted sources for registry data want to work together. We would recommend seeking to resolve this issue first, before getting too far into the nuts and bolts of things… but its important to have robust solutions lined up and ready.
  We were planning to have this as a theme for our upcoming FR technical conversations. We had planned to have focused time for Federation discussions as part of our community roadmap. This is a good reaffirmation that this is an important topic.

Best,

Scott

–

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

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

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

–

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

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

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

On Sun, May 17, 2015 at 10:00 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Derek. Will try out the OpenHIE v1.0 now and call for help…

On May 18, 2015 7:17 AM, “Derek Ritz” derek.ritz@gmail.com wrote:

Hi Alvin (and everyone).

The role of an interlinked registry (ILR) – as Carl described – is precisely to address challenges regarding code set consistency and entity relationship management between data regarding health workers, facilities, organizations and services. As defined by IHE’s Care Services Discovery (CSD) profile, the InfoManager actor supports this interlinking. By design, an InfoManager also supports federation of these many underlying directories.

Alvin, I have attached a short PPT that illustrates these points. The first slide shows the entity relationships between health workers (providers), facilities, organizations and services; it is a graphic from the CSD profile (the text of which can be found here: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_CSD.pdf). The second slide, also from the CSD profile, illustrates how the InfoManager actor refreshes it’s data cache from underlying Directory actors (FR, HWR, codes sets / services – perhaps from the TS, organization lists, etc.) using ITI-74. After the InfoManager cross referencing these data – it exposes the interlinked data to clients (Service Finder actors) who may query for it via ITI-73.

The last slide in the PPT illustrates the position of the InfoManager actor within OpenHIE’s architecture. Sadly (as it can create confusion), we typically do not explicitly show the InfoManager in our OpenHIE diagrams. I think we should probably start to show it. Not calling it out in its own right is likely why, Alvin, you asked if the ILR InfoManager is part of the Interoperability Layer. Indeed, the ILR and the IL are regularly “bundled” (as part of a country implementation); but Carl is correct: they are distinct architectural puzzle pieces.

Thank you for such excellent questions, Alvin!

Warmest regards,

Derek.

PS: slide 2 shows CSD’s freeBusy" transaction (ITI-75). Although ITI-75 is not supported in OpenHIE v1, Carl prototyped and showed this transaction at an eHealth conference in California last summer.

–

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

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

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

–

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

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

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

–
Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

On Sun, May 17, 2015 at 6:18 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl –

In the Philippines there are distinct governance structures for the HWR and the FR. And I think our problem is that the HWR uses a different codeset for facilities aside from the FR causing headaches. The ILR is the ideal bridge…

Pls see attachments - I have two models …

I was thinking that in our context, the ILR is more appropriate as a subset inside the HWR (2nd attachment).

alvin

–

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

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

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

–
Derek Ritz

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

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Mon, May 18, 2015 at 4:18 AM, Carl Leitner litlfred@gmail.com wrote:

Hi Alvin,

The ILR does not exist inside the IL. Really, the question depends largely on the data governance policy for health worker and facility data that you are using. One option, to preserve a bit of ambiguity while these questions are clarified, is to put the HWR and the FR inside/on top of a box called ILR.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 3:26 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl – I’ll need some time to digest these new resources…

Should I then revise my images and put a rectangle called InfoMan between the IL and the HWR/FR? Or is the InfoMan actually embedded inside the IL (ESB) as an implementation of CSD? Sorry but can you guide me from what I understand (the OpenHIE architecture) to how it should be…

I’ll also be seeing Derek in two weeks and I can ask him for a crash course too…

Thanks!

alvin

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 10:46 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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.

[amarcelo]

Thanks Carl. Are there CSD-compliant ILRs already? That we can start using to understand how they work?

Or where we can point our existing FR and HWRs?

Sent from my BlackBerry 10 smartphone.

···

On Mon, May 18, 2015 at 9:26 PM, alvin.marcelo@gmail.com wrote:

Thanks Scott. Trust is key to getting an ILR to link the FR and HWR. From my perspective, either one is wary to‎ be dependent on the other causing the disintegration.

With an OpenHIE architecture providing solid support to the technical backend, there will be greater confidence in proceeding with (and investing on) the trust-building exercise.

In the end, is the ILR simply a relation of the FR and HWR? ‎And the IHE CSD has all the specs for it?

Lastly, has the community arrived at a maturity model that can help countries assess their readiness for OpenHIE‎ and also to monitor their progress?

These are interesting times for the community!

Alvin

Sent from my BlackBerry 10 smartphone.

From: Scott Teesdale

Sent: Tuesday, May 19, 2015 00:48

To: facility-registry@googlegroups.com

Reply To: facility-registry@googlegroups.com

Cc: Shaun Grannis; charityltan@gmail.com

Subject: Re: path forward / road map for FR community

Great conversation here. Alvin, thanks for your interest! We would love your feedback as you get into these materials and would be happy to work with you as you explore the workflow and its associated components as it relates to your FR/HWR integration.

To answer another one of your past questions, the acronym RM is referencing Resource Map, a reference facility registry tool for OpenHIE.

Lastly, for this request that you shared:

“I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.”

• The assumptions here are correct: Yes, existing data, tools, and governance, can and should be leveraged to the extent possible. It is OpenHIE’s intent to unseat existing systems, but rather look at a comparison of the existing landscape against requirements for how a registry needs to operate and then seek to address those gaps as needed.
  And then for the conditional aspect you requested, I would suggest something along the lines of:
• That the governance per existing system aligns with the requirements for your FR/HWR. Essentially, seeking to mitigate the garbage in garbage out problem by resolving the typical challenges of facility IDs, standardization, federation, etc… So as you choose systems to act as trusted partners, the aspects of both limitations / challenges and benefits are all well understood.
• Some examples to highlight the issues that have come up along these lines include:
• There is no trusted partner that covers a particular geographic (region A) or functional aspect of the health system (i.e., private/FBO facilities)
• Partner A does not update their facility list as routinely as others, or follows a different curation process as is required. or Partner B, identifies new facilities much quicker than other systems (i.e., supply chain and logistics systems)
• Partner C & D both govern a subset facilities, which may lead to a multiple master type of scenario.
• There are standardization problems across systems that need to be resolved prior to federation being successful or a national identifier needs to be implemented across systems successful.
• Also, a not trival issues… is the higher level question of alignment of goals among the multiple actors, or do trusted sources for registry data want to work together. We would recommend seeking to resolve this issue first, before getting too far into the nuts and bolts of things… but its important to have robust solutions lined up and ready.
  We were planning to have this as a theme for our upcoming FR technical conversations. We had planned to have focused time for Federation discussions as part of our community roadmap. This is a good reaffirmation that this is an important topic.

Best,

Scott

–

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

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

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

–

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

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

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

On Sun, May 17, 2015 at 10:00 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Derek. Will try out the OpenHIE v1.0 now and call for help…

On May 18, 2015 7:17 AM, “Derek Ritz” derek.ritz@gmail.com wrote:

Hi Alvin (and everyone).

The role of an interlinked registry (ILR) – as Carl described – is precisely to address challenges regarding code set consistency and entity relationship management between data regarding health workers, facilities, organizations and services. As defined by IHE’s Care Services Discovery (CSD) profile, the InfoManager actor supports this interlinking. By design, an InfoManager also supports federation of these many underlying directories.

Alvin, I have attached a short PPT that illustrates these points. The first slide shows the entity relationships between health workers (providers), facilities, organizations and services; it is a graphic from the CSD profile (the text of which can be found here: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_CSD.pdf). The second slide, also from the CSD profile, illustrates how the InfoManager actor refreshes it’s data cache from underlying Directory actors (FR, HWR, codes sets / services – perhaps from the TS, organization lists, etc.) using ITI-74. After the InfoManager cross referencing these data – it exposes the interlinked data to clients (Service Finder actors) who may query for it via ITI-73.

The last slide in the PPT illustrates the position of the InfoManager actor within OpenHIE’s architecture. Sadly (as it can create confusion), we typically do not explicitly show the InfoManager in our OpenHIE diagrams. I think we should probably start to show it. Not calling it out in its own right is likely why, Alvin, you asked if the ILR InfoManager is part of the Interoperability Layer. Indeed, the ILR and the IL are regularly “bundled” (as part of a country implementation); but Carl is correct: they are distinct architectural puzzle pieces.

Thank you for such excellent questions, Alvin!

Warmest regards,

Derek.

PS: slide 2 shows CSD’s freeBusy" transaction (ITI-75). Although ITI-75 is not supported in OpenHIE v1, Carl prototyped and showed this transaction at an eHealth conference in California last summer.

–

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

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

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

–

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

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

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

–
Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

On Sun, May 17, 2015 at 6:18 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl –

In the Philippines there are distinct governance structures for the HWR and the FR. And I think our problem is that the HWR uses a different codeset for facilities aside from the FR causing headaches. The ILR is the ideal bridge…

Pls see attachments - I have two models …

I was thinking that in our context, the ILR is more appropriate as a subset inside the HWR (2nd attachment).

alvin

–

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

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

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

–
Derek Ritz

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

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Mon, May 18, 2015 at 4:18 AM, Carl Leitner litlfred@gmail.com wrote:

Hi Alvin,

The ILR does not exist inside the IL. Really, the question depends largely on the data governance policy for health worker and facility data that you are using. One option, to preserve a bit of ambiguity while these questions are clarified, is to put the HWR and the FR inside/on top of a box called ILR.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 3:26 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl – I’ll need some time to digest these new resources…

Should I then revise my images and put a rectangle called InfoMan between the IL and the HWR/FR? Or is the InfoMan actually embedded inside the IL (ESB) as an implementation of CSD? Sorry but can you guide me from what I understand (the OpenHIE architecture) to how it should be…

I’ll also be seeing Derek in two weeks and I can ask him for a crash course too…

Thanks!

alvin

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 10:46 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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.

[Carl_Leitner1]

Hi Alvin,

We have a reference application of the InfoManager actor in CSD standard. It is called OpenInfoMan and can serve as the ILR:
https://github.com/openhie/openinfoman

If you have an Ubuntu 14.04 LTS machine, then it is an easy install according to the directions above.

Cheers.

-carl

···

On Tue, May 19, 2015 at 7:49 AM, alvin.marcelo@gmail.com wrote:

Thanks Carl. Are there CSD-compliant ILRs already? That we can start using to understand how they work?

Or where we can point our existing FR and HWRs?

Sent from my BlackBerry 10 smartphone.

From: Carl Leitner

Sent: Tuesday, May 19, 2015 15:11

To: facility-registry@googlegroups.com

Reply To: facility-registry@googlegroups.com

Cc: Shaun Grannis; charityltan@gmail.com

Subject: Re: path forward / road map for FR community

Hi Alvin,

Yes, the ILR is simply the joining of the FR and HWR according to the common CSD standard.

Cheers.

-carl

–

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

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

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

–

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

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

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

On Mon, May 18, 2015 at 9:26 PM, alvin.marcelo@gmail.com wrote:

Thanks Scott. Trust is key to getting an ILR to link the FR and HWR. From my perspective, either one is wary to‎ be dependent on the other causing the disintegration.

With an OpenHIE architecture providing solid support to the technical backend, there will be greater confidence in proceeding with (and investing on) the trust-building exercise.

In the end, is the ILR simply a relation of the FR and HWR? ‎And the IHE CSD has all the specs for it?

Lastly, has the community arrived at a maturity model that can help countries assess their readiness for OpenHIE‎ and also to monitor their progress?

These are interesting times for the community!

Alvin

Sent from my BlackBerry 10 smartphone.

From: Scott Teesdale

Sent: Tuesday, May 19, 2015 00:48

To: facility-registry@googlegroups.com

Reply To: facility-registry@googlegroups.com

Cc: Shaun Grannis; charityltan@gmail.com

Subject: Re: path forward / road map for FR community

Great conversation here. Alvin, thanks for your interest! We would love your feedback as you get into these materials and would be happy to work with you as you explore the workflow and its associated components as it relates to your FR/HWR integration.

To answer another one of your past questions, the acronym RM is referencing Resource Map, a reference facility registry tool for OpenHIE.

Lastly, for this request that you shared:

“I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.”

• The assumptions here are correct: Yes, existing data, tools, and governance, can and should be leveraged to the extent possible. It is OpenHIE’s intent to unseat existing systems, but rather look at a comparison of the existing landscape against requirements for how a registry needs to operate and then seek to address those gaps as needed.
  And then for the conditional aspect you requested, I would suggest something along the lines of:
• That the governance per existing system aligns with the requirements for your FR/HWR. Essentially, seeking to mitigate the garbage in garbage out problem by resolving the typical challenges of facility IDs, standardization, federation, etc… So as you choose systems to act as trusted partners, the aspects of both limitations / challenges and benefits are all well understood.
• Some examples to highlight the issues that have come up along these lines include:
• There is no trusted partner that covers a particular geographic (region A) or functional aspect of the health system (i.e., private/FBO facilities)
• Partner A does not update their facility list as routinely as others, or follows a different curation process as is required. or Partner B, identifies new facilities much quicker than other systems (i.e., supply chain and logistics systems)
• Partner C & D both govern a subset facilities, which may lead to a multiple master type of scenario.
• There are standardization problems across systems that need to be resolved prior to federation being successful or a national identifier needs to be implemented across systems successful.
• Also, a not trival issues… is the higher level question of alignment of goals among the multiple actors, or do trusted sources for registry data want to work together. We would recommend seeking to resolve this issue first, before getting too far into the nuts and bolts of things… but its important to have robust solutions lined up and ready.
  We were planning to have this as a theme for our upcoming FR technical conversations. We had planned to have focused time for Federation discussions as part of our community roadmap. This is a good reaffirmation that this is an important topic.

Best,

Scott

–

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

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

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

–

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

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

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

On Sun, May 17, 2015 at 10:00 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Derek. Will try out the OpenHIE v1.0 now and call for help…

On May 18, 2015 7:17 AM, “Derek Ritz” derek.ritz@gmail.com wrote:

Hi Alvin (and everyone).

The role of an interlinked registry (ILR) – as Carl described – is precisely to address challenges regarding code set consistency and entity relationship management between data regarding health workers, facilities, organizations and services. As defined by IHE’s Care Services Discovery (CSD) profile, the InfoManager actor supports this interlinking. By design, an InfoManager also supports federation of these many underlying directories.

Alvin, I have attached a short PPT that illustrates these points. The first slide shows the entity relationships between health workers (providers), facilities, organizations and services; it is a graphic from the CSD profile (the text of which can be found here: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_CSD.pdf). The second slide, also from the CSD profile, illustrates how the InfoManager actor refreshes it’s data cache from underlying Directory actors (FR, HWR, codes sets / services – perhaps from the TS, organization lists, etc.) using ITI-74. After the InfoManager cross referencing these data – it exposes the interlinked data to clients (Service Finder actors) who may query for it via ITI-73.

The last slide in the PPT illustrates the position of the InfoManager actor within OpenHIE’s architecture. Sadly (as it can create confusion), we typically do not explicitly show the InfoManager in our OpenHIE diagrams. I think we should probably start to show it. Not calling it out in its own right is likely why, Alvin, you asked if the ILR InfoManager is part of the Interoperability Layer. Indeed, the ILR and the IL are regularly “bundled” (as part of a country implementation); but Carl is correct: they are distinct architectural puzzle pieces.

Thank you for such excellent questions, Alvin!

Warmest regards,

Derek.

PS: slide 2 shows CSD’s freeBusy" transaction (ITI-75). Although ITI-75 is not supported in OpenHIE v1, Carl prototyped and showed this transaction at an eHealth conference in California last summer.

–

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

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

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

–

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

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

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

–
Scott Teesdale
Project Manager - InSTEDD

Email: steesdale@instedd.org

Skype: scott.teesdale

Social: Twitter / LinkedIn

On Sun, May 17, 2015 at 6:18 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl –

In the Philippines there are distinct governance structures for the HWR and the FR. And I think our problem is that the HWR uses a different codeset for facilities aside from the FR causing headaches. The ILR is the ideal bridge…

Pls see attachments - I have two models …

I was thinking that in our context, the ILR is more appropriate as a subset inside the HWR (2nd attachment).

alvin

–

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

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

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

–
Derek Ritz

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

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Mon, May 18, 2015 at 4:18 AM, Carl Leitner litlfred@gmail.com wrote:

Hi Alvin,

The ILR does not exist inside the IL. Really, the question depends largely on the data governance policy for health worker and facility data that you are using. One option, to preserve a bit of ambiguity while these questions are clarified, is to put the HWR and the FR inside/on top of a box called ILR.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 3:26 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Thanks Carl – I’ll need some time to digest these new resources…

Should I then revise my images and put a rectangle called InfoMan between the IL and the HWR/FR? Or is the InfoMan actually embedded inside the IL (ESB) as an implementation of CSD? Sorry but can you guide me from what I understand (the OpenHIE architecture) to how it should be…

I’ll also be seeing Derek in two weeks and I can ask him for a crash course too…

Thanks!

alvin

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 10:46 PM, Carl Leitner litlfred@gmail.com wrote:

Dear Alvin,

The InfoManager is not a new component, you case it for example here:
https://wiki.ohie.org/pages/viewpage.action?pageId=16482605

where it is the Inter-Linked Registry (ILR) InfoMan. The role of ILR is to bring the data from the FR and the HWR together using the CSD standard. Thus you would have one place to query for both HW and facility data. The term InfoManager is the name of one of the actors in the CSD standard:
http://wiki.ihe.net/index.php?title=Care_Services_Discovery

The inter-linking indicates that the health workers form the HWR are associated to the facilities in the FR.

Hope this helps clarifies.

Cheers,

-carl

–

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 Sun, May 17, 2015 at 12:32 PM, Alvin Marcelo alvin.marcelo@gmail.com wrote:

Hi Derek, Ed,

I’m wary to jump in as I have been lurking mostly and this space is really for you guys. However, I’d like to register some questions which may add clarity (for others who may also be lurking) -

1. OpenHIE InfoManager (I don’t see that in the first attachment – is this a new component?)

2. I know DHIS2 but not RM…what is RM?

3. I agree that some countries already have some sort of facility and HRH registries and these become “constraints” to change. From Derek’s description, it appears the countries can actually retain these (esp the governance around them) but still be at play in the larger scheme of things as long as they ________. I need help in filling the blanks.

Lastly, in the second image, I placed the IHE profiles which are important to an OpenHIE implementation. Pls check if I got them right…I was hoping we could populate this schema with the necessary IHE profiles to give guidance to our member countries…

Many thanks!

alvin (aehin)

–

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.

Alvin B. Marcelo

ph.linkedin.com/in/alvinmarcelo

www.researchgate.net/profile/Alvin_Marcelo

resume

On Sun, May 17, 2015 at 1:56 AM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Derek for your suggestions; I am flying right now but wanted to acknowledge the email; and explain how we can work with these ideas you are contributing in the country requirements-based approach & process that we advocate in the FR community.

See you and others on this list in Ghana!!

~ ej

On May 15, 2015, at 3:00 PM, Derek Ritz (ecGroup) derek.ritz@gmail.com wrote:

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.
2. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.
3. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.] Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.
4. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.
   My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems. As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

Warmest regards,

Derek.

–

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

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

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

–

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.

[Eduardo_Jezierski]

Hi Derek, I was owing this response, after the Accra meeting I got very sick and am now emerging.

Hi all.

I’d like to suggest some thoughts / ideas regarding the Facility Registry (FR) community’s path forward and where I see we have opportunities to add significant value to the overall OpenHIE initiative. I invite others who have opinions on these topics (affirming or dissenting) to add them to this thread so we can have a transparent dialogue on subjects that aren’t always easily discussed.

1. All “save clinical content” transactions submitted to OpenHIE make use of FR data to resolve local facility IDs to “enterprise” facility IDs. This resolution is a crucial part of the transaction. To play its role successfully, an OpenHIE-conformant FR must support the IHE ITI-74 Query for Updated Services transaction.

Yes Derek, isn’t it the way it is now documented? e.g. Log In - OpenHIE Wiki

1. I think we should, prominently in our FR community materials, make it clear that this is so. It seems to me it would be helpful for us to also provide info/content that would assist a software developer who wanted to test whether their FR product meets this crucial criteria for OpenHIE conformance.

Yes, we will refer to the workflows from the implementation guide. Updating the guide is an activity that is ongoing, and is actively happening all the time with different effort volumes going into different packages depending on demand of users and the implementing landscape (e.g. all the effort into making this guide in sync with other MFL/PEPFAR efforts). Scott did let me know he also thinks this is an important area to maintain next.

1. To interoperate with other OpenHIE puzzle pieces (e.g. HMIS, HWR) it is essential for the FR (and all the other architectural elements) to abide common code sets. A number of these common code sets are cached in the OpenHIE InfoManager. To leverage these code sets, the FR must support the IHE ITI-73 Find Matching Services transaction. Again, it would behoove us to explicitly indicate this in our community documentation. And as before, it will be useful to software developers for us to link to conformance test materials and, indeed, to OpenHIE sandbox/test lab assets that may be employed to ensure an FR product is “OpenHIE-ready”.

Agree it should be in the guide. After the last OHIE testing, Scott is going to update the How-Tos so that configuring it to be a facility finder and service finder is easily replicable (first, as it is what’s in the sandbox) and then service finder. CSD has some intricacies allowing for combinations of services, organizations, etc that make it harder to document, but that’s the goal.

1. Our existing FR Implementation Guide materials speak at length about the requirements-gathering and modeling and custom development processes that we purport will necessarily be part of any facility registry “project”.

A correction -there is (should!) be little to no recommendation of custom “development” process. Everyone looses if that’s the perception. We do advocate gathering requirements around model of data, governance, workflows and uses of data.

1. In my experience, there is actually a significant commonality to FR requirements. [NOTE: A distinction must be made between an FR and end-user software applications. There are lots of interesting ways for applications to use FR data… but the FR itself, as an infrastructural service, is comparatively rudimentary.]

Agree that the level of variability of requirements at the FR ‘technology’ level is almost zero; the variability we see is in some aspects of how data is modeled and how people will work with it, which is above and beyond the purview of the FR itself as a service in a SOA system, but critical to those deciding to implement and govern it and extract value from it.

1. Importantly, one of the benefits of OpenHIE’s standards-based approach (vs. a bespoke software development approach) is that it affords countries a way to avoid having to start from scratch. I think we should underline this important benefit. Presently, the CSD profile’s data model is not at all discussed in our FR community materials – even though this schema was developed by OpenHIE community members and it operationalizes the WHO MFL guideline and the joint HL7-OMG specification of facilities & care services. Personally, I think it would be useful for the FR community to lay out a kind of “FR quick start” guide. This guide would describe how countries can leverage their existing, federated, facility databases (found in DHIS2, RM, Excel spreadsheets, whatever…) along with the governance that already surrounds these databases. Such an approach would enable a country to, almost immediately, create a virtual national-scale FR out of existing DHIS2 and RM installations (both of these products already support ITI-74). Such an approach would yield highly valuable results very inexpensively and very rapidly. It also would, quite respectfully, acknowledge a country’s existing investments in technology and governance and embrace these rather than trying to unseat them.

I think we all want to achieve the goal; rather than a quick start it would be a rough ‘quick demonstration guide’ One click and bam! you have something that shows how it could work… Setting the technology up is not the issue in our experience (point in case, Tanzania never set up anything!) ; the biggest questions helping countries is to help them elicit their own governance, schema, curation, sharing, ownership, etc policies. A federated approach to these is an improved paradigm I’m highly supportive of - because it removes the need to agree on meta-governance! - but in the end it just adds degrees of freedom to answer those questions; it doesn’t remove them from the picture.

I think you are mischaracterizing the guide (or it has a terrible bug!) if you think it encourages ‘bespoke software dev approach’ vas ’ a standards based approach’ . If anyone we speak to gets that impression we need to tweak and correct it asap.

1. In my experience, the value of facility lists increases exponentially when these lists are cross-referenced to other key data. An interlinked FR supports queries regarding which locations provide which services under the auspices of which organizations supported by which health workers funded by which mechanisms. I believe we should, as an OpenHIE community of communities, focus explicitly on operationalizing such interlinking by finding ways to coordinate our HWR and FR communities – both of which employ the same underlying standards to support such linking (ITI-73 and ITI-74, described above). Personally, I would even support merging these two communities into one “Interlinked Registries” community.

We have discussed this with the HWR community this week and agreed to add a shared-agenda call periodically to address the needs of those implementers and other community members that are at that stage, but after the sort of feedback we hear every week and also that was loud and clear in Accra, we need to keep making sure that the entry path to interoperable, service oriented HIS presents ‘first rungs in the ladder’ that are as easy/accessible as possible. Many countries are still independently trying to figure out governance around these distinct data elements separately, so coupling them as a default way to have the conversation will push them into an unnecessary level of complexity that will IMO hurt the long term goal of accelerating interoperable HIS deployments. Also coupling them in terms of architecture doesn’t seem like good SOA.

My OpenHIE colleagues know how strongly I favour interoperable, interchangeable, standards-based eHealth infrastructure elements vs. one-off, bespoke software systems.

don’t we all!

As initiatives like PEPFAR’s DATIM start to go to scale, OpenHIE’s value proposition regarding standards-based actors really has an opportunity to pay dividends. Being able to immediately leverage facility information from any database that supports (or can readily support) ITI-73 and ITI-74 represents the difference between a slow and expensive standing start and an agile and affordable running start. I think we should favour the latter option and I believe our FR community can re-focus itself on very deliberately supporting this important aspect of OpenHIE’s vision.

I agree that is a great leverage, but I think implicit in your statement is the belief that what holds the use of a great-high-quality dataset back is that it is not in some piece of software that supports ITI-73 / ITI-74 . Based on the experience of the FR community supporting implementations and requirements and so on, that seems an optimistic perspective about the state of affairs of most countries AND about the ability to brush away ownership/deduplication/curation/governance “sociotechnical” issues.

As a path to integrated systems, a past “loss cascade” analysis (commissioned by the Gates Foundation) attached shows that interoperability (of the sort we discuss here) only becomes the bottleneck once the common goals, incentives, policy, and data quality/semantics get addressed.

OHIE transactions help with the fourth; and the implementation guide is a tool to help countries and implementers navigate the first three as well.

Thanks Derek for the great points and the guide is constantly improving so the feedback is appreciated!

Annex 9 - Obstacles to Integration (Shareable).pdf (4.39 MB)

···

On Friday, May 15, 2015 at 3:00:29 PM UTC-7, Derek Ritz (ecGroup) wrote:

Warmest regards,

Derek.