Key facts
| Access control | Scoped API keys with rotation; enterprise SSO and RBAC options |
| Deployment | Cloud, VPC, on-prem or air-gapped to match patient-data rules |
| Auditability | Request, model and response logging for clinical review trails |
| Data grounding | Embeddings and RAG are live for guidelines and care protocols |
| Structured output | JSON mode returns intake and triage records in fixed schemas |
| Models | 30+ models behind one OpenAI-compatible API |
| Pricing model | Flat monthly self-serve plans; no per-token billing on self-serve |
| Endpoint roadmap | Audio, images, moderation, files, batch and fine-tuning are coming soon |
TL;DR
- Classify clinical data before any workflow touches patient information.
- Give each application and department its own scoped key with rotation.
- Decide residency and retention explicitly; do not inherit defaults.
- Log requests, retrieved sources and model versions for clinical review.
- Keep a named clinician accountable for every care-facing output.
How it works, step by step
- Inventory AI use cases and the patient data each one touches, then label data classes.
- For each class, choose the deployment mode: cloud, VPC, on-prem or air-gapped.
- Issue per-application keys, store them in a secrets manager, and set a rotation schedule.
- Define log fields and retention: request ID, model, retrieved sources, output, reviewing clinician.
- Approve a model allow-list tied to evaluation results, and re-test when models change.
- Require citations from approved guidelines and clinician review before clinical use.
- Run a tabletop exercise for a wrong or leaked answer, including patient notification paths.
Try it yourself
Open the AI data residency checklist →
Patient data scope and classification
Security starts with knowing what a workflow can see. Split content into classes: public health guidance, clinical protocols and pathways, operational hospital data, and protected patient information with identifiers. Each class gets its own rules for whether it may leave your boundary and what logging it requires.
Most teams begin with public guidance and internal protocols, then extend to patient data only on private deployments where prompts, documents and embeddings stay inside the environment.
Keys, access and least privilege
Model credentials deserve the same discipline as database credentials. Issue a distinct API key per application and environment, store it in a secrets manager, rotate it on a schedule, and revoke on role changes. Where enterprise identity is available, connect SSO and role-based access so console permissions follow your joiner-mover-leaver process.
Never share a production key across departments, and never place keys or patient identifiers in prompts; retrieve only the fields a task requires.
Residency, retention and audit trails
Decide explicitly where processing happens and how long records live. Region selection covers many residency needs; VPC, on-prem and air-gapped deployment covers mandates that require data to stay inside the hospital or health system. Retention is your policy applied to prompts, outputs, logs and retrieval indexes, not a platform default.
Log enough to reconstruct a clinical answer: request ID, model name and version, retrieved source identifiers, output and the reviewing clinician. See AI audit logs for a schema.
Model governance and clinician accountability
Keep an approved model list with evaluation evidence for each model, and re-run evaluations when versions change. Restrict clinical workflows to models and prompts that passed review, and require citations from approved guidelines. Regardless of automation, a qualified clinician remains accountable for care decisions, so the checklist should name that reviewer in the workflow design.
Honest comparison
| Control area | Plugsky capability | Common gap | Owner |
|---|---|---|---|
| Identity | Scoped keys, rotation, enterprise SSO and RBAC options | Shared production keys | Security engineering |
| Data boundary | Cloud, VPC, on-prem or air-gapped deployment | Prompt data path undocumented | Privacy officer |
| Retention | Configurable logging of requests and responses | No defined retention | Privacy officer |
| Audit trail | Request, model and source logging | Clinical answers not traceable | Clinical governance |
| Model governance | Model choice behind one API with evaluation | Silent model changes | Clinical informatics |
| Human sign-off | Citations and structured output for reviewers | Unreviewed AI drafts | Medical director |
Frequently asked questions
Does using Plugsky make us compliant?
No. Compliance is your program. Plugsky provides deployable controls - scoped keys, private deployment, logging - that you document and audit against your own patient-privacy obligations.
Can patient data stay inside the hospital?
Yes. VPC, on-prem and air-gapped deployments keep prompts, documents and embeddings inside your environment, and the API stays OpenAI-compatible.
What should we log?
Request IDs, model names and versions, retrieved source identifiers, outputs and the reviewing clinician, retained under your policy. That is enough to reconstruct how an answer was produced.
How do we handle identifiers in prompts?
Keep them out where possible, retrieve only the fields a task requires, and use private deployment for workflows that must process identified records.
Is fine-tuning available on clinical notes?
Fine-tuning, batch and file endpoints are coming soon. Today, use retrieval over approved protocols with JSON mode for consistent output structure.
How do we evaluate a model for clinical content?
Build a question set from approved guidelines, score answers for accuracy and citation quality, and require clinician review before any workflow reaches patients.
Where should a pilot start?
Pilot on public guidance and internal protocols using the free plan, prove accuracy and logging, then extend to patient data on a private deployment.