Security and compliance
HIPAA, SOC 2, ISO, BAAs, and the controls around healthcare data workflows.
Medblocks is built for teams that need healthcare data integrations to pass security, compliance, and commercial review. Public Medblocks materials list HIPAA, SOC 2 Type II, ISO 27001, and GDPR, and commercial plans include BAA support.
Use this page to understand the controls your implementation should preserve. For formal review, request the current Medblocks security packet, agreements, and compliance materials from the Medblocks team.
Healthcare-grade compliance
Medblocks sits in the path of PHI, patient authorization, source credentials, export credentials, webhooks, and operational audit trails. The platform is designed around healthcare integration work, not generic file transfer.
The compliance posture matters before you go live: customers often need a BAA, evidence of security controls, and clarity on where records, credentials, and webhook payloads move.
PHI handling
Medblocks handles patient data as integration infrastructure. Records can arrive through patient access, clinical workflows, backend connections, or network-based workflows, then move to destinations such as your FHIR server, S3 bucket, warehouse, webhook receiver, or API client.
Your implementation should decide what data to store, how long to retain it, who can access it, and where it should be delivered. Keep raw PHI out of logs unless your compliance program explicitly allows it.
Server-side secrets
Treat Medblocks as backend infrastructure. Keep these values out of browser code, mobile apps, and client-side bundles:
- Medblocks API keys.
- Webhook signing secrets.
- Source client secrets and private keys.
- Private keys used for SMART on FHIR client authentication.
- Export destination credentials.
Your frontend calls your backend. Your backend calls Medblocks.
Workspace separation
Use separate Sandbox and Production workspaces. Sandbox workspaces use mb_sk_sbx_ keys and sandbox-scoped sources. Production workspaces use mb_sk_live_ keys and production credentials.
That separation keeps synthetic patients, development webhooks, trial export destinations, and sandbox credentials away from live patient workflows.
Customer-owned destinations
Exports should land in destinations you control, such as your FHIR server, object storage, or data platform. Configure production destinations only after you have confirmed the receiving system, access controls, retention policy, and incident response path.
Keep destination credentials server-side in Medblocks, rotate them when ownership changes, and test exports in a Sandbox workspace before using live records.
Webhook verification
Webhook receivers must verify the Medblocks-Signature header against the raw request body before trusting an event. Do not parse JSON before computing the signature. Return a 2xx response quickly and process longer work asynchronously.
Webhooks covers endpoint setup, retries, redelivery, and signatures.
Production readiness
Before going live, confirm:
- A BAA and required commercial agreements are in place.
- Production source credentials are configured in a Production workspace.
- API keys and webhook secrets live in server-side secret storage.
- Return URLs and webhook receivers use HTTPS.
- Export destinations are owned by your organization and tested.
- Your app has access controls, audit logging, retention rules, and support workflows for data it receives from Medblocks.
- Application logs avoid raw PHI unless your compliance program explicitly allows it.