Design-partner programme. Concept and early development — not commercially available; no CE mark, FDA clearance or authorization.
medoscan.ai
Apply for early access

Clinical document intelligence API

From fragmented records to structured clinical context.

Build intake, documentation and review workflows with extraction, terminology normalization, de-identification, traceable summaries, semantic retrieval and quality checks — through one healthcare-first API.

Become a design partner Explore the API
Non-binding early access No patient data in this form EU and US pathway assessment
POST /v1/extractionsDraft API
// structured, source-linked output { "document_id": "doc_01J...", "status": "completed", "entities": [ { "type": "medication", "text": "metformin", "normalized": { "system": "ATC", "code": "A10BA02" }, "confidence": 0.97, "source": { "page": 2, "span": [418, 427] } } ] }
Document completenessExample
Required fields detected
2 items to review92%
Traceabilitysource-linked
36 entities5 pages
De-identificationhuman review
Design partners wanted
Clinics & hospital groups
EHR & workflow vendors
Healthtech platforms
CROs & research teams

One integration layer

The document layer your healthcare workflow is missing.

MedoScan AI turns PDFs, scans, notes and mixed-format records into structured, reviewable outputs that your team can use in intake, documentation, operations and research workflows.

Extract and structure

Medical NER, OCR, table extraction and normalized fields with confidence, page and source-span metadata.

NEROCRtables

De-identify with control

Detect and redact configurable identifiers, preserve source maps and route uncertain findings to human review.

PII / PHIpoliciesaudit

Normalize terminology

Map concepts to configured terminologies and return ranked candidates, context and provenance.

SNOMED CT*ICD-10LOINC*ATC

Draft documentation

Create source-grounded visit summaries, SOAP drafts, discharge drafts and patient-friendly transformations with no-new-facts controls.

SOAPsummariescitations

Search and retrieve

Semantic search, case retrieval and deduplication across permitted corpora, with filters and source snippets.

RAGsemantic searchdedupe

Check documentation quality

Flag missing sections, coding inconsistencies and post-hoc documentation mismatches without issuing patient-specific treatment decisions.

completenesscoding QAconsistency

*Terminology availability and licensing depend on the selected deployment, territory and customer permissions.

From source to system

A controlled processing pipeline, not a black box.

Every job is asynchronous, traceable and designed to expose confidence and provenance for downstream review.

Ingest

Upload a document or reference an approved object-store location. Attach tenant and workflow metadata.

Process

Run only the requested modules with configurable locales, schemas, redaction policies and output constraints.

Review

Inspect confidence, source spans and exceptions. Route uncertain or sensitive outputs to your review queue.

Integrate

Receive webhooks, fetch artifacts and write structured outputs into your EHR, data platform or research workflow.

Regulatory scope by design

One platform. Separate claims, modules and pathways.

The initial design-partner programme is focused on document infrastructure and administrative support. Patient-specific decision support is a separate roadmap track and is not available for clinical use.

Important: the labels below are an initial regulatory-screening view, not a binding classification opinion. Qualification depends on the precise intended purpose, users, inputs, outputs, workflow and foreseeable harm.

Early-access infrastructure track

Designed around extraction, documentation and operational workflows.

⌄
Medical NER and field extractionPure extraction/representation only; no patient-specific clinical recommendation.
Infrastructure
OCR and table extractionCapture, parsing and structure preservation.
Infrastructure
Terminology normalizationRanked mappings and provenance; configured for non-decisional use in this track.
Context-dependent
De-identificationPrivacy/security function; GDPR/HIPAA analysis remains separate.
Infrastructure
Administrative document classificationRouting by document type, source or workflow category.
Administrative
Documentation compliance checkingPost-hoc audit against configured documentation requirements, not patient treatment selection.
Context-dependent
Visit and history summariesSource-grounded administrative draft for professional review.
Context-dependent
Ambient scribing to SOAPDocumentation support only; no independent diagnostic conclusion.
Context-dependent
Draft discharge notes and referralsDraft generation from provided facts, subject to human validation.
Context-dependent
Professional-to-patient language transformationPlain-language transformation without changing clinical meaning.
Context-dependent
Informed-consent document draftingLegal/document workflow; local consent law and professional review still apply.
Separate legal review
Literature RAG without patient-specific recommendationRetrieval and synthesis with citations, separated from patient-level decision outputs.
Context-dependent
Case retrieval, deduplication and semantic searchNon-decisional retrieval in the early-access track.
Context-dependent
Completeness, coding audit and post-hoc consistencyQuality assurance; not a real-time challenge to diagnosis or therapy.
Context-dependent

Clinical decision-support roadmap

Research and regulatory pathway only — not offered for clinical use.

⌄
Clinical urgency triageTime-critical outputs can materially change regulatory treatment and risk class.
Regulated roadmap
Patient risk stratificationClassification depends on clinical context, intended user and consequence of error.
Regulated roadmap
Red flags and critical valuesPotentially higher-risk when an output triggers urgent action or uses device/IVD signals.
Regulated roadmap
Differential-diagnosis suggestionsRequires a defined intended purpose, clinical evidence and jurisdiction-specific pathway.
Regulated roadmap
Drug interactions and contraindicationsRegulatory status depends on whether the logic is transparent/reference-based and on the use context.
Regulated roadmap
Patient-specific test suggestionsA recommendation affecting diagnosis or management requires dedicated assessment.
Regulated roadmap
Deterioration detection from longitudinal recordsUrgency, physiological inputs and intervention consequence drive classification.
Regulated roadmap
Adherence monitoring with therapeutic triggersBasic reporting and treatment-triggering versions are treated as separate modules.
Regulated roadmap
Patient-specific follow-up planningPure logistics is separated from clinically determined intervals or escalation.
Regulated roadmap
Real-time diagnosis-versus-symptom challengeDistinct from post-hoc documentation QA and assessed as patient-level decision support.
Regulated roadmap

Current regulatory watch

What the programme tracks as of July 2026.

⌄
EU MDR / Rule 11Current law remains the baseline; the December 2025 software-classification revision is a proposal and is not used as an achieved status.
Monitoring
FDA CDS guidance — January 2026Each function is screened against all four statutory non-device CDS criteria, including input type, intended user, time criticality and independent review.
Monitoring
EU AI Act / medical-device AIHigh-risk treatment is assessed only when the Article 6(1) conditions are met; implementation dates and the 2026 Digital Omnibus text are tracked separately from current MDR status.
Monitoring
Public early-access scope: the endpoints below do not expose urgency triage, diagnosis, treatment recommendations, critical-value alerts or deterioration alarms.
POST/v1/documents

Create a document resource

Upload a file using multipart/form-data or register a pre-authorized object URL. Returns a document and ingestion job identifier.

Idempotency-Key
Required UUID; the same key and payload return the original operation.
file | source_url
Exactly one source. Proposed formats: PDF, JPEG, PNG, DOCX and UTF-8 text.
metadata
Tenant-safe business metadata; do not use free text for secrets.
curl -X POST 'https://sandbox.api.medoscan.ai/v1/documents' \
  -H 'Authorization: Bearer <token>' \
  -H 'Idempotency-Key: 2f8e0fb1-7252-4aba-9bc8-56e3139b78f8' \
  -F 'file=@record.pdf;type=application/pdf' \
  -F 'metadata={"external_id":"case-1048","locale":"en-GB"};type=application/json'

HTTP/1.1 202 Accepted
{
  "document_id": "doc_01JZ6YH9N5V6WWN7E4A84B9K1J",
  "job_id": "job_01JZ6YH9Q21H9M4P8VDZ8FQ6X2",
  "status": "queued",
  "created_at": "2026-07-13T09:41:22Z"
}
POST/v1/extractions

Run structured extraction

Request only the required extraction tasks and a versioned target schema. Results include confidence and source provenance.

document_id
Previously ingested document.
tasks[]
medical_ner, tables, sections, document_classification
output_schema
Customer or MedoScan schema identifier and version.
provenance
Set to true to require page, bounding box and text-span links.
{
  "document_id": "doc_01JZ6YH9N5V6WWN7E4A84B9K1J",
  "tasks": ["medical_ner", "tables", "sections"],
  "locale": "en-GB",
  "output_schema": {"id": "clinical-record", "version": "2026-07"},
  "provenance": true,
  "confidence_threshold": 0.72
}
POST/v1/deidentifications

Create a de-identified derivative

Apply a named policy, select entity classes and choose redaction or consistent pseudonymization. Original and derivative permissions remain separate.

policy_id
Versioned policy agreed for the tenant and purpose.
strategy
redact, mask or pseudonymize
reversible
Defaults to false; reversible mapping requires a separately controlled vault.
review_threshold
Entities below threshold are returned in a review queue.
POST/v1/terminology/normalize

Normalize extracted concepts

Return ranked mappings instead of silently replacing source text. Every candidate carries terminology, version, confidence and context.

mentions[]
Text, entity type, negation, temporality and optional source location.
systems[]
Configured terminologies permitted for the tenant and territory.
top_k
One to ten ranked candidates per mention.
POST/v1/summaries

Generate a source-grounded draft

Produce a configured administrative or documentation draft with citations. The API can reject unsupported statements when no_new_facts is enabled.

summary_type
clinical_history, visit_note, soap_draft, discharge_draft, patient_plain_language
constraints
no_new_facts, maximum length, language and required sections.
citations
Returns source references for each material statement where available.
{
  "document_ids": ["doc_01JZ6YH9N5V6WWN7E4A84B9K1J"],
  "summary_type": "soap_draft",
  "language": "en",
  "constraints": {
    "no_new_facts": true,
    "required_sections": ["subjective", "objective", "assessment", "plan"],
    "max_words": 650
  },
  "citations": true,
  "human_review_required": true
}
POST/v1/quality/completeness

Check completeness and post-hoc consistency

Evaluate records against a versioned documentation template. A separate /v1/quality/consistency operation is limited to post-hoc documentation QA in the early-access track.

template_id
Versioned checklist or documentation policy.
mode
informational or workflow_gate; never a clinical alarm in this scope.
explain
Returns rule identifiers and source evidence for each finding.
GET/v1/jobs/{job_id}

Retrieve job status and artifacts

Poll only when webhooks are unavailable. Terminal states are completed, completed_with_review, failed and cancelled.

result.artifacts[]
Typed artifact references with content hash, schema version and expiry.
review_items[]
Low-confidence or policy-triggered items requiring customer review.
error
RFC 9457-style problem object with stable machine code and correlation ID.
01Tenant and regional boundaryScoped credentials, regional processing profile and customer-specific retention.
02Data and key controlsEncryption in transit and at rest, managed secrets and least-privilege service access.
03Traceable operationsCorrelation IDs, immutable audit events, schema and model-version records.
04Human review controlsConfigurable thresholds, exception queues and output approval workflows.

Security without inflated claims

Built around healthcare-grade control objectives.

Security architecture, data-processing terms and deployment boundaries are agreed before any pilot uses production or patient data. This page does not claim certifications that have not been completed.

Data minimization and purpose-limited processing by module.
DPA/BAA and subprocessor review before controlled data exchange.
No customer data used for general model training unless separately and explicitly agreed.
No third-party marketing trackers in this build.

Design-partner programme

Validate the workflow before committing to a rollout.

Tell us where document friction is slowing your team down. We will map the use case, identify the regulatory boundary and define a measurable, non-binding pilot hypothesis.

1

Workflow discovery

Inputs, users, current process, volumes, pain points and target metrics.

2

Scope and boundary review

Administrative versus patient-specific purpose, data roles, security and integration.

3

Non-binding LOI or pilot outline

Success criteria and dependencies without an order, reservation or promise of availability.

Request a design-partner conversation

Business contact details only. We normally respond by email to arrange a short scoping call.

Do not enter patient or health data. Use synthetic or fully de-identified examples only after a separate onboarding process.

This static build sends the completed request through your email client. Before production launch, connect a controlled first-party endpoint and publish the final controller-specific privacy notice.

FAQ

Clear answers before a pilot.

The programme is structured to validate demand and workflow fit without implying product availability or regulatory status.

Can we buy or deploy MedoScan AI now?+
No. This page invites non-binding design-partner discussions. Availability, scope, commercial terms and readiness are not promised. Any pilot requires a separate written agreement and readiness review.
Does the platform have CE marking or FDA status?+
No such status is claimed. The early-access scope is framed around document infrastructure and administrative support. Any patient-specific clinical decision module would follow a separately defined regulatory strategy before clinical use.
Can we send real patient records during discovery?+
No. Initial discovery uses workflow descriptions, synthetic examples or appropriately de-identified material. Production or patient data is accepted only after legal, security and data-processing controls are agreed.
Is a letter of intent binding?+
The proposed market-validation LOI is expressly non-binding except for any clauses that are deliberately identified as binding, such as confidentiality or governing law. It does not create an order or guarantee a product launch.
How do you separate infrastructure from regulated clinical functions?+
By defining module-level intended purposes, users, inputs, outputs, claims and access controls. Clinical roadmap functions are not exposed through the public early-access endpoints shown on this page.

Bring us the workflow that still depends on manual record review.

We will turn it into a measurable design-partner hypothesis — without pretending the finished product or regulatory status already exists.

Start the conversation

Early-access privacy note

Launch requirement: insert the legal name, registered address and jurisdiction-specific controller information before public deployment. The contact point used in this draft is medoscan@mimfertility.ai.

Purpose and data

The early-access form asks for business contact details and workflow information so the team can respond to an inquiry, assess design-partner fit and, only when separately selected, send product-development updates. Do not submit patient or health data.

How this static build works

The downloadable preview does not include analytics or a form database. On submit, it opens the user's email client. A production deployment must define the controller, legal bases, retention periods, processors/subprocessors, international-transfer mechanism and rights process in a tailored notice.

Marketing choice

The optional update checkbox is separate from the request itself. A production implementation must record and honor withdrawal and suppression choices.

Regulatory status statement

MedoScan AI is presented here as a concept and early-development programme. It is not commercially available. No CE mark, notified-body certificate, FDA clearance, approval or authorization is claimed.

The described early-access API is intentionally limited to document infrastructure, administrative support and post-hoc documentation quality use cases. Whether a particular function is medical-device software depends on its exact intended purpose and deployment context; the page therefore avoids an absolute classification claim.

Clinical triage, patient risk scoring, critical-value alerts, diagnosis or treatment suggestions and deterioration detection are roadmap concepts only. They are not exposed for clinical use and would require separate evidence, quality, risk-management and regulatory work before any permitted deployment.

Reference basis

Official sources used for this draft: FDA CDS guidance (January 2026); MDCG 2019-11 Rev.1; MDCG 2025-6 / AIB 2025-1; December 2025 MDR/IVDR proposal; and final Council adoption of the 2026 Digital Omnibus on AI. Guidance is not legislation, and classification remains fact-specific.