Facility Identifier Resolution

[ghost]

Hello all,

Just wanted to confirm that the following message if sent to a FRED registry:

GET /facilities.json?identifiers.id=1234&identifiers.agency=MOH

Would match all facilities with identifier 1234 assigned by agency MOH. Would this be the most appropriate way to perform identifier resolution?

I know that facility cross referencing is out of scope for FRED 1.0 registries, but I assume this functionality could be easily implemented by wrapping a FRED service with something that can detect the 409 (conflict) error on a create and can perform the appropriate update/delete for a resolution/merge.

Thanks

[ghost]

Additionally would it be safe to assume that the "agency" field in the identifiers section could be set to an OID rather than a display name? For example:

{
    "facilities": [
        {
            "name": "X",
            "href": "Y",
            "uuid": "550e8400-e29b-41d4-a716-446655440000",
            "active": true,
            "createdAt": "2011-11-16T14:26:15Z",
            "updatedAt": "2011-11-16T14:26:15Z",
            "coordinates": [
                -1.6917,
                29.525
            ],
            "identifiers": [
                {
                    "agency": "1.3.6.1.4.1.33349.3.1.2.1.2",
                    "context": "DHIS",
                    "id": "203945"
                } 
            ]
          }
     ]
}

[bobjolliffe]

Hi Justin

On 21 March 2013 14:09, justin-fyfe1 notifications@github.com wrote:

Additionally would it be safe to assume that the "agency" field in the identifiers section could be set to an OID rather than a string name? For example:

I don't think that would be safe to assume that it would. Though certainly it could. Perhaps In an ideal world there would be an agency registry from which such OIDs might come. But in reality this will rarely if ever be the case. So the implementors have some freedom and flexibility to identify agencies in whichever way is useful to them.

Of course - as with all discussions of identifiers - global vs local concerns crop up. So whereas it might make sense in a particular national context to have an agency such as "MOH", it is probably a better convention to say "MOH_TZ" or such like.

Bob

{ "facilities": [ { "name": "X", "href": "Y", "uuid": "550e8400-e29b-41d4-a716-446655440000", "active": true, "createdAt": "2011-11-16T14:26:15Z", "updatedAt": "2011-11-16T14:26:15Z", "coordinates": [ -1.6917, 29.525 ], "identifiers": [ { "agency": "1.3.6.1.4.1.33349.3.1.2.1.2", "context": "DHIS", "id": "203945" } ] } ] }

— Reply to this email directly or view it on GitHubhttps://github.com/facilityregistry/fred-api/issues/52#issuecomment-15240426 .

[bobjolliffe]

On 20 March 2013 17:57, justin-fyfe1 notifications@github.com wrote:

Hello all,

Just wanted to confirm that the following message if sent to a FRED registry:

GET /facilities.json?identifiers.id=1234&identifiers.agency=MOH

Would match all facilities with identifier 1234 assigned by agency MOH. Would this be the most appropriate way to perform identifier resolution?

I think you should also use the context. For example, the MOH in Rwanda might be the responsible agency for DHIS2 uids as well as the national FOSA codes.

So you might need something like GET /facilities.json?identifiers.id =1234&identifiers.agency=MOH&identifiers.context=FOSAID

I know that facility cross referencing is out of scope for FRED 1.0 registries, but I assume this functionality could be easily implemented by wrapping a FRED service with something that can detect the 409 (conflict) error on a create and can perform the appropriate update/delete for a resolution/merge.

Thanks

— Reply to this email directly or view it on GitHubhttps://github.com/facilityregistry/fred-api/issues/52 .

[ghost]

Hi Bob,

Thanks for the feedback. I am trying to come up with some guidance and an idea of how FRED could be used within an enterprise integration project where the FRED API isn't contacted by end user systems, rather by other services which identify facilities by OID & ID (like CDA, XDS, etc.).

I know that PIX managers are required to map named identifiers to OIDs (in PIX this looks like 1234^^^MOH to 1234^^^MOH&1.2.3.4.5.6.7&ISO) however the onus is on the service provider rather than the consumer. I guess mapping agency + context to an OID (or vice-versa) could be an option with low probability of collision (and would have to be done in the consumer)

Is there anything preventing a jurisdiction from configuring software implementing FRED to support OIDs in the agency field? Would a specialized FRED implementation which uses OIDs in the agency field still be compliant? Reading the spec it looks like there isn't anything explicitly against using OIDs if the implementer wants to use them in the agency field.

Thanks -Justin

[bobjolliffe]

On 21 March 2013 15:27, justin-fyfe1 notifications@github.com wrote:

Hi Bob,

Thanks for the feedback. I am trying to come up with some guidance and an idea of how FRED could be used within an enterprise integration project where the FRED API isn't contacted by end user systems, rather by other services which identify facilities by OID & ID (like CDA, XDS, etc.).

I know that PIX managers are required to map named identifiers to OIDs (in PIX this looks like 1234^^^MOH to 1234^^^MOH&1.2.3.4.5.6.7&ISO) however the onus is on the service provider rather than the consumer. I guess mapping agency + context to an OID (or vice-versa) could be an option with low probability of collision (and would have to be done in the consumer)

Is there anything preventing a jurisdiction from configuring software implementing FRED to support OIDs in the agency field? Would a specialized FRED implementation which uses OIDs in the agency field still be compliant? Reading the spec it looks like there isn't anything explicitly against using OIDs if the implementer wants to use them in the agency field.

No there is nothing in the spec which I am aware of which would prevent you doing this. AFAIK the spec simply assumes a string identifier.

Thanks -Justin

— Reply to this email directly or view it on GitHubhttps://github.com/facilityregistry/fred-api/issues/52#issuecomment-15245190 .

[mberg]

Go with this. Agency or identifier not passed then do a global in the identifiers block.

[edjez]

I would say more simply, the results are filtered using the supplied arguments

Otherwise as expressed below it may be read erroneously as "if either the agency or context argument is omitted, the other one is omitted too" which would be undesirable and confusing IMO.

On Mar 21, 2013, at 9:10 AM, Matt Berg notifications@github.com wrote:

Go with this. Agency or identifier not passed then do a global in the identifiers block.

— Reply to this email directly or view it on GitHub.

[mortenoh]

This is probably another place that would need ':' or '.' alignment.

[edjez]

Checked it is using ":" - the behavior Matt describes is the one the doc express right now, unless I'm misinterpreting it.