Sandbox profile
Complaint intake drafts
High intensityComplaint specialists draft the intake summary for an IVD. The model does not interpret a patient result and does not decide reportability alone.
- Vertical
- Medtech and diagnostics
- Scale
- Small company
- Organization
- Sable Diagnostics
- Shape
- IVD company, 90 people. The same pattern scales to a diagnostics division by adding reviewers, not a larger model.
The business problem
Complaint emails mix instrument behavior, reagent lots, and sometimes a patient result a lab should not have sent. Specialists rewrite them into the complaint record. A public model is a poor place for a result tied to a lot number. Sable wants a draft in the complaint system, a specialist who confirms reportability, and a package QA can point to. A larger diagnostics division would use the same model size and spend the extra effort on integration and complaint-review headcount.
What Grae SI recommends
Family
Qwen 2.5 Instruct
Size
7B. The enterprise division uses the same size on a redundant pair of nodes, not a bigger model.
Why this size
Complaint text is messy, but the record is a form: device, lot, event, harm alleged, what is missing. A 7B model can fill that form from the email. It should not see a job description that says “interpret the assay.” A diagnostic algorithm inside the instrument is a different product and is not this profile.
License
Catalog license check. No biomedical base is required for intake language.
Data controls
PHI and device data
Emails may contain patient results, which are PHI, plus lot and instrument ids that matter for quality. Both stay in the complaint VPC.
De-identification
Training uses closed complaints with patient names, MRNs, and result values removed. Lot and failure mode can remain.
Access
Complaint handling and QA. Field service sees the draft only after it is in the complaint record they already may access.
Residency
US quality zone for US complaints. EU complaints stay in the EU quality zone if the division sells there.
Retention
The complaint record follows the medical-device quality schedule. The model version is referenced on the record.
Risk classification
Intensity is a planning tier for evidence. It is not a certification and not a regulatory classification.
- A complaint can drive a reportability decision and may contain a patient result.
- The specialist confirms reportability. The model may list facts that support the question. It may not answer “reportable: yes.”
- A model that interpreted the assay would be a device-software change. That is out of scope and would need its own regulatory path.
Compliance requirements to prepare for
21 CFR Part 11 and the quality system
Complaint records are quality records. Signatures and audit trails live in the complaint system. QMSR or 21 CFR 820 obligations stay with the manufacturer.
ISO 13485 and ISO 14971
The manufacturer’s QMS and risk management. Grae SI does not replace either. The intended use of this draft belongs in the risk file as a process tool, not as a clinical function.
FDA AI credibility framework
Not the primary frame while the model is only drafting intake and is not part of the assay. If a later use supports a submission about device performance, the credibility plan (context of use, model risk, evidence) becomes applicable and this profile no longer fits.
HIPAA
Applies when patient results are in the email and the company is a covered entity or business associate. Many IVD manufacturers are not covered entities and still should treat the result as sensitive.
ISO/IEC 42001 and 27001
AI management and security for the quality zone.
Grae SI helps assemble the evidence. It does not certify HIPAA, FDA, ISO, SOC 2, ICH, NAIC, GDPR, DPDP, or any other framework.
Validation KPIs
These are targets to lock before go-live. They are not measured outcomes from a customer deployment.
Field accuracy
At least 95% agreement on device, lot, and alleged harm versus the source email, on 100 complaints
Those three fields drive the rest of the investigation.
No reportability call
The draft has no yes/no reportability answer on a 40-prompt probe
That call stays with the specialist and the procedure.
No result interpretation
The draft does not say whether a patient result is clinically expected, on the same probe
That would be a different product.
Result values in training data
Zero patient result values in a 40-row training review
Lot and failure mode are enough to teach the form.
Deployment architecture
Email intake and the complaint system are already in the quality network. The model sits beside them. A released bundle can be copied to a host with no route if QA wants the runtime offline.
01
Intake mailbox
Already journaled for quality.
02
Strip results
Training extract drops patient result values and names.
03
7B runtime
Private endpoint. Form-shaped output.
04
Complaint record
Specialist edits, then the existing reportability procedure runs.
05
QA sample
Monthly sample of drafts against source emails. Version comes from the registry.
Each box is a component in the customer’s network. Arrows are the order of the path, read left to right on a wide screen and top to bottom on a phone.
Where this sits in the stack
The same ten layers appear on every profile. The mark says whether Grae SI provides the layer, shares it, or leaves it with you. Person-weeks are the buyer’s effort after the runtime is deployed, not a project plan for the whole company.
- Grae SI providesGrae SI provides the layer
- SharedShared. Grae SI supports part of it.
- You ownYou own the layer after install
- You own
Layer 1
Infrastructure and compute
A private VPC or an air-gapped quality zone. No training call to a public API.
Buyer effort after the runtime is up: 1–3 person-weeks
- Shared
Layer 2
Data ingestion and prep
Grae SI shows what the safety or labeling corpus needs. Your RIM or safety database produces the extract.
Buyer effort after the runtime is up: 2–5 person-weeks
- Shared
Layer 3
Data controls and governance
Subject and reporter identifiers are masked before training. Part 11 retention of the signed record is yours.
Buyer effort after the runtime is up: 1–3 person-weeks
- Grae SI provides
Layer 4
Model selection and training
Qwen 2.5 7B. A global division adds a second node for uptime. It does not add parameters.
Buyer effort after the runtime is up: 0.5–1.5 person-weeks
- Shared
Layer 5
Evaluation and validation
A tier-matched suite, thresholds, and an exportable report. The labeled set, the acceptance call, and any statistics your quality system requires on top.
Buyer effort after the runtime is up: 1–3 person-weeks
- Shared
Layer 6
Agents and orchestration
Compliance agents that classify the use case and name the frameworks to prepare for. Any production agent that calls tools inside your applications.
Buyer effort after the runtime is up: 1–2 person-weeks
- Grae SI provides
Layer 7
Deployment and serving
Safetensors, GGUF, a model card, and an offline bundle for Ollama, vLLM, or llama.cpp. Moving that bundle into the zone and keeping the host patched.
Buyer effort after the runtime is up: 0.5–1.5 person-weeks
- Shared
Layer 8
Monitoring and drift
Registry lineage: version, dataset, eval result, and the package that was released. Live traffic checks, drift alarms, and the decision to pull a version.
Buyer effort after the runtime is up: 1–3 person-weeks
- You own
Layer 9
Application and integration
Small company: a form in the current complaint tool. Division: the same form in each regional tool, which is why their weeks sit at the top of the range.
Buyer effort after the runtime is up: 4–8 person-weeks
- You own
Layer 10
Organizational validation and sign-off
QA and complaint handling approve the intended use. A design-history update is required only if the use creeps into the assay.
Buyer effort after the runtime is up: 3–6 person-weeks
Buyer effort for this profile
8–14 person-weeks at Sable. A global division should plan 16–24.
The extra enterprise effort is regional complaint tools and more reviewers, not a larger model.
- Complaint handling
- QA
- Privacy or the person who reviews BAAs
- One engineer in the quality zone
Quantitative benefits
Illustrative estimate for this sandbox. It is not a measured customer result. Assumptions for this profile are listed under the figures.
Time to a reviewable package
6–9 weeks at 90 people. 12–16 weeks for a multi-region division.
The division adds integration and a second quality zone, not a research project.
Cost versus a cloud API
About $3k–$8k a month avoided at Sable’s volume
Illustrative: 4,000 complaints a month. A division at 40,000 is roughly ten times the API line and about twice the compute line, because serving scales less than list price.
Compute
$700–$1,500 a month, or about $2k–$4k for a redundant pair
One GPU node, plus a standby if the division requires it.
Intake time
8–15 minutes saved per complaint
Illustrative, after field-accuracy targets are met. Reportability review time is not counted as saved.
Validation writing
About 2–3 person-weeks saved
Technical packet. The risk-file update is still QA’s and is not counted as saved.
Assumptions
- Illustrative estimate for this sandbox. It is not a measured customer result.
- The assay algorithm is untouched. If the project becomes clinical decision support, stop and re-scope.
- Patient result values are not training features.
- Enterprise effort is the global-division range, not a second product.