FR Community Notes - Feb 19th

Participants: Clara, Derek, Ed, Scott, Frank, Jennifer, Larry, Niamh, Shaun

Sharing Code Sets w/ A Terminology Service

First Steps

1. Define how we will identify a terminology/codeset in a facility registry to be shared with a Terminology Service.

1. Lets use the example of an administrative hierarchy from TZ

1. (See here - updated link)

2. First - identify the resource

1. URI + Version String (no semantics)

2. Can query if that is the latest

Notes:

• Need for a pub/sub activity to send/receive updates

• If you want a version you pass it, if you want the most recent just get the current.

• In sweden there is a standard for ISO approach, that looks at how changes are created within the hierarchical

• there are not links to the ISO standards, the intention would be we could use any coding standards, but need to identify the code sets.

• SVS would be best for flat code sets

• Once you have the code set identified you can validate it

• So once it is identified, what do you want to do with it?

• How much information do you want?

• What kind of method do you want to execute?

• Let’s use a simple example

• Ownership: Each type has a code, also have human readable labels

• When assuming it is a bounded set, it would be handled similarly to other HL& codesystems.  A value set called “Facility Type” … would have codes and associated attributes (display names, etc.).  One thing that is typical in FHIR, is to get the expansion of the value set, ID It, query for expansion, you get back set of objects where each is an entry or code w/ attributes.  The current FHIR spec, but for bounded sets of flat files … a FHIR expansion query does well.

• Niamh Q: Types change over time… is there a way with this that date info is stored to see changes?   

• General that is done by a new version that is active on a new date.  The updating of dependent databases … that is outside the TS and falls back on the consuming tools to help manage.

• The FR would then help to manage the change mgmt after they are shared by the

• Given that a FHIR expansion query could be a robust way to share simple code sets

• FHIR And SVS are totally separate

• For bounded sets FHIR defines an XML payload that have the elements and attributes of the request that you need.

• As they get fancier they can be paged with follow up links

• After the call could we come up with an example from TZ to give it a shot?

• Would be interesting… would take a week or two.

• Scott and Niamh will follow up with Niamh

• FHIR has promise but may have some fluidity … Derek

• This process is not for hierarchies

• life is more complicated

• Scott and Niamh to work with Jack to dictate some user stories

• Consider IM from CSD as an option

Niamh via TZ

• FR Calls the software tools

• MFL is the data at a point of time

Other Questions For the Future:

• Any ideas on how we identify a code system?

• Any ideas on how we identify

• So once it is identified, what do you want to do with it?

• How much information do you want?

• What kind of method do you want to execute?

Updates:

• Ongoing discussion with other communities for similar needs

• Homework is ongoing to assess standards/profiles/APIs we may use

• Data Sets are collected with these specifications (TZ, RW, BD, Philippines)

Image Removed

Example of bounded set

• A value set like “Facility Type”

• CLI (Clinic, Clinique)

• LAB (Laboratory, laboratoire)

• Issue A fihr expansion query to get the data above

What happens once the change is detected? Out of scope for this exchange.

Can we start coding a terminology in the service to see how it looks like? Niamh, Jack and Scott follow up.

Facility Registry Compared to A Master Facility List

Past Documentation

Implementation Guide Definition

The purpose of a health facility registry is to act as the central authority to collect, store and distribute an up to date and standardized set of facility data.  The resulting standardized and current facility dataset stored in the registry is called a master facility list (MFL).  While these concepts are closely related, a facility registry can be understood as the technology that manages and shares facility data and an MFL is the standardized data stored in the tool.  

Quick Comparison Table:

Congrats you have an MFL, so now what?

• Link

User Stories for a Facility Registry

• https://docs.google.com/a/instedd.org/spreadsheets/d/0AvRUEKy5Lc7BdEViVzQ1bnViWE1oUUZ0UXZsWHJqcnc/edit?usp=drive_web

To Do”: Draft and collect diagrams of the intersection between MFL and FR

Tanzania Hierarchy Management Requirement Summary

• Pasted in from Niamh and RTI’s work on the FR

Country ‘Hierarchy’ Registry

1.    Background

In most countries, the county is administered via administrative units or divisions (and many other terms are used for this).   In some instances, these are similar to the geographic administration, but there are several instances where the hierarchy across political, administrative and geographic country organization are different.

For example, a country may be divided geographically into provinces, counties, and districts.  It may for administrative purposes be divided into provinces, counties, districts and LGAs under districts.  For political purposes it may be divided into provinces, counties, and political divisions.

The administrative hierarchy can be described as first administrative level, second administrative level to the lowest level of administration.

2.    Country Administration Change Management

In most countries, while the geographic territory may expand, reduce or stay the same over time, with population expansion there is often a need to sub-divide administrative hierarchy levels, or political hierarchy levels.  This on-going sub-division or merging at different levels is managed through different state agencies, and then is rolled out within the administrative management structure along with revisions for political purposes.

In each sector (e.g. Health, Education, Water), with the expansion in the use of Information Communication Technology (ICT) and development of eSector strategies, there is a need to share this hierarchy information in a consistent manner with other Information Systems that use this hierarchy for managing resources.  For example, in the Health Sector, if an administrative level splits into 2 different administration divisions at the same levels, health facilities that belong to this level will now need to be linked to the new level, maintaining the history of their affiliation with the older level from the specific point in time the change was made.  

It is critical for a country’s policy makers to understand how resources are used at different levels of the hierarchy, over time, so they can plan better for changes in population and sector changes.

There is a need for a centralized authority to be the sole source of the current and historical hierarchy (whether geographic, administrative or political) – in essence the authority that can manage the Hierarchy Registry.

3.    Standards and Hierarchy Management

This issue of hierarchy management, and a country (or countries) having a common way of tracking these changes over time, has led to the development of at least one standard in this area.  One such standard is International Organization for Standardization (ISO) 1366, Codes for the representation of names of countries and their subdivisions, Parts 1, 2 and 3.  This standard includes country codes and country subdivision codes, along with information on their period of use.

Using Sweden as an example, http://www.geonames.org/SE/administrative-division-sweden.html, you can see that the changes that have happened are all date stamped, and the change marked as ‘delete’, ‘add’ or ‘change’.

Another example is Canada, http://www.statcan.gc.ca/pub/82-402-x/2013002/app-ann/app2-ann2-eng.htm, where the changes are listed, but not with reference to ISO codes.

In South African Health Sector, a separate instance of DHIS2 is used to manage their health administration hierarchy, so that their main HMIS DHIS2 instance gets updates from the hierarchy instance of DHIS2.

4.       Tanzania Hierarchy

4.1   Health Sector Hierarchy

In the Health Facility Registry (Master Facility List) the health sector hierarchy is broken out into

·         Zones

·         Regions

·         Districts

·         Councils (or LGAs) (Municipal Council – MC, Town Council – TC, District Council – DC and City Council – CC)

·         Wards

·         Village or Mtaa

And facilities are located down to the level of Village/Mtaa.

In DHIS2, the health sector hierarchy is broken out into Regions and Councils/LGAs.

In other Health Information Systems, the health sector hierarchy is maintained with some mapping to this overall structure of Regions and Councils/LGAs, and sub LGA levels.

During 2012/2013, Tanzania introduce 6 new regions, and also introduced new councils.  To date, these changes have been made manually, and while details of the historical mapping are maintained in the database engine (in DHIS2, HFR), there is no reporting mechanism currently to pull this information out in an easy to use manner, nor is this information managed according to any international standard.

4.2   Census Hierarchy

In discussions with NBS, who contributed to the hierarchy that is used in the HFR, they also include a level called Division.  So this goes from Regions – LGAs/Councils – Divisions – Ward.  It was decided not to use Divisions in the HFR as these are used for managing surveys and not normally something the population interacts with.  Also, NBS use Enumeration Areas as part of its census data collection and these are not used in the health administrative hierarchy.

4.3   PMORALG Hierarchy

As mentioned with the HFR, PMORALG were also part of the discussions about the finalized hierarchy selected for the HFR.  However, they also mentioned the administrative unit of a Township Authority that may be setup (by PMORALG) and eventually converted into a Town Council.  The Local Government administration hierarchy can be very similar to the sector hierarchies but there may also be differences at different levels.

4.4   Political Hierarchy

Needs more details to be filled out.

5 Hierarchy Management High Level Requirements (User Stories) for Tanzania

1.       The ability to manage multiple hierarchies for a country, with designation of which kind of hierarchy (e.g. health administration, political administration, education administration, NBS administration etc)

2.       Agreement on standard mechanism for how changes (add, delete, update) are managed so that all changes can be fully recorded, so that data sets that depend on a hierarchy can reflect these changes for reporting purposes

3.       At each level of the hierarchy, a level splits into multiple units, or multiple units merge into one level (e.g. Region splits into two regions, LGA splits into two LGAs – or merge)

4.       Across levels of the hierarchy, a level splits into multiple units, or multiple units merge into one level (e.g. 2 Regions splitting into 3 regions, with some LGAs from both moving to the new region)

5.       Other Information Systems can subscribe to the Registry to be notified of changes

6.       The registry has a standards based interface for any other information system to read the hierarchies (and specify which hierarchy)

7.       All hierarchy levels have unique IDs across the different hierarchies

8.       The registry maintains the mapping from one hierarchy to another

9.       Some mechanism to link the hierarchy level to the associated shape file (s) – need to define who is the central authority for shape files in the country

10.   Ensure that the registry is part of the Tanzania Enterprise Architecture and is approved by the NeHSC to work in the most flexible standards based way to support the other Health Information Systems (HIS) that need to subscribe to changes