QCDSM is typically pre-coordinated

[isaacvetter]

Hence, it could make sense to make this optional.

[isaacvetter]

@jmandel , mind reviewing this PR?

[jmandel]

This element is documented as "CMS-assigned". Is that not explicitly a kind of centralized global pre-coordination?

[isaacvetter]

I mean pre-coordination at the level of the healthsystem/QCDSM. E.g. when the healthsystem contracts with, configures, and tests the QCDSM before moving the itnegration into production, the QCDSM will tell the healthsystem it's G-code. The healthsystem will not accept guidance from any other QCDSMs/that have any other G-codes. In fact, it would be reasonable for the healthsystem to ignore this field, because the healthsystem is specifically configured to only use a single contracted QCDSM with an already known and static G-code. If the healthsystem started getting guidance from a different QCDSM/G-code, that would be an alarming problem.

So, how about:

Note that this element is typically communicated to the healthsystem during contracting, and thereafter is static.

[jmandel]

I'd be OK adding a note that this value might often be static over the lifetime of a service, but I still think including it in the record explicitly is important, because it keeps the relevant data in a single package (rather than spreading it between explicit and implicit sources) and because it allows for services that might "front" multiple QCDSMs (e.g., I could imagine using several and picking the one, if any, that supports a proposed order in realtime). Not trying to add new requirements here, just advocating that I don't see the benefit in omitting this field from the payload. EHRs can always ignore if it if they find it entirely redundant.

[isaacvetter]

Updated, how's this, Josh?