La transition vers FHIR

On entend partout que FHIR va remplacer HL7 v2. C'est faux, et c'est même rassurant : tout ce que tu viens d'apprendre reste valable. FHIR n'est pas un nouveau monde, c'est le même contenu médical habillé pour le web.

De messages à ressources

En v2, on envoie un message entier, une suite de segments. FHIR organise les choses autrement : en ressources. Une ressource est un objet autonome, en JSON, avec un identifiant et une adresse web. Les principales portent des noms parlants : Patient,Observation, Encounter, ServiceRequest.

Du flux au service web

Plutôt que d'attendre qu'un message arrive, un système peut demander une donnée au serveur : GET /Patient/123 pour lire un patient, ou envoyer un nouveau résultat avecPOST /Observation. C'est une API REST, exactement comme n'importe quel service web moderne. C'est ce qui rend FHIR si pratique pour les applications mobiles et l'accès patient.

Les mêmes concepts, d'un format à l'autre

Voici la clé qui rend FHIR facile quand on connaît la v2 : les concepts se correspondent. Clique sur un champ ci-dessous, puis sur le bouton FHIR de l'éditeur pour voir vers quelle ressource il pointe.

• PID (le patient) devient la ressource Patient.
• PID-5 (le nom) devient Patient.name.
• OBX (un résultat) devient une Observation.
• PV1 (la visite) devient un Encounter.

Même information, même logique. Tu n'apprends pas un nouveau langage, tu apprends une correspondance.

Pourquoi les deux coexistent

Les hôpitaux ne remplacent pas du jour au lendemain des décennies d'interfaces v2 qui tournent sans faillir. En pratique, la v2 reste la plomberie interne, et FHIR sert aux nouvelles applications, aux portails patients, aux échanges entre établissements. Les deux vont cohabiter encore longtemps, et savoir passer de l'un à l'autre est exactement la compétence recherchée.