Stream: implementers
Topic: Readying resources for containment
Paul Knapp (Nov 10 2016 at 12:35):
How far shoukd we go in readying resources for containment, and other uses such as reporting, in setting minimum cardinality to 0? Should we set all root elements to 0..? or All but a very very few elements? All including subclasses?
Grahame Grieve (Nov 10 2016 at 12:36):
Containment is not relevant for minimum cardinalities.
Grahame Grieve (Nov 10 2016 at 12:37):
you should look at each element, and ask (a) whether there are valid use cases for the information to be not known and (b) what is the impact on implementers if it is not known
Paul Knapp (Nov 10 2016 at 12:45):
Well the problem I'm seeing is people using resources for other than the 'primary purpose' where they say 'but we don't send over that element' or 'when we are constructing the resource we may not have that info yet' - which can apply to pretty much everything. I see a lot of resources which require Status or a code where in the contained situation they may only have some text from an elemnt or two, the same way you may not have the minimum reasonable info on Patient.
Paul Knapp (Nov 10 2016 at 12:51):
True, containment isn't the only driver, but those situations where you have a resource contained may lead to realizing where required elements cannot be fulfilled.
Paul Knapp (Nov 10 2016 at 12:56):
The difficulty is knowing all use-cases. We had a situation where we had made the issuer of an insurance coverage required because you can't have one without them and its pretty useless without that info - except that someone came with teh use case of when they do X they send a subset of the coverage info and specifically don't include the issuer. A committee can know what is the minimum required to do something with the resource, but not the minimum that people will require when they use the content model for example for reporting to someone.
Lloyd McKenzie (Nov 10 2016 at 20:23):
Resource minOccurs should be based on all uses, not primary uses. So use-cases considered need to include secondary use, anonymous reporting, interacting with legacy systems, etc. In general, minOccurs should be 1 only if the resource is pretty much useless without the element being present. Status is typically made "required" because you can't do much with a record in any context if you don't know if it's "entered in error" or not. But there aren't many elements like that. In your coverage example, the question is "can anyone do anything useful with coverage if they don't know the issuer" and the answer is often "yes" - because the identifier and/or coverage type sufficiently identify the issuer for coverage to be processed by the recipient.
Paul Knapp (Nov 11 2016 at 20:03):
no, coverage type generally doesn't as you don't know which of those (who, type is what). If I have the identifier of a thing then I don't need to know the status to refer to the thing - that's why the status of Patient (active) is 0.. I expect.
Given that we don't have the resources to know all use cases I think we have to assume all root elements must be 0.. - and many currently are not.
Grahame Grieve (Nov 11 2016 at 20:43):
it's certainly going to be only selected root elements that have a base cardinality of 1..x. One notable one that will probably have to change is Procedure.code
Last updated: Apr 12 2022 at 19:14 UTC
