/skill

Healthcare EMR Patterns

Use these patterns to build EMR and EHR systems.

Patient safety comes first. Records must be correct, clear, secure, and easy for care staff to use.

Give Credit

These patterns were contributed by Dr. Keyur Patel of Health1 Super Speciality Hospitals.

Keep this credit when you copy or share this skill.

Use This Skill For

• Patient visit flows
• Clinical notes
• Typed, structured, and voice-based data entry
• Prescriptions and drug safety checks
• Clinical decision support
• Lab and imaging results
• Clinical audit logs
• Safe and easy forms for care staff

Core Rules

Ask this before each design choice:

Could this harm a patient?

Follow these rules:

• Never hide a drug warning.
• Mark abnormal results with text and an icon.
• Start the correct alert flow for critical vital signs.
• Keep a full audit log for every clinical data change.
• Show when data is missing, late, or not checked.
• Do not guess when a safety check fails.
• Use local laws and hospital rules for final choices.
• Test all rules with trained clinical staff.

This skill is not medical advice. It gives software design rules.

One-Page Visit Flow

Keep the main visit on one page. Use a clear top-to-bottom flow.

Fixed patient header
├── Full name and patient ID
├── Date of birth and sex
├── Allergies
├── Current drugs
└── Key warnings

Visit form
├── 1. Main problem
├── 2. History of the problem
├── 3. Past history
├── 4. Physical exam
├── 5. Vital signs and scores
├── 6. Diagnosis
├── 7. Drugs
├── 8. Lab and imaging orders
├── 9. Care plan and follow-up
└── 10. Review, sign, lock, and print

Do not hide key patient facts while the user scrolls.

Long forms may use section links. Do not split one visit across tabs if that hides data or breaks the care flow.

Keep unfinished work as a draft. Show its draft state at all times.

Clinical Templates

A template can speed up common visits. It must not replace clinical judgment.

interface ClinicalTemplate {
  id: string;
  name: string;
  chips: string[];
  requiredFields: string[];
  redFlags: string[];
  diagnosisSuggestions: string[];
  version: string;
}

Template rules:

• Show all facts added by the template.
• Let the user remove facts that do not apply.
• Do not add a diagnosis without user review.
• Show why a field is required.
• Save the template name and version in the audit log.
• Test each red flag with clinical staff.
• A red flag must open a clear safety alert.
• Do not let a red flag vanish on its own.

Free text and voice text must stay editable before signing. Mark voice text as unreviewed until the user checks it.

Drug Safety Flow

Run safety checks before a prescription can be signed.

User picks a drug
  -> Check allergies
  -> Check current drugs
  -> Check drugs added in this visit
  -> Check duplicate drugs or drug groups
  -> Check age, weight, pregnancy status, and kidney or liver data
  -> Check dose, route, rate, timing, and length
  -> Show the check result
  -> Apply the local stop or override rule
  -> Save all alerts, actions, and reasons in the audit log

Safety rules:

• A known severe risk must stop the order by default.
• Some risks may be a hard stop under local policy.
• A hard stop cannot be passed by the user.
• If local policy allows an override, require a clear reason.
• Record who used the override and when.
• A major risk must require active review.
• Never treat a failed check as a safe result.
• If safety data is missing, say what is missing.
• Do not let stale patient data pass without warning.
• Show the source date and version of the drug rules.
• Require a new check after the drug, dose, or patient data changes.

Do not use one alert level for every risk. Too many weak alerts can hide urgent ones.

Clinical Decision Support

Decision support may guide the user. It must not act as the final clinician.

For each rule, show:

• What caused the alert
• The facts used by the rule
• The level of risk
• The next safe action
• Any missing facts
• The rule name and version

If the rule system is down, show a clear failure state. Do not show “no risk found.”

Signing and Locking Visits

After a visit is signed:

• Lock the signed facts.
• Remove edit actions from the signed record.
• Allow only a linked addendum.
• Keep the first record and every addendum.
• Show all records on the patient timeline.
• Record the signer, time, reason, and changes.
• Use the server time and store the time zone.
• Never replace the first signed text with addendum text.

A signed record must stay readable even if a template or code list later changes.

If a record is signed in error, follow the local correction policy. Do not delete it without a trace.

Audit Log Rules

Each audit event should include:

interface ClinicalAuditEvent {
  eventId: string;
  patientId: string;
  recordId: string;
  action: string;
  actorId: string;
  actorRole: string;
  timestamp: string;
  reason?: string;
  before?: unknown;
  after?: unknown;
  source: string;
}

The audit log must be write-only for normal users.

Track these events:

• Create
• View, when local rules require it
• Change
• Sign
• Lock
• Addendum
• Drug alert
• Alert review
• Override
• Print
• Export
• Failed access

Do not place passwords, access tokens, or unneeded private data in the log.

Clinical Data Display

Vital Signs

Show:

• Current value and unit
• Expected range
• Time measured
• Person or device that entered it
• Change from the last value
• Text, icon, and color for risk
• Any score, such as NEWS2 or qSOFA
• What the user must do next

Check that units match before you compare values.

Do not calculate a score when required facts are missing. Name the missing facts.

Lab Results

Show:

• Result and unit
• Lab reference range
• Abnormal flag
• Change from the last result
• Collection time
• Result time
• Result state, such as pending, final, or corrected
• Expected return time for pending tests

Reference ranges may change by lab, age, sex, or test method. Use the range sent with that result.

A critical result must require review. Record who reviewed it and when.

Prescription PDF

Include:

• Patient name and ID
• Date of birth
• Allergies
• Diagnosis, when required
• Generic and brand drug names
• Dose
• Route
• Frequency
• Length
• Special notes
• Prescriber name and ID
• Signature area
• Date and time
• Page number when there is more than one page

Preview the PDF before signing. Do not cut off text, units, or warnings.

Easy and Safe Access

Use these minimum rules:

• Text contrast of at least 4.5:1
• Touch targets of at least 44 by 44 pixels
• Full keyboard use
• Clear focus marks
• Labels for all form fields
• Error text next to the field
• Text and icons with color
• No color-only warnings
• No alerts that fade away on their own
• A clear way to review each alert
• Plain words and short steps
• Zoom support without hidden controls

Do not play sound as the only alert. Busy and loud care areas may hide it.

Keep the user’s place after an error. Do not clear entered data.

Privacy and Access

• Store clinical data only on approved servers.
• Encrypt data in storage and in transit.
• Give each user only the access needed for their role.
• Lock idle sessions under local policy.
• Do not show patient data in browser logs or error reports.
• Do not put clinical data in URLs.
• Do not save clinical data in browser localStorage.
• Check access again for print, export, and bulk actions.
• Follow local privacy, health, and record laws.

Failure and Edge Cases

Plan for these cases:

• Two users edit the same draft.
• The network stops during save or sign.
• A user clicks sign twice.
• A device sends the wrong unit.
• A patient has no known weight or kidney result.
• A drug or diagnosis code is retired.
• A lab result is corrected after review.
• A patient has two records by mistake.
• The safety rule service is slow or down.
• The same allergy is entered with two names.
• The user leaves with unsaved work.
• The patient is unknown in an emergency.

Use safe defaults. Show the state clearly. Never claim a save, check, or signature worked until the server confirms it.

For two edits, do not silently replace either one. Show the conflict and let the user review it.

Patterns to Avoid

Do not:

• Store clinical data in browser localStorage.
• Hide failed drug checks.
• Use alerts that can be missed or fade away.
• Allow edits to signed records.
• Show clinical data with no audit trail.
• Use tabs that hide key visit facts.
• Use TypeScript any for clinical data.
• Trust data without a unit, time, and source.
• Auto-fill a diagnosis without review.
• Delete signed records to fix mistakes.
• Use sample data in a real patient record.
• Mark missing checks as passed.

Concrete Usage Example

Task:

Build a prescription form for a signed patient visit.

Apply this skill as follows:

1. Keep the patient name, ID, allergies, and current drugs in a fixed header.
2. Let the user search for a drug.
3. Ask for dose, unit, route, frequency, and length.
4. Check allergies, other drugs, duplicate drugs, age, weight, and kidney data.
5. If kidney data is missing, show "Kidney check not complete."
6. If a severe risk is a hard stop, block signing.
7. If policy allows an override, ask for a reason.
8. Run the checks again after any drug or dose change.
9. Show a final review screen.
10. Save the prescription on the server.
11. Sign and lock it only after the server confirms the save.
12. Record all alerts, reviews, and overrides in the audit log.
13. Create the PDF from the signed record.

Example result:

Patient: Rajesh M, ID 4521
Allergy: Penicillin
Current drug: Metformin 500 mg

New drug: Warfarin
Alert: Severe bleeding risk with aspirin
Cause: Aspirin is also active
Action: Prescription blocked by local policy
Status: Not signed
Audit event: Alert shown at 14:27 to Dr. Shah

Visit Example

Dr. Shah opens visit E-2024-0891.

The fixed header shows:
Rajesh M, age 58, male
Allergy: Penicillin
Current drug: Metformin 500 mg

Main problem:
Chest pain

Chosen facts:
Behind the breastbone
Moves to the left arm
Feels like pressure

A red flag alert opens and stays on screen.

Vital signs:
Heart rate: 110 beats per minute
Blood pressure: 90/60 mmHg
Oxygen level: 94 percent

NEWS2:
Score 8
High risk
Urgent review needed

Dr. Shah signs the visit at 14:30.
The visit is locked.

At 15:10, a lab result arrives.
Dr. Shah adds:
"Troponin result is high."

The system creates addendum E-2024-0891-A1.
Both records stay on the timeline.