Fragmented sources
Useful information may live across formats, systems or episodes, with different access paths.
Architecture
Build on the institution’s existing ecosystem (EAI). Make every responsibility visible.
Depending on the institution, the target architecture may use the existing interoperability engine (EAI) and interfaces such as FHIR, HL7 and APIs. Those mechanisms must be validated locally; this demo demonstrates no production compatibility.
The operational problem
Integration is an operational discipline
Interfaces, identity, terminologies, latency, authorizations and errors must be defined — not a promise of universal connectivity.
Scopes
Source systems remain the systems of record; Ariane provides a derived context layer.
What Ariane does not claim to be
A universal connector that erases local interface, mapping or identity work.
Architecture
Four layers. One status per capability.
From source system to workflow.
Each capability carries exactly one of the three statuses below.
- Illustrated in this demoBehavior illustrated here with fictional data — not evidence of a live integration.
- Target architectureIntended technical pattern; not an operational integration.
- To validate with the institutionDepends on local systems, interfaces, permissions or governance.
Institution applications
To validate with the institution
- EHRTo validate with the institution
- LISTo validate with the institution
- RIS / reportsTo validate with the institution
- PharmacyTo validate with the institution
- DocumentsTo validate with the institution
Each institution system remains the authority for its domain.
Interfaces & identity
- FHIR APIsTarget architecture
- HL7 v2/v3Target architecture
- Secured APIsTarget architecture
- Files (PDF, OCR, Word…)Target architecture
- DICOMweb / reportsTarget architecture
- Patient identity / INSTo validate with the institution
Exchange and patient identity between source applications.
Patient-context layer
- ProvenanceIllustrated in this demo
- SearchIllustrated in this demo
- AbstentionIllustrated in this demo
- NormalizationTarget architecture
- Longitudinal indexTarget architecture
- Audit eventsTarget architecture
Ariane derives a patient context from authorized sources.
Clinical workflows
- Patient viewIllustrated in this demo
- SearchIllustrated in this demo
- Preparatory documentsIllustrated in this demo
- SMART-on-FHIRTarget architecture
- Embedded widgetTarget architecture
- Source-system APITo validate with the institution
The workflows shown here are simulated.
In this demonstration, nothing is written to a source system. Source consultation is read-only by default. Any eventual export or write-back would be separate, explicitly triggered, authorization-gated and auditable — only if the institution and source application allow it.
Scoping envisaged for a deployment
Steps and responsibilities to validate with an institution.
Interfaces, identity, terminologies, latency, authorizations and error handling must be defined — and not hidden behind a promise of universal connectivity. This scoping describes a validation method with the institution; it is not evidence of a deployment already completed.
Institution and project side
- Authorize access to sources, identity and roles.
- Validate interfaces, mappings, clinical use and acceptance criteria.
- Validate hosting, security and support.
Proposed Ariane scope
- Preserve provenance in the derived context and in outputs.
- Implement agreed interfaces, search and application behavior.
- Document retained configuration, testing, monitoring and change control.
Use-case definition
Users, workflow, sources, expected outcome and exclusions.
Scope and success criteria
Technical validation
Interfaces, identity (including INS), authorizations, provenance and responsibilities.
Architecture and responsibility matrix
Controlled pilot
Configure, test failure modes, train and measure.
Pilot results and risk review
Production rollout — if pilot criteria are met
Controls, monitoring, support and possible extension.
Production acceptance package
Timeline estimated only after prerequisites are validated with the institution.
Questions to resolve before deployment
Architecture and governance
Does Ariane replace the EHR or the interoperability engine?
No. Ariane is a clinical information-access layer. Source systems remain the systems of record. The exact boundary is defined with each institution.
Is a particular EAI or EHR required?
No. Depending on the institution, the target architecture may use the existing interoperability engine (EAI) and the interfaces already available. No single EHR, EAI or standard is imposed here. Scope is validated locally.
Is the product always read-only?
Read-only by default in this demo — see the scoping stated above.
Does this demo establish FHIR, HL7 or DICOM compatibility?
No. FHIR, HL7, APIs or files are possible mechanisms — each to be validated locally. This demo establishes no production compatibility.
What happens if a source is missing or a mapping is incomplete?
Ariane does not replace local interface or mapping work. In this demo, missing information is made visible rather than filled in. The production approach is defined with the institution.
What integration timeline should be expected?
No universal timeline is announced. A schedule is estimated only after prerequisites — sources, interfaces, authorizations and use case — are validated with the institution.
What must be defined regarding security, GDPR and compliance?
With the institution: GDPR roles, localization, retention, subprocessors, data scope, hosting, access controls, logging and operational responsibilities. This demo presents neither a certification nor a declared GDPR compliance posture.
Start with an institution workflow and make the evidence visible.
Which EHR and key systems do you use? With your users and use case, we assess architecture, risks and a validation plan tailored to your institution.