Fake Medical Record Generator

Anonymized fake patient records for health demos

Generate fake patient medical record summaries with ICD-10 diagnosis codes, medication lists, vitals, and visit history. Entirely fictional data for building and testing health software safely. Dev use only. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Is this real patient data?

Absolutely not. Every patient, diagnosis, medication, and date is randomly generated and fictional. No record corresponds to a real person, so there is no privacy or HIPAA concern in using it for development.

What this tool does

The Fake Medical Record Generator creates fully fictional patient record summaries so you can build and test electronic health record (EHR) screens, patient portals, and clinical dashboards without ever handling real protected health information. Each record includes a patient identifier, demographics, ICD-10 diagnoses, a medication list, vitals, and a recent visit date.

How it works

Each record is assembled from independent random draws. A medical record number (MRN) is generated with a numeric suffix, and demographics (name, age, sex) are chosen at random. One to three diagnoses are pulled from a curated table of real, correctly formatted ICD-10 codes and their descriptions, while one to four medications are paired with plausible doses. Vitals are sampled from realistic ranges — systolic/diastolic blood pressure, heart rate, temperature, and BMI — purely so layouts and validators have sensible values. A visit date within the last two years is emitted in ISO 8601 format.

Everything runs locally in your browser; no data is transmitted anywhere.

Why synthetic data matters for health software

Health software developers face a harder version of the fake-data problem than most. Real patient records are protected under regulations like HIPAA in the US and the Data Protection Act in the UK, meaning a development team cannot simply copy a production database into a staging environment. Even de-identified real records carry re-identification risk if the dataset is small enough. Fully synthetic records remove this risk entirely while still giving developers the right field shapes, code formats, and value ranges to build against.

What makes a health record realistic enough for development

For a medical record to be useful as test data it needs to pass a higher realism bar than, for example, a fake name or address. Specific things that matter:

  • ICD-10 code format. An ICD-10 code follows a letter-then-digits pattern like J45.909 (unspecified asthma). If your frontend renders codes, it needs to handle the dot separator and the variable digit count. The codes in this generator are drawn from real common ICD-10 values and formatted correctly.
  • Medication and dose pairing. Medications are paired with plausible dose strings like 10mg daily rather than random numbers, so display tests produce readable output.
  • Vitals in range. Blood pressure values outside a physically plausible range (for example 400/200) would crash a BMI-based risk chart or a triage-colour renderer. This tool keeps vitals within realistic bounds.
  • Visit dates. ISO 8601 format with dates within the last two years means timeline charts render without issues in either direction.

An illustrative example record

For example, a generated record might look like:

MRN: 7834291
Name: Patricia Nguyen, Age: 58, Sex: Female
Diagnoses: J45.909 (Asthma), E11.9 (Type 2 diabetes)
Medications: Metformin 500mg twice daily, Salbutamol inhaler 100mcg
Vitals: BP 134/88, HR 72 bpm, Temp 37.1°C, BMI 27.4
Last visit: 2024-11-03

This record is entirely fictional. The ICD-10 codes are real and correctly formatted, but their pairing with this patient, these medications, and these vitals is random and carries no clinical meaning.

Tips and notes

  • Use JSON output to seed a development EHR database, build Jest fixtures, or populate a Storybook component story.
  • Always label generated records as synthetic in any demo or presentation to avoid clinical misinterpretation.
  • The combinations of diagnoses, medications, and vitals are not clinically validated — never interpret them as medical advice or realistic co-morbidity profiles.
  • This data is for software development and testing only — it must never appear in any system involved in real patient care.