Data to Consumed Insight: Clinical Context

01/31/2022 Collected and organized by Valmeek Kudesia; based on real experience

Conceptual System

  • Red arrow, outline, text denote essential components or data, which may not be available in traditional sources e.g. which clinical/staff role "should act" vs "should know" and "what matters" to each role

  • "Analysis-based" enrichment e.g. CMS-HCC risk scoring

  • "Rule-based" enrichment e.g. definition of polypharmacy

Methodology Principles

Based upon user-centered design. Recall, characteristics of an enabling environment, particularly in clinical context

Start with Desired Identity

Build foundation of identity and behavior of clinical organization

Pursue Desired Identity via Design

  • Reinforce link between designed data and technology solution and new mental models to

  • Design for failure and adaptation thereafter

    • Participants' view of themselves and purpose will undergo progression as they are enabled by data and technology solution, therefore

    • Correct design requires learning from iteration and failure (both participants and data/tech experts)

  • Be ready for insight through making e.g.

    • First, enhanced visibility of "patients that need me"

    • Second, mirror or enhance existing capability "what I do for patients who need me"

    • Third, new relationships or actions in "what else could I do for patients who need me?"

Identify What to Avoid

  • Recall, any system performing well despite overwhelming complexity will have many hidden processes and dependencies

  • Recall, Conway's Law and most visible demand will be "Failure Demand", which distorts the true need and opportunity

  • Listen very closely to "what" is the desired goal or outcome

  • Observe very closely "how" the desired goal or outcome is pursued in order to confidently avoid the same avoid traps

Don't Solve the Problem, Make the Problem Obsolete

  • Initially, there will be many "tasks", "needs" - think of these as work "demands" upon a system

  • Primary goal - remove work demands that never should have existed i.e wrong work or failure demand

    • By itself will allow "right work" to manifest itself

    • Identify associated activities, processes, mental-models that must stop or else "improvements" will be seen as "extra work" vs the "right work"

  • Secondary goal - make easier work that that should exist i.e. right work or value demand

  • Recall,

    • characteristics of an enabling environment, particularly in clinical context

    • at most %50 of appropriate tasks or needs will be described at the start

    • at minimum 50% of described tasks or needs described at the start will be "complexity-accommodating" and will reinforce distortion

Primary Goal - Remove wrong work; this by itself will allow "right work" to manifest itself

Approach

      1. Engage each task or need with the following approach

        1. "This task or need will be eliminated in the following way....."

        2. Failing above, "This task or need could be eliminated in the following way..."

        3. Failing above, "This task or need is made simpler and easier in the following way..."

      2. For each remaining task or need, imagine the scenario where a licensed role was physically prevented from performing any action NOT directly related to license and then engage each task or need in the following approach

        1. "This particular licensed role will NOT be physically prevented from performing this task or need because...."

        2. For each task or need that fails above, return to step 1.1 above to eliminate the task or need

Data-Ops Philosophy

  • Idea/need →zero-latency→ valuable charts/models (literally)

  • Draws from manufacturing eng → nimble high-output “data factory”

  • "Dev-ops" for data / automated factory for data

  • Pioneered by Airbnb, Netflix, FAANG etc

  • Combines

    • Relentless resilient automation + statistical process control

    • Concurrent automated testing + development

    • Self-organizing with intense collaboration

    • Data scientists, engineers, analysts, and IT

Data-Ops General Practices

From https://datakitchen.io/the-dataops-cookbook/

  • Add data and logic tests as part of routine

  • Use a version control system

  • Branch and merge

  • Use multiple environments

  • Reuse and container-ize

  • Parameterize processing

  • [[maximize-the-work-not-done]]

  • Work without fear and innovate i.e [[drive-out-fear]]

  • Power a learning organization resulting in [[remove-causes-failure-better-job-with-less-effort]]