Medical Engineering Modeling Ontology
MEMO¶
A domain model for medical-device engineering, based on SysML v2, that keeps architecture, risk, verification, and evidence connected as the design changes.
Experimental before 1.0
Until MEMO reaches version 1.0, the ontology and its public API are
experimental. Namespaces, definitions, relationships, and imports may
change as feedback is incorporated. Use a tagged release
or an exact npm version rather than main for reproducible project work.
Project links¶
- MEMO Ontology GitHub repository
- MEMO Tools documentation · GitHub repository
- MEMO Architect documentation · GitHub repository
- MEMO product website
What is MEMO¶
MEMO is a domain model for medical-device engineering. It specializes SysML v2 with the concepts and rules needed to describe a device architecture and its assurance information in the same model.
Its architecture definitions cover operational context, scenarios, behavior, design, and realization. Its assurance definitions cover requirements, safety, cybersecurity, human factors, verification, validation, and evidence. Typed relationships connect these facts in one engineering model, and viewpoints select them for diagrams, tables, and documents.
MEMO is distributed as importable SysML v2 source for use by projects and SysML v2 modeling environments.
Problem statement¶
Medical devices can combine clinical workflows, configurable behavior, software, electronics, mechanics, interfaces, and connected services. Safety depends on how the whole system behaves in its intended and foreseeable use.
The assurance case, however, is split across teams and artifacts:
- Requirements are traced to tests, but not always to the behavior being tested.
- Hazards and controls are recorded, but controls may not be anchored to the design.
- Threats are listed, but may not be tied to the interfaces they threaten.
- Architecture is documented, but can drift from the implementation.
The artifacts are linked, but the links often stop at IDs. They do not capture the engineering meaning of the claim. When the design changes, the links still resolve even when the evidence behind them has become stale.
Solution¶
MEMO supplies a shared, architecture-backed model that assurance activities can use.
One engineering model¶
Clinical intent, behavior, architecture, requirements, risk, verification, and evidence are modeled together.
Relationship definitions¶
Relationship definitions state the engineering claim, direction, and accepted endpoint roles.
Architecture and assurance¶
Risk controls, interfaces, behavior, implementation, and evidence remain tied to the design they describe.
Rules and viewpoints¶
Completeness checks, change-impact analysis, and assurance views can be derived from the model.
The result is one version-controlled engineering model whose meaning can be reviewed and checked as the design evolves.
Introducing MEMO¶
SysML v2 provides the language substrate: packages, parts, requirements, actions, interfaces, relationships, and typed model structure. MEMO adds the medical-device semantic layer:
- Typed elements for clinical use, medical products, architecture, requirements, hazards, controls, verification, and evidence.
- Relationship definitions with direction, meaning, and declared endpoint roles.
- Closure rules that express completeness and consistency questions as model constraints.
In this model, the requirement exists because of a known hazard, the component satisfies that requirement and implements the lockout control, the control mitigates the hazard, and the verification case produces evidence. A change can therefore follow the meaning of the model instead of stopping at a list of IDs.
memo:: · open source · SysML v2 · ISO 14971 · IEC 62304 · ISO/IEC/IEEE 42010