Key facts
| Healthcare fit | PHI stays inside the hospital network; clinical apps keep one API |
| Deployment | Same OpenAI-compatible API in your VPC, on-prem or air-gapped |
| Data path | Prompts, embeddings and logs remain in hospital infrastructure |
| Live endpoints | Chat, streaming, function calling, JSON mode and embeddings |
| Identity | Scoped keys per clinical service; SSO with SCIM and RBAC for staff |
| Retention | Configurable prompt retention; review the DPA for your terms |
| Audit | Authentication, key lifecycle and admin events exportable to SIEM |
| Pricing | Flat monthly self-serve plans; enterprise deployment scoped on the pricing page |
TL;DR
- Run inference inside the hospital network when PHI cannot leave it.
- Keep the OpenAI-compatible API so clinical applications do not need rework.
- Minimise or de-identify PHI before it reaches any model, on-prem included.
- Give each clinical service a minimum-necessary scoped key, never a shared one.
- Set retention per workload and export auth and key events to the security team.
How it works, step by step
- Select a documentation workflow where a clinician reviews every output, and agree the review step in writing.
- Design the network zone and segmentation so only approved clinical applications can reach the model endpoint.
- Issue minimum-necessary scoped keys per service and environment, and federate staff identity with SSO and SCIM.
- Redact or de-identify text before prompting where the task allows, keeping identifier mappings inside hospital systems.
- Set retention to the minimum the records policy permits, and confirm the terms in the DPA and contract review.
- Export authentication, key, admin and inference events to the security operations platform, and test incident response.
- Pilot with human review, track accuracy and edit rates, and expand only when the evidence supports it.
Try it yourself
Open the private LLM deployment estimator →
Why hospitals put inference on-prem
Clinical data carries legal, ethical and reputational weight that makes external processing a hard conversation. On-prem deployment removes that conversation for the inference path: prompts, embeddings and logs stay inside the hospital network, under the same segmentation, backup and incident processes as other clinical systems.
It also simplifies integration politics. The application team calls one OpenAI-compatible endpoint; the security team sees familiar controls; the clinical safety review focuses on workflow and human oversight rather than on a third-party data flow.
Controls that make a clinical pilot defensible
The pilot design matters as much as the technology. Drafting and extraction tasks with a mandatory clinician review are safer starting points than anything that decides care. Around that, keep access tight and evidence rich.
- Access: minimum-necessary scoped keys per service; no shared clinical credentials.
- Identity: SSO with SCIM for staff, RBAC for administrative actions.
- Data: de-identify before prompting where possible; keep mappings internal.
- Retention: configurable per workload, set to the shortest period your policy allows.
- Evidence: auth, key, admin and inference events exported for review.
Operations and honest boundaries
On-prem shifts operational duty to the hospital: capacity, patching, monitoring and incident response. Size on peak clinical usage hours and worst-case document length, and budget engineering time alongside licensing; compare with VPC and flat monthly plans on the live pricing page rather than assuming self-hosting is cheaper.
Keep compliance claims precise. Plugsky provides scoped authentication, retention settings, audit export, residency choices and deployment variants. It does not provide clinical judgement, consent management or a compliance certification that transfers to your organisation; map its controls into your own risk analysis. Endpoint coverage is the same in every deployment: chat, streaming, JSON mode, function calling and embeddings are live, while audio, images and files are labelled coming soon.
Honest comparison
| Concern | Plugsky on-prem | Vendor cloud API | DIY open-source stack |
|---|---|---|---|
| PHI location | Inside the hospital network | Leaves the network | Inside, but you assemble it |
| Clinical application change | None: OpenAI-compatible API | None | Custom serving and client code |
| Access control | Scoped keys, SSO, SCIM, RBAC | Vendor controls | Built by your team |
| Audit | Auth, key and inference events to SIEM | Vendor logs | Your logging stack |
| Effort | Platform deployment plus hospital ops | Lowest | Highest: full MLOps |
Frequently asked questions
Does on-prem remove the need to minimise PHI?
No. Minimisation is still the strongest control. Redact or de-identify before prompting wherever the task allows, and keep identifier mappings inside hospital systems.
Is Plugsky HIPAA compliant?
Plugsky provides security documentation, scoped authentication, retention settings, audit export and deployment options you can assess. Whether your use is compliant depends on configuration, contracts and policies — decide that with your compliance team.
How do clinicians access the system?
Through your identity provider with SSO, provisioned with SCIM and authorised with RBAC roles. Services use minimum-necessary scoped keys rather than staff accounts.
Which workloads are safe to start with?
Documentation support, coding assistance and inbox triage with mandatory human review. Avoid anything that makes or recommends clinical decisions without a clinician.
What capacity should we plan for?
Peak clinical hours and worst-case document length, with headroom for model upgrades. Long records consume far more capacity than short notes.
Can we move to on-prem later?
Yes. Applications built against the OpenAI-compatible API keep working when the deployment moves from cloud or VPC to on-prem, so you can pilot first and relocate when required.
What audit evidence is available?
Authentication, key lifecycle, administrative and inference events can be exported to your security platform, giving a joined view of access and model activity.