Has anyone come up with an artifact that would convert an v2 FT field to a FHIR narrative or markdown field? I have a need for this and it's proving slightly difficult for me to wrap my head around all the conversions that are needed.

Ages and ages ago I had an XSLT that converted an FT string to XHTML. Don't remember what project it was for or where the heck it is now.

well, that is only mildly helpful! :stuck_out_tongue:

It shows it's at least theoretically possible... ;)

Probably best to first investigate what FT markup is actually being used by source systems, from what I've seen at various sites only a very small set of FT markup stuff is actually ever used.

Digging up this conversation from 2021 regarding FT Formatted text and how to deal with it in FHIR. In Australia, it is fairly common for HL7 v2 ORU laboratory reports to include OBX segments that utilise the FT datatype. Generally, the only formatting markup used is line breaks \.br\ and \H\Highlighting\N\. What would be the cleanest way to convert this over to a FHIR Observation resource? Two things come to mind: Strip out all the formatting within the FT string and put it into the Observation.value of type valueString. Furthermore, convert the FT string into xHTML, retaining the formatting, and place that in the Observation.text.div as the resource's Narrative. OR Create a new extension on Observation for the `Observation.value' using FHIR's primitive Markdown data type. Then convert the FT data to Markdown and place it in this new extension. No need for a resource narrative. Option 1 creates a new dependency for us, that all Observations would now require a Narrative. Something we were not intending to do. Option 2 seems straightforward and obvious, without the need to generate xHTML narratives for everything. I'd love to hear the views of others.

The solution most in line with the philosophy of FHIR around text would be option (1). Note that all resources SHOULD have .text anyway, you just stumbled upon a use case where it becomes a SHALL. I'd debate whether you'd still need to put any text in .value - but I leave that up to the FHIR Lab pundits (on the #Orders and Observation WG channel) to provide you with guidance.

This creates a huge challenge for both the conversion and the receiving application. How does the receiving application know when to show the user the Resource.narrative, and when to show the atomic Observation.value[x]. We will already have a complete report narrative within the DiagnsoticReport resource, which includes all the child observations rendered as the Lab wishes the whole report to be seen.

resource.text is meant as a summary of the overall content of the resource, whereas your use case is about an observation value (only). As such you're right - .text may be useful, but a textual observation value has a conceptual relationship with .value. Not option (1), I withdraw my earlier suggestion. The use case for markup in textual values (and the use of markdown) still exists - best to ask the #Orders and Observation WG channel, as such guidance is FHIR related.

Practically, what I'm finding is quite a bit of v2 <-> FHIR Resource <-> FHIR Document conversions around this. V2 is most likely to be the method of getting this into an EPR and out of a LIMS - this is still occurring if the shared report is in FHIR Resource/Document formats. So I'd prefer the Observation answer Screenshot 2026-02-03 at 06.46.14.png

Option 2, then - raw ASCII in .value, plus an extension with a Markdown version.

LInk to source of that diagram https://build.fhir.org/ig/HL7/v2-to-fhir/ConceptMap-segment-obx-to-observation.html

Thanks for the reference @Kevin Mayfield . I like @René Spronk 's thinking, include both. But I feel it kicks the can down to the receiving systems. Which one does it use when? To me, it feels like a misrepresentation to provide the string without the formatting. That is not what the lab intended the downstream systems to do. It feels safer to provide a Markdown value extension (e.g. Observation.value[x] = valueMarkdown), thereby forcing downstream systems to address the formatting requirement, rather than aiding and abetting their desire to skirt around the responsibility. Noting also that HL7 v2 ST: String data types would flow through to the normal valueString type in FHIR where encountered in v2.

An 'extension' is what the word indicates - it 'adds'. Extensions may be ignored by receivers. The expectation is that receiver who are aware of the extensions will use the value in the extension, and that those not in the know will have the non-formatted .value as a fallback. To not populate .value would mean some systems won't be able to process any value - the clinical safety risks of not having anything are far greater than the risk of having a result in an ugly textual format. Note that highlighting can be preserved by using special characters, so the only thing that goes missing are linebreaks.

Isn't this what Modifier Extensions are used for? Although I do note the warning, which reads to your point: "Implementers SHOULD avoid the use of modifier extensions where possible. Any use should be carefully considered against its possible downstream consequences. Inclusion of modifier extensions in an instance would be expected to significantly limit the ability of other systems to process the instance. However, implementers are often forced into these situations by the business arrangements around the use of resources, so this specification creates a framework for handling such cases. Implementers who are introducing an extension and are uncertain whether the extension should be marked as a modifier are encouraged to raise the question on chat.fhir.org  ."

No. Modifier extensions are for when the whole information is not usable unless you understand the extension to it. An extension that provides something extra (such as nice formatting) is not usually a modifier. Unless you say that the formatting is critical to the understanding, which would not generally be the case. So it sort of depends, but generally I think formatting is not a total blocker to using the information (or a "significant limit", which again is open to interpretation).

A modifier extension can't be ignored - so that'd choke any use of such resources by any systems not in the know of the extension. That's a pretty big hammer. A regular extension is probably called for.

I know it is ugly and has it's own problems but you could just leave all the markup in .value, couldn't you? I don't think there is anything in the data type definition that disallows it(??). Maybe that just kicks the can down the road to whomever has to parse what's in the field.

Should this be a change in a future FHIR version? e.g. valueMarkdown or even valueAnnotation

That's probably not a backwards compatible change, so this is unlikely to happen.. in practice, if it's not already present in R6, it's unlikely to be relevant even if it were to be added in releases after R6.

(deleted)

(deleted)

For more context, I'm receiving many HL7 v2 ORU inbound feeds from private laboratory providers. I'm then converting to FHIR to feed into a large cloud-based primary care Clinical Information System, which services many independent community care doctors. Furthermore, a longer-term use case is that these FHIR laboratory reports may be sent further downstream to referring specialists. Each source v2 Message also contains a full PDF rendition of the report from the lab, which is the lab's legal representation and the preferred viewing experience for the end user. That PDF will be stored in a Binary resource referenced by the DiagnosticReport.presentedForm. However, just as the end user 'Doctor' can view the PDF, they can also see all the atomic result values, and therefore these FT: Formatted Text strings, depending on what decisions I make here regarding their formatting. Given this, and the presence of the PDF report, perhaps stripping the Formatting would be reasonable in the Observation.valueString. We can argue that the PDF is the formatted legal version of the report, and the FHIR Observation is the machine-level data for searching and analytics.

That sounds very similar to what I'm doing. I do have a view that FHIR + v2 + IHE models should be the same (within reason), as a I've got v2 -> FHIR -> v2 conversions. So I would prefer not to alter the markdown.

p.s. 5am I haven't got a use case for FT 9am Have a use case for FT Maybe I should have kept quiet :)

nah you're doomed anyway

Spent a few hours looking at this. I think I'm going to have to say to my data consumers, assume Observation.valueString is returning markdown. As a data consumer (converting back to HL7 v2), I found I could work out if I should convert to ST or TX, and probably also FT. Ideally I need to see what Epic is doing and compare notes.

there's a problem with this, which is that some technical values that might be found in Observation.valueString look like markdown but aren't. This routine is my best guess in Java at telling them apart: public boolean isProbablyMarkdown ( String content , boolean mdIfParagrapghs ) { if ( content == null ) { return false ; } if ( mdIfParagrapghs && content . contains ( "\n" )) { return true ; } String [] lines = content . split ( "\\r?\\n" ); for ( String s : lines ) { if ( s . startsWith ( "* " ) || isHeading ( s ) || s . startsWith ( "1. " ) || s . startsWith ( " " )) { return true ; } if ( s . contains ( "```" ) || s . contains ( "~~~" ) || s . contains ( "[[[" )) { return true ; } if ( hasLink ( s )) { return true ; } if ( hasTextSpecial ( s , '*' ) || hasTextSpecial ( s , '_' ) ) { return true ; } } return false ; }

I may have other options. The TX and FT OBX are present where I have PDF on other feeds. Those (OBX type ED) are being converted to DocumentReference + Binary and linked via DiagnosticReport.presentedForm It's got me wondering if I should map to DiagnosticReport.conclusion instead of a Observation - this is a string in R4 but markdown in R5

Have you looked at https://hl7.org/fhir/uv/v2mappings/STU1/ConceptMap-datatype-ft-comment-to-annotation.html ? What updates would you suggest based on the discussion?

The defacto answer for the UK appears to be convert to html or pdf (if it is a report). Which I think is like https://hl7.org/fhir/uv/v2mappings/STU1/ConceptMap-segment-obx-to-documentreference.html

@Hans Buitendijk and @Kevin Mayfield , I've looked at those two links provided. Yet, I can see how they further my challenge. Thankfully, in Australia, we have clear HL7 v2 standards advice and reasonable adherence regarding the transmission of Laboratory PDF reports in OBX segments of type 'ED', and appropriate standardised codes to identify these OBX segments among all the OBX segments under an OBR segment. Using a Full Blood Count (aka CBC) example. We will get many OBX segments for HB, WCC, PLAT, etc under an OBR. The last OBX segment is what we call a display segment, which has an OBX-3 code of |PDF^Display Format in PDF^AUSPDI| . This allows us to locate the PDF report binary data and place it into a Binary resource, which we reference in the DiagnsoticReport.presentedform. All good here. Where things get tricky are FT atomic-level comments and text that live within that report's OBXs. Just as we get an OBX Hemoglobin result, we also receive comments or findings in their own FT OBX Segments. Often there is a final comment or conclusion OBX that is FT. However, we have poor standardisation as to how this OBX is identified; the codes used in its OBX-3 are wide and varied. For this reason its very hard to single it out and place it into the DiagnsoticReport.conclusion element. Therefore, it finds itself in another FHIR Observation placed in the list of DiagnsoticReport.result . As do any other comments or text that are not conclusions. The advice in the links provided is to put FT: Formatted Text into a DocumentReference.content.contentType or Annotation or Markdown. Yet they are silent on how those datatypes or resources are then integrated into a DiagnosticReport as a child element, such as an Observation. We can't just have them hanging as loose ends. Their context, where they sit within the web of information that is the complete Report / Diagnostic Report, is lost. It's for this reason that I'm exploring possible extensions like Observation.valueMarkdown, or stripping off the formatting and using Observation.valueString. As soon as I explore the idea of not using an Observation, I'm then stuck with a loss of context; I now have some floating comment or text without context.

I do like the way you described that. I've

p.s. I think I have vested interest in what you are doing @Angus Millar . One of the providers we are working with supports AU eRequesting, I think this gives us a leg up.

That must be Magentus's UK arm. I'm good friends with Andy Bond, who represents most of their FHIR work.

I think I may have my wires crossed. I believe I'm acting as an Order Filler and the UK Magentus system would be the Order Placer (probably doing a reflex order). I think that is different to what is currently supported.

For FT the OBX would go to an Observation with value[x] valueString (per current guidance). When ED it pre-adopts valueAttachment from R5. Neither case would pull in a DocumentReference when the OBX came from an ORU. In the MDM_T02 OBX is mapped to DocumentReference given the use of OBX, but not here. OBX in ORU always goes to Observation, thus always is able to be linked to from DiagnosticReport. So not sure what the use case is to not use Observation. In the transition of this topic from general FT to an OBX-2=FT I may have started with a link directly to a dataype mapping, not the applicable OBX mapping: https://hl7.org/fhir/uv/v2mappings/STU1/ConceptMap-segment-obx-to-observation.html .

I'll comment on ED in the other thread. For FT I'm currently leaning towards using * valueString.extension contains http://hl7.org/fhir/StructureDefinition/rendering-markdown named valueMarkdown 0..* Screenshot 2026-02-14 at 07.15.04.png

I can see that Observation.valueString.extension is a reasonable approach to get an FT to maintain as formatted through Markdown. I'll enter a JIRA with that proposal for v2-FHIR E2.

@Kevin Mayfield : I added https://jira.hl7.org/browse/V2-25866 . Please add comments for any clarity, corrections, otherwise. Thank you!

Angus Millar said : That must be Magentus's UK arm. I'm good friends with Andy Bond , who represents most of their FHIR work. AFAIK its not been picked up in Magentus UK yet but I have talked with them about it.

@Andy Bond FYI we've just started conversations with Magentus UK, we've said we'd be open to Australia eRequesting (FHIR Workflow) for reflex orders, i.e. we may bypass IHE TLW/ILW and HL7 v2

Kevin Mayfield said : Andy Bond FYI we've just started conversations with Magentus UK, we've said we'd be open to Australia eRequesting (FHIR Workflow) for reflex orders, i.e. we may bypass IHE TLW/ILW and HL7 v2 That'd be awesome. We're going to use the same workflow transparency for other care collaborations.

@Declan Kieran /\

So the LIS in Australia then will support FHIR workflow capabilities for orders - can't wait to learn more! Riki Merrick, MPH, FHL7 Vernetzt, LLC rikimerrick@gmail.com cell: 916.216.0052 skype: riki.merrick *What you do makes a difference, and you have to decide what kind of difference you want to make. - Jane Goodall*