A Theoretical Basis for Modeling the EUDAMED Domain

Entities, part II.

Purpose

This note sets out a theoretical basis for modeling the EUDAMED domain. It gives one consistent way to decide whether a thing is a real entity, an MDR concept, or a database record, and how the three connect, so that the data model rests on sound distinctions instead of the confusion that comes from treating one thing as “both a concept and a real entity”.

Background

The approach rests on three strands of existing work.

Foundational ontology for conceptual modeling. UFO (Guizzardi 2005) and its language OntoUML separate individuals from the types they instantiate, and separate rigid types (a Kind, which an entity cannot stop being) from roles an entity plays and can drop (a Role). DOLCE’s Descriptions and Situations (Masolo et al. 2004) treats a role as a concept defined by a description, kept apart from the things classified under it. BFO’s information-artifact work (Smith & Ceusters 2015) separates a record from the thing it is about. Together these give the three sorts used here, real thing, role, and record, and the principle that they must not be merged.

How a regulation creates entities. Searle (1995) distinguishes brute facts from institutional facts, which are created by rules of the form “X counts as Y in context C”, the mechanism by which a company becomes a manufacturer. Eriksson, Johannesson and Bergholtz (2018) apply this to information systems: a registry does not only describe a prior reality, it partly creates it, since an identifier the system issues is a fact made by the system.

The relation between a regulation and its system. Governatori and Sadiq (2009) define compliance as a relation between two separate specifications, the process and the norm, so the system is one side of a relation and never the norm itself. Breaux and Antón (2008) show that much of a regulation cannot be decided by software and needs human interpretation. Hildebrandt (2011) notes that a system which makes non-compliance impossible has replaced the norm rather than enforced it. MDR Article 33 is consistent with this: it gives Eudamed the role of enabling compliance and supporting the authorities, not enforcing the regulation.

The core idea

Take “manufacturer”. It shows up in three different places, and they are not the same thing:

• In reality: ACME Ltd, a real company.
• In MDR: “Manufacturer”, a role the law defines.
• In EUDAMED: an actor record with an SRN.

These are three separate things: a company, a legal role, and a database record. Treating them as one thing is what causes confusion in the model. Modeling them means describing how the three connect.

Each of the three lives in its own domain, and “exists” means something different in each:

This split follows UFO (Unified Foundational Ontology, Guizzardi 2005), a general theory of what kinds of things exist, built to give conceptual models a rigorous basis. In its terms a real thing is a Substantial (an entity that exists on its own and carries identity) and an MDR role is a Role it plays; this note keeps the plain words “real thing” and “role”.

How the three connect

Three plain relations link them:

• A real thing plays an MDR role. ACME is a manufacturer; a hospital is an investigation site. The role comes from MDR; the company or hospital was there already.
• A EUDAMED record is about a real thing. The SRN record is about ACME. The record is not the company, and it has its own life (created, changed, closed) that the company does not share.
• A EUDAMED record follows an MDR role. The actor form turns the “Manufacturer” role into fields and constraints.

Role is not representation

Two of these are often both called “representation”. They are different:

• A role is played by a thing. The hospital is the investigation site.
• A representation stands for another thing. The record points at the hospital.

“Investigation site” is a role. “Actor record” is a representation. Keep the words apart.

Do you always need all three

A model is correct for its purpose, not in the absolute. So a smaller model can be fine:

• If you only model reality, you list companies, hospitals, devices, and leave out the MDR role names. Correct, if reality is what you want.
• If you only model roles, you list manufacturer, importer, site, and leave out the companies. Correct too, but keep the link that gives each role meaning: a site is always a site of an investigation.

You need all three in one model the moment a statement crosses domains. “This record is about that hospital” needs both the record and the hospital in the same model, or you cannot say it. EUDAMED’s real questions all cross domains: does this record match a real company, does it follow the right role, can we trace it. So EUDAMED needs one model.

One model is not one diagram. You can keep a separate view per domain, as long as the same company keeps the same identity across the views. Same identity, separate views: fine. Separate models that never meet: the links cannot be drawn.

Whether the real thing is in the model

For the EUDAMED forms, fields, roles and states you do not need the real thing as a separate entity, and EUDAMED is built this way on purpose. Its unit is the Actor, which is a role, identified by an SRN. The real company appears only as attributes of the actor record (name, address), not as a separate entity that ties a firm’s several roles together. This is a design choice, not a defect: EUDAMED is not a company register, and the authoritative identity of a legal entity lives in national registers, which EUDAMED points at rather than owns.

The choice has a cost. Some questions cross actor boundaries, and EUDAMED cannot answer them from inside:

• Same company, several roles. Manufacturer and importer as one firm are two actors with two SRNs, not linked.
• Duplicates. One firm registered twice is two actors; calling it a duplicate means matching name and address, not reading a shared company entity.
• Counting. “How many manufacturers” counts actors, not firms, and the two differ.

So this is a scoping decision set by purpose. For per-role tracking the actor-as-unit design is right, and the real company can stay outside, referenced by external identity. For cross-role identity (“everything firm ACME does”) you would add the real company as a shared entity the roles attach to. EUDAMED took the first path deliberately.

First-class entity, attribute, or absent

What gets to be a first-class entity in EUDAMED (its own record and identifier) is a design decision, not a reading-off of MDR. EUDAMED has many such entities, Actor, Device, CI/PS, Notified Body, Certificate and more. But not everything in MDR becomes one: some things are attributes of another entity, and some are not held at all. The borderline cases are worth naming:

• Real company. Present only as attributes of the Actor record (name, address), not a first-class shared entity (see above).
• Investigation site. Present only as an attribute of the CI/PS record, not a first-class actor with its own identifier.
• Distributor. Absent. A regulated role (economic operator, Art. 2(35)) with no SRN, so no EUDAMED presence at all (Art. 31).
• SRN. The reverse case: first-class in EUDAMED, required by MDR (Art. 31), but nothing in reality. EUDAMED creates the fact instead of recording it.

The point: one MDR role can land in EUDAMED as a first-class entity, as an attribute, or as nothing, and which one is a modeling decision to be made on purpose, not a fact inherited from the regulation.

An MDR role with no EUDAMED record shows EUDAMED is not a copy of MDR. Site and distributor are two such cases.

Modeling guidance

1. First, decide what you are modeling and why. The subject can be the real world, the MDR roles, the EUDAMED records, or the links between them, and the purpose (understanding the regulation, building the system, operating it) sets which of the three sorts are in scope and which stay out. Make this call before anything else.
2. Keep the three distinct, even inside one record. An actor record holds a role (the actor type), a company’s attributes (name, address), and is itself a record. That is fine, as long as you keep clear which field is which and do not treat them as one thing.
3. A role is not a sub-type of the thing that plays it. Do not make Manufacturer a sub-type of company. Whether the company is its own entity or, as in EUDAMED, only attributes of the Actor, the role is still something played, not a kind of company.
4. A record is not what it points to. Draw “is about” as a link, never as sameness. Mixing them up is the main cause of registry data errors.

Example

Manufacturer / ACME Ltd:

• MDR has the role Manufacturer (Art. 2(30)).
• Reality has ACME Ltd, a manufacturer because it puts a device on the market.
• EUDAMED has an actor record + SRN, about ACME, following the Manufacturer role.

Three things, three links.

EUDAMED enables, it does not enforce

EUDAMED does not enforce the regulation. MDR itself does not claim it does: Article 33(1) says Eudamed is set up “to enable” manufacturers and other operators “to comply with their obligations” and “to enable the competent authorities … to carry out their tasks”. The system’s own legal purpose is to enable and support, not to enforce, which is also how the compliance literature frames it: compliance is a relation between the system and the norm, not the norm itself (Governatori & Sadiq 2009). In practice EUDAMED creates some facts (SRN, SIN, Basic UDI-DI), records others, limits what can be entered, and shows some breaches to an authority. Only the last is close to enforcement, and the authority does it, not the database.

Beyond EUDAMED (hypothesis)

Most information systems work in some real-world domain, and that domain is usually regulated by law. So the same three sorts should apply widely, not just to EUDAMED: a real world, the law over it, and the system’s records. A tax system has taxpayers, the tax code, and tax returns and tax IDs. A company register has firms, company law, and registration numbers. A land register has plots, property law, and title entries. In each one the identifier the system hands out (tax ID, company number, SRN) is created by the system, not found in the world, and the three sorts do not line up one to one. If this holds, the approach here is not specific to EUDAMED but a general way to model any system that serves a regulated domain.

References

• Breaux, T. D. & Antón, A. I. (2008). Analyzing Regulatory Rules for Privacy and Security Requirements. IEEE Transactions on Software Engineering, 34(1), 5-20.
• Eriksson, O., Johannesson, P. & Bergholtz, M. (2018). Institutional ontology for conceptual modeling. Journal of Information Technology, 33(2), 105-123.
• Governatori, G. & Sadiq, S. (2009). The journey to business process compliance. In Handbook of Research on Business Process Modeling (pp. 426-454). IGI Global.
• Guizzardi, G. (2005). Ontological Foundations for Structural Conceptual Models. PhD thesis, University of Twente, Enschede. Telematica Instituut Fundamental Research Series No. 015.
• Hildebrandt, M. (2011). Legal Protection by Design: Objections and Refutations. Legisprudence, 5(2), 223-248.
• Masolo, C., Vieu, L., Bottazzi, E., Catenacci, C., Ferrario, R., Gangemi, A. & Guarino, N. (2004). Social Roles and their Descriptions. In Proceedings of KR 2004 (pp. 267-277). AAAI Press.
• Regulation (EU) 2017/745 (Medical Device Regulation), Article 33. OJ L 117, 5.5.2017.
• Searle, J. R. (1995). The Construction of Social Reality. The Free Press, New York.
• Smith, B. & Ceusters, W. (2015). Aboutness: Towards Foundations for the Information Artifact Ontology. In Proceedings of ICBO 2015, CEUR-WS Vol. 1515, 1-5.