The move to FHIR

You hear everywhere that FHIR will replace HL7 v2. It will not, and that is actually reassuring: everything you just learned still holds. FHIR is not a new world, it is the same medical content dressed for the web.

From messages to resources

In v2, you send a whole message, a sequence of segments. FHIR organizes things differently: intoresources. A resource is a self-contained object, in JSON, with an identifier and a web address. The main ones have telling names: Patient, Observation,Encounter, ServiceRequest.

From a stream to a web service

Rather than waiting for a message to arrive, a system can ask the server for data:GET /Patient/123 to read a patient, or send a new result withPOST /Observation. It is a REST API, exactly like any modern web service. That is what makes FHIR so convenient for mobile apps and patient access.

The same concepts, from one format to the other

Here is the key that makes FHIR easy once you know v2: the concepts line up. Click a field below, then the FHIR button in the editor to see which resource it points to.

• PID (the patient) becomes the Patient resource.
• PID-5 (the name) becomes Patient.name.
• OBX (a result) becomes an Observation.
• PV1 (the visit) becomes an Encounter.

Same information, same logic. You are not learning a new language, you are learning a mapping.

Why the two coexist

Hospitals do not replace decades of v2 interfaces, running without fail, overnight. In practice, v2 stays the internal plumbing, and FHIR serves new applications, patient portals, and exchange between institutions. The two will live side by side for a long time, and being able to move between them is exactly the skill in demand.