I've hit a really tricky docs problem in fhir-gen
Some builders support multiple profiles. For example, the Observation:
Each type of observation has it's own set of keys. But we present a single flat interface
So it's not clear which properties belong to which profile
EVEN WORSE! Some profiles have the same property but different docs and value sets. code is a huge problem: every observation type provides a code key, but it means something different for each.
The docs in the screenshot above show the code docs and value map for the SzMannerOfDeath profile. But obviously they don't make sense for the LabResult profile.
I'm not sure how to handle this. Should we have a builder per profile, rather than per resource? but that's a lot of docs duplication in many cases. Should we concatenate docs for all profiles into the object definition in the docs page? Maybe but that could be super hard to read.
Really tough one this.
I've hit a really tricky docs problem in fhir-gen
Some builders support multiple profiles. For example, the Observation:
Each type of observation has it's own set of keys. But we present a single flat interface
So it's not clear which properties belong to which profile
EVEN WORSE! Some profiles have the same property but different docs and value sets.
codeis a huge problem: every observation type provides acodekey, but it means something different for each.The docs in the screenshot above show the
codedocs and value map for theSzMannerOfDeathprofile. But obviously they don't make sense for theLabResultprofile.I'm not sure how to handle this. Should we have a builder per profile, rather than per resource? but that's a lot of docs duplication in many cases. Should we concatenate docs for all profiles into the object definition in the docs page? Maybe but that could be super hard to read.
Really tough one this.