Architecture et flux

Architecture de la plateforme

Chaque client, du site web au logiciel d’un hôpital partenaire, parle à un seul hôte : opescare.com. Les requêtes passent un contrôle d’authentification et, pour tout ce qui est clinique, un contrôle de consentement avant d’atteindre un service.

Vue d’ensemble

Un client appelle opescare.com Le site, l'application, les systèmes partenaires et le Bridge Agent passent par l'un des trois points d'entrée : routes web, API REST ou point FHIR R4.
Authentification Les routes web utilisent une session ; l'API vérifie un JWT signé et ses périmètres.
Contrôle du consentement La lecture d'un clinicien passe le contrôle de la relation de soins avant toute réponse d'un service.
Garde d'ingestion FHIR Les écritures des partenaires passent trois contrôles : établissement issu du jeton, Health ID existant, accord actif.
Stocké et journalisé Les services lisent et écrivent dans PostgreSQL, et chaque lecture d'un dossier est inscrite au journal des accès.
Refusé Un contrôle échoué répond 401 ou 403 et rien n'est lu ni écrit.

Comment ce diagramme est vérifié 21 contrôles sur 21 réussis

L'image, les étapes, le PDF et le JSON sont générés à partir d'une seule spécification. Un test automatisé démontre le graphe et vérifie chaque référence ci-dessous dans l'application en fonctionnement.

Chaque carte a un identifiant unique
Chaque carte a un type connu
Chaque flèche relie deux cartes existantes
Un seul point de départ (personne, appareil ou partenaire)
Chaque carte est atteignable depuis le départ
Chaque carte mène à une issue (aucune impasse)
Aucun cycle sauf les boucles de nouvel essai déclarées
Chaque étape numérotée suit de vraies flèches
Les issues terminent le flux
Deux cartes ne partagent jamais une case
Chaque carte cite sa preuve
Chaque route, classe, méthode et réglage existe
Chaque icône vient du jeu Lucide
Chaque icône correspond au type de sa carte
Chaque libellé existe en anglais et en français
Chaque libellé tient dans sa carte
Aucune flèche ne traverse une carte
Deux flèches sans rapport ne se superposent jamais
Aucune étiquette de flèche ne couvre une carte ou une autre étiquette
Chaque pointe de flèche est visible
Deux cartes reliées de types différents ne partagent jamais une couleur

Carte	Preuve dans le code
Clients	`route:docs.index` `route:docs.widget` `route:docs.bridge`
Pages web	`route:login` `route:public.network.medicine-finder`
API REST	`uri:POST api/v1/connect/auth/token` `uri:GET api/mobile/consents`
Ingestion FHIR R4	`uri:POST api/fhir/R4` `uri:GET api/fhir/R4/metadata`
Authentification	`route:login.submit` `method:App\Http\Controllers\Api\V1\Connect\AuthController::introspect`
Contrôle consentement	`method:App\Support\ClinicalRelationshipGate::evaluate` `config:staff_capabilities.capabilities.clinical_chart`
Garde d’ingestion	`method:App\Services\Fhir\FhirIngestGuard::requireConsent`
Refusé	`route:docs.errors`
Services OpesCare	`class:App\Modules\PatientIdentity\Services\PatientIdentityService` `class:App\Services\WebhookService` `route:public.care-map`
PostgreSQL	`config:database.connections.pgsql`
Journal d’accès	`class:App\Models\AccessLog` `uri:GET api/mobile/access-logs`
Réponse	`route:docs.api`

Tous les flux en JSON

Les couches

Clients

Le site opescare.com, l’application mobile OpesCare, les systèmes partenaires (logiciels d’hôpital, de laboratoire et de pharmacie), le Bridge Agent et le Widget.

opescare.com

Une seule application Laravel : pages web, API REST sous /api (Connect v1 et mobile) et point d’accès FHIR R4 sous /api/fhir/R4.

Contrôles

Authentification par session et par jeton porteur avec portées, contrôle de relation clinique à chaque lecture, et garde d’ingestion FHIR à chaque écriture partenaire.

Services

Health ID et index patient maître, dossiers cliniques, les quatre recherches, documents et vérification, paiements ponctuels et webhooks.

Données

PostgreSQL conserve les dossiers ; des workers de file d’attente livrent webhooks et imports en arrière-plan ; chaque accès clinique est inscrit au journal d’accès et d’audit.

Flux clés

Tous les flux en JSON lisible par machine /docs/flows.json

Consentement et accès limité Un clinicien demande, le patient approuve dans l’application, l’accès est limité et temporaire, chaque lecture est journalisée et le patient peut révoquer. Ingestion FHIR R4 Un partenaire envoie un Bundle transaction avec un jeton porteur ; trois contrôles vérifient l’établissement, le Health ID et le consentement ; le Bundle est enregistré en entier ou pas du tout. Détection des doublons et fusion réversible Des analyses planifiées proposent des Health ID probablement en double, une personne examine chaque paire, et une fusion conserve un survivant, transforme l’autre en alias et peut être annulée. Livraison des webhooks Les événements sont mis en file, signés en HMAC-SHA256, envoyés uniquement à des adresses publiques, réessayés en cas d’échec et rejouables. Vérification du QR Health ID Un vérificateur scanne le QR Health ID du patient et opescare.com répond par l’un de quatre états ; un scan réussi est enregistré.

Règles imposées par le code

L’identité de l’établissement provient de la session authentifiée ou du jeton signé, jamais du corps de la requête, d’un en-tête ou de la chaîne de requête.
Un clinicien ne lit un dossier qu’avec un fondement : rendez-vous, équipe de soins, relation de soin, séjour dans l’établissement ou consentement actif.
Les partenaires peuvent écrire des données cliniques pour un Health ID existant dont ils ont le consentement. Ils ne peuvent jamais créer de Health ID.
La disponibilité affichée par les recherches ne provient que de stocks réels issus de systèmes sources autorisés. Un résultat vide est un résultat correct.
Aucune identité patient n’est fusionnée automatiquement. Chaque fusion est une décision humaine et peut être annulée.