Methods to create links and references to the provider registry

[steesdale]

Methods to create links and references to the provider registry (and other registries)

Why it matters: It is important to arrive to an interoperable suite of services where complex interrelationships of data are solved by other methods than glomming and replicating all data into all databases. Provider and facility data have many interlinks.

Interested parties: Provider registry, DHIS

[ctford]

One thing to consider is whether a provider registry and a facilities registry would each reference the other.

You could have e.g. the provider registry just have pointers to the facilities registry, but then it would be difficult to query all the providers present at a particular facility.

If we do have bi-directional references, which would be the canonical one? ie how would we interpret it if a facility said it had a provider working there but the provider registry didn't?

[litlfred]

FYI: The use case that you mentioned, as far as I understand, would be handled by the Care Services Discovery (CSD) profile that is under development
ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr11-2013-2014/Technical_Cmte/WorkItems/CareServicesDiscovery/
through the use of XQuery

The provider registry community will likely be getting behind the CSD profile.

[edjez]

@ctford We had a brief discussion about that case in today's call. I think overall, in any SOA environment you want only one 'service' to own a given piece of data (i.e. the duplication of edits leading to the inconsistency you mention is a 'smell'). It seemed to the participants (and myself) and the 'which providers work at a given facility / facility service' would be kept within the provider registry.

This way a single relation can be expressed as in the following example for ContactPerson but a link to a "many" relationship can be also expressed in the second link

        "externalLinks": [
            {
                "type": "ContactPerson",
                "href": "http://providers.moh.gov.rw/employees/123",
                "id": "123"
            },
        {
                "type": "EmployeesOfFacility",
                "href": "http://providers.moh.gov.rw/employees?facility=777",
                "id": ""
            },
        ],

Segregating the ID and the base URL allows for centralized management of the base URL for the entities, and easier data input by users. E.g. a data entry person adds 123 as the provider ID, and the Facility Registry is pre-configured that this field refers to http://providers.moh.gov.rw/employees/{{ID}}.
This also adresses a question about server/dns migration that may happen if services get swapped around as it centralizes that change management.

Carl L (@litlfred) from Intrahealth commented on the call that the provider registry currently does not expose provider objects on URLs a la REST, that all their APIs are SOAP based. Adding simple REST interfaces may be worthwhile for you guys to explore, IMO.

Note: It was commented on the call that this does not match the CSD specification. CSD represents an exchange that ultimately gets implemented by an aggregator, which would consume this information, and maybe do all the de-referencing and lookups internally. That topic is better suited for the CSD board (https://github.com/facilityregistry/ihe/issues)

Dear members - Is the JSON chunk above palatable as a way to represent links?

[litlfred]

Just a point of clarification... I said that the APIs for HPD and CSD are SOAPy (though not SOAP) as opposed to the RESTful web API that FRED is using. Specifically, HPD is based on DSML and CSD is based on XQuery.

As far as adding a RESTful interface, I am not sure if you are meaning to the CSD or the provider registry as implemented under RHEA. In the case of the former, I wouldn't think we would want to impose upon an CSD implementation the need to build two different APIs (the XQuery one and the RESTful one). If this is about facilitating the interchange within the OpenHIE context, and assuming that such a RESTful API has be defined, it may be better to have the HIM handle the translation of the REST queries into those defined by CSD.

Finally, we did start down the path of developing a RESTful API for the Provider Registry:
http://www.ihris.org/wiki/Provider_Registry_Web_Services
The version 1 part is what was implemented for RHEA, and version 2 was the result of some initial conversations about expanding that functionality for Rwanda. Hovever, the PR community decided to abandon this process after determining that the HPD or CSD profiles could meet our use cases.