ADR: How to define which source is authoritative for which resource and properties?

[stevenvegt]

See 2.7.1

An update client needs to consolidate data from multiple authoritative sources. A source is only authoritative for a subset of resources of certain types and specific properties. How to define this in an expressive way so that we support a wide range of sources.

[bramwesselo]

FHIRPath for configuration of specific elements per source (Administration Directory).

For example, LRZa is the authoritative source for URA-identifiers. Vektis is the source for Organization type. Could be stored in JSON/YAML:

# mCSD (Mobile Care Services Discovery) configuration
mcsd:
  # Root Admin Directories to synchronize from
  admin:
    "LRZa":
      fhirbaseurl: "https://www.cibg.nl/lrza/fhirr4/"
      # operation determines what to do with the instances found in source and can be 'publish_all' (publish instances of root admin and child admin directories , 'publish_childs' (just publish child admin directories) or 'verify_authoritative_data' (don't publish anything, but compare specific elements in exiting instances)
      operation: "publish_childs"
      # specify which elements to use to link entities in this admin directory to instances in child admin directories
      key_elements_in_child:
        - Organization.identifier.where(system='http://fhir.nl/fhir/NamingSystem/ura')
      # specify authoritative elements for this admin directory
      authoritative_elements:
        - Organization.identifier.where(system='http://fhir.nl/fhir/NamingSystem/ura')
      

    "Vektis":
       fhirbaseurl: "https://www.vektis.nl/agb-register/fhirr4/"
       operation: "verify_authoritative_data"
       # specify which elements to use to link entities in this admin directory to existing instances
       key_elements_in_existing:
        - Organization.identifier.where(system='http://fhir.nl/fhir/NamingSystem/ura')
       authoritative_elements:
        - Organization.type

I'm not fully happy with this config; feels a bit constraint or 'custom'. On the other hand, every possible option should also 'work' in the update-client, so we might want to limit the options...

[stevenvegt]

this is a difficult problem. I'm really on the fence between consolidation and complex queries.

Consolidation keeps the complexity away from the client which otherwise has to perform multiple queries on the query directory becouse there are multiple resources for the same logical id. And query by reference is not possible.

However, the complexity of the update client becomes very high. I already tried 2 times to solve it and each time I run quickly in edge cases. I'm not sure if there really is an "elegant" consolidation solution. Also, chances are big that other implementations won't follow it completely which will result in incomplete implementations. You have to provide an elaborate test suite to make sure every implementation is compliant.

The other option is laying the burden at the Query Client. And in our case we can abstract this complexity away in our nuts-knooppunt. You'll need to perform a few queries, however, it will al be standard fhir and the update client will be much simpler.

Regarding to your proposal, see my code in this PR which tries to do something similar: https://github.com/nuts-foundation/nuts-knooppunt/pull/2/files#diff-94939b89318bf5a5b24cbf34fcc64d3b55cc149aadd66cf9fca3c898d85da1e6

[bramwesselo]

I read your code before making this comment