MedVertical

Built for trust. Designed for oversight.

How Records handles your data, protects your infrastructure, and safeguards your operations.

What Records accesses

Read-only integration via standard REST APIs.

Records connects to your FHIR server through standard REST APIs. It issues GET and HEAD requests only. It never writes, modifies, or deletes.

Your FHIR Server

Source of truth

GET / HEAD

Records

Read-only observer

Signals

Evidence

PASS / WARN / FAIL

What Records stores

Clear boundaries on data residency and retention.

Stored

  • • Resource IDs
  • • Validation run metadata
  • • Signal outputs (PASS / WARN / FAIL)
  • • Configuration fingerprints
  • • Timestamps

Never stored

  • • Clinical payloads
  • • Patient data
  • • PHI / PII
  • • Authentication tokens
  • • Source FHIR resources

Deployment options

Your infrastructure, your rules.

SaaS — Hosted by MedVertical

  • EU-hosted infrastructure
  • Data processed in-region
  • Managed updates
  • Standard HTTPS

On-Premises

  • Your network, your control
  • Air-gap capable
  • Offline-capable validation
  • No external connectivity required

Data Handling & Liability

Privacy-preserving architecture by design.

No Clinical Payload Storage

Records stores resource IDs, validation outcomes, issue counts, and run metadata — never clinical content, patient data, or resource payloads.

Evidence, Not Authority

Records outputs PASS/WARN/FAIL signals. Your governance team decides whether to ship, investigate, or block. Records never enforces policy.

Adjacent to FHIR Server/CDR

Deploys alongside your existing infrastructure as a sidecar. No replacement, no migration — adds capability without disrupting what you already run.

Read-Only Access

Connects via GET and HEAD requests only. Records never writes, modifies, or deletes data on your FHIR server or any external system.

Six guarantees

Non-negotiable architectural boundaries.

Adjacency

Runs alongside your FHIR server (sidecar or proxy), not partially.

Evidence

Every validation result is stored as immutable proof.

Any Volume

Records stores metadata results, never your patient PHI.

Read-Only

We adhere to a strict read-only policy for your source data.

Non-Blocking

Validation happens asynchronously. Zero latency impact.

Neutral

Works with HAPI, Firely, Aidbox, Azure, Google, AWS.

What Records never does

Hard boundaries on what Records can and cannot do.

Store clinical payloads
Write to your FHIR server
Make governance decisions
Block deployments or apply policy
Require platform lock-in
Access data beyond GET/HEAD

Authentication & access

How Records connects to your FHIR server.

Records authenticates to your FHIR server using the credentials you provide. It supports multiple authentication methods to match your infrastructure.

OAuth2 Client Credentials
Bearer Token
Basic Auth
Open (no auth)

On-prem deployments: credentials stay entirely within your network.

Secrets handling

How credentials are managed.

On-Premises

  • Credentials never leave your network
  • Environment variables or local config
  • You control key management

SaaS

  • EU-based infrastructure
  • Encrypted at rest
  • Never logged or exposed in output

Data retention & lifecycle

What is kept, for how long, and how to remove it.

Validation metadataRetained for the duration of your subscription. Exportable on request.
Configuration snapshotsRetained per run for reproducibility. Deletable on request.
Clinical payloadsNever stored. There is nothing to retain or delete.
Account deletionOn request, all data can be exported and permanently deleted.

Logging & auditability

What Records tracks about its own operation.

All validation runs are logged with:

Timestamp
Unique run ID
Configuration fingerprint
Signal output (PASS/WARN/FAIL)
Resource count and duration
Server endpoint (anonymized in logs)

Logs are available for export. No clinical content is ever included in log output.

Support & incident posture

What happens when something goes wrong.

Key principle

Records operates adjacent to your infrastructure. If Records is unavailable, your FHIR server and all downstream systems continue exactly as before. Records has no write access, no pipeline dependency, and no blocking integration point.

Email supportResponse within 2 business days
Direct founder accessAvailable for early-access evaluators
Downtime impactZero — Records is adjacent, not blocking

Compliance positioning

How Records supports your regulatory requirements.

Records is not a certified medical device. It does not make clinical decisions. It produces evidence signals that your governance stakeholders use to make decisions.

Records is designed to support — not replace — your existing compliance workflows including: audit preparation, vendor acceptance, release gating, and regulatory evidence production.

Transparency notice

MedVertical does not claim ISO 27001, SOC 2, or HIPAA certification. This page documents how the system is architected. Certifications, if pursued, will be listed here when achieved.

Questions about data handling?

We'll walk through the architecture on a call.

Explore Records