Digital Medical Records — What They Must Contain for GDPR Compliance and Operational Efficiency

Does your medical practice still rely on paper files? Or do you have a digital record that is just an unstructured PDF? The problem is not paper itself: without a structured system you risk fines and wasted time. At Meteora Web, we work with doctors and healthcare professionals who had to comply with EU GDPR and local regulations (in Italy, DM 70/2020). We have seen it all: missing backups, unsigned consent forms stored in unprotected shared folders, clinical data in plain text on third-party hosting. A digital medical record is not a luxury: it is a regulatory obligation and, if done right, a productivity booster. In this didactic and operational guide we explain exactly what data it must contain, in what format, and with which safeguards. No useless theory—only what you need to be compliant and efficient.

What minimal data must a digital medical record contain?

Regulations (e.g., EU GDPR, DM 70/2020 for Italy) define a minimal set of data that every digital medical record must include. Non-negotiable. Here is the concrete list:

• Patient demographic data: name, surname, date of birth, tax ID (SSN or equivalent), gender, address, contacts (phone, email).
• Treating physician data: name, surname, professional license number, specialty, facility.
• Record opening date and last update date.
• Medical history: past conditions, allergies, surgeries, ongoing treatments.
• Clinical documentation: reports, test results, imaging (DICOM if applicable), lab results.
• Clinical diary: visits, doctor notes, prescriptions, treatment plans.
• Informed consent digitally signed (mandatory for treatments and clinical studies).
• Traceability: every access and modification must be logged with date, time, user and action.

Common mistake: entering only demographics and prescriptions, ignoring medical history and consents. This makes the record incomplete and non-compliant. We recommend starting with a structured data schema, for example a relational database with normalized tables. Here is a minimal SQL schema:

CREATE TABLE patients (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50),
    surname VARCHAR(50),
    date_of_birth DATE,
    tax_id VARCHAR(16) UNIQUE,
    email VARCHAR(100),
    phone VARCHAR(20)
);

CREATE TABLE visits (
    id INT PRIMARY KEY AUTO_INCREMENT,
    patient_id INT,
    visit_date DATETIME,
    doctor_id INT,
    history TEXT,
    diagnosis TEXT,
    FOREIGN KEY (patient_id) REFERENCES patients(id),
    FOREIGN KEY (doctor_id) REFERENCES doctors(id)
);

CREATE TABLE access_logs (
    id INT PRIMARY KEY AUTO_INCREMENT,
    patient_id INT,
    user VARCHAR(50),
    action VARCHAR(50),
    timestamp DATETIME DEFAULT CURRENT_TIMESTAMP
);

This is just an example, but it gives you the idea: each data element has its place and you can query it without searching through thousands of PDFs.

How to manage digital signature and informed consent?

Informed consent is a critical document. A checkbox on a website is not enough: it must be digitally signed by the patient (or by the person exercising parental authority) and archived immutably. Regulation requires a qualified electronic signature (QES) or, in some jurisdictions, an advanced electronic signature (AES). We have integrated remote signing services such as Aruba Sign or InfoCert for several practices, or used server-side libraries to create PAdES signatures. Typical flow:

1. The doctor uploads a custom consent form.
2. The patient receives it via email or app and signs it digitally.
3. The system verifies signature validity and archives the PDF/A with a timestamp.
4. The consent is linked to the medical record and to the specific visit/treatment.

Warning: digital signature is not optional. Without it, in case of litigation or inspection, the record has no legal value. At Meteora Web, we helped a practice transition from paper consent forms to a digital system with remote signing: consent collection time dropped by 70% and verifications became immediate.

How important are traceability and change history?

The digital medical record must be immutable in the sense that every modification does not delete the previous version but creates a new one. This is required by GDPR Article 7 (right to rectification, but with history) and by data integrity principles. In practice: every time a doctor modifies a diagnosis or adds a note, the system must save the previous version and log who did what and when. A record_versions table can handle that:

CREATE TABLE record_versions (
    id INT PRIMARY KEY AUTO_INCREMENT,
    patient_id INT,
    version INT,
    content JSON,
    created_by VARCHAR(50),
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

We often see practices using Google Drive or Dropbox to share files. Attention: those systems do not guarantee compliant change history (they do not log who deleted a file, for example) and do not offer integrated digital signing. Our advice is to use a solution built for healthcare or, if building from scratch, ensure you implement robust versioning.

What security measures are mandatory for storage?

GDPR imposes appropriate technical and organisational measures. For digital medical records, these include:

• Encryption at rest: data must be encrypted on the server (AES-256).
• Encryption in transit: HTTPS mandatory, preferably TLS 1.3.
• Daily backups with off-site storage and periodic restore tests.
• Access control: strong authentication (2FA), differentiated roles (doctor, nurse, secretary).
• Access logs and audit trail kept for at least 10 years (according to healthcare regulations).
• Documented disaster recovery plan.

Concrete example: a client had a cloud practice management system with data in plain text on a shared server. We migrated to a dedicated instance with EFS encryption, configured automatic backups to cold storage, and introduced two-factor authentication. Additional cost was negligible (about €30/month) compared to the risk of a fine or ransomware attack. Security is not a cost; it is an investment to protect your license.

How to integrate the digital medical record with prescriptions?

A digital medical record is not complete if it cannot generate e-prescriptions. Italian DM 70/2020 requires interoperability with regional and national systems. The record must be able to produce a dematerialised prescription (NRR) to be sent to the Electronic Health Record (FSE). Minimal prescription data include: active ingredient, dosage, frequency, duration, notes. These data must be extracted from the record and sent via regional APIs or services like Sistema TS. We developed for one practice a module that, starting from clinical notes, automatically generates a prescription draft, reducing errors and entry time. Here is an example JSON payload for a prescription:

{
  "patient": {
    "taxId": "RSSMRA85M10H501U",
    "name": "Mario",
    "surname": "Rossi"
  },
  "doctor": {
    "regionalCode": "12345",
    "license": "ME12345"
  },
  "prescription": {
    "date": "2026-04-10",
    "medicines": [
      {
        "atc": "C09CA01",
        "activeIngredient": "Losartan",
        "dosage": "50 mg",
        "frequency": "1 tablet daily",
        "duration": 30,
        "notes": "Take in the morning"
      }
    ]
  }
}

This JSON can be sent to a regional API or used to populate an NRR form. If your record cannot generate standard output, the doctor will have to retype data manually. We advise against solutions that do not communicate with the FSE: interoperability is the future.

What to do now

If you are planning or renewing your practice's digital medical record, here are immediate actions:

1. Check compliance with GDPR and local regulations. Ensure your solution includes all minimal data, digital signature, traceability, and encryption.
2. Migrate from paper to structured digital data. Do not scan old files as PDFs; insert them into a database with separate fields.
3. Integrate digital signing for informed consent. You can use services like Aruba Sign or InfoCert.
4. Set up documented backup and disaster recovery. Test restoration at least once a month.
5. Connect to the Electronic Health Record via regional APIs or a practice management system that already supports it.

At Meteora Web, we have helped several practices through this transition. For a broader view on practice management software including billing and privacy, read our article on gestionale per studio medico (Italian). For official GDPR guidelines, refer to the Italian Data Protection Authority. For security pipeline integration, see our article on SAST and DAST in the pipeline.