MediReady.
REGULATORY POSITIONING

Compliance Documentation & Workflow Audit Tool

Regulatory positioning statement

MediReady is an administrative tool for compliance documentation and workflow audit

MediReady is not a clinical decision-support system, not a medical device, and not a tool for diagnosis, treatment, or patient-facing decisions. The platform is designed for administrators, quality leads, and operations managers who need to structure, document, and audit internal workflows, policies, and compliance posture.

The system processes administrative information only. It does not process medical decisions, clinical parameters, or patient records.

Defined and limited intended use

MediReady is intended for:

Compliance documentation
Policies, SOPs, risk assessments, gap analyses, standards mapping.
Workflow audits
Administrative processes, internal routines, information flows.
Internal controls and quality work
Non-clinical audit activities, administrative risks, organisational weaknesses.
Administrative reporting
Non-patient-facing summaries, internal improvement plans.

MediReady does not influence medical decisions, does not process clinical data, and does not provide recommendations on diagnosis, treatment, or care.

Regulatory classification — why MediReady is not MDSW or NMI

1. Not medical device software (MDR 2017/745)

The EU MDR applies only where software has a medical purpose — for example diagnosis, treatment, monitoring, or alleviation of disease. MediReady does not meet these criteria.

“Software for administrative purposes is not covered.”

— from the MDR administrative-purpose exclusion

MediReady is an administrative compliance tool, not a clinical system.

2. Not a national medical information system (NMI) under HSLF-FS 2022:42

NMI covers systems that:

  • process medical information of significance for an individual patient's care, or
  • provide direct access to or update authority registers.

Supporting reference:

NMI does not apply to generic software used in a care environment unless the software has been adapted for a medical purpose.

MediReady does not process medical information, does not process patient data, and does not access registries.

GDPR — data protection architecture and accountability

MediReady is built to minimise data-protection risk and to align with IMY's published supervisory priorities.

Stateless processing

Inputs are processed in memory and discarded immediately after the run. No PHI is stored. No background collection, no telemetry, no profiling.

Role allocation

The healthcare provider is the controller. MediReady is the processor. A GDPR-compliant Data Processing Agreement (DPA) is required under Article 28.

IMY supervisory logic

IMY prioritises AI use, children and young people, sensitive data, and the healthcare sector. MediReady does not process sensitive personal data, which lowers supervisory exposure.

NIS2 — applies only at certain company size

NIS2 applies where a company:

MediReady is not an EHR system and is not automatically in scope. Assessment is made by company size, not by product function.

EHDS — future interoperability requirements

EHDS is primarily directed at EHR systems and national health-data flows. MediReady is an administrative tool and is out of scope, but the regulatory development is tracked.

Recommended actions

1. Refine marketing language

Avoid terms that imply clinical function. Use: compliance documentation tool, workflow audit tool, administrative audit engine.

2. Document the classification

Maintain an internal document that records why MediReady is not MDSW and not NMI. Reference the MDR administrative-purpose exclusion and the HSLF-FS 2022:42 definitions.

3. Strengthen the data-protection architecture

Highlight the stateless design in the DPA and security documentation. Make the no-PHI-stored statement explicit.

4. Legal review before launch

Recommended for regulatory reasons. Focus areas: marketing, intended use, DPA, risk analysis.

Summary

MediReady is an administrative tool for compliance documentation and workflow audit, not a medical system. It falls outside MDR, outside NMI, and does not process PHI. GDPR is followed through stateless processing and clear role allocation. NIS2 and EHDS may become relevant depending on company size and future interoperability requirements.