ePI and eIFU · scan · ask · answer
Scan the pack. Ask a question. Get the answer from the approved leaflet.
AI reads your SmPC and patient leaflet, turns them into HL7 FHIR ePI for your team to approve, and puts them behind the QR code on the carton — where patients and healthcare professionals can ask in their own words and get an answer drawn only from the document you signed.
Summary of Product Characteristics
p0002-b0034.3 Contraindications
p0002-b004Carvedilol is indicated for the treatment of essential hypertension and of stable, symptomatic chronic heart failure.
p0002-b007Hypersensitivity to carvedilol or to any of the excipients listed in section 6.1. Severe hepatic impairment.
p0002-b009Bronchospastic conditions, decompensated cardiac failure requiring intravenous inotropic therapy.
contraindications
Hypersensitivity to carvedilol or to any of the excipients listed in section 6.1. Severe hepatic impairment.
ClinicalUseDefinition:contraindication
200000029897 · Contraindications
ema.europa.eu/fhir/CodeSystem/200000029659
The problem
The information is approved. Reaching the person holding the pack is the hard part.
A patient unfolds a leaflet printed in six-point type, in one language, that may be months behind the current wording. A prescriber wants one line from the SmPC and gets a forty-page PDF. Both end up guessing — or asking somewhere you do not control.
The leaflet is out of date the moment it is printed.
A safety update, a dose change, a new contraindication — the insert in a box already on the shelf can be months behind the approved wording, and nothing in the supply chain can reach it.
It cannot be searched, and it cannot be asked.
Six-point type, one language per pack, no index and no way to put a question to it. The reader who needs it most is often the least able to use it in the form it arrives.
So people ask somewhere else.
A search engine or a general assistant will answer readily, from sources you do not control and wording you never approved, with nothing to tell the reader where the answer came from.
The document you already approved is the right answer. ePIL is how it reaches the person asking, in the form they asked in.
Scan and ask
One QR code on the pack. Two audiences. Answers that name their source.
The QR code or barcode on the carton resolves to that product's approved document, at the version approved today — not the version printed with the box. From there, patients and healthcare professionals each get the view meant for them, and either can ask a question in their own words.
On the pack
Carvedilol 25 mg film-coated tablets
28 tablets · oral use
scan · leads to this leaflet, at this version
01
A QR code or barcode on the pack
Publishing generates a QR code and a GS1 DataMatrix barcode for the artwork. Scanning either one reaches that product's approved document rather than a general index, with no app to install and nothing to sign into.
The link behind the QR code is persistent and version-aware, so a pack printed last year resolves to the version approved this morning, and the barcode carries the identifiers your serialisation already uses.
The same record, two views
PatientPackage leaflet- 1. What Carvedilol is and what it is used for
- 2. What you need to know before you take it
- 3. How to take Carvedilol
- 4. Possible side effects
Healthcare professionalSummary of Product Characteristics- 4.1 Therapeutic indications
- 4.2 Posology and method of administration
- 4.3 Contraindications
- 4.4 Special warnings and precautions
02
The view meant for the reader
Patients get the leaflet as ordered sections with a contents list, at a size that reads on a handset, in every language you publish. Healthcare professionals get the SmPC, searchable by product, active substance or classification code.
Both views are drawn from the same approved record, so the two audiences never see wording that disagrees with each other, and neither sees anything your approver has not signed.
Asked in their own words
I already take a water tablet for my heart. Is it safe to take this as well?
Carvedilol is used for heart failure alongside a medicine that removes water from the body, sometimes called a water tablet or a diuretic, so the two are often prescribed together. S1 Always take carvedilol with food, and do not stop taking it suddenly without talking to your doctor first. S2
Answered from
- S11. What Carvedilol is and what it is used for
- S23. How to take Carvedilol
03
A conversation with the document
Either reader can ask in their own words — can I take this with a water tablet, what is the dose adjustment in renal impairment — and the AI assembles an answer from that document's own sections, with the sections it drew on named beside it.
The answer is built only from the approved document's text. Nothing is taken from the open web or from a model's own knowledge, and every part of the answer points back to a section the reader can open and read in full.
That is the sentence you get to take into an internal review: the answer a patient or a prescriber is given comes from the document you approved, and points back to the line it came from.
What is the starting dose in chronic heart failure?
The recommended starting dose is 3.125 mg twice daily for two weeks, increased at intervals of no less than two weeks if tolerated. S1 Doses should be taken with food to reduce the risk of orthostatic hypotension. S2
Answered from
- S14.2 Posology and method of administration
- S24.4 Special warnings and precautions for use
A worked example on a real molecule, using illustrative wording. Both answers name their sources because they are assembled from them.
The journey
How a document gets there, from arrival to the pack.
Six stages behind that code. You hand over the SmPC or leaflet you already hold, and you get back something your reviewers can sign, your systems can read and your market can accept.
- 01
Your document arrives
You upload the SmPC or leaflet you already hold, as a PDF, Word file or XML. Multi-column, scanned, illustrated — it is read as it is, with nothing retyped and no template to fill in first.
Format and malware checks run on upload, optical character recognition reads image-based scans, and the page images and the position of every word are kept so the original stays beside everything drawn from it.
- 02
We read it
A model reads it end to end. Every section, product detail and warning comes back as a structured record, and each value carries a link to the page, passage and quote it came from.
Sections are classified against the regulatory template and pharmaceutical entities are tagged, each with a confidence score, and where the source is genuinely unclear the value is marked for a reviewer rather than guessed at.
- 03
It becomes FHIR
The record is mapped to an HL7 FHIR ePI bundle — Composition, MedicinalProductDefinition, Ingredient, ClinicalUseDefinition and the rest — with coded elements bound to the terminologies a submission expects.
Candidate codes are proposed from a managed terminology service and ranked for a person to accept, rather than typed by hand, and the mapping is recomputed on every edit so what you review is never a stale document.
- 04
It is checked before anyone reads it
Structure, profile conformance, terminology binding and pharmaceutical business rules are checked automatically, and the result is a score out of a hundred with every finding graded as an error, a warning or information.
Errors block progression outright. A warning can be carried forward, but only with a recorded justification against a named person, and the score itself can be set as a gate on the workflow.
- 05
Your team reviews and signs
Medical, regulatory and quality review are separate stages with a different person accountable for each, each on a clock that escalates rather than waits. Final approval is an electronic signature.
The reviewer who made a change cannot be the only person who approves it, and signing captures the signer, the meaning of the signature, the time in UTC and a checksum of the exact version signed.
- 06
It reaches the pack
One approval publishes to the QR code and barcode on the carton, the web portal, the mobile apps and the FHIR API — every one of them carrying the version that was signed.
The QR code resolves through a permanent link that survives republication, so a pack already in circulation reaches the current approved version rather than the one printed with it.
Where the AI works
The AI does the reading. Your reviewers do the deciding.
A model turns the document you already hold into structured, coded content, and drafts the answer a reader is given. It does not approve anything, and it never publishes wording your team has not signed. Every value it produces carries a confidence score, so a reviewer can see what it was sure of and what it was not.
Reading the document
It reads the leaflet however it was produced.
Optical character recognition handles scanned and image-based pages, and the layout is recovered so multi-column text, tables and footnotes come back in the order a person would read them.
Finding the sections
It works out which passage belongs to which section.
Passages are classified against the regulatory template — indications, posology, contraindications, undesirable effects — from a fixed list rather than an open one, and each classification carries its own confidence.
Tagging what matters
It picks out the things a submission is assembled from.
Active substances, excipients, strengths, dose forms, routes of administration and therapeutic indications are tagged as pharmaceutical entities rather than left as prose a person has to re-read.
Proposing the codes
It suggests the coded term for each value, ranked, for a person to accept.
Candidates come from the terminologies the standard accepts, presented with their confidence, so your reviewer chooses between real options instead of searching a code browser — and can always reject them and search themselves.
Answering the reader
It assembles the answer a patient or prescriber gets, from that document alone.
The question is matched against the approved document's own sections and the answer is built from their text, with each part pointing back to the section it came from so the reader can open it and read it in full.
What it is not allowed to do
- Approve anything. Every stage gate is a named person holding the permission to pass it.
- Guess. A value the source does not support is flagged for a reviewer rather than filled in.
- Invent wording. What a reader sees is the text your approver signed, unchanged.
- Reach outside the document. No open web, no model's own knowledge, no other product's leaflet.
Confidence scores are stored with the values themselves, so what the model was unsure of stays visible long after review.
One data standard
Coded as FHIR, so it is not only readable — it is reusable.
Everything published is an HL7 FHIR ePI bundle. That is what lets one approved document answer a patient's question, populate a prescriber's system, satisfy a submission, and carry whatever is required next without being rebuilt.
Any system that speaks FHIR can read it.
Hospital systems, pharmacy software, prescribing tools and regulators read the approved content straight from the FHIR API, with no rekeying and no bespoke integration built per customer.
The content is coded, not merely captured.
Substances, indications, adverse reactions, dose forms and routes are bound to the terminologies the standard expects, so a value means the same thing to every system that reads it rather than being a string that happens to match.
Extension is part of the standard, not a workaround.
Market-specific fields, device identifiers and obligations that do not exist yet attach as FHIR extensions on the same resources, so a new requirement becomes a mapping change rather than a new system.
The structure is what keeps the answers honest.
Because each section is an addressable resource with its own coded identity, an answer can be assembled from named sections and cite them — rather than being generated from a document nobody can point back into.
One platform, two document families
- ePIAvailable today
Electronic product information
The SmPC and the patient information leaflet for medicinal products. Available today for the United Kingdom, with the European profile in development.
- eIFUIn development
Electronic instructions for use
The equivalent document for medical devices and combination products — insulin pens, inhalers, glucose monitors — carried on the same ingestion, review and publishing spine rather than a second system to buy and validate.
Tracks are labelled with what is available today. Nothing marked in development is offered as a current capability.
What it does
Six things your team gets on the first document you upload.
All six are running in the product today. Each one leads with what you get; the paragraph underneath is there for whoever on your side reads the small print.
Nothing has to be taken on trust
Any value your reviewer questions opens the page, the passage and the exact quote it came from, without leaving the screen they are working in.
Each value is stored with its own source references and a confidence score, and a value the source does not support is marked for a person rather than guessed at.
Separation of duties the inspector expects
Medical, regulatory and quality review are separate gates with their own permissions and their own accountable reviewer, and the person who made a change can never be the only person who approves it.
Each stage carries a target duration that escalates automatically rather than waiting on a reminder, and every assignment, comment and transition is recorded against a named person and a time in UTC.
Final approval is a signature, not a button
Signing takes two identification components and a second factor, records what the signature means, and ties it to a checksum of the exact version in front of the signer.
The platform implements the electronic-record and signature controls set out in 21 CFR Part 11 and EU Annex 11: unique identities that are never reused, authority checks, signature manifestation carrying printed name, time and meaning, and cryptographic linking so a signature cannot be moved to another record.
See the FHIR ePI mapping before you commit to it
Every value shows which FHIR ePI element it maps to and what a submission is still missing, and publication produces a fixed FHIR ePI bundle and the codes for the pack.
The mapping is built from the published implementation-guide terminology rather than typed by hand, and it is recomputed on every edit, so what you review is never a stale document.
The codes a submission needs that the leaflet never prints
Dose form, route of administration and the marketing-authorisation number are captured by your reviewer during review, from the codes the standard accepts, so none of it is discovered at submission time.
Reviewer-supplied codes are held apart from the document's own content, carry their own record of who supplied them, and close the gap they were raised against as soon as they are saved.
Built to be validated, not just demonstrated
The validation deliverables your quality team needs arrive with the platform, so they qualify a system that already carries its evidence rather than authoring that evidence from scratch.
Components are categorised on a risk basis, with the ingestion, conversion and validation engines treated as custom software and taken through the full lifecycle: requirements and design specifications, a bidirectional traceability matrix, and installation, operational and performance qualification protocols.
Traceability
Every value, traceable.
Choose a value in the record and the passages behind it light up. Choose a passage and you get the values it produced. This is the same link your reviewers follow inside the product — and the same link an answer follows when it cites a section.
page 1
page 2
page 3
page 4
Structured record
“4.1 Therapeutic indications” draws on 2 passages of the leaflet, highlighted alongside it.
A worked example on a real molecule, using illustrative wording. Your own documents behave the same way.
Validation and data integrity
Designed to be validated, and to stay validated.
The platform is built against a risk-based validation framework and implements the electronic-record and signature controls that 21 CFR Part 11 and EU Annex 11 set out. The evidence your quality team needs is part of the product, not a later project.
Every component carries a validation approach proportionate to its risk.
Infrastructure, non-configured products, configured products and custom software are categorised separately, with the ingestion, conversion and validation engines treated as custom and taken through the full lifecycle.
The Part 11 record and signature controls are implemented, and testable.
Unique identities that are never reused or reassigned, authority checks before signing, a tamper-evident audit trail, signature manifestation carrying printed name, time and meaning, and cryptographic linking of each signature to the version it signed.
The Annex 11 controls are implemented alongside them.
Risk management across the lifecycle, accuracy checks at critical data points, printouts that state whether they are draft or approved, change and configuration control, periodic evaluation, and business continuity.
Data integrity follows ALCOA+.
Every entry is attributable to an authenticated person, recorded contemporaneously against a synchronised time source, and appended rather than overwritten — regulated records are never hard-deleted, only superseded.
The validation pack ships with the platform.
User and functional requirements, the design specification, a bidirectional requirements traceability matrix, and installation, operational and performance qualification protocols are produced and maintained against every release.
Regulated records are retained for the product lifecycle plus ten years.
Source documents, generated bundles, validation results, workflow records, signatures and audit events are all held on that basis, in archival formats chosen to remain readable for the duration.
Markets
- United KingdomMHRAAvailable today
- European UnionEMAIn development
- United StatesFDAPlanned
ePIL is built to each regulator's published requirements. It is not accredited, certified or endorsed by any medicines regulator, and nothing here should be read as regulatory approval of the platform itself.
Who it's for
Six people have to agree before a document reaches a pack. Each gets their own view.
The platform enforces separation of duties rather than trusting the process to remember it. Nobody sees a queue that is not theirs, and nobody can approve their own work.
Author
Uploads the SmPC or leaflet, completes the product metadata, corrects the structured record against the source, and answers reviewer comments.
Medical reviewer
Checks clinical accuracy and scientific correctness. Can comment in place, approve the medical stage, or return the document to the author with the reason recorded.
Regulatory reviewer
Checks template adherence, section ordering, standard terms and identifiers against the requirements of the market the document is going to.
Quality reviewer
Confirms data integrity, reads the validation report, and records the disposition of any warning carried forward rather than fixed.
Approver
Applies the final electronic signature. That signature is the act that authorises publication, and it is bound to the exact version signed.
Auditor
Read-only access to every document, signature, validation record and audit event, for inspection support, with no ability to change anything.
Security
The questions your information-security review will ask first.
Eight answers you can take into that review. Each one is true of the product today; the line underneath it is for whoever on your side reads the detail.
Your data stays in the UK.
The platform runs in a London region, chosen so that UK product information is processed and stored in the UK.
Scanning a QR code does not identify the person scanning it.
No account is needed to read a document or ask a question, no personal data is collected from public readers, and access reporting is aggregated so it can never be resolved back to an individual.
Each customer's data is isolated from every other's.
Every request is bound to the organisation it came from, and the database itself refuses rows belonging to anyone else rather than trusting the application to filter them.
Your team signs in with your own identity provider.
Single sign-on is available per organisation over SAML 2.0 and OIDC, with a second factor enforced on every account, so joiners and leavers are handled where you already handle them.
Data is encrypted at rest and in transit.
AES-256 at rest and TLS 1.2 or above in transit, with all traffic to the application and the API served over HTTPS exclusively.
Every change is recorded and attributable.
Each edit, comment and stage transition is stored as its own entry against the person who made it and the moment they made it, and entries are added rather than overwritten.
Approvals are recorded immutably.
Approving a version fixes its content and stamps it with a checksum, so a later change produces a new version instead of quietly altering an approved one.
A published document can be withdrawn under audit.
Withdrawal runs as its own recorded workflow with a documented reason and downstream notification, and the withdrawn version stays in the audit history while leaving the public channels.
Get started
Put your own leaflet behind a QR code and ask it a question.
Create a workspace and upload a document, or start a conversation with us first. No sales call is required to look at the product.
Already a customer? Sign in