Data Meaning Layer: Difference between revisions

Created page with "This page introduces the concept of the Data Meaning Layer, a shared framework for defining, tracking, and communicating the meaning of data elements and metrics in CCMDB. It serves as a central reference point for how we manage evolving definitions, support consistent interpretation, and connect meaning across tools like Access/SQL, SAS, Power BI, and the wiki. == The Problem == * We have a complex legacy dataset that has had significant data encoding changes over time..."
 
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
This page introduces the concept of the Data Meaning Layer, a shared framework for defining, tracking, and communicating the meaning of data elements and metrics in CCMDB. It serves as a central reference point for how we manage evolving definitions, support consistent interpretation, and connect meaning across tools like Access/SQL, SAS, Power BI, and the wiki.
{{Discuss |
* This had been percolating in my head for a while and I finally had a chance to look into it. Looking forward to thoughts. [[User:Ttenbergen|Ttenbergen]] 18:11, 18 July 2025 (CDT)
}}
 
This page introduces the concept of the Data Meaning Layer, a shared framework for defining, tracking, and communicating the meaning of data elements and metrics in CCMDB. It serves as a central reference point for how we manage evolving definitions, support consistent interpretation, and connect meaning across tools like Access/SQL, SAS, Power BI, and the wiki. We have a page [[Data Semantics]] that touches on this, and a [[:Category:Data Semantics]] that contain pages about some of the complexity that make such a layer relevant.


== The Problem ==
== The Problem ==
Line 29: Line 33:
* [[Transfer Ready DtTm tmp entry]] changed to include judgment from Allied Health, changing the meaning of [[Transfer Delay (Medicine)]]
* [[Transfer Ready DtTm tmp entry]] changed to include judgment from Allied Health, changing the meaning of [[Transfer Delay (Medicine)]]
* The meaning of [[Service/Location field]] has changed over time, where it used to tell both the [[Service tmp entry|service]] and [[Boarding Loc| location]] of an admission and now does neither, but only serves as an indicator of [[Program]] and a way to ensure uniqueness of [[D_ID]]s; in the context, the [[Definition of a Medicine Program Admission]] changed.  
* The meaning of [[Service/Location field]] has changed over time, where it used to tell both the [[Service tmp entry|service]] and [[Boarding Loc| location]] of an admission and now does neither, but only serves as an indicator of [[Program]] and a way to ensure uniqueness of [[D_ID]]s; in the context, the [[Definition of a Medicine Program Admission]] changed.  
* [[Definition of a Critical Care Program Admission]] changed over time causing confusion about [[ICUotherService]]
* [[Definition of a Critical Care Program Admission]] changed over time causing leading to [[2025-05 Revision of concept around ICUotherService]]
* also see [[:Category:Change explainer page]]


== People Involved ==
== People Involved ==
Line 100: Line 105:
** Cache and manage intermediate forms (e.g., “semantic LOS definition v3 applied to 2023 discharges”)
** Cache and manage intermediate forms (e.g., “semantic LOS definition v3 applied to 2023 discharges”)


== possible extension ==
* '''cross checks''' - our cross-checks are currently hard coded as queries in MS Access, which are also not transparent to users. Depending on implementation details this framework would allow us to include them
* '''test data and validation''' - this framework could also include test data and validation or unit test functionality
* '''branching, merging and code review''' - depending on the repository of the code, and the integration into the tool, this could introduce git-like code version management 


[[Category:Reporting]]
[[Category:Reporting]]
[[Category:Statistical Analysis]]
[[Category:Statistical Analysis]]
[[Category:Data Semantics | * ]]