Seeking input on the definition of Indicator Registry

Architecture & Standards
1

The architecture community is seeking comments on its definition of Indicator registry. Please make all comments by September 10th, 2020.

The draft definition can be found at this link on Slide One: https://docs.google.com/presentation/d/1D2wIh4faclyTeuE5PqoCjGAetJoCx49orkqneL_mYvQ/edit#slide=id.g5bbc9f5238_0_197

The draft of the text as of 8/10/20 is posted below as well for those who would prefer to comment here.

An Indicator Registry (IR) provides an authoritative source for definitions of indicators, quality and performance measures and other forms of aggregate reporting. An IR should provide functionality which includes:

  • editing and versioned publishing of aggregate report definitions
  • subscribing and relaying of disaggregation terminologies referenced in an aggregate report definition
  • uploading of local code lists used in aggregate report definitions
  • subscribing and relaying aggregate report definitions from external sources
  • grouping of related aggregate report definitions based on thematic area and disaggregation dimensions
  • Perhaps add requirements around frequency of reporting, tagging “owner/editor” of indicator
  • Perhaps add calculations of indicators (aggregating from patient level, or indicator to indicator) e.g. CQL in a FHIR Library

An IR may also provide lightweight management of the terminologies (code lists) used as disaggregation dimensions in an aggregate report including:

  • mapping of local codes to the codes required in the definition of the aggregate report
  • editing, publishing/versioning and other basic curation functions for the management of code lists and terminologies
1 Like
2

Very exciting topic, April. Without having followed the previous discussion I’d add the following points:

  • compatibility rules for indicator versions to be able to aggregate automatically across different versions of the same indicator (e.g. in different years, organisations, countries …) or to be at least warned that there are different definitions in an aggregate. (old thoughts on this)
    • something similar for code lists, org-hierarchies …
    • technical implementation would be a nightmare, though - haven’t seen this, yet
  • redundancy management for indicator definitions. E.g. if a definition of an indicator “Number of Births” contains a list of x birth giving procedures, this indicator should only be defined once in the system and then be reused in other indicators (e.g. Number of Births per Target Population) to avoid inconsistencies
    • should be manageable technically, have seen this elsewhere
  • Alias Management of the same indicator with different names e.g. by allowing an indicator definition to be a mere reference to an existing indicator
    • should be manageable technically, have seen this elsewhere
  • Applicability management e.g. certain indicators only make sense in certain wards, geographic regions, years etc.
  • Validity management e.g. rules for valid values as basis for error messages or warnings)

Again - not sure if all that makes sense in the context of the discussions you had so far …

3

Thank you for the response! Tagging @cleitner1 and @arch_review_board to ensure they have also seen this.

1 Like