All our technology serves one goal:Making medical data, under compliance, a genuinely governable, traceable and trainable asset. Along three main lines — medical data governance, disease-specific models and medical agents — we have built an A–H eight-layer platform architecture ourselves, and used architecture laws to fix compliance requirements in code rather than in documents.
These three are not parallel products but a technically dependent chain: governance decides whether data can be used; annotation and models decide what the data is worth; agents decide whether the data can return to clinical practice.
Governing raw records from heterogeneous hospital systems into data assets with consistent definitions, traceable lineage and controllable sensitivity — the foundation for every capability above it.
We do not build general-purpose large models. We work only on the two disease areas where we genuinely master the clinical semantics: infertility (tubal) and pelvic floor dysfunction.
Bringing model capability into clinical workflows in a way that is usable, traceable and accountable for clinicians — not just handing over a chat box.
Eight layers from the bottom up: the seven product layers A–G all depend on a single H kernel and may not implement any of its capabilities themselves. This is the single most important architectural constraint of the platform.
Layer H is the shared kernel; the seven product layers A–G receive it through KernelBridge injection, and layers are forbidden from instantiating kernel components themselves.
If compliance requirements for medical data stay at the level of policy and promises, they will be bypassed in some iteration. Our approach is to turn every red line into test cases and static checks, so that violating code cannot pass the build.
The seven product layers A–G must receive kernel instances through KernelBridge injection, and layer code may not contain new EventCenter from instantiating such kernel components.
Patient-level writes must pass, in order: identity verification → ABAC authorisation decision → PurposeToken purpose verification. If any step fails, nothing is written.
Forged tokens are blocked and leave no traceThe system provides no anonymous fallback of any kind. Requests from unregistered principals are always rejected, with rejection reasons recorded by category.
Covered by end-to-end test casesAll audit trails must converge into the kernel's unified EventCenter hash chain; no layer may start its own independent audit chain.
Audit chain integrity is verifiable by third partiesNot every module is worth writing ourselves. We concentrate R&D on genuine industry know-how and buy or fork generic capabilities from open source — controlling cost while focusing the team on what is hardest to replicate.
Turning clinicians' inclusion and exclusion judgements into configurable, version-frozen, reproducible machine semantics — the starting point for whether a model can be trusted.
Disease-specific mappings to ICD-10 (China clinical edition), LOINC and SNOMED CT must generate a new version on change; silently overwriting historical mappings is forbidden.
The full workflow of single-blind / double-blind / review / sampling / rework / arbitration / freeze / release: anything failing the agreement threshold is automatically escalated to arbitration, and arbitrators may not be either annotating party.
A complete evidence chain from data source through processing to authorisation scope, supporting data asset registration, capitalisation support and compliance proof for external delivery.
Model release must pass a medical approval state machine: candidate → validated → approved → deployed. Automatic retraining without approval may not go live.
Recognition and blocking of critical values, emergency and critical conditions, self-harm and harm to others, off-label use and prompt injection; personalised recommendations require human review before release.
We avoid words like industry-leading or world-class. What follows are reproducible, verifiable engineering facts — you may ask us to demonstrate any of them live during a technical discussion.
The following data is hard-blocked at the architecture level and cannot be unlocked by any workflow approval:
The worst thing a medical data platform can do is present something planned as already available. In technical discussions we always separate what is done from what is not — because it directly affects whether a partner can entrust us with a project.
We do not build foundation models. We focus on the engineering of disease-specific data semantics and clinical use cases, and on medical approval gates before and after model release.
Imaging archiving covers only data-side reception and governance and never intervenes in a hospital's main image-reading workflow — that is both a safety boundary and a boundary of responsibility.
Cryptography and e-signature capabilities are always integrated from compliant products; we only call them and log the calls, and never invent our own algorithms.
We welcome collaboration with healthcare institutions, research organisations and data exchanges in disease-specific data governance, joint model validation and new indications. Our technical team can engage directly.
