Design an electronic health record system: system design interview question

How the interviewer opens it

“Design an electronic health record system for a network of care organizations. Staff use it to store and retrieve patient histories, diagnoses, prescriptions, and test results. The system must control access and maintain a record of changes.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Scale and request mix
Record and document size
Latency
Access rules
Consistency and availability
Clinical changes
Lab identity and order
Audit and administrator access
Retention and durability
Identity and exclusions

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Store and retrieve patient histories, diagnoses, prescriptions, and test results.
Preserve prior revisions when staff or labs correct clinical records.
Enforce access rules for each patient, record type, and action.
Record access attempts and changes, including approved direct database access.

Usually out of scope

Match patient identities across organizations.
Exchange records across organizations.
Send prescriptions to pharmacies.
Provide clinical advice or drug interaction checks.
Process insurance claims or certify legal compliance.
Permit unrestricted clinical SQL or database exports across patients.
Protect against compromise of the independent security control plane.

What interviewers ask about

Access to patient records: A staff role alone does not determine access. Consent, care relationships, record restrictions, and emergency access can change the result.
Changes to clinical records: A correction must preserve the original clinical fact. Concurrent edits and delayed lab results can otherwise change treatment history without clear evidence.
Evidence of access and changes: Reads need evidence as well as changes. Direct database access can bypass application events, while statement audits do not identify every patient row read.

Common mistakes

The design uses a staff role as the only access rule.
The service replaces signed records and loses the original clinical facts.
The service sends audit events after the response without a durable copy.
The service exposes documents through URLs that bypass access checks.
The design lacks a stable lab identity or assumes that arrival order defines correction order.
The design assumes that SQL statement logs identify every patient whose records a query reads.

The bar by level

Senior (L5/E5): Defines access rules for each record type and enforces revocations. Handles concurrent edits, source identity, correction order, and audit outages. Sizes storage and indexes from the workload. Restricts privileged clinical queries so audit events have reliable patient attribution.
Staff (L6+/E6+): Defines enforceable administrator privileges and independent evidence for database access. Covers procedure scope, grants, alternate access paths, and uncertain audit outcomes. Specifies failure rules for policy checks, source updates, and audit capture. Evaluates recovery tests, retention costs, and organization isolation.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design an electronic health record system
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design an electronic health record system for a network of care organizations. Staff use it to store and retrieve patient histories, diagnoses, prescriptions, and test results. The system must control access and maintain a record of changes.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Scale and request mix

Record and document size

Latency

Access rules

Consistency and availability

Clinical changes

Lab identity and order

Audit and administrator access

Retention and durability

Identity and exclusions

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Store and retrieve patient histories, diagnoses, prescriptions, and test results.
Preserve prior revisions when staff or labs correct clinical records.
Enforce access rules for each patient, record type, and action.
Record access attempts and changes, including approved direct database access.

Usually out of scope

Match patient identities across organizations.
Exchange records across organizations.
Send prescriptions to pharmacies.
Provide clinical advice or drug interaction checks.
Process insurance claims or certify legal compliance.
Permit unrestricted clinical SQL or database exports across patients.
Protect against compromise of the independent security control plane.

What interviewers ask about

Access to patient records

A staff role alone does not determine access. Consent, care relationships, record restrictions, and emergency access can change the result.

Changes to clinical records

A correction must preserve the original clinical fact. Concurrent edits and delayed lab results can otherwise change treatment history without clear evidence.

Evidence of access and changes

Reads need evidence as well as changes. Direct database access can bypass application events, while statement audits do not identify every patient row read.

Common mistakes

The design uses a staff role as the only access rule.

The service replaces signed records and loses the original clinical facts.

The service sends audit events after the response without a durable copy.

The service exposes documents through URLs that bypass access checks.

The design lacks a stable lab identity or assumes that arrival order defines correction order.

The design assumes that SQL statement logs identify every patient whose records a query reads.

The bar by level

Senior (L5/E5)

Defines access rules for each record type and enforces revocations. Handles concurrent edits, source identity, correction order, and audit outages. Sizes storage and indexes from the workload. Restricts privileged clinical queries so audit events have reliable patient attribution.

Staff (L6+/E6+)

Defines enforceable administrator privileges and independent evidence for database access. Covers procedure scope, grants, alternate access paths, and uncertain audit outcomes. Specifies failure rules for policy checks, source updates, and audit capture. Evaluates recovery tests, retention costs, and organization isolation.