Main Research Question¶
Main research question
How can a stack-agnostic Intermediate Representation (IR) be used to automate the translation and enforcement of healthcare compliance requirements within a CI/CD pipeline?
Problem Investigation¶
Healthcare software delivery faces a recurring mismatch between legal text and technical implementation. Manual compliance checks are often periodic, expensive, and weakly coupled to daily delivery workflows.
Stakeholders¶
- Direct: ECC operational/compliance roles, DSTRCT engineering roles, and audit/vetting actors who decide release readiness.
- Indirect: Patient/end user. The patient is a beneficiary of safer and more reliable delivery, but not a direct actor in certification workflow.
Why Patient Is Not a Direct Stakeholder¶
Shift-left compliance changes when and where controls are checked, not the release prerequisite itself. Software is still only released when certification and governance conditions are met. The most likely patient-facing effect is shorter lead time for compliant improvements, not direct participation in certification decisions.
Synthesis Framework¶
The main question is answered through four supporting sub-questions:
- SQ0 establishes existing solutions and known limitations.
- SQ1 defines the representational requirements of the IR.
- SQ2 defines transformation from IR to technical guardrails.
- SQ3 evaluates delivery/security impact and trade-offs.
Integration Matrix¶
| Supporting Question | Primary Output | Role in Main Answer | Remaining Uncertainty |
|---|---|---|---|
| SQ0 Existing Work | Comparative baseline of tools and limits | Justifies novelty and design choices | External tools evolve quickly |
| SQ1 Meta-Model | Required IR attributes and constraints | Defines what must be encoded | Completeness across all clauses |
| SQ2 Compiler Mapping | Mapping strategy from IR to controls | Defines how automation is operationalized | Environment-specific edge cases |
| SQ3 Impact | Observed or predicted delivery/security effects | Validates utility and trade-offs | Generalization to other contexts |
Risk Management¶
All research risks are tracked in the centralized Research Risk Register, categorized by main question and sub-question scope.
Iteration Checkpoints¶
- Checkpoint A: Stakeholder boundary validated with audit/compliance roles.
- Checkpoint B: SQ0-SQ2 provide implementable design basis.
- Checkpoint C: SQ3 establishes effect and limitations.
Evaluation Boundary¶
The thesis can validate expected effects using experiments, expert review, or case evidence, but cannot fully evaluate long-term behavior in all real-world operational contexts.
Evidence Map¶
- Regulatory and scientific sources.
- Stakeholder interview notes and decisions.
- IR schema drafts and mapping examples.
- Pipeline gate prototypes and validation outputs.
- Risk register entries and compensating-control decisions.