Shared Location Reference Data

[euanmillar]

This is a discussion on an approach to homogenisation of address reference data through the system. Should we use a real country or a fake country?

If you want to use a fake country we have created the country "Farajaland"

https://documentation.opencrvs.org/default-configuration/intro-to-farajaland

During configuration of our system, we import these district and state csvs which are converted into FHIR Locations and shared via a public API for other systems to consume. Address lines can be entirely custom and stored as strings in an array in the FHIR Location JSON.

Note that the partOf value in the CSV is used to structure the country hierarchy using a country's own statistical ID for the division when creating the CSVs. After importing into our system, the statisticalID becomes one of the FHIR Location's "identifiers", but new uuids are generated for the FHIR API. The statistical data such as population and crude birth rate/death rate data joins the FHIR Location as extensions. Check the FHIR Location JSON docs to see where this goes.

We can generate new CSVs with all the JSON data and production uuids once we have deployed our setup. Our API exposes all the data for the entire country as JSON so you can also use that if you want to get the data on the fly.

We aren't using standardised city names or postcodes in Farajaland, but they are available in FHIR if we wanted to do this in implementation countries. We wanted to standardise at only 2 admin levels for now and leave the rest of our inputs flexible. We wanted to show how OpenCRVS can be used in a country where address standardisation is not available in rural areas and where population statistics were not granular.

In our fake country, we reserved these indexes in registered individual's Address line array if you are interested. All can be custom label-ed in implementations.

Farajaland options

AddressLine1: E.G. Number of property in a street. Or any other use.
Array index: 1

AddressLine2: Used for street name. Or any other use.
Array index: 2

AddressLine3: Used for residential area name.
Array index: 3

Used for a rural purpose: E.G. village name. Or any other use.
Array index: 5 (4 is available for another residential area: e.g. town, municipality, cantonment, ward if needed)

International options

The following indexes function in a similar way as above. When the environment country is not the same as the default country.

International AddressLine1:
Array index: 7

international AddressLine2:
Array index: 8

internationalAddressLine3:
Array index: 9

[pramodkvarma]

Excellent! We could use example country, data, etc from this. But, not sure why we need to have common address formats across DPGs within G2P-Connect given this is about payment transfer and hence physical address structuring across G2P is not necessary (at least for now).

@vvujjini

[jeremi]

In our case, we support:

• Traditional address
• Administrative level (usually 1-4): Import excel files from humdata such as https://data.humdata.org/dataset/cod-ab-ukr

The second type is the one we use the most. In many countries, there is no formal address or people might not know it. It is even harder to get the GPS position. So I'm not sure the FHIR format is the best.
Administrative levels are easy to work with. Usually, people know the name of their area. Then we can easily use it to explore the data using the hierarchy of areas, and in the case of demo 1, limit to the impacted areas.

Geonames also support administrative areas and provide data: http://www.geonames.org/export/subdiv-level.html

[euanmillar]

You can now access all the OpenCRVS location data in FHIR standard Location Bundle on this URL:

https://countryconfig.farajaland-g2pconnect.opencrvs.org/fhir-locations

If you pass the parameter of a single FHIR ID you can get a single location like this:

https://countryconfig.farajaland-g2pconnect.opencrvs.org/fhir-locations/7dbf10a9-23d9-4038-8b1c-9f6547ab4877

Refer to the csv file description at the beginning of this thread to understand more.