The first step is to submit a change request that complains about the cardinalities and indicate that they’re problematic (so they get fixed in future versions). Just click on the “propose a change” link at any place in the spec. There’s a one-time (free) registration, after which you can provide feedback at will.
If you have a 1…1 element that has a ‘required’ binding, you have a choice:
- pick one of the codes from the value set - whatever is ‘closest’ or ‘good enough’ - something that might not be exactly what you want, but is at least ‘true’
- use Basic as a replacement for the resource
- be non conformant
One of the challenges with an STU specification is that sometimes when implementers try to use it in production, they’ll find that the specification is fatally broken in a particular space. That’s part of the reason why we have a “Standard for Trial Use” period where we get a variety of implementers to actually use the specification to make sure we fix those before we lock the specification down as “normative”. Obviously when it breaks for you, that really sucks.
Something else that can help is to have a wider set of perspectives at the work groups that are doing the designs. Typically if content is over-constrained, it’s because the group of individuals doing the design doesn’t have a wide enough perspective. FHIR is driven by the volunteers who show up to help drive the work. We always welcome more people and more perspectives to participate.