Integration & data exchange

A consistent integration pattern prevents repeated one-off solutions and makes errors reliably actionable.

Versioned REST, FHIR and event contracts document purpose, schema, permitted operations, error codes, versioning and deprecation, paging or cursors and permission context. External clients do not receive direct database access.

For each partner, the source and target systems, issuer namespace, external IDs, profile and mapping revision, delivery semantics, ordering and idempotency strategy are registered; external IDs are not used as internal primary keys.

Incoming data is checked for schema, size and permissions and transferred to a traceable inbox; domain processing uses authorised commands with provenance instead of direct table-writing permissions.

Technical delivery, professional acceptance, rejection and unknown outcome are separate. Retries and backoff, duplicates, late messages, dead letters and manual resumption are bounded and auditable.

Connector status shows configured, tested, professionally accepted, active or disrupted; an unconnected partner never appears as successfully synchronised.

Responsibility

Integration administrators configure narrowly scoped service accounts, professional leads decide on domain-related rejections, and operators see technical metadata without blanket payload access.

Automation & AI

Classify technical errors and retry under rules. AI may explain authorised error messages or produce mapping drafts; profile approval and uncertain assignments remain human-confirmed. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Connect medical communication, document exchange, medicine data and pharmacy processes without retyping information.

Connection profiles for HIN and secure communication, EPD, medicine data, pharmacy and relevant professional identifiers are defined separately. Counterparties actually commissioned have specific contracts, test cases, operational contacts and acceptance.

Each profile must define transport and authentication, required standards, permissions and consents or another valid approval basis, namespaces, document and message types, acknowledgements and fault procedures; the unverified assumption ‘EPD = any FHIR’ is not accepted.

Medication, interaction and master data require permitted use, a version, currency checks and clinical approval of the intended purpose. A language model does not replace a licensed or qualified medication source.

Person and provider assignment validates the issuer and context; uncertain assignment leads to a secure clarification process, never silent merging of residents.

Received prescriptions, documents and technical acknowledgements are correctly handed to M03/M12; an external message is not automatically treated as an internally approved clinical order.

Each adapter family receives an isolated subdirectory and its own fixtures within the chunk path; partner tasks assigned in parallel require explicit ownership. Independent tests must not use other parties' live patient data.

Responsibility

Narrowly authorised integration accounts, professionals for identity and order verification, and defined communication approvers. Technical configuration is not permission to publish all documents externally.

Automation & AI

Automatic assignment follows only approved unambiguous rules; AI can structure protected incoming content into drafts. Ambiguous identity, clinical acceptance and external approval remain explicitly checked. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Automate operational handovers under control and enable a genuinely usable change of provider or system.

Separate adapter profiles cover insurers and funding bodies, financial accounting and payroll; appointed partners require specific formats, period and currency rules, checksums, acknowledgements and professionally approved reference cases.

M11 supplies approved invoice and service data, M06 approved time and allowance foundations. M17 transports and checks mappings, calculates neither the general ledger nor payroll, and does not interpret technical acceptance as payment.

A portability package contains machine-readable professional objects, original documents, revisions and relationships, external ID namespaces, time, language and unit context, permission and provenance context and interpretable schema versions.

The key and decryption route, recipient identity, secure handover, retention and permitted scope are approved before export. Portability is not feigned by uselessly handing out ciphertext that cannot be decrypted; system-wide master keys are not handed out wholesale.

An export creates a consistent snapshot with a manifest, hashes and evidence of completeness. An import dry run in an isolated target environment checks integrity, relationships and permission assumptions; changing provider requires an approved cutover and delta workflow.

Partner tasks and the portability profile receive separate subdirectories and fixtures and specific owners; outstanding partner access prevents their production release without blocking the contract draft.

Responsibility

Finance and staff administration are strictly separated by payload; data protection and data owners approve the scope, recipients are authenticated personally or as a service; support receives no blanket export right.

Automation & AI

Scheduled approved handovers, reconciliation and error classification. AI explains approved mapping errors; no unauthorised field release or completion of missing financial data. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

The adapter connects the approved signing process to a genuinely qualified provider profile.

Each customer account uses an approved provider, identification and jurisdiction contract. Credentials remain securely managed; outgoing documents and hashes are linked to the exact transaction. The domain module determines signature requirements and signing authority.

Request, pending identification or consent, signature and independent validation are maintained separately. Responses are checked against the provider, process and document revision. Duplicate or manipulated responses do not trigger another contract execution.

The chosen Swiss signature profile requires evidence that actually matches it. A foreign service or test certificate does not count as a suitable production signature simply because it is available. The adapter does not create its own supposedly qualified certificates.

A timeout after a potentially successful signature is reconciled before another chargeable transaction is triggered. Fee and resource limits form part of the verified profile. An API outage leaves the approved paper or clarification route visibly open.

Documents, validation findings and provider evidence receive an exportable evidence format. Later verification should remain possible within the approved retention concept even if the provider account no longer exists.

Responsibility

Integration managers configure the provider; professional processes decide content, form and signatories.

Automation & AI

AI can explain technical errors. Certificate checks, identification and professional execution rules are not replaced by model text. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Connection & offline use

All provider calls and binding response checks take place online.

Approved documents can be passed to the postal service through a verified printing and dispatch process.

Every dispatch order binds the document revision, recipient, sender, purpose, channel and cost profile. A subsequently changed address or content revision requires a new check before dispatch. The selected Pingen organisation account clearly belongs to the institution.

Technical acceptance, printing, handover to the postal service, any available delivery evidence and undeliverability are separate states. “Handed to the postal service” confirms neither actual reading nor a signature or contract execution.

Stable sending identities and verified responses prevent uncontrolled retries. If a response is absent after possible acceptance, the task is reconciled. A second chargeable letter is not blindly ordered as a new transaction.

Dispatch evidence and returned items are assigned to the responsible document or contract case. Cost limits, external processing, permitted document types and the protected channel are part of the approved profile. A general postal adapter does not permit every transmission of health data.

Returned mail or an unclear outcome leaves an open case with responsible people. The institution can use the approved alternative route and record its evidence in the same process.

Responsibility

Professional senders approve content and recipients. The integration technically carries out approved dispatch and assigns evidence.

Automation & AI

Rules monitor statuses and returned items. AI may explain errors but cannot independently approve an additional letter or recipient. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Connection & offline use

Transmission and status reconciliation require a connection to the appointed dispatch partner.

Transport and technical checks complement the professional email identities and tickets from M12.

Incoming messages are assigned to a customer account through the checked recipient and transport context. Freely manipulable headers, domain names in text and model suggestions do not determine a tenant. Domain authentication and permitted sender profiles are checked.

Raw email and attachments are subject to size limits, quarantine and secure display. Active scripts, tracking pixels and malicious archives must not trigger data transmission or code execution. A document is assigned to its domain context only after these checks.

Outgoing mail uses the current sending permissions from M12-F and the approved recipients of the case. Transport encryption alone does not replace the channel check required for especially sensitive content. A HIN or portal error does not lead to silent unprotected dispatch.

Acceptance by a mail server, actual delivery, returned mail, cancellation and an unclear outcome are documented separately. Technical acceptance does not prove reading. Repeats and responses remain assigned to the original order.

Incoming and outgoing messages are linked to the exact message and its permitted revisions. Professional content remains in the protected process; general transport logs contain minimised technical information. The ticket in M12 shows the history needed by authorised employees.

Responsibility

Technical operations manages narrowly scoped transport profiles. Domain teams decide on content, recipients and the required secure channel.

Automation & AI

Automatic checks handle transport errors and quarantine. AI receives only already authorised content for a reviewable draft. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.

Connection & offline use

Incoming mail, dispatch and reconciliation require an online connection; a missing connection is explicitly shown.