5.1.0

We now export the meta_date and meta_version tables during a cumulus-library export action.

5.0.1

When stratifying by category, data-metrics now follows US Core more closely by adding additional Condition category codes (health-concern and 16100001 - death diagnosis from SNOMED) and restricting DiagnosticReport category codes to just the ones mentioned by US Core (LAB and three specific LOINC note codes).

5.0.0

Breaking changes since 4.x:

• Requires Cumulus Library 3.0
• Requires Python 3.11

Notable changes:

• Exports the "flat" summary tables that the quality (q_*) metrics create

4.0.2

Stop trying to export the "flat" summary tables for now - that requires the unreleased 3.0.0 version of Cumulus Library.

4.0.1

• Quiets an annoying warning about output-mode if you didn't specify it
• Exports the "flat" summary tables too

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.

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.

2.0.1

One small bug fix:

• q_date_recent: fix field quoting in Athena

2.0.0

Breaking changes since 1.0.0:

• Renamed c_term_coverage -> c_system_use
• Renamed q_term_use -> q_system_use
• All q_* summary percentages are now floats not strings

Other important changes since 1.0.0:

• Added DiagnosticReport Lab profile
• Adjusted DiagnosticReport Note profile to not cover labs anymore
• Add more date fields to all date stratifications
• Add deceased column to c_pt_count
• Changed denominator logic for q_ref_target_valid

1.0.0

Initial release! The initial set of provided metrics are:

• c_pt_count
• c_pt_deceased_count
• c_resource_count
• c_resources_per_pt
• c_term_coverage
• c_us_core_v4_count (most profiles)
• q_date_recent
• q_ref_target_pop
• q_ref_target_valid
• q_term_use
• q_valid_us_core_v4 (most profiles)