#Clinical Safety Boundary Statement: EU

DIS-EU-028 v1.0.0, Last Modified On 01 August 2026, Tier: Public

This is the memorandum a European hospital's medical device or quality function asks for. "We have not looked at it" ends the conversation. A CE claim that is not true ends the company.

---

#Applicability

Regulatory qualification attaches to the software and its intended purpose, not to where it runs. The analysis below is identical in all four deployment models. What changes by model is only who physically controls the installation, which is addressed in ADD-GL-008 and ADD-GL-009.

---

#1. What this varies, and what it does not

This statement varies the global Clinical Safety Boundary Statement DIS-GL-028 for the EU and the EEA. DIS-GL-028 covers India, Australia and the United Arab Emirates and states the shared principle; this document is the European qualification and classification memorandum and it is the operative one for a Danish or Norwegian deal.

It does not change the feature boundary. What the Platform will and will not do is stated once, in DIS-GL-028 Section 7, and repeated here only where the European analysis turns on it.

---

#2. The position, in four sentences

1. The Platform is a hospital information system. It is not a medical device under Regulation (EU) 2017/745, and Edsol Edtech Pvt. Ltd. does not place a medical device on the EU market.
2. Edsol Edtech Pvt. Ltd. holds no CE marking, has appointed no notified body, has issued no EU declaration of conformity under the MDR, and has no authorised representative under Article 11. It does not represent otherwise and will not accept a contract term implying that it does.
3. The functions that would qualify a hospital operating system as a device under Rule 11 are listed in Section 4 and are not enabled in the EEA build.
4. Where a hospital or a third party builds a device-qualifying function inside the Platform, the hospital becomes the manufacturer of that function, and Section 9 states what follows.

---

#3. The frame: qualification, then classification

Two questions, asked in order. Reversing them is the most common analytical error.

3.1 Qualification: is the software a medical device at all? Article 2(1) of the MDR turns on the manufacturer's intended purpose. Software is a device where it is intended by the manufacturer for one of the listed medical purposes, including diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease.

3.2 The guidance that governs. MDCG 2019-11 on the qualification and classification of software, revised in June 2025 (Rev.1), is the operative interpretive document. Two of its statements decide Pensieve Labs's position:

• Software that only stores, archives, communicates, performs simple search, or performs lossless compression is not a medical device. Acting on data in a way that does not change its clinical meaning is not a medical purpose.
• Hospital information systems are not qualified as medical devices. The guidance says so explicitly, while noting that a hospital information system may be used together with additional modules, and that each such module must be assessed on its own.

That second sentence is the whole of Pensieve Labs's European regulatory strategy: the platform is out of scope, and the boundary is enforced at the module level.

3.3 Classification: if it is a device, what class? Only if Section 3.1 is answered yes. Rule 11 in Annex VIII governs software:

• software intended to provide information used to take decisions with diagnostic or therapeutic purposes is Class IIa;
• escalating to Class IIb where such a decision could cause serious deterioration of health or surgical intervention, and to Class III where it could cause death or an irreversible deterioration;
• software intended to monitor physiological processes is Class IIa, or Class IIb where it monitors vital parameters whose variation could result in immediate danger;
• all other software is Class I.

Rule 11 is not a mild rule. For a hospital operating system, crossing the qualification line almost always lands in Class IIa or above, which means a notified body, a quality management system to ISO 13485, clinical evaluation, and post-market surveillance. That is a programme measured in years and hundreds of thousands of euro, not a certification to be bought before a tender.

---

#4. Rule 11 trigger list: the functions that are not in the EEA build

This is the operative list. MSA-EU-001 clause 9.3 makes it contractual.

Items 8 to 16 are not disabled by configuration. They are not built into the EEA release, cannot be enabled by a hospital administrator, and are not supplied under MSA-EU-001. A statement that a device-qualifying feature is merely "switched off" is worth nothing to a competent authority.

---

#5. The module argument, and why Pensieve Labs does not currently need it

MDCG 2019-11 Rev.1 strengthened the treatment of modular software structures, and its Annex I now addresses the boundary between medical device software and EHR systems under the EHDS Regulation directly.

The argument the revision permits is this: where a device module is separable, it is assessed on its own, and the non-device platform around it is not dragged into the scope of the MDR. A hospital operating system can therefore carry a CE-marked module without itself becoming a device, provided the module is genuinely separable: distinct intended purpose, distinct boundary, distinct verification, distinct labelling.

Pensieve Labs does not currently rely on that argument, because it ships no device module in the EEA. It is recorded here for two reasons:

1. If Pensieve Labs ever does ship one, Section 10 states the path, and a hospital that read this document in 01 August 2026 should be able to see that the path was planned rather than improvised.
2. Where a hospital integrates a third party's CE-marked device, a scoring engine, an imaging analysis product, a physiological monitor, the Platform displays that device's output. Displaying a device's output does not make the Platform a device, provided the Platform does not alter the output, does not recompute it, and attributes it to its manufacturer. Section 7 states the display rules that keep this true.

---

#6. What the Platform does, and why each function stays inside the line

---

#7. Display rules for third-party device output

Where the Platform displays the output of a third party's CE-marked device, all of the following hold, and a hospital should verify them:

1. the output is displayed unaltered: not rounded, rescaled, re-thresholded or re-coloured to convey a different clinical meaning;
2. the output is attributed to the device and its manufacturer on the screen where it appears;
3. the Platform does not combine outputs from two devices into a derived score;
4. the Platform does not suppress an output on a rule of its own; and
5. where the device manufacturer specifies display conditions (resolution, calibration, colour profile), the Platform either meets them or displays a notice that it does not, rather than implying it does.

Rule 3 is the one that is easiest to breach by accident. A dashboard that combines two device outputs into a single indicator has created a new intended purpose and a new manufacturer.

---

#8. Language control: what Pensieve Labs may not say

Pensieve Labs does not describe the Platform, in any material, as: diagnosing, detecting, screening, predicting, recommending, prescribing, triaging, scoring, monitoring a physiological parameter, alerting a clinician to a clinical risk, supporting a clinical decision, or improving a clinical outcome. It does not use "clinical decision support", "AI-powered diagnosis", "early warning", "risk score", "smart alerts" or "reduces mortality".

The permitted register is operational: records, displays, transmits, schedules, tracks, reconciles, reports, makes retrievable. POL-GL-062 binds marketing to it, and a claim outside the register is a defect to be raised through POL-GL-059's reporting channel.

This constraint applies to sales conversations, proposals, tender responses and demonstrations, not only to published material. A regulator assessing intended purpose reads what the manufacturer says, wherever it is said.

---

#9. Customer-built content: who becomes the manufacturer

The Platform is configurable, and configurability is where a non-device platform most often becomes somebody's device. This section is deliberately blunt.

9.1 What a hospital may safely build. Forms, letters, templates, static protocol documents, operational rules keyed to non-clinical state, reports and dashboards over historical data, and workflows that route a task to a person.

9.2 What a hospital may not build without becoming a manufacturer. Any rule, calculation, alert or score that provides information used to take a decision with a diagnostic or therapeutic purpose about an identified patient. That includes a locally written dosing calculator, a locally written early-warning score, a locally written interaction check, and a locally written triage rule.

9.3 The consequence, stated once. Where the hospital or a third party acting for it builds a device-qualifying function inside the Platform, the hospital is the manufacturer of that function for the purposes of Article 2(30) of the MDR, and:

1. the hospital carries the manufacturer's obligations, subject to the in-house manufacture provisions of Article 5(5) where and to the extent they apply to a health institution;
2. Edsol Edtech Pvt. Ltd. is not the manufacturer of that function, has not verified or validated it, and makes no representation about it;
3. Edsol Edtech Pvt. Ltd.'s warranties and indemnities in MSA-EU-001 do not extend to it, and ADD-GL-005 (use case restrictions) applies; and
4. the hospital notifies Edsol Edtech Pvt. Ltd. in writing before deploying it, and the Parties record in a Change Order how regulatory responsibility, vigilance reporting and support are allocated.

9.4 Article 5(5). The in-house exemption is available to a health institution on conditions, including that the device is not transferred to another legal entity, that manufacture and use occur under an appropriate quality management system, and that the institution documents and justifies why an equivalent device on the market does not meet the need. It is a real route and several European hospitals use it. It is the hospital's route, not Pensieve Labs's, and Pensieve Labs will not advise on it.

9.5 Detection. Pensieve Labs does not monitor a hospital's configuration for device-qualifying content and cannot guarantee to detect it. Where it becomes aware of such content it raises it in writing and, if it is not remediated or covered by a Change Order, may suspend the affected function under MSA-EU-001.

---

#10. If Pensieve Labs ever crossed the line

Recorded so that a hospital can see that the boundary is a decision rather than an omission. To ship a device-qualifying module in the EEA, Edsol Edtech Pvt. Ltd. would need: a quality management system conforming to ISO 13485; a technical documentation file to Annexes II and III; a clinical evaluation to Annex XIV; a risk management file to ISO 14971; software lifecycle processes to IEC 62304; usability engineering to IEC 62366-1; a notified body conformity assessment for Class IIa or above; an EU declaration of conformity and CE marking; UDI assignment and EUDAMED registration; an authorised representative established in the Union under Article 11; a person responsible for regulatory compliance under Article 15; post-market surveillance and vigilance reporting; and, for an AI-driven module, the overlapping obligations of Regulation (EU) 2024/1689.

Realistic elapsed time from a standing start is not less than eighteen months. Pensieve Labs will not represent that it can compress that, and a hospital should treat any vendor claiming a short path with suspicion.

---

#11. Interaction with the EHDS Regulation

The EHDS Regulation and the MDR are different regimes with different triggers, and conflating them is a current source of confusion in European tenders.

A hospital operating system may be within EHDS scope and outside MDR scope at the same time, which is exactly Pensieve Labs's expected position. MDCG 2019-11 Rev.1 addresses the boundary in its Annex I. The EHDS position is stated in STM-EU-001 and is not repeated here.

---

#12. What the hospital must do

---

#13. Limitations

13.1 This is not a legal opinion. It is Edsol Edtech Pvt. Ltd.'s own reasoned position, produced without a notified body's involvement and without a competent authority's confirmation. [A hospital that needs certainty should obtain its own regulatory advice, and Pensieve Labs will supply the technical detail it needs to do so.]

13.2 The boundary is fact-specific in places. Item 9 of Section 4 in particular, the distinction between a straight unaltered lookup and an evaluation, is a line on which reasonable regulators differ. Pensieve Labs stays well clear of it rather than arguing about where exactly it falls.

13.3 Guidance can change. MDCG guidance is not law and is revised. This statement is reviewed on 31 January 2027 and immediately on any revision of MDCG 2019-11, any relevant national competent authority position, or any change to the Platform's function list.

13.4 National competent authorities. Qualification is assessed by the competent authority of the Member State or EEA State concerned. Pensieve Labs has not sought a determination from any of them and does not claim one.

---

#14. Related documents

---

#15. Change history