Ingestion FHIR R4

Les partenaires écrivent des Observations, DiagnosticReports et Immunizations dans un dossier patient via FHIR R4. Chaque écriture passe trois contrôles, et un Bundle transaction est enregistré en entier ou pas du tout.

Le flux

Faites défiler les étapes sous le diagramme, ou survolez-en une, pour la mettre en évidence.

POST /api/fhir/R4 Bundle Un Bundle de type transaction avec un jeton porteur. Les ressources isolées vont vers /Observation, /DiagnosticReport ou /Immunization.
Vérifier JWT et portée La signature et les portées du jeton sont vérifiées ; chaque entrée exige la portée de son type de ressource.
Contrôle 1 : établissement L’établissement auteur est pris dans le jeton vérifié uniquement, jamais dans le contenu.
Contrôle 2 : Health ID existant Le patient doit correspondre exactement à un Health ID existant. Un partenaire n’en crée jamais.
Contrôle 3 : accord actif Le patient doit avoir un accord actif envers cet établissement. Pas d’accord, pas d’écriture.
Tout enregistrer, ou rien Toutes les entrées sont écrites dans une seule transaction ; tout refus annule l’ensemble.
200 transaction-response Chaque entrée indique 201 Created. Un POST de ressource isolée renvoie 201.
Refus : OperationOutcome Tout contrôle échoué renvoie un OperationOutcome FHIR et rien n’est enregistré.

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
Système partenaire	`uri:POST api/fhir/R4` `uri:GET api/fhir/R4/metadata`
Vérifier JWT et portée	`method:App\Services\Fhir\FhirIngestGuard::scopes` `method:App\Services\Fhir\FhirIngestGuard::requireScope`
Contrôle 1 : établissement	`method:App\Services\Fhir\FhirIngestGuard::facilityId`
Contrôle 2 : Health ID existant	`method:App\Services\Fhir\FhirIngestGuard::resolveSubject`
Refus : OperationOutcome	`method:App\Services\Fhir\FhirIngestGuard::recordRefusal`
200 transaction- response	`method:App\Services\Fhir\FhirIngestGuard::recordAccepted` `uri:POST api/fhir/R4/Observation`
Tout enregistrer, ou rien	`method:App\Http\Controllers\Api\Fhir\FhirIngestController::transaction` `class:App\Services\Fhir\FhirIngestService`
Contrôle 3 : accord actif	`method:App\Services\Fhir\FhirIngestGuard::requireConsent` `class:App\Models\ConsentGrant`

Tous les flux en JSON

Ce que cela garantit

L’établissement auquel une écriture est attribuée ne peut pas être usurpé via le contenu.
Les partenaires complètent un dossier pour lequel ils ont le consentement ; ils ne créent pas de patients.
Un Bundle transaction est atomique : aucune écriture partielle.

Où cela se trouve dans le code

uri:POST api/fhir/R4
uri:GET api/fhir/R4/metadata
method:App\Services\Fhir\FhirIngestGuard::scopes
method:App\Services\Fhir\FhirIngestGuard::requireScope
method:App\Services\Fhir\FhirIngestGuard::facilityId
method:App\Services\Fhir\FhirIngestGuard::resolveSubject
method:App\Services\Fhir\FhirIngestGuard::recordRefusal
method:App\Services\Fhir\FhirIngestGuard::recordAccepted
uri:POST api/fhir/R4/Observation
method:App\Http\Controllers\Api\Fhir\FhirIngestController::transaction
class:App\Services\Fhir\FhirIngestService
method:App\Services\Fhir\FhirIngestGuard::requireConsent
class:App\Models\ConsentGrant