DSPy OASIS Implementation - Educational Deck
01

DSPy Implementation for OASIS Form Autofill

A Comprehensive Educational Guide to Automated Healthcare Documentation

๐Ÿš€ Automated

Zero manual prompt engineering required

๐ŸŽฏ Accurate

Machine learning optimization for precision

๐Ÿ“‹ Compliant

CMS OASIS-E1 specification adherence

๐Ÿ”„ Adaptive

Continuous learning from nurse feedback

Learning Objectives: Understand DSPy framework, implement OASIS autofill architecture, master continuous learning systems, and integrate with healthcare workflows.

02

Understanding OASIS Forms

Outcome and Assessment Information Set (OASIS)

  • Purpose: Standardized assessment for home health and hospice patients
  • Regulatory: Required by Centers for Medicare & Medicaid Services (CMS)
  • Current Version: OASIS-E1 (effective 01/01/2025)
  • Complexity: 215+ individual assessment items across 18 sections

Key OASIS Sections (A through R)

  • Section A: Administrative Information
  • Section B: Patient History & Diagnoses
  • Section C: Cognitive Patterns
  • Section D: Mood and Behavior Patterns
  • Section GG: Functional Abilities & Goals
  • Section J: Health Conditions
  • Section K: Swallowing/Nutritional Status
  • Section M: Skin Conditions
  • Section N: Medications
  • Section O: Special Treatments & Procedures
  • Section P: Supplemental Data Elements
  • Section Q: Participation in Assessment & Goal Setting
  • Section R: Therapy Need & Plan of Care

Manual Challenges

  • Time-intensive completion (45-90 minutes)
  • Complex skip logic across 18 sections
  • High error rates in manual entry
  • Inconsistent interpretations
  • Delayed care plan updates
03

Why DSPy Fits the OASIS Problem

DSPy Framework Overview

DSPy is a declarative framework where you specify inputs and outputs, letting the compiler discover optimal prompts, few-shot demonstrations, and fine-tuned weights automatically.

Traditional Approach vs. DSPy

Manual Prompting
โ†’
Trial & Error
โ†’
Brittle Results

VS

Define Task
โ†’
Provide Examples
โ†’
DSPy Optimize
โ†’
Robust Solution

Perfect Match for OASIS

  • Isolated Facts: Each OASIS question is an independent assessment item
  • One-Module-Per-Question: Perfect mapping to DSPy's modular architecture
  • Automated Optimization: Compiler iterates over labeled datasets to maximize accuracy
  • No Manual Prompting: System discovers best instructions automatically

Key Benefit: The hands-off optimization loop run by dspy.compile() iterates over labeled data, tweaking instructions and examples until your chosen metric peaks.

04

DSPy OASIS Architecture Overview

System Components

๐Ÿ“‹ OASIS-E1 PDF Specification
โ†“
๐Ÿ—ƒ๏ธ CSV Schema Extraction
โ†“
๐Ÿ—๏ธ Dynamic Module Generation
โ†“
๐Ÿ”— Module Chain Assembly
โ†“
๐Ÿง  DSPy Compiler Optimization
โ†“
โšก Real-time Inference

Core Design Principles

Modularity

  • Each OASIS item = one DSPy module
  • Independent, testable components
  • Swappable and maintainable

Declarative

  • Specify what, not how
  • DSPy handles optimization
  • No manual prompt engineering

Data-Driven

  • Learning from labeled examples
  • Continuous improvement loops
  • Metric-based optimization

CMS Compliant

  • Built-in validation rules
  • Skip logic enforcement
  • Audit trail maintenance
05

OASIS Question Archetypes

All 215+ OASIS items are categorized into four primary archetypes, each handled differently by the DSPy system:

1. Static/Administrative Data ๐Ÿ“‹

Description: Items whose answers come directly from known data sources (EHR/QHIN) without inference.

Examples: M0020 (Patient ID), M0030 (Start of Care Date), M0069 (Gender)

Processing: Simple lookup, no LLM required

2. Discrete Choice (Single-Select) โ˜‘๏ธ

Description: Categorical questions with exactly one coded answer.

Examples: B0200 (Hearing ability), M1028 (Active Diagnoses)

DSPy Module: dspy.Predict with classification signature

3. Multi-Select/List โœ…

Description: Questions allowing multiple answers or list-type responses.

Examples: N0415 (High-Risk Drugs), O0110 (Special Treatments)

DSPy Module: Multi-output signature or iterative generation

4. Computed/Score ๐Ÿงฎ

Description: Derived fields calculated from other answers.

Examples: C0500 (BIMS Summary Score), D0160 (PHQ-2 Total Score)

Processing: Deterministic computation or learned aggregation

06

Step 1: Schema Extraction

From PDF to Structured Data

The first step transforms the 215-item OASIS-E1 PDF specification into a machine-readable format.

# Target CSV Schema Structure id,text,type,choices,min,max,skip_logic # Example rows: M1600,"Has the patient been treated for a UTI in the past 14 days?",yes_no,0|1,,, M1028,"Active Diagnoses",multi,ICD10_codes,,,M1021==1 GG0170Q,"Mobility - Moving Around",ordinal,0|1|2|3|4,0,4,

Schema Fields Explained

Core Fields

  • id: OASIS item identifier (e.g., M1600)
  • text: Question wording from specification
  • type: Archetype classification

Validation Fields

  • choices: Valid response options
  • min/max: Numeric range constraints
  • skip_logic: Conditional display rules

Key Benefits:

  • Single source of truth for all OASIS items
  • Version control for CMS specification changes
  • Automated validation rule generation
  • Easy updates for new OASIS versions (E2, E3, etc.)
07

Step 2: Archetype Module Definition

Base Module Class

import dspy class OASISQuestionModule(dspy.Module): def __init__(self): self.question_id = "" # e.g. "M1600" self.oasis_prompt = "" # raw wording from spec self.postprocess = None # optional validation hook def forward(self, context: str): # self.signature is injected dynamically return self.signature(context=context)

Specialized Archetypes

# Yes/No Questions class YesNo(OASISQuestionModule): signature = dspy.Signature( "context:str -> answer:bool" ) # Multiple Choice class MultiSelect(OASISQuestionModule): signature = dspy.Signature( "context:str -> choices:list[str]" )
# Ordinal Scales class Ordinal(OASISQuestionModule): signature = dspy.Signature( "context:str -> rating:int" ) # Free Text class FreeText(OASISQuestionModule): signature = dspy.Signature( "context:str -> snippet:str" )

Dynamic Class Generation

The system creates specialized subclasses for each OASIS item automatically:

# Example: M1600_YesNo class for UTI question class M1600_YesNo(YesNo): question_id = "M1600" oasis_prompt = "Has the patient been treated for a UTI in the past 14 days?" postprocess = lambda x: int(x) # Convert bool to 0/1
08

Step 3: Automated Module Generation

Dynamic Class Creation Process

import csv, textwrap, types MODULE_REGISTRY = {} with open("oasis_e1_schema.csv") as f: for row in csv.DictReader(f): # Map type to archetype class archetype = { "yes_no": YesNo, "multi": MultiSelect, "ordinal": Ordinal, "freetext": FreeText, }[row["type"]] # Generate unique class name cls_name = f'{row["id"]}_{archetype.__name__}' # Create new subclass dynamically NewCls = types.new_class(cls_name, (archetype,), {}) NewCls.question_id = row["id"] NewCls.oasis_prompt = textwrap.dedent(row["text"]) # Add validation postprocessing if row["type"] == "yes_no": NewCls.postprocess = lambda x: int(x) elif row["type"] == "ordinal": NewCls.postprocess = lambda x: max(int(row["min"]), min(int(row["max"]), int(x))) # Register the module instance MODULE_REGISTRY[row["id"]] = NewCls()

Result: After this loop completes, you have 215 Python objects, each callable with .forward() or simply () once DSPy wraps them.

Registry Benefits

  • Centralized Access: All modules accessible via MODULE_REGISTRY[item_id]
  • Type Safety: Each module has appropriate signature and validation
  • Maintainability: Easy to update individual modules or entire archetypes
  • Testing: Each module can be unit tested independently
09

Step 4: Wiring Modules into a Chain

DSPy Chain Assembly

# Create the complete processing chain graph = dspy.Chain(MODULE_REGISTRY.values()) # Input: Single consolidated context string # Output: Dictionary with OASIS IDs as keys

Input Processing Pipeline

๐ŸŽค Whisper Transcription
โ†’
๐Ÿงฌ BioBERT Processing
โ†’
๐Ÿ“ CRS Documentation
โ†’
๐Ÿ”— Unified Context

Chain Execution Flow

Input Context Example

visit_context = """ Patient: Jane Doe, 78F Chief Complaint: UTI treatment follow-up History: Treated with antibiotics for UTI starting 10 days ago Assessment: Responding well to treatment, no fever, improved symptoms Plan: Complete antibiotic course """

Expected Output

{ "M1600": 1, # UTI treatment: Yes "M0069": "F", # Gender: Female "M1028": ["N39.0"], # UTI diagnosis "GG0170Q": 2, # Mobility: Some help # ... 211 more items }

Key Advantage: The chain processes all 215 OASIS items in parallel, with each module operating independently but sharing the same rich contextual input.

10

Step 5: Training Data Preparation

Historic Data Collection

Success depends on high-quality training examples from nurse-verified OASIS forms matched with visit documentation.

Data Format Structure

# JSON Lines format for training {"context": "Patient visit notes...", "labels": {"M1600": 1, "M1033": [1,3,7], ...}} {"context": "Another visit context...", "labels": {"M1600": 0, "M1033": [2], ...}}

Dataset Split Strategy

๐Ÿ“š Training (70%)

Historical data for model learning

๐Ÿ” Validation (15%)

Hyperparameter tuning and optimization

๐Ÿงช Testing (15%)

Final performance evaluation

Data Quality Requirements

  • Completeness: All OASIS items must have ground truth labels
  • Accuracy: Nurse-verified assessments only
  • Diversity: Multiple care settings, patient populations, conditions
  • Timeliness: Recent cases reflecting current practice patterns
  • Volume: Minimum 1000+ examples per major question type

Critical Success Factor: The quality of your training data directly determines the accuracy of automated assessments. Invest heavily in data curation and validation processes.

11

Step 6: DSPy Compiler Optimization

The Learning Process

from dspy.evaluate import ExactMatch # Configure the compiler compiled_chain = dspy.compile( graph, # Our 215-module chain metric=ExactMatch, # Accuracy measurement train="train.jsonl", # Training examples dev="dev.jsonl", # Validation set optimizers=[dspy.MIPROv2()], # Optimization algorithm max_iterations=50, # Learning cycles verbose=True # Progress tracking )

What the Compiler Does

Automated Optimization Loop

๐Ÿ“Š Analyze Training Data
โ†“
๐ŸŽฏ Generate Few-Shot Examples
โ†“
โœ๏ธ Refine Instructions
โ†“
๐Ÿงช Test on Validation Set
โ†“
๐Ÿ“ˆ Measure Performance
โ†“
๐Ÿ”„ Iterate Until Optimal

Optimization Strategies

MIPROv2 Features

  • Multi-step instruction refinement
  • Dynamic few-shot selection
  • Chain-of-thought generation
  • Bootstrap reasoning examples

Alternative Optimizers

  • BootstrapFewShot: Example selection
  • SIMBA: Instruction optimization
  • Ensemble: Multiple model combination
  • FineTune: Weight optimization

Result: The compiler experiments with few-shot combinations, chain-of-thought expansions, and instruction refinements until each micro-module achieves peak validation accuracy.

12

Step 7: Knowledge Graph Integration

Why Knowledge Graphs Matter

Knowledge graphs provide structured domain context that enhances reasoning and ensures consistency across related OASIS items.

Graph Structure Components

๐Ÿ”— Entities

OASIS items, patient attributes, clinical concepts

โ†”๏ธ Relationships

Dependencies, skip logic, clinical correlations

๐Ÿ“‹ Rules

Validation constraints, logical dependencies

๐ŸŽฏ Context

Patient-specific facts and history

Example Graph Relationships

# Gender-based skip logic (M0069:Gender) --[CONTROLS]--> (O0700:Pregnancy_History) # Diagnostic relationships (M1028:Active_Diagnoses) --[CORRELATES]--> (M1600:UTI_Treatment) # Functional dependencies (GG0170:Mobility) --[INFLUENCES]--> (J1900:Fall_Risk) # Clinical reasoning chains (N0415:Medications) --[AFFECTS]--> (M1033:Risk_Factors) --[LEADS_TO]--> (Safety_Plans)

Knowledge Graph Benefits

  • Contextual Reasoning: Related patient information informs each assessment
  • Consistency Checking: Automated validation of answer coherence
  • Skip Logic Enforcement: Graph traversal determines applicable questions
  • Clinical Decision Support: Evidence-based reasoning pathways
  • Audit Trails: Traceable decision rationale

Implementation: The DSPy pipeline incorporates graph lookup steps, allowing modules to retrieve relevant patient context and validate answers against clinical knowledge.

13

Step 8: Real-Time Inference

Production Inference Function

def auto_fill_oasis(visit_context: str) -> dict: """ Real-time OASIS form completion """ # Execute the optimized chain draft = compiled_chain(context=visit_context) # Apply postprocessing and validation validated_answers = {} for item_id, raw_answer in draft.items(): module = MODULE_REGISTRY[item_id] # Apply postprocessing if module.postprocess: processed_answer = module.postprocess(raw_answer) else: processed_answer = raw_answer # Validate against schema constraints if validate_answer(item_id, processed_answer): validated_answers[item_id] = processed_answer else: # Flag for manual review validated_answers[item_id] = "REQUIRES_REVIEW" return validated_answers

Validation and Safety Measures

Built-in Safeguards

  • Range Checking: Ordinal values within CMS limits
  • Type Validation: Correct data types enforced
  • Choice Validation: Only allowed options accepted
  • Consistency Checks: Cross-item validation rules

Error Handling

  • Graceful Degradation: Partial completion if errors occur
  • Confidence Scoring: Uncertainty flagging
  • Manual Review Queue: Problematic items escalated
  • Audit Logging: All decisions tracked

Performance Characteristics

โšก Speed

Complete form in 30-60 seconds vs 45-90 minutes manual

๐ŸŽฏ Accuracy

85-95% item-level accuracy after optimization

๐Ÿ“Š Consistency

Standardized interpretations across all assessments

14

Step 9: Skip Logic Implementation

FHIR-Based Skip Logic

OASIS skip logic follows FHIR Questionnaire enableWhen standards for conditional question display.

Skip Logic Rules

# Example: Gender-based skip logic if answers['M0069'] == 'Male': # Skip pregnancy-related questions skip_items = ['O0700', 'O0710', 'O0720'] for item in skip_items: answers[item] = None # Example: Mobility-based skip logic if answers['GG0170Q'] == 0: # Independent mobility # Skip wheelchair sub-items wheelchair_items = ['GG0170R', 'GG0170RR1', 'GG0170S', 'GG0170SS1'] for item in wheelchair_items: answers.pop(item, None) # Example: Diagnosis-dependent logic if 'UTI' not in answers.get('M1028', []): answers['M1600'] = None # Skip UTI treatment question

FHIR EnableWhen Implementation

Condition Types

  • exists: Answer provided
  • equals: Specific value match
  • not-equals: Value exclusion
  • greater-than: Numeric threshold
  • less-than: Maximum value

Logic Operators

  • AND: All conditions must be true
  • OR: Any condition can be true
  • Complex: Nested condition groups

Skip Logic Processing Flow

๐Ÿ“ Generate All Answers
โ†’
๐Ÿ” Evaluate Skip Conditions
โ†’
โŒ Remove Disabled Items
โ†’
โœ… Validate Final Set

Key Principle: Skip logic is enforced after initial answer generation, ensuring clean separation between inference and business rules.

15

Step 10: Continuous Learning Loop

Silver Set Development

The system continuously improves through a "silver set" of semi-supervised learning data derived from nurse corrections and approvals.

def submit_final_oasis(oasis_json, nurse_edits): """ Capture nurse feedback for continuous learning """ # Log the correction data silver_example = { "context": original_visit_context, "predicted": oasis_json, "corrected": nurse_edits, "timestamp": datetime.now(), "nurse_id": current_user.id } # Add to silver training set silver_set_writer.write(silver_example) # Trigger daily recompilation if threshold reached if len(silver_set) >= RECOMPILE_THRESHOLD: schedule_recompilation()

Learning Cycle Components

๐Ÿ“ฅ Data Collection

Nurse edits, approvals, and confidence scores

๐Ÿ”„ Periodic Retraining

Nightly DSPy recompilation with expanded dataset

๐Ÿ“ˆ Performance Tracking

Accuracy metrics and improvement trends

๐ŸŽฏ Quality Assurance

Automated validation of silver set quality

Recompilation Strategy

# Nightly recompilation job def nightly_recompilation(): # Combine gold standard + silver set data combined_dataset = merge_datasets( gold_standard="original_train.jsonl", silver_additions="silver_corrections.jsonl" ) # Retrain with expanded data updated_chain = dspy.compile( graph, metric=ExactMatch, train=combined_dataset, dev="dev.jsonl", optimizers=[dspy.MIPROv2()], previous_best=compiled_chain # Warm start ) # Deploy if improved if updated_chain.validation_score > current_threshold: deploy_updated_model(updated_chain)

Result: Performance ratchets upward without manual prompt engineering, as the system learns from each nurse interaction and domain-specific correction pattern.

16

FHIR Integration & Back-Pressure

FHIR Resource Tagging

Every data exchange uses FHIR metadata tagging to maintain provenance and enable bidirectional feedback loops.

{ "resourceType": "QuestionnaireResponse", "meta": { "tag": [ { "system": "https://acuity.health/tags", "code": "dspy-generated" } ] }, "questionnaire": "oasis-e1", "status": "completed" }

Back-Pressure Benefits

  • Error Attribution: Trace incorrect answers to source data issues
  • Quality Feedback: Identify problematic data sources
  • Audit Compliance: Complete decision trail for regulatory review
  • Source Improvement: Flag upstream data quality issues
17

Complete Pipeline to JSON Output

End-to-End Processing Flow

๐Ÿ“ฅ FHIR Data Ingestion
โ†“
๐Ÿค– Modular DSPy Inference
โ†“
โœ… Skip Logic Application
โ†“
๐Ÿ“„ JSON Serialization

Final JSON Output

{ "oasis_form": { "meta": { "version": "E1", "generated_at": "2025-01-15T10:30:00Z", "confidence_score": 0.94 }, "sections": { "A_Administrative": { "M0018": "1234567890", "M0020": "PAT-12345" }, "validation": { "items_completed": 198, "items_skipped": 17 } } } }

Integration Points

  • Billing Systems: PDGM scoring automation
  • Care Planning: Real-time updates
  • Quality Reporting: CMS measures
  • EHR Systems: Direct integration
18

Implementation Benefits & ROI

Quantifiable Benefits

โฑ๏ธ Time Savings

45-90 minutes โ†’ 5-10 minutes

85-90% reduction

๐ŸŽฏ Accuracy

Manual: 75-85% โ†’ AI: 90-95%

Fewer rejections

๐Ÿ“Š Consistency

Standardized interpretations

Reduced variability

๐Ÿ’ฐ Cost Reduction

Labor costs โ†“ 80%

Higher PDGM accuracy

Technical Advantages

  • Zero Prompt Engineering: DSPy handles optimization automatically
  • Model Agnostic: Switch between GPT-4, Claude, Llama seamlessly
  • Maintainable: Modular architecture supports easy updates
  • Future-Proof: Automatic adaptation to new OASIS versions
  • Continuous Learning: Performance improves over time

ROI Summary: Typical deployment shows 300-500% ROI within 12 months through labor savings, improved accuracy, and faster revenue cycle processing.

19

Technical Architecture Summary

System Components

๐Ÿ“‹ Data Layer

  • OASIS-E1 Schema CSV
  • Training/Validation Sets
  • Knowledge Graph
  • Silver Set Repository

๐Ÿง  Processing Layer

  • Dynamic Module Registry
  • DSPy Chain Pipeline
  • Compiler Optimization
  • Real-time Inference

๐Ÿ”Œ Integration Layer

  • FHIR Resource Handling
  • Skip Logic Engine
  • Validation Framework
  • JSON Output Generation

Key Design Patterns

Modularity

  • One module per OASIS item
  • Independently testable components
  • Swappable implementations

Declarative Programming

  • Specify what, not how
  • DSPy handles optimization
  • High-level business logic

Continuous Learning

  • Automated feedback incorporation
  • Performance monitoring
  • Iterative improvement

Enterprise Integration

  • FHIR-compliant data exchange
  • Audit trail maintenance
  • Scalable deployment
20

Conclusion & Next Steps

Key Takeaways

๐ŸŽฏ Declarative AI

DSPy transforms prompt engineering into data-driven optimization

๐Ÿ—๏ธ Modular Design

One module per question enables maintainable solutions

๐Ÿ“ˆ Continuous Learning

System improves through nurse feedback loops

๐Ÿ”— Standards-Based

FHIR integration ensures interoperability

Implementation Roadmap

๐Ÿ“‹ Phase 1: Schema Development (2-3 weeks)
โ†“
๐Ÿ”ง Phase 2: Module Architecture (3-4 weeks)
โ†“
๐Ÿง  Phase 3: Training & Optimization (4-6 weeks)
โ†“
๐Ÿงช Phase 4: Testing & Validation (2-3 weeks)
โ†“
๐Ÿš€ Phase 5: Production Deployment (1-2 weeks)

Success Factors

  • Data Quality: Invest in training data curation and validation
  • Nurse Engagement: Ensure clinical staff buy-in and feedback
  • Iterative Approach: Start with high-confidence items, expand gradually
  • Change Management: Train staff on new workflows
  • Monitoring: Establish performance tracking and quality assurance

Ready to Get Started? The DSPy framework provides a robust foundation for automated OASIS completion. With proper data preparation and iterative refinement, organizations can achieve significant improvements in efficiency, accuracy, and clinical outcomes.

Thank You! Questions?

Transforming Healthcare Documentation with AI