In Development. A health-information application with distinct patient and practitioner journeys. The architecture prioritises reviewed knowledge, understandable language and continuity when connectivity is limited.
Product in development
Interface in development. Displayed counters are demonstration data, without verified user adoption.
01
Two audiences, separate responsibilities
The patient track centres on health education, plain-language explanations and navigation through reviewed information. The practitioner track addresses reference retrieval and structured knowledge workflows. They require separate roles, permissions and review rules. A patient-facing explanation and a professional reference are not interchangeable outputs.
02
Mobile as the primary setting
The interface brief prioritises legible text, simple navigation and modest devices. Supported operating systems and distribution routes will follow device evaluation. The corporate review does not contain a patient account, practitioner workspace or application download.
03
Language as a safety requirement
Content packages need a source language, terminology review, local comprehension checks and version ownership. Priority international and African languages must be selected with appropriate reviewers. A translated interface is insufficient if the explanation changes meaning or fails to communicate uncertainty.
04
An explicit offline boundary
Reviewed educational content and selected references are candidates for local storage. The design must show review dates, versions and synchronisation state, including what happens after an interrupted update. Remote models and live information remain network-dependent. Local access is not a claim of offline clinical intelligence.
05
AI with sources and limits
Retrieval-grounded explanations and terminology assistance are research functions. Evaluation must detect unsupported statements, missing qualifications and translation errors. Data minimisation, consent where needed, qualified content review and routes to professional help are requirements. Diagnostic and prescribing services are outside this review.
06
Release evidence
Before controlled access, the project needs reviewed sources, patient and practitioner usability tests, privacy design and explicit safety boundaries. Any clinical functionality would require its own validation and applicable regulatory assessment. No clinical outcomes or approvals are claimed.
01
Define patient and practitioner boundaries and content review responsibilities.
02
Prototype mobile journeys, language packages and offline reference access.
03
Evaluate comprehension, privacy and safety before controlled access.
Product briefs describe development work. Release access, supported features and commercial terms will be stated separately.
Active development — before any pilot
Development materials show professional interfaces, authentication, scheduling and profiles. Broader concepts do not establish working telemedicine, prescriptions, payments or medical records. No clinical validation or regulatory certification is claimed.
No pilot deployment has begun. Integrations, offline features and AI functions are not presented as end-to-end verified.
VISIONS INTERLINKED
Your project begins
with a conversation.
Tell us the need, the audience and the result you want. Initial contact carries no obligation; terms are agreed before paid work begins.