Details
-
Change Request
-
Resolution: Persuasive with Modification
-
Medium
-
FHIR Core (FHIR)
-
R4
-
FHIR Infrastructure
-
ExampleScenario
-
-
Jose Costa Teixeira/Kathleen Connor: 7-0-0
-
Correction
-
Non-compatible
-
Yes
-
R5
Description
- In
FHIR-25260, we agreed to add 'structureVersion'. However, inFHIR-37195, we agreed to rename resourceType to 'type'. Suggest that we change and use 'structureType' instead of 'type' as that's clearer and also aligns the names. - In
FHIR-25260, we said structureVersion would be mandatory. However, in the common case where an ExampleScenario is just defining a bunch of examples within an IG, this is verbose. Suggest making it optional, with an invariant and meaningIfMissing. Specifically, the invariant would say "structureVersion is required if structureType is not from the FHIR Structures value set" and meaningIfMissing would say "If not specified, the structure must be a FHIR structure and the version is presumed to be the same version of FHIR the ExampleScenario itself is" - In
FHIR-25260, we said we would add 'profile' as type uri. However, I think we should make it a choice of uri|canonical, so that we can use the "|version" syntax for FHIR profiles. Also, to make things consistent, perhaps change the name to structureProfile[x]. - The initial theory with ExampleScenario was that we'd define the 'id' and the 'type' and that would be enough to allow resolving to the actual example instance defined in the IG. However, if we have multiple versions, they'll actually end up with distinct 'real' ids in the example instances. As well, if we're pointing to examples of other FHIR versions or non-FHIR instances, the references will need to be to Binary instances. Therefore we should add a new element called 'content' of type Reference<Any>, 0..1 with short definition "example instance" and definition "A reference that points to the instance (FHIR or otherwise) for the specific example instance. Add an invariant that it's only allowed at the root, not for contained.
(Actually, turns out that we need content at both the instance and version levels, with an invariant that says you can't have it at the instance level if there are versions.) - Definitions of many of the elements are the same as the short definitions. They need to be made distinct.
- actor, process, and process.step and alternate should all be conditional. It's ok for them to be absent when draft or unknown, but there should be at least one of all of them for active or retired.
- There's nothing in the resource that requires keys or titles to be unique (or defines the scope of their uniqueness). version stuff should be unique within the instance. The rest should be unique within the scenario.
- All of the descriptions are optional except version description. It should be optional too.
- Should be invariants that enforce that references actually resolve, and that versioned references are used when there referenced instance has versions
- Should make clear that a step can't have more than one of process, scenario, or operation (though it can have none of those - just description or just alternatives is ok).
- Shouldn't have multiple processes in a step - a process is already a repetition and steps in a process have sequence. Multiple processes have no sequence. Change cardinality from 0..1 to 0..*
- operation.type shouldn't just be string - should be a coding drawing from the same extensible valueset as TestScript operation.type
- ExampleScenario.workflow should be under step, not at the root. At the root, there's no ordering or any idea of 'where' in the flow the nesting occurs.
- operation.number should be migrated to step, as a step has a number even if it's represented by a sub-process or an externally defined workflow, however it should be optional as if we just have alternatives, they'll have their own numbers and having a number on the step is unnecessary.
- operation.title should be mandatory. initiator and recipient should be conditionally required when active/retired
- We say we allow multiple 'responses' for an operation, but my leaning is that response should be for synchronous responses and subsequent async responses should be conveyed as subsequent steps. Otherwise, there's no mechanism to convey the delay involved, nor the differentiation between "what are your alternatives to the accept response?" and "what are your alternatives to the application response?" Therefore, I think 'response' should be limited to synchronous and remove the ability for multiple responses
- ExampleScenario is missing 'title' and 'description' at the root
- ExampleScenario shouldn't have a 'name' element - this is not a resource that should ever be instantiated in code because it represents an example pathway, not a definition of what can occur.