Releases: smart-on-fhir/cumulus-library-data-metrics
Releases · smart-on-fhir/cumulus-library-data-metrics
6.0.0
5.1.0
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
4.0.2
4.0.1
4.0.0
Breaking changes since 3.0.0:
c_resources_per_pt
- Special value
* All
is renamed tocumulus__all
and* No recognized category
is renamed tocumulus__none
- Special value
- Flat tables (that is, non-cube tables like
c_resources_per_pt
and all theq_*
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
orcategory
) - 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 anull
value)
Other notable changes:
c_resources_per_pt
: Added astd_dev
columnc_us_core_v4_count
: Stop looking forpresentedForm
in DiagnosticReport profiles, since the ETL strips that fieldq_date_recent
: Fixed a syntax error when running against AWS Athenaq_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
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.
2.0.1
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