IHE: CSD response documents are aggregate, placing functional constraints on implementers

[edjez]

Summary

Currently CSD describes return documents that are aggregates that include by value all the information. This places a functional requirement on the exchange specification that an underlying SOA architecture will either already have, or add, an Aggregator or Enricher actor, and could even add forces to depart from SOA approaches to a shared database.

By changing the document returned to accept hrefs to subentities, it removes the need for an active enricher, allows for arbitrary partitioning and federation of registries, and supports some of the integration benefits of REST.

Issue Description

The exchanges described in the profile have response documents that embed information across entities that may typically be maintained by independent services (eg provider registries, facility registries, etc).

• This adds complexity to the spec as it generates the need for an enricher/aggregate actor which is the only one that can support the CSD profile. This aggregator could be implemented inside an ESB or a separate physical service that then consumers provider and facility registries; or embedded in either/both registries.

  Recommendation

Instead of 'embedding' response data in documents across all entitiy types, allow responses to include hrefs to entities whenever they are contained/reference within a larger entity. This simplifies interlinking data across a SOA environment. For example, instead of this example (pseudocode) return document:

Facility Data
   Service A
      Provider One
      Provider Two
   Service B
      Provider One
      Provider Three

the CSD could specify a return of:

Facility Data
   Service A
      {href link to Provider One}
      {href link to Provider Two}
   Service B
      {href link to Provider One}
      {href link to Provider Three}

With this partitioning, there is no implication of where data is physically sourced in the spec. If it is all on the same server, aggregator, or registry, or kept across many is left as an implementation choice not forced by the data exchange specification.

• There is also precedent for this approach in CSD in linking to external URIs for calendaring data, using these links would continue that direction
• The use of reference IDs as a 'foreign key' is less robust than URIs as it assumes an authority (physical and logical) to dereference them. By using full URI references to main entities (eg providers, facilities) as references, it allows the co-existence and evolution of IDs in those entities independently, and allows for different approaches for IDs (eg composite keys etc). This further helps the independence of the services in a SOA environment.
• The use of URIs also allows a federated environment to conform to CSD where the e.g. a facility could host providers that are managed by two different registries (a private large NGO and a MOH registry, for example, each with their own provider list).

  More Information

Doing aggregate exchange formats is sometimes a result of premature optimization where the design assumes the receiver will want data, so why not go get it for him/her? This may be a valid concern but it is best adressed in specific implementations according to their topologies and requirements.

[djritz]

The pattern described is one which was discussed within the IHE technical committee but the preference was to move forward using the actors and transactions as presently described in the CSD specification. I believe this choice was made out of preference, not ignorance. The expected use of a service reference to obtain optional freeBusy information is a nod to the idea that this information might NOT be centralized in a shared infrastructure but rather might be maintained by and exposed by local physician scheduling systems.

Very specifically to openHIE, the premise of a central bus (the HIM) is preferred over supporting clients' direct access to registry information. My understanding is that this pattern (all communication through the HIM) is being used by other openHIE registries.