Releases · smart-on-fhir/cumulus-library-data-metrics

15 Jul 19:14

mikix

4.0.0

Breaking changes since 3.0.0:

c_resources_per_pt
- Special value * All is renamed to cumulus__all and * No recognized category is renamed to cumulus__none
Flat tables (that is, non-cube tables like c_resources_per_pt and all the q_* tables) got a few new guarantees:
- The first column is always the resource
- There is always a second column for a group identifier - the column will be named something table-specific (like profile or category)
- For each resource, the second column will always include a cumulus__all roll-up entry and a more-specific entry (even if that more specific entry is a complete duplicate with a null value)

Other notable changes:

c_resources_per_pt: Added a std_dev column
c_us_core_v4_count: Stop looking for presentedForm in DiagnosticReport profiles, since the ETL strips that field
q_date_recent: Fixed a syntax error when running against AWS Athena
q_system_use: Catch cases of codeableConcepts that are defined but with all null values
Support the new cumulus-library option syntax of --option output-mode:aggregate for specifying an aggregate output mode.

Assets 2

10 Jun 13:40

mikix

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 and valid 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 a c_us_core_v4_count context, so we only track valid_verification_status in the must-support table.
c_us_core_v4_count: Encounter's must-support valid_reason_code field has been renamed to valid_reason as it now also checks the alternative field reasonReference (in addition to reasonCode)

Other import changes:

c_us_core_v4_count: Encounter's must-support valid_location field also checks the alternative field serviceProvider (in addition to location.location)
q_system_use: Allow the NullFlavor system for DocumentReference's type field
q_system_use: Correct a few typos on Procedure's code field's allowed systems
q_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 a valueCodeableConcept field). If a required field is missing altogether, that's another metric's job - this metric just flags the systems in use.