3.0.0
Breaking changes since 2.0.0:
c_us_core_v4_count
: The existing per-profile tables have all been split in two: a_mandatory
table and a_must_support
table.- The
valid_mandatory
andvalid
fields have been removed from the must-support table and the mandatory table now lists each separate mandatory check. - When running in
cube
mode (the default), the observation mandatory tables are also broken up into two or three smaller tables for performance reasons (_mandatory1
,_mandatory2
, etc). This is not elegant, but the observation table is a big beast and cubing wouldn't complete on a large database if we don't do this.aggregate
mode keeps all the fields in one table. - Any duplicated checks between mandatory and must-support profiles are not included in the mandatory table, to avoid duplicate field names and the resulting confusion. For example, Condition's must-support
verificationStatus
field's value is both (a) checked for validity against the required binding as a mandatory check and (b) checked for whether it is present (and also checked for a valid value) as a must-support check. That's redundant in ac_us_core_v4_count
context, so we only trackvalid_verification_status
in the must-support table.
- The
c_us_core_v4_count
: Encounter's must-supportvalid_reason_code
field has been renamed tovalid_reason
as it now also checks the alternative fieldreasonReference
(in addition toreasonCode
)
Other import changes:
c_us_core_v4_count
: Encounter's must-supportvalid_location
field also checks the alternative fieldserviceProvider
(in addition tolocation.location
)q_system_use
: Allow theNullFlavor
system for DocumentReference'stype
fieldq_system_use
: Correct a few typos on Procedure'scode
field's allowed systemsq_system_use
: If a field is not present, we don't include it in the numerator (this avoids erroneously including Vital Signs that don't have avalueCodeableConcept
field). If a required field is missing altogether, that's another metric's job - this metric just flags the systems in use.