Open edjez opened 11 years ago
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.
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).
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:
the CSD could specify a return of:
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.
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.