Security architecture for laboratory data
This page describes technical controls that exist in the platform. It does not claim certifications we do not hold, and it does not display badges we have not earned — which is a deliberate choice, and one worth checking other vendors against.
Access control
Who can see and do what, enforced by the platform rather than by convention.
Role-based access control
Permissions are granted by role, not per person. Roles are scoped to a laboratory, a facility or a group, and users inherit only what their role allows.
Least-privilege defaults
New roles start with the minimum access needed for the work, and additional permissions are granted deliberately.
Tenant isolation
Data is scoped to the organization it belongs to. A request authenticated for one laboratory does not return another laboratory's records.
Administrative controls
User provisioning, role assignment and access review are administrative functions with their own audit trail.
Authentication and sessions
How identity is established for people and for systems.
Secure authentication
Credential handling follows current practice, including password hashing, credential rotation support and configurable password policy.
Session management
Sessions expire, can be revoked, and are tied to the role context the user was granted.
API authentication
System-to-system access uses issued, signed credentials scoped to a consumer and an organization. An unrecognized consumer is refused rather than served.
Presigned document access
Document and image access is granted through short-lived signed URLs rather than by exposing storage directly.
Data protection
How data is protected at rest, in transit and over time.
Encryption in transit
All traffic between clients, services and integrations runs over TLS.
Encryption at rest
Stored data and documents are encrypted at rest in the underlying infrastructure.
Backup strategy
Backups are taken on a defined schedule and their restoration is tested rather than assumed.
Data retention
Retention periods are configured per laboratory in line with the laboratory's own record-retention obligations.
Auditability
The record of what happened, who did it and when.
Audit logging
Record creation, field-level edits, approvals, releases and deliveries are logged with the acting user and timestamp.
Field-level change history
Changes to patient, order and result data record the previous value, the new value and who made the change.
Release and delivery records
Every result release and every delivery is recorded, so what was sent, to whom and when is answerable from the record.
Monitoring
Platform and pipeline health are monitored, and processing failures surface as exceptions rather than silence.
Application security
How the platform itself is built and operated.
Secure APIs
Endpoints authenticate and authorize every request against the caller's scope before returning data.
Input validation
Data entering the platform through forms, interfaces and documents is validated before it is written.
Dependency management
Dependencies are tracked and updated as part of routine maintenance.
Environment separation
Development, testing and production environments are separated, and production data is not used casually in lower environments.
One laboratory's data does not reach another
Data is scoped to the organization it belongs to at the platform level rather than filtered in the interface.
Laboratory group
Group-level catalog, governance and consolidated reporting
Laboratory A
Clinical · 2 facilities
Laboratory B
Molecular · 1 facility
Laboratory C
Toxicology · 3 facilities
Users
Roles scoped per laboratory or across the group
Facilities
Own catalogs, delivery routes and report formats
Providers
Ordering providers with their own preferences
Patients
Records isolated to the organization they belong to
Data is scoped to the organization it belongs to. A user or API consumer authenticated for one laboratory does not receive another laboratory's records, and group-level access that spans laboratories is granted explicitly and logged.
HIPAA and compliance
GetLabServices is designed to support HIPAA-compliant operations when properly configured and operated within an appropriate compliance program. That wording is deliberate. HIPAA is not a software certification: compliance is a property of an organization's policies, training, agreements and operations, of which software is one part. We provide the technical controls described on this page — access control, audit logging, encryption, tenant isolation and administrative controls — and we work within your compliance program rather than claiming to replace it.
- We do not claim HIPAA certification, because no such certification exists for software.
- We do not display compliance badges we have not earned.
- Business Associate Agreements are handled contractually as part of the engagement.
- Where a formal attestation or audit report is required, we will tell you plainly whether we currently hold it.
PLACEHOLDER — this section is where verified attestations, audit reports and formal certifications will be listed once they are held. Nothing is listed here today.
Security questions
Are you HIPAA certified?
No — and neither is anyone else, because HIPAA has no software certification scheme. The platform is designed to support HIPAA-compliant operations when properly configured and operated within an appropriate compliance program. We are happy to walk through the specific technical controls with your compliance officer.
Do you sign a Business Associate Agreement?
BAAs are handled contractually as part of the engagement. Discuss the specifics with our team before implementation begins.
How is one laboratory's data kept separate from another's?
Every record belongs to an organization, and access is scoped to that organization at the platform level. A user or API consumer authenticated for one laboratory does not receive another laboratory's data. Group-level roles that span laboratories are granted explicitly and their access is logged.
Can we see who changed a record?
Yes. Field-level changes record the previous value, the new value, the acting user and the time. Approvals, releases and deliveries are logged the same way.
Do you hold a SOC 2 report?
We do not currently publish a SOC 2 report on this site, and we will not imply one exists. If a formal attestation is a requirement for your organization, raise it early and we will tell you exactly where we stand.
Bring your compliance officer.
We would rather have the detailed conversation early than discover a gap during implementation. Security and compliance questions are welcome in the first call.