README.md

---
license: apache-2.0
base_model: microsoft/Phi-4-mini-instruct
tags:
  - phi-4
  - lora
  - iec-62304
  - medical-device
  - regulatory
  - compliance
  - healthcare
  - fine-tuned
library_name: peft
pipeline_tag: text-generation
---

# IEC 62304 Compliance Support Model

A fine-tuned LoRA adapter for [Phi-4-mini-instruct](https://huggingface.co/microsoft/Phi-4-mini-instruct) specialised in generating IEC 62304-compliant medical device software documentation.

## Overview

This model assists with authoring regulatory documentation for medical device software under IEC 62304:2006+AMD1:2015. It handles three core tasks:

- **Prose generation** — drafting sections of Software Development Plans (SDP), Software Requirements Specifications (SRS), Software Architecture Descriptions (SAD), FMEA, Threat Models, and Traceability matrices
- **Requirement expansion** — expanding brief requirement statements into structured fields (description, rationale, priority, acceptance criterion, source)
- **Compliance review** — evaluating documentation excerpts for correctness and issuing PASS/FAIL verdicts with explanations

The model is trained to be class-aware, applying different verification and documentation expectations for IEC 62304 Safety Classes A, B, and C.

## Model Details

| Parameter | Value |
|-----------|-------|
| Base model | `microsoft/Phi-4-mini-instruct` (3.8B parameters) |
| Adapter | LoRA (r=32, alpha=32) |
| Target modules | q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj |
| Quantisation | 4-bit (QLoRA) during training; Q4_K_M GGUF for inference |
| Context window | 512 tokens (training); model supports up to 16K |

## Training

### Dataset

10,302 examples (9,268 train / 1,034 validation), stratified 90/10 split by task type and safety class.

| Task Type | Count | Proportion |
|-----------|-------|-----------|
| Prose generation | 4,800 | 46.6% |
| Compliance review (reflection) | 3,589 | 34.8% |
| Requirement expansion | 1,800 | 17.5% |
| Standards knowledge | 113 | 1.1% |

**Safety class distribution:** Class A 46.7%, Class B 30.6%, Class C 21.6%, General 1.1%

The dataset covers 120 fictional medical device projects spanning embedded firmware, mobile apps, desktop software, web applications, cloud SaaS, hybrid edge+cloud systems, IVD software, and AI/ML SaMD. Examples are parameterised from templates to ensure diversity while maintaining regulatory accuracy.

**Quality controls applied during generation:**
- Zero instances of "Per IEC 62304" as a paragraph opening (anti-repetition)
- Zero references to "IEC 62304-1" or other non-existent sub-parts
- Zero instances of filler language ("as appropriate", "as needed") in model outputs
- Class A examples explicitly state that unit and integration testing are not required
- FAIL verdicts in compliance reviews correctly identify hallucinated standards, wrong-class content, and generic filler

### Configuration

| Parameter | Value |
|-----------|-------|
| Epochs | 7 |
| Batch size | 32 |
| Gradient accumulation | 2 (effective batch 64) |
| Learning rate | 2e-4 (cosine schedule) |
| Warmup steps | 30 |
| Optimiser | AdamW 8-bit |
| Weight decay | 0.01 |
| Sequence packing | Enabled (padding-free) |
| Precision | BF16 |
| Hardware | NVIDIA RTX A6000 (48 GB) |
| Training time | ~10 hours |
| Response-only training | Enabled (loss computed on assistant tokens only) |

### Loss Curve

| Epoch | Train Loss | Eval Loss |
|-------|-----------|-----------|
| 1 | 0.448 | 0.407 |
| 2 | 0.128 | 0.148 |
| 3 | 0.075 | 0.092 |
| 4 | 0.051 | 0.069 |
| 5 | 0.042 | 0.061 |
| 6 | 0.033 | 0.058 |
| 7 | 0.027 | 0.058 |

Eval loss plateaued at epoch 6, suggesting 7 epochs was appropriate for this dataset size.

## Evaluation

Eight inference tests covering the model's target capabilities:

| # | Test | Result |
|---|------|--------|
| 1 | Class A SDP — should not mandate unit/integration testing | FAIL |
| 2 | Class C SRS — safety requirements | PASS |
| 3 | Requirement expansion — structured field output | FAIL |
| 4 | Compliance review — detect Class A violation | FAIL |
| 5 | Class B SAD — architecture description | PASS |
| 6 | Class A testing — should not mandate unit/integration testing | FAIL |
| 7 | Standards knowledge — detect hallucinated "IEC 62304-2" | PASS |
| 8 | Standards knowledge — confirm correct standard citations | PASS |

**4/8 tests passed.**

### Observations

**Strengths:**
- Standards knowledge is solid. The model correctly identifies hallucinated standard references (e.g. "IEC 62304-2:2015") and validates correct citations (IEC 62304:2006+AMD1:2015, ISO 14971:2019, ISO 13485:2016).
- Prose generation for Class B and C produces well-structured, relevant content with appropriate clause references.
- Safety requirement generation for Class C is accurate and specific to the device context.

**Known limitations:**
- The model does not reliably suppress unit and integration testing recommendations for Class A devices. IEC 62304 only requires system-level verification for Class A, but the base model's general software engineering knowledge tends to override the fine-tuned behaviour. This is the expected hardest failure mode — the model must learn to *omit* standard good practices when the regulatory framework does not require them.
- Requirement expansion sometimes outputs prose paragraphs rather than the expected structured fields (Description, Rationale, Priority, Acceptance Criterion, Source).
- The compliance review task does not reliably detect Class A violations where unit testing is incorrectly mandated.

These limitations reflect the challenge of overriding strong priors in the base model with domain-specific regulatory rules. For production use, Class A verification strategy sections should be reviewed by a regulatory specialist.

## Files

```
lora_v3/                          # LoRA adapter (apply on top of base model)
  adapter_config.json
  adapter_model.safetensors
  tokenizer files

phi-4-mini-instruct.Q4_K_M.gguf  # Full merged model, quantised Q4_K_M for local inference

training_data_v3/                 # Training artifacts
  train.jsonl                     # 9,268 training examples
  val.jsonl                       # 1,034 validation examples
  training_summary.json           # Hyperparameters and loss curve
  trainer_state.json              # Full training log (every 10 steps)
  inference_report_v3.json        # Detailed evaluation results with model responses
```

### Weights

The full unquantised base model is available at [`microsoft/Phi-4-mini-instruct`](https://huggingface.co/microsoft/Phi-4-mini-instruct) on Hugging Face. To obtain the full fine-tuned model at original precision, load the base model and apply the LoRA adapter from `lora_v3/`. For a self-contained quantised model ready for local inference, use the GGUF file directly.

## Usage

### With Unsloth / Transformers

```python
from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="cpiuk/htech_compliance",
    adapter_name="lora_v3",
    max_seq_length=2048,
    load_in_4bit=True,
)
FastLanguageModel.for_inference(model)

messages = [
    {"role": "system", "content": "You are an IEC 62304 regulatory documentation expert."},
    {"role": "user", "content": "Write a Software Development Plan section on verification strategy for a Class B patient monitoring system."},
]

inputs = tokenizer.apply_chat_template(messages, tokenize=True, add_generation_prompt=True, return_tensors="pt").to("cuda")
outputs = model.generate(input_ids=inputs, max_new_tokens=512, temperature=0.3, top_p=0.9)
print(tokenizer.decode(outputs[0][inputs.shape[1]:], skip_special_tokens=True))
```

### With GGUF (llama.cpp / Ollama)

Download `phi-4-mini-instruct.Q4_K_M.gguf` and use with any llama.cpp-compatible runtime:

```bash
ollama create iec62304 -f Modelfile
ollama run iec62304 "Write safety requirements for a Class C infusion pump controller."
```

## Citation

If referencing this work, please cite:

```
IEC 62304 Compliance Support Model
CPI (UK) — https://uk-cpi.com
Fine-tuned LoRA adapter for Phi-4-mini-instruct
Dataset: 10,302 IEC 62304 regulatory documentation examples
```

## Disclaimer

This model is a development aid and does not replace qualified regulatory expertise. All generated documentation must be reviewed by appropriately qualified personnel before submission to regulatory bodies. The model may produce content that is incorrect, incomplete, or non-compliant. Users are responsible for verifying all outputs against the applicable version of IEC 62304 and relevant national regulations.