Digital platforms and AI workflows for regulated MedTech.
We plan digital platforms and AI workflows around ownership, approvals and traceability.
A MedTech product platform can carry controlled product information. The workflow behind it matters.
Most agencies learn what a claim is during acceptance testing.
A medical-device product platform may carry instructions for use, product claims, intended purpose, market-specific status and reporting routes. Treating all of that as ordinary page copy can hide who owns a statement, which version is current and who needs to approve a change.
We bring those questions into discovery: which information is controlled, who may change it, where the approved source lives and which evidence the workflow needs to retain. The answers shape the content model, permissions and implementation scope.
The same discipline applies to data and AI. Before a model or automation touches sensitive or controlled information, we map the sources, intended use, human checks and escalation route together with your responsible stakeholders.
Six places where marketing content stops being just marketing.
None of these are exotic. They appear across most digital product platforms for devices and instruments, usually without the structure that makes them safe to change.
Claims and intended purpose
Performance and clinical statements are approved wording, per product and often per market. We model them as fields with an owner, not as sentences in a rich-text block, so a change is a reviewed change.
Instructions for use and eIFU
Where instructions are provided electronically, the regulation sets rules for availability, versioning and access. We build the download, its version history and its fallback as one controlled solution, not as a PDF on a page.
Regulatory status per market
A product can be CE marked, cleared, pending or unavailable depending on the country. The content model carries status per market, and the page renders what is true for the visitor's market, including the notice when a product is not available there.
Professional-only content
Some content is intended for healthcare professionals. We build the gate, log the acknowledgement and keep the wording under the same approval as the rest.
Complaints and vigilance
A device company has to be reachable for complaints and adverse events. The route from the platform into your vigilance process is designed and tested, and it does not depend on a marketing inbox.
Consent and tracking
Analytics, session recording and marketing pixels each need a legal basis. We start from the minimum and document why each tool is there, so the answer to your data protection officer is already written.
Regulatory context belongs in the architecture conversation.
We do not certify or provide legal advice. We identify which frameworks may affect the scope, involve the responsible client stakeholders and translate their requirements into architecture, content and workflow decisions.
The device regulations
Technical documentation, labelling and instructions for use, claims, post-market surveillance and vigilance.
Claims, intended purpose, IFU and market status are modelled as controlled fields with owners. Changing one is a reviewed change with a history, not an edit.
Quality management
The processes your company runs, how they are documented, who owns them, and how changes are controlled and validated.
Roles and approvals in the platform mirror the ones in your quality system. We work as a supplier inside it, with documentation written so it can be filed.
Medical device software lifecycle
Software that is a medical device or part of one: safety classification, development process, maintenance and risk control.
Whether a digital system falls within this scope depends on its intended use and relationship to the product. We flag that boundary early so the client can make the classification and plan the right lifecycle evidence.
Risk management
Identifying, evaluating and controlling risk across the lifecycle of a device and the processes around it.
Every workflow that touches a controlled text or an automated decision carries a risk entry: what happens when it is wrong, who catches it, how fast, and the fallback.
Data protection
Personal data of patients, users, customers and employees: legal basis, purpose, transfers, processors, and impact assessments.
Data classes, purpose, processors and hosting requirements are mapped before integrations are designed. Where the client identifies the need for an impact assessment, it becomes part of the plan.
AI regulation
Obligations by risk class for providers and deployers of AI systems, including documentation, transparency and human oversight.
Each use case needs its own role, risk and obligation assessment. We make intended use, human oversight, information sources and records explicit so the responsible client team can assess it.
Information security
How an organisation manages information security: access, environments, suppliers, incidents, continuity.
Access, environments, secrets, suppliers and operating documentation are treated as architecture requirements and aligned with the client's security policies.
Computerised systems in life sciences
Validation of computerised systems in GxP environments, and electronic records and signatures where US rules apply.
Where a platform touches GxP data or records, we work with the client's validation team to define scope, specifications, test evidence, records and audit-trail requirements.
Accessibility, EN 301 549
Accessibility requirements for websites, e-commerce and digital services sold to consumers in the EU.
Accessibility is built into the component system and tested, not audited at the end. It also happens to be what search engines and screen readers both reward.
We are not a notified body, an auditor or a law firm. Where a project needs a validation plan, a data protection impact assessment or a legal opinion, we say so, name who has to produce it, and build so that their job is straightforward.
Six delivery habits for controlled information.
The exact controls depend on scope and the client's quality system. These are the habits we use to make ownership, review and handover explicit.
Approved wording lives in one place
Claims, intended purpose and product names are single fields with a single owner. Every page, language and channel reads from them. Nobody retypes an approved sentence.
Every change has a name and a time
Who changed which field, from what to what, approved by whom. Exportable when your audit asks, and readable without us.
Roles in the CMS mirror your quality system
An editor drafts, a reviewer approves, regulatory has the last word on claims. The permissions enforce it, so the process does not depend on people remembering.
Data is classified before it moves
Marketing copy, product data, service documentation and personal data are not the same class and do not go to the same places. The classification is written down before any integration or model is connected.
Environments and access are yours
Your tenant, your accounts, your keys. We hold access while we build and lose it when we hand over. On-premises where your policy requires it.
Documentation is a deliverable
Architecture, data model, integrations, permissions, runbooks. Written for the person who inherits the system, and for the person who audits it.
Your solution. Your infrastructure. Your data boundary.
Before implementation, we agree hosting, access and data flows with your IT, security and privacy teams.
Runs in your environment
Deploy in your cloud tenant, an agreed EU region or on premises where the stack supports it.
Your systems remain the source of truth
We connect the required parts of your PIM, ERP, CRM, QMS or document system.
No dependency on Veren or one model
You receive the code, configuration and documentation. Models and providers remain replaceable.
Data protection is part of the architecture
Data classes, access, retention and transfer paths are defined before implementation.
Device companies, instrument makers and a component catalogue.
Two manufacturer platforms that show our experience structuring technical product information. They support the method; they are not claims of certification or regulatory approval.
The part your quality lead will ask.
Are you ISO 13485 or ISO 27001 certified?
No. We are a software partner, not a manufacturer or a hosting provider, and we work inside your quality system as a supplier. We complete supplier questionnaires, work under quality agreements, and are open to a supplier audit. The frameworks on this page are what we design against, not certificates we hold.
Can you support the validation of what you build?
Where validation is required, we can plan the specifications, traceability and test evidence with your validation team and include that work in the delivery scope. The required form and final approval remain with your responsible organization.
Where is our data hosted, and can it stay on premises?
Hosting and deployment are architecture decisions made against your data classes, security policy and operating model. Options can include an EU region, your tenant or on-premises infrastructure where the selected technology and scope support it.
Who approves regulatory content on the product platform?
Your regulatory lead, as today. We do not take that role. We build the route so that a claim cannot be published without their approval, and so that the approval is logged.
What about accessibility?
Where accessibility requirements apply, we translate them into component and testing criteria early. The applicable legal scope should be confirmed by your responsible team; our role is to make the resulting requirements concrete in the build.
Who owns the audit trail after handover?
Ownership, retention and export requirements are defined during architecture. Our preferred pattern is that operational records live in systems and accounts controlled by the client, with handover documented.
Does all of this slow the project down?
It adds explicit decisions to discovery, but that is the point: ownership, approval and evidence requirements affect scope. Resolving them early gives the team a more dependable estimate and reduces late rework.
Bring your quality lead to the first call.
We would rather answer their questions before the project than during acceptance. Tell us what you are building and what it has to comply with.
Find the right AI starting point.
Align the business case, governance and first implementation—without starting a large programme.