Imagine: a hospital is implementing a new laboratory system. A doctor orders a test, the result comes back—but not in the right medical record, but in the neighboring one. Or worse: it arrives, but without units of measurement, and a hemoglobin of 150 becomes 15. Technically everything works: HL7 messages are sent, received, logs are clean. But the error is costly—up to and including incorrect treatment. Familiar? If you've encountered something like this, you're already familiar with medical informatics and data exchange standards. And you probably know: the main pain is not that the standards are bad, but how they are prepared and applied.
Below is a breakdown of typical myths about medical data exchange standards (HL7 v2, FHIR, DICOM, IHE) and how they actually work. With numbers, examples, and consequences of errors.
Myth one: “HL7 FHIR is just JSON, any developer can master it in a week”
FHIR really does look like a regular REST API: resources Patient, Observation, Condition, MedicationRequest, endpoints like /Patient/123, JSON or XML to choose from. It seems that after a REST tutorial you can go to production. In practice, everything hinges not on syntax but on semantics and profiles.
Take the Observation resource. It has a value[x] field—the value itself (number, string, CodeableConcept, Quantity, etc.). There is code—what exactly was measured (e.g., LOINC code 718-7 for hemoglobin). There is subject—to whom it relates. And then it begins: in one institution, hemoglobin is coded with LOINC, in another with a local dictionary, in a third not coded at all, written as text “HGB”. During integration, you have to build a mapping, and it's not a couple of lines of code but a correspondence table with hundreds of entries.
And there's also the US Core IG—a profile that imposes constraints: mandatory fields, allowed codes, formats. If you're building a system for the US market, you can't do without it. But even in Russia, many projects rely on FHIR R4 as the base standard, and R5 adds new capabilities (e.g., enhanced work with subscriptions and versioning).
Typical mistake: a developer takes an example from the FHIR documentation, plugs in their data, and thinks the integration is ready. Then it turns out that in the real system the LOINC code for glucose is 2345-7, while the example had 15074-8 (a different test). Or units: mg/dL versus mmol/L. Without cross-checking dictionaries and validating against the profile, such data exchange leads to clinically significant errors. More on the topic: GDPR (EU Data Protection).
Myth two: “HL7 v2 is an outdated format, it can be ignored”
HL7 v2 has been around since the late 1980s and is still used in most hospitals worldwide. Its format is pipe-delimited strings, where each field is separated by a vertical bar and components by a caret. It looks archaic, but behind this simplicity lies flexibility: you can extend fields for your needs, use Z-segments for non-standard data.
The problem is that this flexibility turns into chaos. The same PV1 segment (patient information) can be interpreted differently in different systems. For example, the PV1-3 field (department) is filled with a code by some, a name by others, and left empty by yet others. During integration, you have to write parsers that “guess” the meaning from context.
Tip: if you work with HL7 v2, always request the interface specification (conformance profile) and test messages from the vendor. Don't rely on “standard” HL7—it doesn't exist in pure form.
Myth three: “DICOM is just images, everything is simple there”
DICOM is the standard for medical images. At first glance: a file with the.dcm extension, inside are tags with metadata and pixel data. But the devil is in the details. First, DICOM tags have a hierarchy (group, element), and not all are mandatory. Second, image transfer between systems (PACS, workstations) uses network services: C-STORE (send), C-FIND (query), C-MOVE (retrieve). Each requires configuring AE titles (Application Entity Title)—unique node identifiers. More on the topic: Medical Bill After Surgery.
A typical configuration error: wrong AE title or mismatched ports. As a result, C-STORE returns an error, and the logs show an unclear message. Or worse: the image is transferred but with lost metadata (e.g., patient information is not transmitted), and it cannot be matched to the study.
Real-world example: in one clinic, PACS was configured so that a C-FIND query returned all studies for the last year instead of the requested period. Doctors complained about slow performance, and the cause was an incorrect date filter—in DICOM, the date is stored in tag (0008,0020) in YYYYMMDD format, and if the wrong format is specified, the filter is ignored.
Myth four: “One standard is enough, the rest is superfluous”
In real medical informatics, standards work together. HL7 v2 or FHIR transmit clinical data (orders, results), DICOM—images, IHE profiles describe interaction scenarios (e.g., XDS for document sharing, PIX for patient identification, PDQ for demographic queries). Using only FHIR and ignoring IHE means missing ready-made recipes for typical tasks. More on the topic: Your Medical Bill After a Doctor's Visit.
Take XDS (Cross-Enterprise Document Sharing). It is an IHE profile that describes how to publish, find, and retrieve medical documents between institutions. It relies on EbXML and requires a document registry. If you build document exchange from scratch on pure FHIR, you'll have to work out metadata, access policies, versioning yourself—things that are already standardized in XDS. More on the topic: Medical Expense Tax Deduction.
Trade-off: IHE profiles are harder to learn, but they save months of design. FHIR is more flexible but requires more effort to agree on semantics.
How much it costs and what it depends on
Let's get to the numbers. Developing an integration between two systems (e.g., a laboratory system and a hospital information system) using HL7 v2 or FHIR usually takes 2 to 6 months depending on complexity and documentation quality. If you use ready-made IHE profiles, the timeline can be shortened, but time is needed to study them. The cost of a developer hour in Russia varies, but for an order of magnitude: an integration of medium complexity costs several million USD. Errors at the design stage (e.g., incorrect code mapping) lead to rework and additional costs.
What affects the cost:
- Number of systems — each new system adds its own requirements and formats.
- Dictionaries — if the system lacks standard codings (LOINC, SNOMED CT), you'll have to create a mapping manually.
- Regulatory requirements — for example, the need to comply with personal data protection laws adds tasks for securing channels and anonymization. More on the topic: Health Law and Patient Rights.
Important: don't skimp on testing. Experience shows that up to 70% of integration time goes into debugging and fixing discrepancies that only surface when exchanging real data.
How to learn through practice
Self-study of medical informatics runs into the lack of feedback and real data. You can read FHIR specifications, but without analyzing cases it's hard to understand how to choose between different coding options, how to build profiles, how to validate correctness.
Courses provide structure, but it's important that they are practice-oriented. For example, the course “Medical Informatics and HL7 FHIR” covers exactly such situations: how to map LOINC, how to configure DICOM connections, how to design exchange with IHE in mind. Plus, you can ask questions about your own tasks.
Alternatives: an internship in an integration project (the fastest path but requires time and such a project), participation in open-source initiatives (e.g., HAPI FHIR), building your own test bench with open servers (Orthanc, HAPI FHIR).
Who the course is for: developers, analysts, system architects who are already familiar with the basics and want to systematize their knowledge. Not for those looking for a magic pill—standards require thoughtful work.
If you're ready to dive into the topic and get tools for real projects, check out Medical Informatics and HL7 FHIR—it covers HL7 v2, FHIR, DICOM, and IHE, with a focus on practical tasks.