Simplifying CSD by avoiding internal functional descriptions

[edjez]

Currently CSD has both a specification for an exchange of information to meet certain use cases, but also tries to do a design of the services and the functions that would meet the exchange.

• It may simplify the spec and open the door for more varied compatible implementations if the spec assumed the implementation of the exchange was a black box. i.e. if CSD just said 'a CSD compliant actor can receive these queries and provide these return documents.
• By having less implications about actors, the spec has less probability of embedding assumptions derived from a particular internal design. These assumptions currently appear as particular ways of partitioning the data amongst underlying services, or as specific exchange protocols behind the CSD compliance actor.

  Recommendation

Just focus on what a CSD compliant actor must do to implement the profile, and don't place assumptions about the sequence of exchanges, actors and other elements behind the CSD manager.

It would take diagrams like these: and make them look like this, simplifying the spec:

(sorry for image quality, I'm just editing diagrams from the CSD document for illustration)

[djritz]

The introduction of the CSD Manager was recommended by the IHE's assigned mentor on this work item. It was a helpful suggestion that usefully simplified the original CSD design, which explicitly described interlinking between multiple registries (e.g. facility, provider, organization, service, freebusy).

It is up to an implementer where/how they implement specific actors; multiple actors may be embodied in a single application, for example. The introduction of the Manager supports separation and abstraction that otherwise would not be interoperable or conformance testable. Supporting a standards-based way to interlink registries is a core goal of the specification.

[edjez]

I think the reason why adding the actors may have been useful was because having them allowed some mental prototyping of the workflows; but not because it helps the profile itself be any simpler (as it demonstrably adds more entities, interactions, etc to it).

And if, as you say, any implementation may deviate from the implications of the existence those actors then not much would be lost by removing them from the exchange. Do they represent a normative, or an inspirational or 'implementation guide' artifact? If the latter, CSD can be leaner AND help more configurations respect the standards/profiles. In any profile like this that is used in conjunction with others less surface area with less degrees of freedom -not more with more flexibility- leads to longevity and interoperability.

(I realize after today's IHE call the ship may have sailed on this, but would be worth noting in the profile that as you state here the actors are inspirational not normative)