Documents Initial use case
- secure upload;
- a limited set of formats;
- recognition with verification;
- links to the source and version.
Integrations and API
Integration starts with a precise data contract.
For each data flow, we define field meanings, sources, units, access rights and error handling in advance.
The public API is not yet open. A test environment is available as part of a pilot.
01
Purpose
RequiredWho needs the data, and for which process.
02
Contract
Project-specificSchema, units, identifiers and versions.
03
Access
Project-specificRoles, consents, tenant and processing period.
04
Monitoring
Before launchErrors, retries, audit and stop criteria.
Integration options
Choose the channel according to risk and data volume
Data scope, security and operational readiness are confirmed separately for each channel.
API and events Project-specific
- REST API;
- webhooks;
- idempotent operations;
- versioned schemas.
Medical data exchange On request
- FHIR / HL7 under an agreed profile;
- SFTP;
- CSV / XML;
- mapping of terminology and units.
Data contract
BIOS accepts a verifiable fact, not just a value
A minimum contract must make clear what was transmitted, its source, when it was recorded, its units and the basis for processing it.
A stable link to the record
Association with a person or episode without silently mixing records.
Source and time
Organisation, document, device, author and precise event time.
Code, unit and range
A value is interpreted only together with its term, unit and applicable reference range.
A correction preserves the previous version
A correction creates a new version and retains its link to the previous one.
Purpose and basis for access
Data transfer is limited by the use case, role, consent and duration.
Errors remain visible
An unknown field, duplicate or conflict does not automatically become a medical fact.
Integration stages
From the first conversation to stable operation
Each stage begins only after the previous one has been checked.
Use case
Purpose, users, owners and scope.
Mapping
Sources, fields, terminology and quality.
Security
Access, transfer, storage and incident response.
Pilot
A limited data flow, test data and success criteria.
Operation
Monitoring, versions, support and a decision on scaling.
Responsibilities
Responsibilities are defined alongside the data contract
An integration is not complete until the parties know who is responsible for the source, field mapping, access and failure response.
Shared model
Integration risks are documented before launch
Medical data must retain its meaning and provenance. The recipient of the result and its review status must also be defined in advance.
Partner
Source quality, lawful transfer and notification of changes.
BIOS
Ingestion, contract validation, data provenance and controlled processing.
Clinic
Clinical rules, staff permissions and medical review.
Joint responsibility
Incidents, schema changes, stop criteria and scaling.
Technical readiness
What you can request now
Materials are provided after the use case is defined. Real medical data is not shared at the initial stage.
Integration reviewA session on sources, volume, roles and the target process.
AvailableDraft data contractFields, provenance, errors and version policy.
For a pilotTest environment and API specificationProvided after technical and legal agreement.
On requestPublic developer portalSelf-service documentation and keys are not yet available.
In preparationStart with a single data flow.
A source, a contract, security and a measurable result.