Care Pathways Parcours de soins
This illustrative guide shows how to represent care-pathway knowledge, selected constraints and supporting evidence. Adapting it requires the organisation's sources, rules and responsible reviewers. General consent enforcement and complete access tracing remain integration targets. Ce guide illustratif montre comment représenter les connaissances d’un parcours de soin, certaines contraintes et leurs preuves. Son adaptation demande les sources, les règles et les responsables de revue de l’organisation. L’application générale du consentement et la traçabilité complète des accès restent des objectifs d’intégration.
The problem Le problème
1 patient, 5 to 12 siloed systems. Electronic health records, lab systems, pharmacy, imaging, scheduling, billing — each holding a fragment of the patient's journey. None speak the same language. 1 patient, 5 à 12 systèmes cloisonnés. Dossiers médicaux électroniques, laboratoires, pharmacie, imagerie, planification, facturation — chacun détenant un fragment du parcours patient. Aucun ne parle le même langage.
Administrative re-entry, copy-paste between systems, manual reconciliation of conflicting records. Ressaisie administrative, copier-coller entre systèmes, réconciliation manuelle d'enregistrements contradictoires.
Consent information can be represented explicitly. Machine enforcement requires a working policy evaluator at each relevant access point. Les informations de consentement peuvent être représentées explicitement. Leur application par le logiciel demande un évaluateur de politiques opérationnel à chaque point d’accès concerné.
When an AI suggests a clinical decision, who authored the knowledge it relied on? Under whose authority? With what evidence? Quand une IA suggère une décision clinique, qui a rédigé le savoir sur lequel elle s'appuie ? Sous quelle autorité ? Avec quelle preuve ?
How bra0 addresses this Comment bra0 répond
| Challenge | bra0 capability | Standard | Layer |
|---|---|---|---|
| Consent policy representationReprésentation des politiques de consentement | GOV-2 · Target for enforcement. ODRL represents intended permissions and prohibitions. Availability of policy authoring does not establish query-time access control.GOV-2 · Application à l’exécution : cible. ODRL représente les permissions et interdictions prévues. Le contrôle d’accès au moment de la requête demande une intégration au-delà de la rédaction de politiques. | ODRL 2.2 |
CP |
| Clinical traceabilityTraçabilité clinique | GOV-3 — PROV-O activity logging. 13 activity types. Immutable trail: who did what, when, under whose authority, with what input.GOV-3 — Journalisation d'activités PROV-O. 13 types d'activité. Piste immuable : qui a fait quoi, quand, sous quelle autorité, avec quelle entrée. | PROV-O |
CP |
| Data quality at boundaryQualité des données à la frontière | GOV-4 — SHACL validation gates. Every data import validated against domain shapes before entering the KnowledgeSpace.GOV-4 — Portiques SHACL. Chaque import de données validé contre les shapes domaine avant d'entrer dans le KnowledgeSpace. | SHACL 1.2 |
CP |
| Vocabulary mappingMapping de vocabulaires | SL-5 — RML data mapping. Connect FHIR, OMOP, HL7, proprietary formats to a unified semantic model via TriplesMap declarations.SL-5 — Mapping RML. Connecter FHIR, OMOP, HL7, formats propriétaires à un modèle sémantique unifié via des déclarations TriplesMap. | RML |
SL |
| AI groundingAncrage IA | NS-2 — Grounding verification. Grounding Index: KG-provenance-backed triples / total. Target: >0.95 for clinical CDSS. Every AI output traces back to formal knowledge.NS-2 — Vérification d'ancrage. Indice d'ancrage : triplets avec provenance KG / total. Cible : >0.95 pour CDSS cliniques. Chaque sortie IA remonte au savoir formel. | PROV-O |
SL |
| Data sovereigntySouveraineté des données | DP-3 — Local-first persistence. All computation runs in the browser via Rust/WASM. P2P E2E encrypted sync. No patient data transits through a cloud service.DP-3 — Persistance local-first. Toute la computation s'exécute dans le navigateur via Rust/WASM. Synchronisation P2P chiffrée E2E. Aucune donnée patient ne transite par un service cloud. | CRDT |
DP |
Machine-verifiable consent Consentement vérifiable par machine
An ODRL policy can record intended permissions on an entity. The example below illustrates the representation. Query-time consent enforcement requires additional runtime evaluation and integration. Une politique ODRL peut enregistrer les permissions prévues sur une entité. L’exemple ci-dessous illustre cette représentation. L’application du consentement au moment de la requête demande une évaluation à l’exécution et une intégration supplémentaires.
To assess this policy, define and execute the relevant constraints and document the result. Answering who accessed patient data also requires an access log with declared coverage and a link to the policy in force. This guide provides no executed end-to-end consent audit. Pour évaluer cette politique, définissez et exécutez les contraintes pertinentes, puis documentez le résultat. Déterminer qui a accédé aux données d’un patient demande aussi un journal d’accès dont la couverture est déclarée et reliée à la politique en vigueur. L’audit du consentement de bout en bout reste à exécuter.
EHDS alignment Alignement EHDS
The following table is an architectural mapping for discussion. It provides no regulatory compliance assessment; applicable requirements and their satisfaction need competent review in the organisation's scope. Le tableau suivant est une correspondance architecturale destinée à la discussion. L’évaluation de conformité réglementaire demande une revue compétente des exigences applicables et de leur satisfaction dans le périmètre de l’organisation.
| EHDS | bra0 | Status |
|---|---|---|
| Patient access to health dataAccès du patient à ses données | Local-first — patient owns the data by construction (P2). Export in W3C standard formats.Local-first — le patient possède les données par construction (P2). Export en formats standards W3C. | Architecture |
| Consent managementGestion du consentement | ODRL policy representation. Runtime consent enforcement requires a verified integration.Représentation des politiques ODRL. L’application du consentement à l’exécution demande une intégration vérifiée. | GOV-2 Partial |
| Data portabilityPortabilité des données | Turtle, JSON-LD, PROV-O export. If bra0 disappears, data persists in W3C formats (P5).Export Turtle, JSON-LD, PROV-O. Si bra0 disparaît, les données persistent en formats W3C (P5). | DP-4 Exists |
| Secondary use governanceGouvernance de l'usage secondaire | ODRL policies distinguish primary vs secondary use. DCAT metadata cataloging.Politiques ODRL distinguant usage primaire et secondaire. Catalogage DCAT. | GOV-5 Partial |
| Audit trailPiste d'audit | PROV-O immutable activity logging. Every clinical decision traceable to its source knowledge.Journalisation PROV-O immuable. Chaque décision clinique traçable jusqu'à sa connaissance source. | GOV-3 Exists |
| Interoperability (HL7 FHIR)Interopérabilité (HL7 FHIR) | RML mapping engine. FHIR → RDF via TriplesMap. OMOP CDM also supported.Moteur de mapping RML. FHIR → RDF via TriplesMap. OMOP CDM également supporté. | SL-5 Exists |
The grounding guarantee La garantie d'ancrage
In healthcare, the difference between an AI suggestion grounded in verified clinical knowledge and one generated from probabilistic inference is a patient safety boundary. bra0 makes this distinction formal and measurable: En santé, la différence entre une suggestion IA ancrée dans un savoir clinique vérifié et une générée par inférence probabiliste est une frontière de sécurité patient. bra0 rend cette distinction formelle et mesurable :
Definition: number of KG-provenance-backed triples / total triples in the AI output. Définition : nombre de triplets avec provenance KG / total des triplets dans la sortie IA.
Target for clinical CDSS: > 0.95. Every triple below threshold is flagged for human review. Cible pour CDSS clinique : > 0,95. Chaque triplet en dessous du seuil est signalé pour revue humaine.
How it works: the symbolic cascade (NS-5) processes knowledge through 5 stages. Each stage records provenance (PROV-O). At the end, the grounding index is computed by counting how many output triples trace back to formal knowledge sources vs. neural extractions. Comment ça fonctionne : la cascade symbolique (NS-5) traite le savoir en 5 étapes. Chaque étape enregistre la provenance (PROV-O). À la fin, l'indice d'ancrage est calculé en comptant combien de triplets de sortie remontent à des sources de savoir formelles vs. des extractions neuronales.
Execution and data-flow boundaries must be verified for the deployed configuration. Oxigraph supplies local query processing. Peer-to-peer replication, end-to-end encryption and policy-controlled sharing are designed capabilities requiring separate integration evidence. Les limites d’exécution et de circulation des données doivent être vérifiées pour la configuration déployée. Oxigraph fournit le traitement local des requêtes. La réplication pair-à-pair, le chiffrement de bout en bout et le partage contrôlé par des politiques sont des capacités envisagées qui demandent des preuves d’intégration distinctes.
Knowledge Space — the fundamental unit of organization, and the governance boundary for patient data.
3-Layer Architecture — how governance (Control Plane), meaning (Semantic Layer), and storage (Data Plane) separate cleanly.
SHACL Shapes — the validation gates that enforce data quality at ingestion.
Capability Reference — the full capability map, including GOV-2, GOV-3, NS-2.
Knowledge Space — l'unité fondamentale d'organisation, et la frontière de gouvernance pour les données patient.
Architecture 3 couches — comment gouvernance (Control Plane), sens (Semantic Layer) et stockage (Data Plane) se séparent proprement.
SHACL Shapes — les portiques de validation qui assurent la qualité des données à l'ingestion.
40 Capacités — la carte complète des capacités, incluant GOV-2, GOV-3, NS-2.