Why Medioora
A requirement changes. What else is affected?
Writing a requirement is the starting point. The harder question comes when your team needs to understand which risks, architecture decisions and tests may be affected by a change.
Medioora connects the information spread across your development project. Your change assessment can start with the relationships between items, instead of a search through files.
The information is connected. The files often are not.
Word and Excel can work well for a small, manageable project. As requirements, variants and changes increase, so does the number of relationships someone has to maintain by hand. A new document version does not tell you whether the risk assessment, architecture and test plan still match.
Document-based process
The benefit with Medioora
Requirements
Requirements sit in Word documents. Their relationships are maintained separately.
Work with requirements in context
Medioora keeps parent and derived requirements linked, so your team can follow how they relate.
Architecture and risks
Architecture and risk assessments are kept in separate documents and spreadsheets.
Use relationships to guide assessment
Links to architecture and risks give your team a starting point for assessing the possible impact of a change.
Verification and tests
Test plans and results sit in other files. Links to requirements need to be maintained manually.
Connect test results to requirements
Related tests and results show which requirement is being checked, helping your team assess a deviation in context.
Reviews and approvals
Comments and approval states are coordinated across emails and document versions.
Review information where it is maintained
Reviews, roles and approval status stay alongside the relevant information, so questions can be resolved in context.
Changes and evidence
Change impact is established by searching and discussing. The matrix is updated manually.
Understand changes and focus the assessment
Links, history and recorded project states help your team understand a change and prepare to assess related items.
Individual records become a connected development model.
A requirement is more than a text field. Its links to parent requirements, architecture, risks and verification remain accessible. Reviews, approvals and history add context. Your team decides which connected items need to be assessed again.
What this changes in your project
- Assess changes with a clear starting point
- When a requirement changes, its relationships with risks, architecture and tests guide your assessment. Your team can review related items directly, instead of rebuilding the links before every review.
- Understand what changed
- A new file does not explain a change. History, versions and comparisons between project states make differences visible, so your team can discuss the specific version behind a question.
- Review information where it is maintained
- Copying requirements into review documents, sending them out and merging comments takes time. Medioora keeps reviews and approvals alongside the information. Roles and status make review progress visible.
- Produce evidence from the working information
- Documentation maintained in parallel can drift away from the project. Export makes your development information available for technical documentation, while your team maintains the content where it works with it.
Follow the relationships when a requirement changes
Which derived requirement, risk and test need attention? The links maintained in the project provide a starting point. Your team remains responsible for the engineering assessment.
Four questions from everyday development
- A requirement changes.
- Which tests and risks should we reassess? The links show where the review can start.
- A reviewer asks a question.
- What changed, and who approved this version? History and review information provide the context for an answer.
- A test fails.
- Which requirement was this test meant to verify? The link between the test and requirement helps the team assess the deviation.
- An audit is approaching.
- Which approved version applies, and how did it get here? Versions, approvals and change history provide a basis for preparing the evidence.
Built around collaboration in medical device development
Requirements engineering, systems engineering, risk management, software development, verification and validation all work on the same product. A decision in one discipline raises questions in another. Medioora was developed with these relationships in mind.
For projects working in the context of IEC 62304, ISO 14971 or ISO 13485, Medioora supports structured information and traceable development processes. Using the tool does not establish compliance automatically or replace engineering decisions and an appropriate quality management process.
More structure for development projects: As much as needed, as simple as possible
Small and mid-sized MedTech teams often face a choice: keep synchronising documents or introduce a broad ALM environment. An enterprise system can be the right fit when its scope matches your processes. Medioora focuses the starting point on the work your development team needs to do.
- Define the scope you need
- Requirements structures from user needs to systems, software and hardware, traceability, reviews, approvals and change history provide a shared basis for development.
- Start with your process
- Your templates, roles and first requirements guide the setup. Workspace configuration, training and project startup are supported. Scope and timing depend on your data and ways of working.
- Agree on deployment and interfaces
- Cloud and on-premise deployment are available. Discuss roles, permissions and any API interfaces in the context of how your team plans to use Medioora.
Developed through medical device engineering
Medioora grew out of a recurring problem in development projects at MEDtech Ingenieur GmbH. As projects grew, keeping requirements, risks, architecture, tests and documents consistent required more and more coordination.
That need led to Medioora. Experience from practical engineering work continues to inform its development. A conversation about adopting the tool therefore also covers templates, responsibilities and the work your team does each day.
