What is a CSD InfoMangager?

[Carl_Leitner1]

Hi All,

Paul asked me to start a discussion on the role of the InfoManager in the OpenHIE architecture. There are several aspects to this discussion and perhaps it is good to have a review of the CSD functionality.

Let’s start with the CSD perspective of what the Info Manager is supposed to do which is:

• Periodically refreshes cached content from one or more Services Directory actors. A Service Directory actor is a source of data on one or more of the four CSD entities: health workers, health facilities, organizations and services.
• Executes the inbound queries from Service Finder against its cached content and returns a response document in reply.
  This is done against a common data model, expressed in XML, and which we can call a “CSD document” for simplicity. The inbound queries are the “stored queries” as well as the ad-hoc queries. In the CSD standard, there are required four stored queries each centered around the four main entities. In addition to the four required stored queries, CSD allows for an InfoManager to be optionally enhanced with new stored queries.

Restating this from the perspective of OpenHIE documented workflow with the “Facility Registry” and a “Health Worker Registry”, we have:

• the InfoManager requests from the FR shares updates to its CSD document
• the InfoManager requests from the HWR shares its CSD documents
• the InfoManager merges (interlinks) these two CSD documents together into a unified CSD document and answer inbound queries from the Interoperability Layer. This is the Interlinked Registry.
  In short, the InfoManager actor is supposed to bring together multiple CSD data sources into a unified "CSD document” and allow querying against those. The requirements of an InfoManager actor are a bit broader than those of the corresponding OpenHIE workflow as CSD makes no distinction between a FR and a HWR. The OpenHIE reference implementation of the InfoManager actor, OpenInfoMan, supports these broader CSD requirements.

These broader requirements allow for, in particular, a federated view of data. Let’s take the particular example of the HWR in Nigeria. From the simplest perspective, each state has an HRIS system that serves as a source of health worker data. The HWR of Nigeria is essentially nothing more that an InfoManager actor which merges these state CSD documents together to allow for querying against a national registry of health workers. This federated support is built into the core OpenInfoMan software as one of it’s added stored queries. In fact, the OpenInfoMan supports federation of all four of the main entities (health workers, facilities, organization, and services) as there is only one line of code needed to support each one and it would have been silly not to support this.

One way to try to understand the Nigeria HWR example, and the OpenHIE FR+HWR example, is that they are both two cases of federation. The first is federation of health worker data by state, the second is a federation by entity. Both of these cases are handled simultaneously by the OpenInfoMan reference application.

These examples of federation only require two tiers in it’s federation. However, there are examples such as DATIM or WAHO where a federation at three or more tiers would be useful — e.g. sub-national, national, regional/global. Luckily, the OpenInfoMan application can already handle multi-tiered federation. This is because OpenInfoMan is not only a InfoManager actor but a Service Directory as well. Thus a regional (or global) InfoManager actor can ask each of the national registries (which act as both the InfoManager and Service Directory) actors for their updates to the national CSD documents.

We have only so far touched upon the facility and health worker entities in CSD. There are two other ones: organization and service. The concept of an organization in CSD has a couple of useful features:

• A facility can be associated to an organization
• A health worker can be associated to an organization
• An organization can be associated to another organization in a parent-child relationship
  As a CSD organization is not limited to a “legal entities which are service delivery organizations” we can (and do) encode useful things in the CSD organization:
• the geographic hierarchy under which a facility operates
• an collection of facilities that are operated by an FBO or MOH
• the facilities supported by/reportable on for a funding mechanism (represented as an organization)
  We can save talking about services until another time, but they are pretty useful too

There is one other notable thing that the OpenInfoMan reference application does, and that is to support some basic terminology services. There are two main ways:

• There are terminologies referenced in the CSD data model (such as health worker cadre, facility type, type of contact points (e.g. email, phone, fax), etc.). To facilitate the sharing of these terminologies, OpenInfoMan acts as a Value Set Repository according to IHE’s Sharing Value Sets (SVS) profile. This is essentially a way to ask for an xml list defining a simple value set.
• There are some things in the CSD data model which would be useful to represent as a terminology - for example the organizational hierarchy of facilities. There is some nascent support to represent this as a FHIR Value Set, although this was more exploratory work and will need to be updated to see where the TS community lands on representing hierarchies.
  I should also say what the InfoMan and the CSD InfoManager actor are not. It is not supposed to be a business domain application. Rather, it is the Service Directories that should be considered in general as the business domain systems — in the process of doing supporting their business processes, they generate useful data that needs to be merged into an “InterLinked Registry.” Such business domain systems could be:
• A logistics or supply chain system which gathers and maintains information about warehouses and medical stores
• A professional council license and registration systems which collects information about health worker qualifications
• A HR Management system captures information about health worker deployment
• An HMIS, as part of reporting on service delivery, collects information about clinical facilities in a country

Cheers,
-carl

[Jim_Grace1]

Thanks, Carl. That’s helpful!

···

On Mon, Jun 1, 2015 at 1:31 PM, Carl Leitner litlfred@gmail.com wrote:

Hi All,

Paul asked me to start a discussion on the role of the InfoManager in the OpenHIE architecture. There are several aspects to this discussion and perhaps it is good to have a review of the CSD functionality.

Let’s start with the CSD perspective of what the Info Manager is supposed to do which is:

• Periodically refreshes cached content from one or more Services Directory actors. A Service Directory actor is a source of data on one or more of the four CSD entities: health workers, health facilities, organizations and services.
• Executes the inbound queries from Service Finder against its cached content and returns a response document in reply.
  This is done against a common data model, expressed in XML, and which we can call a “CSD document” for simplicity. The inbound queries are the “stored queries” as well as the ad-hoc queries. In the CSD standard, there are required four stored queries each centered around the four main entities. In addition to the four required stored queries, CSD allows for an InfoManager to be optionally enhanced with new stored queries.

Restating this from the perspective of OpenHIE documented workflow with the “Facility Registry” and a “Health Worker Registry”, we have:

• the InfoManager requests from the FR shares updates to its CSD document
• the InfoManager requests from the HWR shares its CSD documents
• the InfoManager merges (interlinks) these two CSD documents together into a unified CSD document and answer inbound queries from the Interoperability Layer. This is the Interlinked Registry.
  In short, the InfoManager actor is supposed to bring together multiple CSD data sources into a unified "CSD document” and allow querying against those. The requirements of an InfoManager actor are a bit broader than those of the corresponding OpenHIE workflow as CSD makes no distinction between a FR and a HWR. The OpenHIE reference implementation of the InfoManager actor, OpenInfoMan, supports these broader CSD requirements.

These broader requirements allow for, in particular, a federated view of data. Let’s take the particular example of the HWR in Nigeria. From the simplest perspective, each state has an HRIS system that serves as a source of health worker data. The HWR of Nigeria is essentially nothing more that an InfoManager actor which merges these state CSD documents together to allow for querying against a national registry of health workers. This federated support is built into the core OpenInfoMan software as one of it’s added stored queries. In fact, the OpenInfoMan supports federation of all four of the main entities (health workers, facilities, organization, and services) as there is only one line of code needed to support each one and it would have been silly not to support this.

One way to try to understand the Nigeria HWR example, and the OpenHIE FR+HWR example, is that they are both two cases of federation. The first is federation of health worker data by state, the second is a federation by entity. Both of these cases are handled simultaneously by the OpenInfoMan reference application.

These examples of federation only require two tiers in it’s federation. However, there are examples such as DATIM or WAHO where a federation at three or more tiers would be useful — e.g. sub-national, national, regional/global. Luckily, the OpenInfoMan application can already handle multi-tiered federation. This is because OpenInfoMan is not only a InfoManager actor but a Service Directory as well. Thus a regional (or global) InfoManager actor can ask each of the national registries (which act as both the InfoManager and Service Directory) actors for their updates to the national CSD documents.

We have only so far touched upon the facility and health worker entities in CSD. There are two other ones: organization and service. The concept of an organization in CSD has a couple of useful features:

• A facility can be associated to an organization
• A health worker can be associated to an organization
• An organization can be associated to another organization in a parent-child relationship
  As a CSD organization is not limited to a “legal entities which are service delivery organizations” we can (and do) encode useful things in the CSD organization:
• the geographic hierarchy under which a facility operates
• an collection of facilities that are operated by an FBO or MOH
• the facilities supported by/reportable on for a funding mechanism (represented as an organization)
  We can save talking about services until another time, but they are pretty useful too

There is one other notable thing that the OpenInfoMan reference application does, and that is to support some basic terminology services. There are two main ways:

• There are terminologies referenced in the CSD data model (such as health worker cadre, facility type, type of contact points (e.g. email, phone, fax), etc.). To facilitate the sharing of these terminologies, OpenInfoMan acts as a Value Set Repository according to IHE’s Sharing Value Sets (SVS) profile. This is essentially a way to ask for an xml list defining a simple value set.
• There are some things in the CSD data model which would be useful to represent as a terminology - for example the organizational hierarchy of facilities. There is some nascent support to represent this as a FHIR Value Set, although this was more exploratory work and will need to be updated to see where the TS community lands on representing hierarchies.
  I should also say what the InfoMan and the CSD InfoManager actor are not. It is not supposed to be a business domain application. Rather, it is the Service Directories that should be considered in general as the business domain systems — in the process of doing supporting their business processes, they generate useful data that needs to be merged into an “InterLinked Registry.” Such business domain systems could be:
• A logistics or supply chain system which gathers and maintains information about warehouses and medical stores
• A professional council license and registration systems which collects information about health worker qualifications
• A HR Management system captures information about health worker deployment
• An HMIS, as part of reporting on service delivery, collects information about clinical facilities in a country

Cheers,
-carl

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

[pbiondich]

Carl, first of all let me say… this is a fantastic document. A lot of this information probably needs to be captured on the wiki in some form. I was pretty familiar with all of it, but I know some of this might be new to folks, so thanks for being explicit over text.

I wonder if I could make a couple of comments / questions, to get the conversation started:

1. By your description, the InfoManager was an actor built specifically for a standards profile focused on “services discovery”… so it’s designed to support collections of information about facilities, health workers, organizations, and services. I presume that other collections (clinical terminologies, people, etc. aren’t included in this definition… correct? I ask because I’m trying to compare the InfoManager to something like Master Data Management repositories, and seeing how they are different and/or similar.

2. What is the value added benefit of an infomanager, if the only collection that is available for an enterprise is across a single domain… i.e., a facility registry?

3. Can the infomanager paradigms be coded into all registries? What are the benefits of a distinct infomanager actor outside of being compliant with the CSD specification?

4. The use case for the infomanager that seemed well accepted and non-controversial was to interrelate two or more types of different service metadata… i.e. facility and health worker data. But you also describe its utility as a basis for federation of a single type of metadata across various sources. Can you maybe show us graphically how you’d architect that? Some questions that I know people might have include things like: does the central facility registry at the country level go away in that design? Are the sources of metadata in this case “below the IL”?

I would like us to get to a place where its well understood across the community as to when an infomanager should be incorporated as a technical component of a national architecture. Is it an actor in all architectures? Optional for certain circumstances?

-Paul

···

On Mon, Jun 1, 2015 at 1:31 PM, Carl Leitner litlfred@gmail.com wrote:

Hi All,

Paul asked me to start a discussion on the role of the InfoManager in the OpenHIE architecture. There are several aspects to this discussion and perhaps it is good to have a review of the CSD functionality.

Let’s start with the CSD perspective of what the Info Manager is supposed to do which is:

• Periodically refreshes cached content from one or more Services Directory actors. A Service Directory actor is a source of data on one or more of the four CSD entities: health workers, health facilities, organizations and services.
• Executes the inbound queries from Service Finder against its cached content and returns a response document in reply.
  This is done against a common data model, expressed in XML, and which we can call a “CSD document” for simplicity. The inbound queries are the “stored queries” as well as the ad-hoc queries. In the CSD standard, there are required four stored queries each centered around the four main entities. In addition to the four required stored queries, CSD allows for an InfoManager to be optionally enhanced with new stored queries.

Restating this from the perspective of OpenHIE documented workflow with the “Facility Registry” and a “Health Worker Registry”, we have:

• the InfoManager requests from the FR shares updates to its CSD document
• the InfoManager requests from the HWR shares its CSD documents
• the InfoManager merges (interlinks) these two CSD documents together into a unified CSD document and answer inbound queries from the Interoperability Layer. This is the Interlinked Registry.
  In short, the InfoManager actor is supposed to bring together multiple CSD data sources into a unified "CSD document” and allow querying against those. The requirements of an InfoManager actor are a bit broader than those of the corresponding OpenHIE workflow as CSD makes no distinction between a FR and a HWR. The OpenHIE reference implementation of the InfoManager actor, OpenInfoMan, supports these broader CSD requirements.

These broader requirements allow for, in particular, a federated view of data. Let’s take the particular example of the HWR in Nigeria. From the simplest perspective, each state has an HRIS system that serves as a source of health worker data. The HWR of Nigeria is essentially nothing more that an InfoManager actor which merges these state CSD documents together to allow for querying against a national registry of health workers. This federated support is built into the core OpenInfoMan software as one of it’s added stored queries. In fact, the OpenInfoMan supports federation of all four of the main entities (health workers, facilities, organization, and services) as there is only one line of code needed to support each one and it would have been silly not to support this.

One way to try to understand the Nigeria HWR example, and the OpenHIE FR+HWR example, is that they are both two cases of federation. The first is federation of health worker data by state, the second is a federation by entity. Both of these cases are handled simultaneously by the OpenInfoMan reference application.

These examples of federation only require two tiers in it’s federation. However, there are examples such as DATIM or WAHO where a federation at three or more tiers would be useful — e.g. sub-national, national, regional/global. Luckily, the OpenInfoMan application can already handle multi-tiered federation. This is because OpenInfoMan is not only a InfoManager actor but a Service Directory as well. Thus a regional (or global) InfoManager actor can ask each of the national registries (which act as both the InfoManager and Service Directory) actors for their updates to the national CSD documents.

We have only so far touched upon the facility and health worker entities in CSD. There are two other ones: organization and service. The concept of an organization in CSD has a couple of useful features:

• A facility can be associated to an organization
• A health worker can be associated to an organization
• An organization can be associated to another organization in a parent-child relationship
  As a CSD organization is not limited to a “legal entities which are service delivery organizations” we can (and do) encode useful things in the CSD organization:
• the geographic hierarchy under which a facility operates
• an collection of facilities that are operated by an FBO or MOH
• the facilities supported by/reportable on for a funding mechanism (represented as an organization)
  We can save talking about services until another time, but they are pretty useful too

There is one other notable thing that the OpenInfoMan reference application does, and that is to support some basic terminology services. There are two main ways:

• There are terminologies referenced in the CSD data model (such as health worker cadre, facility type, type of contact points (e.g. email, phone, fax), etc.). To facilitate the sharing of these terminologies, OpenInfoMan acts as a Value Set Repository according to IHE’s Sharing Value Sets (SVS) profile. This is essentially a way to ask for an xml list defining a simple value set.
• There are some things in the CSD data model which would be useful to represent as a terminology - for example the organizational hierarchy of facilities. There is some nascent support to represent this as a FHIR Value Set, although this was more exploratory work and will need to be updated to see where the TS community lands on representing hierarchies.
  I should also say what the InfoMan and the CSD InfoManager actor are not. It is not supposed to be a business domain application. Rather, it is the Service Directories that should be considered in general as the business domain systems — in the process of doing supporting their business processes, they generate useful data that needs to be merged into an “InterLinked Registry.” Such business domain systems could be:
• A logistics or supply chain system which gathers and maintains information about warehouses and medical stores
• A professional council license and registration systems which collects information about health worker qualifications
• A HR Management system captures information about health worker deployment
• An HMIS, as part of reporting on service delivery, collects information about clinical facilities in a country

Cheers,
-carl

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

[sgrannis]

Carl – thanks for kicking off this conversation — very informative!

On the topic of federation, my understanding is CSD permits federation by requiring that different data sources use a consistent identification scheme, but it does not
specify the strategy by which such an identification scheme is coordinated. Is that correct?

If it’s correct, has there been any discussion specifying how the unique identification scheme would be practically managed among different, overlapping data sources? E.g., if two (or more) sources of facility data that share overlapping facilities supply
information to the info manager, how would the two (or more) facility sources ensure they use a consistent identification scheme? Also, does CSD place any constraints or make any assumptions about the facility/hw/service/organization identification scheme(s)?

Thank you – looking forward to more discussion,

Shaun

···

From: Carl Leitner litlfred@gmail.com

Date: Monday, June 1, 2015 at 1:31 PM

To: “ohie-architecture@googlegroups.com” ohie-architecture@googlegroups.com

Subject: What is a CSD InfoMangager?

Hi All,

Paul asked me to start a discussion on the role of the InfoManager in the OpenHIE architecture. There are several aspects to this discussion and perhaps it is good to have a review of the CSD functionality.

Let’s start with the CSD perspective of what the Info Manager is supposed to do which is:

• Periodically refreshes cached content from one or more Services Directory actors. A Service Directory actor is a source of data on one or more of the four CSD entities: health workers, health facilities, organizations and services.
• Executes the inbound queries from Service Finder against its cached content and returns a response document in reply.
  This is done against a common data model, expressed in XML, and which we can call a “CSD document” for simplicity. The inbound queries are the “stored queries” as well as the ad-hoc queries. In the CSD standard, there are required four stored queries each
  centered around the four main entities. In addition to the four required stored queries, CSD allows for an InfoManager to be optionally enhanced with new stored queries.

Restating this from the perspective of OpenHIE documented workflow with the “Facility Registry” and a “Health Worker Registry”, we have:

• the InfoManager requests from the FR shares updates to its CSD document
• the InfoManager requests from the HWR shares its CSD documents
• the InfoManager merges (interlinks) these two CSD documents together into a unified CSD document and answer inbound queries from the Interoperability Layer. This is the Interlinked Registry.
  In short, the InfoManager actor is supposed to bring together multiple CSD data sources into a unified "CSD document” and allow querying against those. The requirements of an InfoManager actor are a bit broader than those of the corresponding OpenHIE workflow
  as CSD makes no distinction between a FR and a HWR. The OpenHIE reference implementation of the InfoManager actor, OpenInfoMan, supports these broader CSD requirements.

These broader requirements allow for, in particular, a federated view of data. Let’s take the particular example of the HWR in Nigeria. From the simplest perspective, each state has an HRIS system that serves as a source of health worker data. The HWR of
Nigeria is essentially nothing more that an InfoManager actor which merges these state CSD documents together to allow for querying against a national registry of health workers. This federated support is built into the core OpenInfoMan software as one of
it’s added stored queries. In fact, the OpenInfoMan supports federation of all four of the main entities (health workers, facilities, organization, and services) as there is only one line of code needed to support each one and it would have been silly not
to support this.

One way to try to understand the Nigeria HWR example, and the OpenHIE FR+HWR example, is that they are both two cases of federation. The first is federation of health worker data by state, the second is a federation by entity. Both of these cases are handled
simultaneously by the OpenInfoMan reference application.

These examples of federation only require two tiers in it’s federation. However, there are examples such as DATIM or WAHO where a federation at three or more tiers would be useful — e.g. sub-national, national, regional/global. Luckily, the OpenInfoMan application
can already handle multi-tiered federation. This is because OpenInfoMan is not only a InfoManager actor but a Service Directory as well. Thus a regional (or global) InfoManager actor can ask each of the national registries (which act as both the InfoManager
and Service Directory) actors for their updates to the national CSD documents.

We have only so far touched upon the facility and health worker entities in CSD. There are two other ones: organization and service. The concept of an organization in CSD has a couple of useful features:

• A facility can be associated to an organization
• A health worker can be associated to an organization
• An organization can be associated to another organization in a parent-child relationship
  As a CSD organization is not limited to a “legal entities which are service delivery organizations” we can (and do) encode useful things in the CSD organization:
• the geographic hierarchy under which a facility operates
• an collection of facilities that are operated by an FBO or MOH
• the facilities supported by/reportable on for a funding mechanism (represented as an organization)
  We can save talking about services until another time, but they are pretty useful too

There is one other notable thing that the OpenInfoMan reference application does, and that is to support some basic terminology services. There are two main ways:

• There are terminologies referenced in the CSD data model (such as health worker cadre, facility type, type of contact points (e.g. email, phone, fax), etc.). To facilitate the sharing of these terminologies, OpenInfoMan acts as a Value Set Repository
  according to IHE’s Sharing Value Sets (SVS) profile. This is essentially a way to ask for an xml list defining a simple value set.
• There are some things in the CSD data model which would be useful to represent as a terminology - for example the organizational hierarchy of facilities. There is some nascent support to represent this as a FHIR Value Set, although this was more exploratory
  work and will need to be updated to see where the TS community lands on representing hierarchies.
  I should also say what the InfoMan and the CSD InfoManager actor are not. It is not supposed to be a business domain application. Rather, it is the Service Directories that should be considered in general as the business domain systems — in the process of
  doing supporting their business processes, they generate useful data that needs to be merged into an “InterLinked Registry.” Such business domain systems could be:
• A logistics or supply chain system which gathers and maintains information about warehouses and medical stores
• A professional council license and registration systems which collects information about health worker qualifications
• A HR Management system captures information about health worker deployment
• An HMIS, as part of reporting on service delivery, collects information about clinical facilities in a country

Cheers,

-carl

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

[bobj]

Thanks Carl for laying this out.

A quick comment in response to Paul's question (particularly 2 and 3).
I can see potential value in the infomanager "layer" even in a single
domain setup in that it can provide a standardized CSD facade in front
of *any* source of facility (or other) data even, heaven forbid, the
likes of an excel or openoffice spreadsheet. So if there is a
use-value in having a CSD API for such data then there is no need for
what Carl calls business domain applications to build one. Given the
implicit support for things like ad-hoc xquery then such functionality
would actually not be possible to build anyway unless the data model
was resting on an xml data source. So, for example, its really
convenient to place an infoman in front of DHIS2 in order to provide a
CSD API "for free".

Of course the critical point here rests on whether there is
significant use value to be had in the CSD API. Personally I believe
there is or will be, though we still wait to here the stories of
infomanager search clients. It is still early days but it would be
reassuring to start seeing some of those stories filtering through. I
am sure they will. Maybe that will be Carl's next mail

I have become less convinced over the past few years on the practical
goal of creating single sources of authoritative truth on things like
facility registries. I start to feel there is something a bit
authoritarian, macho, heroic and ultimately ill fated about such
ambitions. What I do see as a concrete challenge in many contexts is
the need for a sort of peer-to-peer reconciliation of the contents of
one another's lists (for example between HMIS, LMIS, HWR, ...). I
have a sense that the infoman could have a really useful role to play
here with some extended API calls to assist applications to resolve
difference. Perhaps this touches a little on Shaun's question as
well. I don't believe that the infoman as a technical machine has any
realistic way for example to ensure consistency of identifiers across
sources. But I think there is great scope for it to act as a sort of
smart diff engine to assist different sources to track one another
when it is important for them to do so.

My 2c
Bob

···

On 3 June 2015 at 04:26, Grannis, Shaun J <sgrannis@regenstrief.org> wrote:

Carl – thanks for kicking off this conversation — very informative!

On the topic of federation, my understanding is CSD permits federation by
requiring that different data sources use a consistent identification
scheme, but it does not specify the strategy by which such an identification
scheme is coordinated. Is that correct?

If it’s correct, has there been any discussion specifying how the unique
identification scheme would be practically managed among different,
overlapping data sources? E.g., if two (or more) sources of facility data
that share overlapping facilities supply information to the info manager,
how would the two (or more) facility sources ensure they use a consistent
identification scheme? Also, does CSD place any constraints or make any
assumptions about the facility/hw/service/organization identification
scheme(s)?

Thank you – looking forward to more discussion,

Shaun

From: Carl Leitner <litlfred@gmail.com>
Date: Monday, June 1, 2015 at 1:31 PM
To: "ohie-architecture@googlegroups.com"
<ohie-architecture@googlegroups.com>
Subject: What is a CSD InfoMangager?

Hi All,

Paul asked me to start a discussion on the role of the InfoManager in the
OpenHIE architecture. There are several aspects to this discussion and
perhaps it is good to have a review of the CSD functionality.

Let’s start with the CSD perspective of what the Info Manager is supposed to
do which is:

Periodically refreshes cached content from one or more Services Directory
actors. A Service Directory actor is a source of data on one or more of the
four CSD entities: health workers, health facilities, organizations and
services.
Executes the inbound queries from Service Finder against its cached content
and returns a response document in reply.

This is done against a common data model, expressed in XML, and which we can
call a “CSD document” for simplicity. The inbound queries are the “stored
queries” as well as the ad-hoc queries. In the CSD standard, there are
required four stored queries each centered around the four main entities. In
addition to the four required stored queries, CSD allows for an InfoManager
to be optionally enhanced with new stored queries.

Restating this from the perspective of OpenHIE documented workflow with the
“Facility Registry” and a “Health Worker Registry”, we have:

the InfoManager requests from the FR shares updates to its CSD document
the InfoManager requests from the HWR shares its CSD documents
the InfoManager merges (interlinks) these two CSD documents together into a
unified CSD document and answer inbound queries from the Interoperability
Layer. This is the Interlinked Registry.

In short, the InfoManager actor is supposed to bring together multiple CSD
data sources into a unified "CSD document” and allow querying against those.
The requirements of an InfoManager actor are a bit broader than those of the
corresponding OpenHIE workflow as CSD makes no distinction between a FR and
a HWR. The OpenHIE reference implementation of the InfoManager actor,
OpenInfoMan, supports these broader CSD requirements.

These broader requirements allow for, in particular, a federated view of
data. Let’s take the particular example of the HWR in Nigeria. From the
simplest perspective, each state has an HRIS system that serves as a source
of health worker data. The HWR of Nigeria is essentially nothing more that
an InfoManager actor which merges these state CSD documents together to
allow for querying against a national registry of health workers. This
federated support is built into the core OpenInfoMan software as one of it’s
added stored queries. In fact, the OpenInfoMan supports federation of all
four of the main entities (health workers, facilities, organization, and
services) as there is only one line of code needed to support each one and
it would have been silly not to support this.

One way to try to understand the Nigeria HWR example, and the OpenHIE FR+HWR
example, is that they are both two cases of federation. The first is
federation of health worker data by state, the second is a federation by
entity. Both of these cases are handled simultaneously by the OpenInfoMan
reference application.

These examples of federation only require two tiers in it’s federation.
However, there are examples such as DATIM or WAHO where a federation at
three or more tiers would be useful — e.g. sub-national, national,
regional/global. Luckily, the OpenInfoMan application can already handle
multi-tiered federation. This is because OpenInfoMan is not only a
InfoManager actor but a Service Directory as well. Thus a regional (or
global) InfoManager actor can ask each of the national registries (which act
as both the InfoManager and Service Directory) actors for their updates to
the national CSD documents.

We have only so far touched upon the facility and health worker entities in
CSD. There are two other ones: organization and service. The concept of an
organization in CSD has a couple of useful features:

A facility can be associated to an organization
A health worker can be associated to an organization
An organization can be associated to another organization in a parent-child
relationship

As a CSD organization is not limited to a “legal entities which are service
delivery organizations” we can (and do) encode useful things in the CSD
organization:

the geographic hierarchy under which a facility operates
an collection of facilities that are operated by an FBO or MOH
the facilities supported by/reportable on for a funding mechanism
(represented as an organization)

We can save talking about services until another time, but they are pretty
useful too

There is one other notable thing that the OpenInfoMan reference application
does, and that is to support some basic terminology services. There are two
main ways:

There are terminologies referenced in the CSD data model (such as health
worker cadre, facility type, type of contact points (e.g. email, phone,
fax), etc.). To facilitate the sharing of these terminologies, OpenInfoMan
acts as a Value Set Repository according to IHE’s Sharing Value Sets (SVS)
profile. This is essentially a way to ask for an xml list defining a
simple value set.
There are some things in the CSD data model which would be useful to
represent as a terminology - for example the organizational hierarchy of
facilities. There is some nascent support to represent this as a FHIR
Value Set, although this was more exploratory work and will need to be
updated to see where the TS community lands on representing hierarchies.

I should also say what the InfoMan and the CSD InfoManager actor are not.
It is not supposed to be a business domain application. Rather, it is the
Service Directories that should be considered in general as the business
domain systems — in the process of doing supporting their business
processes, they generate useful data that needs to be merged into an
“InterLinked Registry.” Such business domain systems could be:

A logistics or supply chain system which gathers and maintains information
about warehouses and medical stores
A professional council license and registration systems which collects
information about health worker qualifications
A HR Management system captures information about health worker deployment
An HMIS, as part of reporting on service delivery, collects information
about clinical facilities in a country

Cheers,
-carl

--
You received this message because you are subscribed to the Google Groups
"OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eduardo_Jezierski]

Thanks Carl for sharing this!

I totally share Bob’s perspective on the first two paragraphs.

Ultimately, federation is a useful concept because it allows for diversity and freedom in answering the questions about ownership, hosting, tools, etc. As a direction, I think we should consider ways to support this diversity. To support it, we have to understand the sort of divisions and overlaps - which are rarely purely hierarchical - that happen in the management of the data in the field.
Typically, we have found the sort of diversity of management to happen around:

• Domain of data (eg services, health workers, facilities etc).

• ‘vertical’ subdomains of data (eg facility infrastructure, facility ownership, facility financials, facility contact, facility GIS data)

• ‘Horizontal’ subdomains of data (e.g. some facilities are managed by that NGO, some by the MOH, some by some other gov agency, etc)

• ‘Temporal’ arrangement - e.g. This NGO curates a subset of information but then ‘hands off’ ownership at a certain time to other groups.

These are not theoretical; we can see them e.g. in Tz with the DHIS, LMIS, public/private, and licensing (i.e operating permission) domains.

I think our experience may be different in the FR community than the HWR community where maybe (I’m speaking out of loose impressions) HWRs evolve with a built-in hierarchical classification.

In these sort of federated scenarios, there is definitely a role for external aggregators/caches that can maintain reference (ie read only) information, and façade it to appropriate actors that can’t -for good reasons- be bothered to deal with the diversity of sources. E.g. a CSD facade for a Save Patient Encounter. I see InfoMan as such a cache-aggregator. Beyond CSD, having such a cache expose standards like OData would allow more explicit navigation of diverse entities and allow for queries across them without being tied to XML document idioms and query languages. here’s a pattern I worked on: Entity Aggregation, maybe it helps.

But, enabling the implementation of federated systems would take more than the existence of aggregating façades - each registry service would need to support the concept of federation, and could do so with diverse levels of maturity. This range could go from “doesn’t at all” to allowing the aggregation of such entities while respecting versioning, provenance, and access rules.

(One thing I think we shouldn’t confuse is a federated system where many ‘masters’ coexist, with one where there are many ‘slave’ systems contributing perspectives of data to one ‘masters’- which is actually what we see a lot of countries also want)

The first step would be to make sure that across all systems references to external entities are done in consistent ways - so pointing to “facility X” is unequivocal and also represents its authority service. (e.g. “Frodo from the Shire” → Facility X from the MOH system). Standards need to make sure provenance is documented ubiquitously, and passed through all documents.

Maybe we should look at a set of concrete needs from e.g, Nigeria and try to see the patterns and solutions applicable to those? This can be a very large domain to discuss ‘in the air’ but best practices will only emerge from solving field realities; and then we can look into how diverse standards may apply.

~ ej & scott

···

On Wednesday, June 3, 2015 at 1:34:40 AM UTC-7, Bob Jolliffe wrote:

Thanks Carl for laying this out.

A quick comment in response to Paul’s question (particularly 2 and 3).

I can see potential value in the infomanager “layer” even in a single

domain setup in that it can provide a standardized CSD facade in front

of any source of facility (or other) data even, heaven forbid, the

likes of an excel or openoffice spreadsheet. So if there is a

use-value in having a CSD API for such data then there is no need for

what Carl calls business domain applications to build one. Given the

implicit support for things like ad-hoc xquery then such functionality

would actually not be possible to build anyway unless the data model

was resting on an xml data source. So, for example, its really

convenient to place an infoman in front of DHIS2 in order to provide a

CSD API “for free”.

Of course the critical point here rests on whether there is

significant use value to be had in the CSD API. Personally I believe

there is or will be, though we still wait to here the stories of

infomanager search clients. It is still early days but it would be

reassuring to start seeing some of those stories filtering through. I

am sure they will. Maybe that will be Carl’s next mail

I have become less convinced over the past few years on the practical

goal of creating single sources of authoritative truth on things like

facility registries. I start to feel there is something a bit

authoritarian, macho, heroic and ultimately ill fated about such

ambitions. What I do see as a concrete challenge in many contexts is

the need for a sort of peer-to-peer reconciliation of the contents of

one another’s lists (for example between HMIS, LMIS, HWR, …). I

have a sense that the infoman could have a really useful role to play

here with some extended API calls to assist applications to resolve

difference. Perhaps this touches a little on Shaun’s question as

well. I don’t believe that the infoman as a technical machine has any

realistic way for example to ensure consistency of identifiers across

sources. But I think there is great scope for it to act as a sort of

smart diff engine to assist different sources to track one another

when it is important for them to do so.

My 2c

Bob

On 3 June 2015 at 04:26, Grannis, Shaun J sgra...@regenstrief.org wrote:

Carl – thanks for kicking off this conversation — very informative!

On the topic of federation, my understanding is CSD permits federation by

requiring that different data sources use a consistent identification

scheme, but it does not specify the strategy by which such an identification

scheme is coordinated. Is that correct?

If it’s correct, has there been any discussion specifying how the unique

identification scheme would be practically managed among different,

overlapping data sources? E.g., if two (or more) sources of facility data

that share overlapping facilities supply information to the info manager,

how would the two (or more) facility sources ensure they use a consistent

identification scheme? Also, does CSD place any constraints or make any

assumptions about the facility/hw/service/organization identification

scheme(s)?

Thank you – looking forward to more discussion,

Shaun

From: Carl Leitner litl...@gmail.com

Date: Monday, June 1, 2015 at 1:31 PM

To: “ohie-arc...@googlegroups.com”

ohie-arc...@googlegroups.com

Subject: What is a CSD InfoMangager?

Hi All,

Paul asked me to start a discussion on the role of the InfoManager in the

OpenHIE architecture. There are several aspects to this discussion and

perhaps it is good to have a review of the CSD functionality.

Let’s start with the CSD perspective of what the Info Manager is supposed to

do which is:

Periodically refreshes cached content from one or more Services Directory

actors. A Service Directory actor is a source of data on one or more of the

four CSD entities: health workers, health facilities, organizations and

services.

Executes the inbound queries from Service Finder against its cached content

and returns a response document in reply.

This is done against a common data model, expressed in XML, and which we can

call a “CSD document” for simplicity. The inbound queries are the “stored

queries” as well as the ad-hoc queries. In the CSD standard, there are

required four stored queries each centered around the four main entities. In

addition to the four required stored queries, CSD allows for an InfoManager

to be optionally enhanced with new stored queries.

Restating this from the perspective of OpenHIE documented workflow with the

“Facility Registry” and a “Health Worker Registry”, we have:

the InfoManager requests from the FR shares updates to its CSD document

the InfoManager requests from the HWR shares its CSD documents

the InfoManager merges (interlinks) these two CSD documents together into a

unified CSD document and answer inbound queries from the Interoperability

Layer. This is the Interlinked Registry.

In short, the InfoManager actor is supposed to bring together multiple CSD

data sources into a unified "CSD document” and allow querying against those.

The requirements of an InfoManager actor are a bit broader than those of the

corresponding OpenHIE workflow as CSD makes no distinction between a FR and

a HWR. The OpenHIE reference implementation of the InfoManager actor,

OpenInfoMan, supports these broader CSD requirements.

These broader requirements allow for, in particular, a federated view of

data. Let’s take the particular example of the HWR in Nigeria. From the

simplest perspective, each state has an HRIS system that serves as a source

of health worker data. The HWR of Nigeria is essentially nothing more that

an InfoManager actor which merges these state CSD documents together to

allow for querying against a national registry of health workers. This

federated support is built into the core OpenInfoMan software as one of it’s

added stored queries. In fact, the OpenInfoMan supports federation of all

four of the main entities (health workers, facilities, organization, and

services) as there is only one line of code needed to support each one and

it would have been silly not to support this.

One way to try to understand the Nigeria HWR example, and the OpenHIE FR+HWR

example, is that they are both two cases of federation. The first is

federation of health worker data by state, the second is a federation by

entity. Both of these cases are handled simultaneously by the OpenInfoMan

reference application.

These examples of federation only require two tiers in it’s federation.

However, there are examples such as DATIM or WAHO where a federation at

three or more tiers would be useful — e.g. sub-national, national,

regional/global. Luckily, the OpenInfoMan application can already handle

multi-tiered federation. This is because OpenInfoMan is not only a

InfoManager actor but a Service Directory as well. Thus a regional (or

global) InfoManager actor can ask each of the national registries (which act

as both the InfoManager and Service Directory) actors for their updates to

the national CSD documents.

We have only so far touched upon the facility and health worker entities in

CSD. There are two other ones: organization and service. The concept of an

organization in CSD has a couple of useful features:

A facility can be associated to an organization

A health worker can be associated to an organization

An organization can be associated to another organization in a parent-child

relationship

As a CSD organization is not limited to a “legal entities which are service

delivery organizations” we can (and do) encode useful things in the CSD

organization:

the geographic hierarchy under which a facility operates

an collection of facilities that are operated by an FBO or MOH

the facilities supported by/reportable on for a funding mechanism

(represented as an organization)

We can save talking about services until another time, but they are pretty

useful too

There is one other notable thing that the OpenInfoMan reference application

does, and that is to support some basic terminology services. There are two

main ways:

There are terminologies referenced in the CSD data model (such as health

worker cadre, facility type, type of contact points (e.g. email, phone,

fax), etc.). To facilitate the sharing of these terminologies, OpenInfoMan

acts as a Value Set Repository according to IHE’s Sharing Value Sets (SVS)

profile. This is essentially a way to ask for an xml list defining a

simple value set.

There are some things in the CSD data model which would be useful to

represent as a terminology - for example the organizational hierarchy of

facilities. There is some nascent support to represent this as a FHIR

Value Set, although this was more exploratory work and will need to be

updated to see where the TS community lands on representing hierarchies.

I should also say what the InfoMan and the CSD InfoManager actor are not.

It is not supposed to be a business domain application. Rather, it is the

Service Directories that should be considered in general as the business

domain systems — in the process of doing supporting their business

processes, they generate useful data that needs to be merged into an

“InterLinked Registry.” Such business domain systems could be:

A logistics or supply chain system which gathers and maintains information

about warehouses and medical stores

A professional council license and registration systems which collects

information about health worker qualifications

A HR Management system captures information about health worker deployment

An HMIS, as part of reporting on service delivery, collects information

about clinical facilities in a country

Cheers,

-carl

–

You received this message because you are subscribed to the Google Groups

“OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to ohie-architect...@googlegroups.com.

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

–

You received this message because you are subscribed to the Google Groups

“OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to ohie-architect...@googlegroups.com.

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

[Carl_Leitner]

Hi Paul,
Please see my responses inline.
Cheers,

-carl

Carl, first of all let me say… this is a fantastic document. A lot of this information probably needs to be captured on the wiki in some form. I was pretty familiar with all of it, but I know some of this might be new to folks, so
thanks for being explicit over text.

I wonder if I could make a couple of comments / questions, to get the conversation started:

1. By your description, the InfoManager was an actor built specifically for a standards profile focused on “services discovery”… so it’s designed to support collections of information about facilities, health workers, organizations, and services.
   I presume that other collections (clinical terminologies, people, etc. aren’t included in this definition… correct? I ask because I’m trying to compare the InfoManager to something like Master Data Management repositories, and seeing how they are different
   and/or similar.

That is correct. The scope of CSD (in terms of its queries and data model) is constrained by the use cases. These include:

• Health Worker Staff Levels

• Provider Availability Query. For example a patient consults with his physician who recommends surgery. The patient needs to find a suitable surgeon, taking into consideration the location and availability of the surgeons)

• Provider Authorization and lookup during an emergency event

• Keeping agency provider information current

• Providing Personal Health records to a new Primary Care Physician: An individual has changed health plans. As a result that individual must change his Primary Care Physician. The individual has a Personal Health Record and would like to provide
  that information to his new Primary Care Physician. The individual needs to determine where to have the Personal Health Record transmitted to.

• Certificate Retrieval: National regulations in many European countries require that an electronically transmitted doctor’s letter is encrypted in a way that only the identified receiver is able to decrypt it. In order to encrypt the letter, the
  sender has to discover the encryption certificate of the receiver.

• Language Retrieval: An individual who only speaks Italian requires healthcare services at an Outpatient Clinic. That individual would like to be able to communicate with the Clinic personnel in his native language. The individual or his caregiver
  needs to determine which clinic supports Italian and provides the care service that is required.

• Generate a full list of facilities, including GPS coordinates, sorted by region or district. Filter the list by specific Service or Services offered at the facility

  Quantify facilities based on service levels and types, locations based on types and service levels, understand resources for a given facility (ICT applications, beds, etc.), catchment area viewing to determine levels of service provision for a
  geographic area, contextual metadata about facility types inline with view of facility attributes, potentially track other facilities outside of health facilities, filter map views by ownership type (to help look for collaborative opportunities)

  Search for facilities by facility name; view details about each facility (operational status, contact information, type), search by district, display the facility information on a map based on the GPS coordinates

  Filter facility by implementing partner, filter by service and region, view data for filtered list one by one both as viewing one per site, and in context of all (map view of facilities based on their GPS coordinates), available mobile networks
  for facility, power source.

  Filter facilities by service, admin hierarchy, view in web application, along with facility details, , subservices provided by facilities (i.e., kangaroo care within a facility)

2. What is the value added benefit of an infomanager, if the only collection that is available for an enterprise is across a single domain… i.e., a facility registry?

Bob’s response highlights quite well some of the added values.

Perhaps a way to restate the question is can a Facility Registry serve as an InfoManager instead of a Services Directory. The answer is certainly. However, this is would be a lot of extra effort for no little value. In order to do so a FR as an InfoManager
would need to:

• Respond to the service search query with an empty result set
• Respond to the health worker search query with an empty set
• Respond to the organization search query with an empty set
• Implement the full facility search query defined in 3.73.4.1.2.3 of the standard.
  Although the first three are pretty trivial, the last one is a search across 10 or so parameters. Moreover, one of those parameters is the “record last updated” parameter which is the only parameter in ITI-74 that a FR as a service directory
  would need to implement. So you haven’t really gained anything functionally and spent a fair amount of development time to reimplement something that already exists.

3. Can the infomanager paradigms be coded into all registries? What are the benefits of a distinct infomanager actor outside of being compliant with the CSD specification?

For the first question, if you are thinking of the client registry, I think that the paradigm is a bit different. The entities represented in CSD are to a certain extent “managed” entities, that there is some authority to say that “this is a facility”
or “this is a health worker”. My understanding of the role of the client registry is that there is little of this type of management — there is no approval process to assert someone is a client to be added to a client registry against which to record clinical
information against.

In terms of federation of data sources, one of the roles of the InfoManager is to enforce the data governance policy for the various Service Directories. Note, in order to keep the first part of the discussion coins, I only gave the example of “simple
merge” federation model, but in reality this is not the case (see 4 below).

There may be some utility of having a simple federated paradigm against which client registries across jurisdictions can cross-reference clients. I am thinking, for example, of the challenges with cross-border contact tracing in the Ebola outbreak. I
don’t know what a data governance model here would be.

For the second question, there are two main benefits that I see. One is that the data on health worker and health facilities that we have is inherently federated and the CSD specification usefully defines a means by which that data can be brought that
together. In fact, in reference to health worker data, this was my main motivation for getting involved in CSD in the first place — there was nothing out there that could solve the problems we were facing for years. Nothing that we could point other vendors
to as a common way to exchange information. Instead we were getting into endless peer-to-peer data exchange between systems that simply added more and more complexity and required more and more software development time.

The second main benefit is the common data model for the four entities in CSD to facilitate data representation and exchange.

4. The use case for the infomanager that seemed well accepted and non-controversial was to interrelate two or more types of different service metadata… i.e. facility and health worker data. But you also describe its utility as a basis for
   federation of a single type of metadata across various sources. Can you maybe show us graphically how you’d architect that? Some questions that I know people might have include things like: does the central facility registry at the country level go away
   in that design? Are the sources of metadata in this case “below the IL”?

Here is an example of how you would implement a multi-tiered regional health worker registry. Red boxes are Service Directories, Blue boxes are InfoManager, and Green are Service Finders. Here the multi-tier is enabled by a service (e.g. OpenInfoMan)
that acts as both a Services Directory and Services Finder. Sorry, but this doesn’t really illustrate where the IL fits in this picture. Certainly it would sit between the SF and the IM on ITI-74.

In the lower part of the picture, you also an example of data federation which is not a simple merging. Looking in the Nigeria case, we have two State Ministries of Health (SMOH) but also the Nursing Council (NC). You will see one nurse represented
in the council system as well as at least one of the SMOH HRISs. The NC will be the authority of the license and registration data for a health worker, the SMOH would be the authority for the deployment/posing data for the health worker. When this data
gets pulled into the Nigeria HWR, the InfoManager will have to merge these data elements together for a specific health worker. We would also need to enforce things like only pull in deployment data for facilities in Cross Rivers from the Cross Rivers HRIS
(and not Lagos State for example).

In the case of multiple sources of facility data, I don’t think the FR goes away in this design at all. There are several sources of facility data and an appropriate governance on these systems needs to be defined. The FR the in an instantiation of
that data model in an InfoManager.

···

On Mon, Jun 1, 2015 at 1:31 PM, Carl Leitner
litlfred@gmail.com wrote:

Hi All,

Paul asked me to start a discussion on the role of the InfoManager in the OpenHIE architecture. There are several aspects to this discussion and perhaps it is good to have a review of the CSD functionality.

Let’s start with the CSD perspective of what the Info Manager is supposed to do which is:

• Periodically refreshes cached content from one or more Services Directory actors. A Service Directory actor is a source of data on one or more of the four CSD entities: health workers, health facilities, organizations and services.
• Executes the inbound queries from Service Finder against its cached content and returns a response document in reply.
  This is done against a common data model, expressed in XML, and which we can call a “CSD document” for simplicity. The inbound queries are the “stored queries” as well as the ad-hoc queries. In the CSD standard, there are required four stored queries each
  centered around the four main entities. In addition to the four required stored queries, CSD allows for an InfoManager to be optionally enhanced with new stored queries.

Restating this from the perspective of OpenHIE documented workflow with the “Facility Registry” and a “Health Worker Registry”, we have:

• the InfoManager requests from the FR shares updates to its CSD document
• the InfoManager requests from the HWR shares its CSD documents
• the InfoManager merges (interlinks) these two CSD documents together into a unified CSD document and answer inbound queries from the Interoperability Layer. This is the Interlinked Registry.
  In short, the InfoManager actor is supposed to bring together multiple CSD data sources into a unified "CSD document” and allow querying against those. The requirements of an InfoManager actor are a bit broader than those of the corresponding OpenHIE workflow
  as CSD makes no distinction between a FR and a HWR. The OpenHIE reference implementation of the InfoManager actor, OpenInfoMan, supports these broader CSD requirements.

These broader requirements allow for, in particular, a federated view of data. Let’s take the particular example of the HWR in Nigeria. From the simplest perspective, each state has an HRIS system that serves as a source of health worker data. The HWR of
Nigeria is essentially nothing more that an InfoManager actor which merges these state CSD documents together to allow for querying against a national registry of health workers. This federated support is built into the core OpenInfoMan software as one of
it’s added stored queries. In fact, the OpenInfoMan supports federation of all four of the main entities (health workers, facilities, organization, and services) as there is only one line of code needed to support each one and it would have been silly not
to support this.

One way to try to understand the Nigeria HWR example, and the OpenHIE FR+HWR example, is that they are both two cases of federation. The first is federation of health worker data by state, the second is a federation by entity. Both of these cases are handled
simultaneously by the OpenInfoMan reference application.

These examples of federation only require two tiers in it’s federation. However, there are examples such as DATIM or WAHO where a federation at three or more tiers would be useful — e.g. sub-national, national, regional/global. Luckily, the OpenInfoMan application
can already handle multi-tiered federation. This is because OpenInfoMan is not only a InfoManager actor but a Service Directory as well. Thus a regional (or global) InfoManager actor can ask each of the national registries (which act as both the InfoManager
and Service Directory) actors for their updates to the national CSD documents.

We have only so far touched upon the facility and health worker entities in CSD. There are two other ones: organization and service. The concept of an organization in CSD has a couple of useful features:

• A facility can be associated to an organization
• A health worker can be associated to an organization
• An organization can be associated to another organization in a parent-child relationship
  As a CSD organization is not limited to a “legal entities which are service delivery organizations” we can (and do) encode useful things in the CSD organization:
• the geographic hierarchy under which a facility operates
• an collection of facilities that are operated by an FBO or MOH
• the facilities supported by/reportable on for a funding mechanism (represented as an organization)
  We can save talking about services until another time, but they are pretty useful too

There is one other notable thing that the OpenInfoMan reference application does, and that is to support some basic terminology services. There are two main ways:

• There are terminologies referenced in the CSD data model (such as health worker cadre, facility type, type of contact points (e.g. email, phone, fax), etc.). To facilitate the sharing of these terminologies, OpenInfoMan acts as a Value Set Repository
  according to IHE’s Sharing Value Sets (SVS) profile. This is essentially a way to ask for an xml list defining a simple value set.
• There are some things in the CSD data model which would be useful to represent as a terminology - for example the organizational hierarchy of facilities. There is some nascent support to represent this as a FHIR Value Set, although this was more
  exploratory work and will need to be updated to see where the TS community lands on representing hierarchies.
  I should also say what the InfoMan and the CSD InfoManager actor are not. It is not supposed to be a business domain application. Rather, it is the Service Directories that should be considered in general as the business domain systems — in the process of
  doing supporting their business processes, they generate useful data that needs to be merged into an “InterLinked Registry.” Such business domain systems could be:
• A logistics or supply chain system which gathers and maintains information about warehouses and medical stores
• A professional council license and registration systems which collects information about health worker qualifications
• A HR Management system captures information about health worker deployment
• An HMIS, as part of reporting on service delivery, collects information about clinical facilities in a country

Cheers,

-carl

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

ohie-architecture+unsubscribe@googlegroups.com.

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

[Carl_Leitner]

Cheers,

-carl

Carl – thanks for kicking off this conversation — very informative!

On the topic of federation, my understanding is CSD permits federation by requiring that different data sources use a consistent identification scheme, but it does not
specify the strategy by which such an identification scheme is coordinated. Is that correct?

Yes, that is to be defined by the jurisdiction. Some hints at that are given in my response to Paul.

If it’s correct, has there been any discussion specifying how the unique identification scheme would be practically managed among different, overlapping data sources? E.g., if two (or more) sources of facility data that share overlapping facilities
supply information to the info manager, how would the two (or more) facility sources ensure they use a consistent identification scheme? Also, does CSD place any constraints or make any assumptions about the facility/hw/service/organization identification
scheme(s)?

The unique identifier for CSD is a UUID and has no semantic meaning. It does allow local identifiers and you would preserve those local identifiers in the “merged” directory. Here is a snippet of what a record might look like (to be concrete):

<csd:facility
entityID=“urn:uuid:477F577B-3E6E-30EA-AD16-BE1127B6EC45”>

<csd:otherID
assigningAuthorityName=“dhis.org:orgid”
code="ezWx8rfhHjc”/>

  **<csd:otherID** assigningAuthorityName=“lmis.org:orgid" code=“1923012930213912"**/>**

<csd:codedType
code=“4”
codingScheme=“2.25.268234768686152474523705575269868869248.2”/>

csd:primaryNameArcturus Nekkar Clinic</csd:primaryName>

The otherID’s are the local IDs.

Hope that answers your question.

···

On Jun 2, 2015, at 11:26 PM, Grannis, Shaun J sgrannis@regenstrief.org wrote:

Thank you – looking forward to more discussion,

Shaun

From: Carl Leitner litlfred@gmail.com

Date: Monday, June 1, 2015 at 1:31 PM

To: “ohie-architecture@googlegroups.com” ohie-architecture@googlegroups.com

Subject: What is a CSD InfoMangager?

Hi All,

Paul asked me to start a discussion on the role of the InfoManager in the OpenHIE architecture. There are several aspects to this discussion and perhaps it is good to have a review of the CSD functionality.

Let’s start with the CSD perspective of what the Info Manager is supposed to do which is:

• Periodically refreshes cached content from one or more Services Directory actors. A Service Directory actor is a source of data on one or more of the four CSD entities: health workers, health facilities, organizations and services.
• Executes the inbound queries from Service Finder against its cached content and returns a response document in reply.
  This is done against a common data model, expressed in XML, and which we can call a “CSD document” for simplicity. The inbound queries are the “stored queries” as well as the ad-hoc queries. In the CSD standard, there are required four stored queries each
  centered around the four main entities. In addition to the four required stored queries, CSD allows for an InfoManager to be optionally enhanced with new stored queries.

Restating this from the perspective of OpenHIE documented workflow with the “Facility Registry” and a “Health Worker Registry”, we have:

• the InfoManager requests from the FR shares updates to its CSD document
• the InfoManager requests from the HWR shares its CSD documents
• the InfoManager merges (interlinks) these two CSD documents together into a unified CSD document and answer inbound queries from the Interoperability Layer. This is the Interlinked Registry.
  In short, the InfoManager actor is supposed to bring together multiple CSD data sources into a unified "CSD document” and allow querying against those. The requirements of an InfoManager actor are a bit broader than those of the corresponding OpenHIE workflow
  as CSD makes no distinction between a FR and a HWR. The OpenHIE reference implementation of the InfoManager actor, OpenInfoMan, supports these broader CSD requirements.

These broader requirements allow for, in particular, a federated view of data. Let’s take the particular example of the HWR in Nigeria. From the simplest perspective, each state has an HRIS system that serves as a source of health worker data. The HWR of
Nigeria is essentially nothing more that an InfoManager actor which merges these state CSD documents together to allow for querying against a national registry of health workers. This federated support is built into the core OpenInfoMan software as one of
it’s added stored queries. In fact, the OpenInfoMan supports federation of all four of the main entities (health workers, facilities, organization, and services) as there is only one line of code needed to support each one and it would have been silly not
to support this.

One way to try to understand the Nigeria HWR example, and the OpenHIE FR+HWR example, is that they are both two cases of federation. The first is federation of health worker data by state, the second is a federation by entity. Both of these cases are handled
simultaneously by the OpenInfoMan reference application.

These examples of federation only require two tiers in it’s federation. However, there are examples such as DATIM or WAHO where a federation at three or more tiers would be useful — e.g. sub-national, national, regional/global. Luckily, the OpenInfoMan application
can already handle multi-tiered federation. This is because OpenInfoMan is not only a InfoManager actor but a Service Directory as well. Thus a regional (or global) InfoManager actor can ask each of the national registries (which act as both the InfoManager
and Service Directory) actors for their updates to the national CSD documents.

We have only so far touched upon the facility and health worker entities in CSD. There are two other ones: organization and service. The concept of an organization in CSD has a couple of useful features:

• A facility can be associated to an organization
• A health worker can be associated to an organization
• An organization can be associated to another organization in a parent-child relationship
  As a CSD organization is not limited to a “legal entities which are service delivery organizations” we can (and do) encode useful things in the CSD organization:
• the geographic hierarchy under which a facility operates
• an collection of facilities that are operated by an FBO or MOH
• the facilities supported by/reportable on for a funding mechanism (represented as an organization)
  We can save talking about services until another time, but they are pretty useful too

There is one other notable thing that the OpenInfoMan reference application does, and that is to support some basic terminology services. There are two main ways:

• There are terminologies referenced in the CSD data model (such as health worker cadre, facility type, type of contact points (e.g. email, phone, fax), etc.). To facilitate the sharing of these terminologies, OpenInfoMan acts as a Value Set Repository
  according to IHE’s Sharing Value Sets (SVS) profile. This is essentially a way to ask for an xml list defining a simple value set.
• There are some things in the CSD data model which would be useful to represent as a terminology - for example the organizational hierarchy of facilities. There is some nascent support to represent this as a FHIR Value Set, although this was more
  exploratory work and will need to be updated to see where the TS community lands on representing hierarchies.
  I should also say what the InfoMan and the CSD InfoManager actor are not. It is not supposed to be a business domain application. Rather, it is the Service Directories that should be considered in general as the business domain systems — in the process of
  doing supporting their business processes, they generate useful data that needs to be merged into an “InterLinked Registry.” Such business domain systems could be:
• A logistics or supply chain system which gathers and maintains information about warehouses and medical stores
• A professional council license and registration systems which collects information about health worker qualifications
• A HR Management system captures information about health worker deployment
• An HMIS, as part of reporting on service delivery, collects information about clinical facilities in a country

Cheers,

-carl

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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

[Carl_Leitner]

Hi Ed,

Sorry for the misleading simplification of the example of state HRIS systems in Nigeria. In reality, HW data is very much not hierarchical, we typically have several types of systems that we need to pull data from:

• HR management system (these will be single sector e.g. public or FBO)
• payroll systems (typically single sector)
• licensure and registration management systems for a professional council (these are cross-sectoral - public/private/FBOs)
• pre-servive training information systems (can be either single training organization or cross sectorial, may be single cadre or multiple cadre)
• in-service training information systems (can be either single training organization or cross sectorial, may be single cadre or multiple cadre)
  These all have a “piece” of the data on the health worker, but no single system has all of them.

Cheers,

-carl

···

On Jun 4, 2015, at 6:40 PM, Eduardo Jezierski edjez@instedd.org wrote:

Thanks Carl for sharing this!

I totally share Bob’s perspective on the first
two paragraphs.

Ultimately, federation is a useful concept because
it allows for diversity and freedom in answering the questions about ownership, hosting, tools, etc. As a direction, I think we should consider ways to support this diversity. To support it, we have to understand the sort of divisions and overlaps - which
are rarely purely hierarchical - that happen in the management of the data in the field.

Typically, we have found the sort of diversity of management to happen around:

• Domain of data (eg services, health workers, facilities etc).

• ‘vertical’ subdomains of data (eg facility infrastructure, facility
  ownership, facility financials, facility contact, facility GIS data)

• ‘Horizontal’ subdomains of data (e.g. some facilities are managed
  by that NGO, some by the MOH, some by some other gov agency, etc)

• ‘Temporal’ arrangement - e.g. This NGO curates a subset of information
  but then ‘hands off’ ownership at a certain time to other groups.

These are not theoretical; we can see them e.g.
in Tz with the DHIS, LMIS, public/private, and licensing (i.e operating permission) domains.

I think our experience may be different in the
FR community than the HWR community where maybe (I’m speaking out of loose impressions) HWRs evolve with a built-in hierarchical classification.

In these sort of federated scenarios, there is
definitely a role for external aggregators/caches that can maintain reference (ie read only) information, and façade it to appropriate actors that can’t -for good reasons- be bothered to deal with the diversity of sources. E.g. a CSD facade for a Save Patient
Encounter. I see InfoMan as such a cache-aggregator. Beyond CSD, having such a cache expose standards like OData would allow more explicit navigation of diverse entities and allow for queries across them without being tied to XML document idioms and query
languages. here’s a pattern I worked on: Entity Aggregation ,
maybe it helps.

But, enabling the implementation of federated
systems would take more than the existence of aggregating façades - each registry service would need to support the concept of federation, and could do so with diverse levels of maturity. This range could go from “doesn’t at all” to allowing the aggregation
of such entities while respecting versioning, provenance, and access rules.

(One thing I think we shouldn’t confuse is a
federated system where many ‘masters’ coexist, with one where there are many ‘slave’ systems contributing perspectives of data to one ‘masters’- which is actually what we see a lot of countries also want)

The first step would be to make sure that across
all systems references to external entities are done in consistent ways - so pointing to “facility X” is unequivocal and also represents its authority service. (e.g. “Frodo from the Shire” → Facility X from the MOH system). Standards need to make sure provenance
is documented ubiquitously, and passed through all documents.

Maybe we should look at a set of concrete needs
from e.g, Nigeria and try to see the patterns and solutions applicable to those? This can be a very large domain to discuss ‘in the air’ but best practices will only emerge from solving field realities; and then we can look into how diverse standards may apply.

~ ej & scott

On Wednesday, June 3, 2015 at 1:34:40 AM UTC-7, Bob Jolliffe wrote:

Thanks Carl for laying this out.

A quick comment in response to Paul’s question (particularly 2 and 3).

I can see potential value in the infomanager “layer” even in a single

domain setup in that it can provide a standardized CSD facade in front

of any source of facility (or other) data even, heaven forbid, the

likes of an excel or openoffice spreadsheet. So if there is a

use-value in having a CSD API for such data then there is no need for

what Carl calls business domain applications to build one. Given the

implicit support for things like ad-hoc xquery then such functionality

would actually not be possible to build anyway unless the data model

was resting on an xml data source. So, for example, its really

convenient to place an infoman in front of DHIS2 in order to provide a

CSD API “for free”.

Of course the critical point here rests on whether there is

significant use value to be had in the CSD API. Personally I believe

there is or will be, though we still wait to here the stories of

infomanager search clients. It is still early days but it would be

reassuring to start seeing some of those stories filtering through. I

am sure they will. Maybe that will be Carl’s next mail

I have become less convinced over the past few years on the practical

goal of creating single sources of authoritative truth on things like

facility registries. I start to feel there is something a bit

authoritarian, macho, heroic and ultimately ill fated about such

ambitions. What I do see as a concrete challenge in many contexts is

the need for a sort of peer-to-peer reconciliation of the contents of

one another’s lists (for example between HMIS, LMIS, HWR, …). I

have a sense that the infoman could have a really useful role to play

here with some extended API calls to assist applications to resolve

difference. Perhaps this touches a little on Shaun’s question as

well. I don’t believe that the infoman as a technical machine has any

realistic way for example to ensure consistency of identifiers across

sources. But I think there is great scope for it to act as a sort of

smart diff engine to assist different sources to track one another

when it is important for them to do so.

My 2c

Bob

On 3 June 2015 at 04:26, Grannis, Shaun J <sgra...@regenstrief.org > > > wrote:

Carl – thanks for kicking off this conversation — very informative!

On the topic of federation, my understanding is CSD permits federation by

requiring that different data sources use a consistent identification

scheme, but it does not specify the strategy by which such an identification

scheme is coordinated. Is that correct?

If it’s correct, has there been any discussion specifying how the unique

identification scheme would be practically managed among different,

overlapping data sources? E.g., if two (or more) sources of facility data

that share overlapping facilities supply information to the info manager,

how would the two (or more) facility sources ensure they use a consistent

identification scheme? Also, does CSD place any constraints or make any

assumptions about the facility/hw/service/organization identification

scheme(s)?

Thank you – looking forward to more discussion,

Shaun

From: Carl Leitner litl...@gmail.com

Date: Monday, June 1, 2015 at 1:31 PM

To: “ohie-arc...@googlegroups.com”

ohie-arc...@googlegroups.com

Subject: What is a CSD InfoMangager?

Hi All,

Paul asked me to start a discussion on the role of the InfoManager in the

OpenHIE architecture. There are several aspects to this discussion and

perhaps it is good to have a review of the CSD functionality.

Let’s start with the CSD perspective of what the Info Manager is supposed to

do which is:

Periodically refreshes cached content from one or more Services Directory

actors. A Service Directory actor is a source of data on one or more of the

four CSD entities: health workers, health facilities, organizations and

services.

Executes the inbound queries from Service Finder against its cached content

and returns a response document in reply.

This is done against a common data model, expressed in XML, and which we can

call a “CSD document” for simplicity. The inbound queries are the “stored

queries” as well as the ad-hoc queries. In the CSD standard, there are

required four stored queries each centered around the four main entities. In

addition to the four required stored queries, CSD allows for an InfoManager

to be optionally enhanced with new stored queries.

Restating this from the perspective of OpenHIE documented workflow with the

“Facility Registry” and a “Health Worker Registry”, we have:

the InfoManager requests from the FR shares updates to its CSD document

the InfoManager requests from the HWR shares its CSD documents

the InfoManager merges (interlinks) these two CSD documents together into a

unified CSD document and answer inbound queries from the Interoperability

Layer. This is the Interlinked Registry.

In short, the InfoManager actor is supposed to bring together multiple CSD

data sources into a unified "CSD document” and allow querying against those.

The requirements of an InfoManager actor are a bit broader than those of the

corresponding OpenHIE workflow as CSD makes no distinction between a FR and

a HWR. The OpenHIE reference implementation of the InfoManager actor,

OpenInfoMan, supports these broader CSD requirements.

These broader requirements allow for, in particular, a federated view of

data. Let’s take the particular example of the HWR in Nigeria. From the

simplest perspective, each state has an HRIS system that serves as a source

of health worker data. The HWR of Nigeria is essentially nothing more that

an InfoManager actor which merges these state CSD documents together to

allow for querying against a national registry of health workers. This

federated support is built into the core OpenInfoMan software as one of it’s

added stored queries. In fact, the OpenInfoMan supports federation of all

four of the main entities (health workers, facilities, organization, and

services) as there is only one line of code needed to support each one and

it would have been silly not to support this.

One way to try to understand the Nigeria HWR example, and the OpenHIE FR+HWR

example, is that they are both two cases of federation. The first is

federation of health worker data by state, the second is a federation by

entity. Both of these cases are handled simultaneously by the OpenInfoMan

reference application.

These examples of federation only require two tiers in it’s federation.

However, there are examples such as DATIM or WAHO where a federation at

three or more tiers would be useful — e.g. sub-national, national,

regional/global. Luckily, the OpenInfoMan application can already handle

multi-tiered federation. This is because OpenInfoMan is not only a

InfoManager actor but a Service Directory as well. Thus a regional (or

global) InfoManager actor can ask each of the national registries (which act

as both the InfoManager and Service Directory) actors for their updates to

the national CSD documents.

We have only so far touched upon the facility and health worker entities in

CSD. There are two other ones: organization and service. The concept of an

organization in CSD has a couple of useful features:

A facility can be associated to an organization

A health worker can be associated to an organization

An organization can be associated to another organization in a parent-child

relationship

As a CSD organization is not limited to a “legal entities which are service

delivery organizations” we can (and do) encode useful things in the CSD

organization:

the geographic hierarchy under which a facility operates

an collection of facilities that are operated by an FBO or MOH

the facilities supported by/reportable on for a funding mechanism

(represented as an organization)

We can save talking about services until another time, but they are pretty

useful too

There is one other notable thing that the OpenInfoMan reference application

does, and that is to support some basic terminology services. There are two

main ways:

There are terminologies referenced in the CSD data model (such as health

worker cadre, facility type, type of contact points (e.g. email, phone,

fax), etc.). To facilitate the sharing of these terminologies, OpenInfoMan

acts as a Value Set Repository according to IHE’s Sharing Value Sets (SVS)

profile. This is essentially a way to ask for an xml list defining a

simple value set.

There are some things in the CSD data model which would be useful to

represent as a terminology - for example the organizational hierarchy of

facilities. There is some nascent support to represent this as a FHIR

Value Set, although this was more exploratory work and will need to be

updated to see where the TS community lands on representing hierarchies.

I should also say what the InfoMan and the CSD InfoManager actor are not.

It is not supposed to be a business domain application. Rather, it is the

Service Directories that should be considered in general as the business

domain systems — in the process of doing supporting their business

processes, they generate useful data that needs to be merged into an

“InterLinked Registry.” Such business domain systems could be:

A logistics or supply chain system which gathers and maintains information

about warehouses and medical stores

A professional council license and registration systems which collects

information about health worker qualifications

A HR Management system captures information about health worker deployment

An HMIS, as part of reporting on service delivery, collects information

about clinical facilities in a country

Cheers,

-carl

–

You received this message because you are subscribed to the Google Groups

“OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to
ohie-architect...@googlegroups.com.

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

–

You received this message because you are subscribed to the Google Groups

“OpenHIE Architecture” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to
ohie-architect...@googlegroups.com.

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.

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

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