Create a new DelegatedTerminologyService

[ewoutkramer]

Create a new DelegatedTerminologyService that interprets the valueset and turns them into calls to codesystem-validate-code and valueset-validate-code as follows:

• If handling a codesystem-validate-code, check the IResourceResolver for the codesystem. If it exists & is complete -> respond to the invocation, else throw.
• Note that we need to add an additional parameter filter to this operation that does not formally exist, but that is required for the following steps. Obviously, for external terminology services, this would always fail. Copy the filter logic from the current valueset expander to this codesystem operation, this is where it belongs.
• We need to implement both the logic for $expand and valueset-validate-code. The logic is very similar, and the expansion logic is mostly there, although instead of throwing when we don't know a valueset (as we do currently), we should delegate the expansion call to an external service.
• For validate call, we will no longer depend on the expansion:
• For include/exclude: determine whether the code is valid for any of the includes (possible optimizations in which one to try first?). If it is, check whether it is not valid for an exclude. If this is both the case, the code is validated.
• For each include/exclude: double check with current expansion algorithm, but basically, IF there is no system, try to validate the code for each of the specified valuesets (delegated). If there is a system, try to quickly validate the code against the included concepts - if they don't provide enough information (e.g. the right designation) we need to invoke a codesystem operation. Not sure if we need to apply the filter to these locally supplied concepts - feels weird that you take the effort of inclujding concepts, to exclude them immediately using a filter.
• If we need to invoke a codesystem operation (no or incomplete concept list), call codesystem-validate-code operation, passing in the custom extra filter parameter. If that fails (e.g. external server), we cannot validate the code. Otherwise, return the result based on this call.

Notes:

• We can optimize the calls: a) local resolution, and we fail to expand the valueset and b) external terminology and the concept was incomplete or failure. We shouldn't re-try again on this terminology server, but mark it as 'ineligible' for this resolution to skip extra work that won't succeed
• There might be a smarter order in which to process concept/system/filter/valueset combinations, maybe even depending on whether this is a slow or local call, but we don't have that information yet. Assume that if access to the service occurs often, the cached layer will go through an expand if possible. Still, we might in the end want a "learning" part here that changes the "execution plan" depending on which calls are slow.