This guide sets out 12 things to test on your own messages, from data loss to terminology, before you commit to a tool.
An HL7 v2 to FHIR converter takes the pipe-delimited messages that hospitals, laboratories and clinic systems have exchanged for decades and turns them into FHIR resources that modern applications, analytics platforms and AI tools can use. Most healthcare organisations will need one at some point, because HL7 v2 still carries the majority of clinical data in motion while almost everything being built today expects FHIR.
Many tools can perform the conversion. The question this guide helps you answer is whether the FHIR that comes out is usable, and those are different things. A converter can produce resources that pass validation and still leave you with data that cannot be compared, trended or trusted. The guide is written to be vendor neutral, and at the end we explain where JondaX fits and where a different kind of tool would serve you better.
Valid FHIR is not the same as usable FHIR
Consider a single result line from a laboratory message:
OBX|3|NM|GLU^Glucose^L||5.4|mmol/l|3.9-5.5|N|||FA structural converter will turn this into a FHIR Observation without difficulty. The resource will be valid. It will also carry the code "GLU" from a local code system that no other system recognises, a unit written in a form that is not standard, and a reference range held as a piece of text. A second laboratory will send the same test as "GLUC" or "Glucose, fasting" in mg/dL. Both Observations are valid FHIR, and an application still cannot tell that they are the same test.
Many converters finish at the third box. Whether that is enough depends on what you intend to do with the data. If FHIR is simply a transport format between two systems that already understand each other, structural conversion may be all you need. If the data will be combined across sources, analysed or used by AI, the fourth box is where most of the value lies. The twelve tests below cover both.
HL7 v2 is often described as a standard that everyone implements differently. Real messages contain custom Z-segments, fields used for purposes the specification never intended, several versions in use at once (2.3, 2.3.1 and 2.5.1 are all common), unusual character encodings and the occasional message that is simply malformed. A vendor's sample messages will be clean. Export a few hundred real messages from each of your source systems, remove or mask identifiers as your policies require, and use that set for every evaluation. Include the messages your current interfaces struggle with.
List the message types you need, such as ADT for admissions and demographics, ORU for results, ORM for orders, SIU for scheduling and MDM for documents, and confirm that each is supported to the depth you need. Then look at the detail: repeating fields, nested components, multiple observations grouped under an order, and above all your Z-segments. Ask how custom segments are handled, whether you can define mappings for them yourself, and how much effort each one takes.
HL7 v2 and FHIR do not line up perfectly, so every converter makes choices about data that has no obvious home. HL7 publishes mapping guidance for v2 to FHIR, and it is reasonable to ask a vendor how closely they follow it and where they depart from it. For your own test messages, compare the input and the output field by field. Check whether unmapped data is dropped silently, placed in FHIR extensions or reported to you. A converter that tells you what it could not map is far more useful than one that quietly discards it.
Most HL7 v2 messages identify tests, procedures and diagnoses with local codes that only the sending system understands. A structural converter carries those codes across unchanged, which means the problem has moved into FHIR without being solved. Ask whether the tool can map local codes to medical coding standards, or to the terminology your organisation has chosen, and whether the original code is kept alongside the mapped one. Ask who builds and maintains those mappings, whether you can review and correct them, and how codes that cannot be mapped are reported. If you receive data from many sources, this single capability will determine how useful your FHIR data is.
Result values in HL7 v2 arrive in several forms: plain numbers, numbers with a comparator such as "<5", coded answers, and free text. Units are typed however the source system chose to type them, so the same unit appears in many spellings. Reference ranges arrive as text, and abnormal flags use a vocabulary that varies by system. Check that numeric values become true quantities, that comparators are preserved, that units are standardised, that reference ranges become structured low and high values where possible, and that the original text is kept so that every transformation can be verified.
A great deal of clinical content inside HL7 v2 is not structured at all. Comments sit in NTE segments. Entire reports, particularly in histopathology, microbiology and radiology, are sent as blocks of free text. Many laboratories send the result as a PDF embedded inside the message. A typical converter wraps this content as an attachment or a text field and moves on, which is valid and leaves the information locked away. If that content matters to you, ask whether the tool can extract structured data from embedded documents and free text, and test it with your own examples.
A patient often carries several identifiers from different assigning authorities, and the same person may appear differently across systems. Check how the tool handles multiple identifiers and whether it supports matching or leaves that to you. Then look at what happens over time. Results are frequently sent as preliminary, then final, then corrected. A well behaved converter updates the existing FHIR resource when a message is re-sent or corrected. A poor one creates duplicates, and duplicated results in a patient record are both confusing and unsafe.
FHIR is a framework, and what counts as correct depends on the version and the profiles you are working to. Most implementations today use R4, though you should confirm what your destination systems expect. Many countries and programmes also publish their own implementation guides that constrain how resources must be populated. Ask whether the tool can produce output that conforms to the specific profiles you need, whether it validates against them as part of the conversion, and how much work it takes to support a new profile when requirements change.
Some messages will fail to convert, and some will convert with doubts, such as a code that could map to two different concepts. Find out what happens in each case. Check whether a failed message is held somewhere you can inspect and reprocess it, whether a partial conversion is clearly marked as partial, whether uncertain mappings are flagged for review, and how you are alerted. In an interface that handles thousands of messages a day, the quality of error handling decides whether problems are found in minutes or discovered by a clinician weeks later.
For every FHIR resource, you should be able to identify the message it came from, when it was converted, which version of the mappings was applied and what was changed along the way. FHIR has a Provenance resource for this purpose, and it is worth asking whether the tool uses it. Check whether the original message is retained and for how long. Provenance is what allows you to answer a clinician's question about a result with confidence, and to reprocess historical data when a mapping is improved.
Decide whether you need real-time conversion of a live feed, batch conversion of historical data, or both, since tools are often stronger at one than the other. Measure throughput and latency with your own message volumes. Confirm how messages reach the tool, whether over the traditional MLLP connection, an API or file transfer. Then cover the questions that apply to any processor of health information: where the data is processed and stored, whether it can run in your own environment if your obligations require it, how identifiers are handled, how long data is retained, whether it is ever used to train models, and what certifications and agreements are in place.
The licence or usage fee is only part of the cost. Source systems change, new sites come on board with their own dialects, and coding standards publish updates, so mappings need continual attention. Ask who does that work. With some tools your own integration team writes and maintains every mapping, which requires scarce HL7 skills. With others the vendor carries some or all of it. Ask how pricing scales, whether by interface, by message volume or by site, and estimate the cost of bringing on your next five sources, because that is where the difference between tools tends to appear.
Score each tool from 1 to 5 on each area, using the same set of your own messages for all of them.
It is worth being clear about what kind of tool you need, because there are two, and they do different jobs.
If your main requirement is to route and transform every kind of message between many hospital systems, including admissions, scheduling and billing, you need a general integration engine. That is a mature category, and JondaX does not set out to replace it.
If your requirement is to take clinical results data from many sources and make it consistent, comparable and ready for use, that is what JondaX was built for. JondaX is the health data transformation engine from Jonda Health, and for laboratory and clinical results data it works as an HL7 v2 to FHIR converter that also harmonises the content. It accepts HL7 v2 messages alongside FHIR, CSV, PDFs, scans and images, and it returns standardised output as FHIR, HL7, JSON or CSV.
The difference lies in the fourth box of the diagram above. JondaX uses AI to resolve the different ways the same test is captured across sources, normalise units, and map local codes to medical coding standards or to your own code set, with clinical review and quality assurance by Jonda Health's own team. Because the same engine is also a lab report API, results that arrive as a PDF embedded in a message, or as a scanned report from a laboratory with no interface at all, can be brought into the same structured form as your HL7 feeds. It works across more than ten languages, and to date it has processed more than 500,000 files and more than 26 million data points.
The two kinds of tool also work well together. Many organisations keep their integration engine for routing and place JondaX behind it, so that the results data flowing through becomes usable and not only valid.
Jonda Health is ISO 27001 certified, and JondaX is designed to comply with HIPAA, GDPR and PDPA. If you would like to see the difference on your own data, send a sample of your results messages through JondaX and compare the output against the scorecard above. Try JondaX or get in touch with our team.
It is a tool that takes HL7 v2 messages, the pipe-delimited format most clinical systems still exchange, and produces equivalent FHIR resources such as Patient, Observation and DiagnosticReport.
Not on its own. Conversion changes the structure of the data. If the content still uses local codes, inconsistent units and free text, other systems can read the resources and still cannot compare or combine them. Interoperability also requires the content to be harmonised.
Mostly, though not perfectly, because the two standards do not map one to one. A good converter follows published mapping guidance, places data without an obvious home into extensions, and tells you what it could not map.
It depends on the job. An integration engine routes and transforms all kinds of messages between systems. A harmonisation tool makes clinical content consistent and standardised across sources. Many organisations use both together.
Most converters carry them across as attachments or text fields, which keeps the content and leaves it unstructured. If you need the results inside those documents as data, look for a tool that can extract them.
Yes. JondaX from Jonda Health converts laboratory and clinical results data from HL7 v2 to FHIR and harmonises the content, including mapping local codes to medical coding standards or your own code set, normalising units and extracting results from embedded or scanned reports.
Suhina Singh is the founder and CEO of Jonda Health, a Singapore-based health data infrastructure company. A physician by training, she works with health systems across Asia-Pacific to harmonise, de-identify and standardise clinical data so it can be trusted and used. Jonda Health is ISO 27001 certified.
