The curious case of use case profiles #361
Description
Generic vs. specific profiles
In information standards, the zibs are usually refined by restricting cardinalities, terminology etc. However, in the zib2017/STU3 implementation, the zib profiles are used as-is, without further refinement. A common complaint is that these profiles are too permissive to make clear what is needed for the use case at hand. This is a design choice; the functional requirements are specified in the functional design, not in FHIR. Regardless, many implementers use the FHIR IG as their starting point and it would help them to be more specific on a FHIR level as well. It could also be helpful for testing/qualification to have more restricted profiles.
On the other hand, there's a strong desire to have solutions that can be re-used across use cases, which seems to contradict the need for restricted profiles.
To solve this contradiction, it is helpful to think what purpose profiles could actually serve and what this means for their requirements:
- Documentation purposes: these profiles should in general be as restricted as possible.
- Validation purposes: these profiles should be as restricted as necessary for the use case, and not more restricted.
- Exchange/implementation: if there are restrictions, they should encompass all possible use cases so that the implementation can be used across all these use cases.
The nl-core profiles defined for the zib2020 publication are designed to fulfill the role for bullet 3; they form a union of all known use cases, and in addition they are "open world", meaning they could potentially serve all use cases. However, this approach does not serve bullet 1 and 2.
The way FHIR profiles work, might provide a way out though. It is possible to derive from profiles, but these can only be a restriction on the underlying profile, which means that an instance of a derived profile is a bona fide instance of the base profile in all its aspects. This aligns neatly with the way data sets are modeled: data set and transactions restrict the underlying model, but they still are an instance of the underlying model.
So, a solution might be to provide use case profiles for documentation and validation purposes, but to fall back to the nl-core layer for exchange purposes. A vendor that implements a specific use case, only needs to look at the use case profiles. When a vendor implements a second use case, the existing implementation can be re-used with only the differences of the new use case. Note that a required concept in use case 1 might be forbidden in use case 2. This unfortunate situation is unavoidable however if the use case calls for it -- it is not a characteristic of the FHIR implementation.
This approach can be used to create validation profiles, that apply the same restrictions as the functional model, which can be further refined to documentation profiles, that forbid everything except the concepts in the functional model. However, a more suitable way is probably to define one profile and add the mustSupport flag to all elements that an implementer needs to take into consideration. The meaning of this flag must be documented in the overarching IG.
Profiles for which no generic base exists
Use cases often introduce additional concepts like grouping mechanisms of workflows without an underlying zib. For these use specific concepts, profiles are defined which usually are restricted to the use case. However, also in this case there's a similar need to be not more restrictive than needed for exchange purposes, while being as restricted as possible for documentation and validation purposes.
In addition, the question arises if these use case concepts shouldn't be generalized to the nl-core layer, so that additional use cases can adopt the same solution. The answer is probably "no", because it's very hard to reason about generalizing these kind of things on an abstract level. The approach should probably be to wait for multiple use cases that have similar problems, and then see how this can be generalized on both a functional and technical level.
Even then, it should be noted that generalizing to nl-core should not be approached from a resource type level, but from a use case or pattern level. For example, it's probably not really useful to create an "nl-core Task" profile, but it might be useful to create something like an "nl-core Task for transfer workflows".
How to make this work in practice?
So the common principle for use case profiles now would become:
- They need to apply the same restrictions as the use case
- And leave everything else alone
- But mark all concepts that need to be supported with
mustSupport.
This is true both for use case profiles that are based on a zib and for use case profiles that arise from a specific use case.
Data set and transaction profiles
On a functional level, refinements are made in two steps: first a data set is made, and from this data set one or more transactions are defined. Things like terminology are typically defined on a data set level, while things like the concepts to include (mustSupport) and cardinalities are defined on a transaction level.
It makes sense to follow this model in FHIR, so to define data set profiles and then derive transaction profiles from them.
Automation
There's probably quite a good opportunity to automate things if mappings are defined between data set and profiles. Most of the cardinalities and mustSupport flags can probably be added from the transaction specification in ART-DECOR. Most of the mappings, for that matter, can be derived from the zib mappings.
Naming profiles
To be determined