FHIR mapping

The stance

OIDM’s position on FHIR is stated in the deck’s call to action as two words: structure first, with FHIR and other standards following.¹ The project builds “functional data structures that can then be expressed in FHIR and other standards” rather than starting from the standard and working back. That ordering explains the state of everything below: the mappings are written down carefully, they have precedent in working examples, and no current code produces them.

The founding pattern: the CDE-labeled FHIR Observation

The project began from FHIR rather than beside it. Its About page defines the unit of radiology data as a “CDE-labeled FHIR Observation object”, and the 2023 post that set the direction works the idea through with a pulmonary nodule.²³

The worked example

FHIRSamples holds four hand-built resources for a lung cancer screening scenario. They remain the clearest statement of the pattern.

The report. A FHIR DiagnosticReport with category coded in SNOMED CT and HL7 v2 table 0074, code coded as LOINC 87279-6 for a screening chest computed tomography, an inline ImagingStudy, result referencing three Observations, and a conclusion with a SNOMED conclusionCode.⁴

The finding. An Observation whose code is a CDE set identifier under the https://radelement.org system, RDES195 for pulmonary nodule, with derivedFrom pointing at the imaging study and component entries whose codes are individual CDE element identifiers and whose valueCodeableConcept gives the chosen value code.⁵

{
  "resourceType": "Observation",
  "code": { "coding": [{ "system": "https://radelement.org", "code": "RDES195", "display": "Pulmonary Nodule" }] },
  "status": "preliminary",
  "derivedFrom": [{ "reference": "ImagingStudy/example1OIDMstudy" }],
  "component": [
    { "code": { "coding": [{ "code": "RDE1717" }] },
      "valueCodeableConcept": { "coding": [{ "code": "RDE1717.1" }] } }
  ]
}

Three patterns come out of it.

Set code, element code, value code. The chain from RDES195 to RDE1717 to RDE1717.1, all through one coding system, is what “CDE-labeled” means concretely. The current Exam Finding List uses the identical chain with a different vocabulary: OIFM identifier, OIFMA identifier, dot-suffixed value code.

Status carries provenance. The example has the same finding twice, once as an AI observation with status preliminary and once as the radiologist’s with status final. The two resources are otherwise identical. Distinguishing a machine-produced finding from a confirmed one is a field value, not a separate resource type.⁵ That is the closest precedent for the “provenance marker” the Exam Finding List specification asks for, and it is also exactly the ACR priority the deck names, correlating artificial intelligence observations against radiologist observations.¹

Assessments are second-order observations. A fourth resource carries the Lung-RADS category as a component of RDES267, and its derivedFrom points at both the imaging study and the radiologist’s finding Observation.⁶ An assessment built on top of a finding is an Observation referring to an Observation. That is the precedent for any future modelling of the reporting-system categories the roadmap names.

Two absences in the example are worth recording. No bodySite appears on the finding Observations, because anatomy was implicit in the CDE definition rather than explicit on the resource. No Patient resource is included; subject.reference is a bare reference.

The Python model

The 2024 reference implementation encodes the same shape in Pydantic. observation.py re-implements the FHIR primitives Identifier, Coding, CodeableConcept, and Reference, and defines an Observation with resourceType, code, status, subject, bodySite as a CodeableConcept, derivedFrom as a list of references, and component as a discriminated union of codeable-concept, string, integer, and boolean variants named after the FHIR value[x] convention.⁷ Its docstring says so plainly: “The Observation class is the model for FHIR Observation objects.”

bodySite is present in the class even though the samples do not use it, which is the field the current model’s explicit anatomic location would occupy. Both are covered in lineage repositories.

The current mappings

Both current structures have a documented FHIR encoding, stated in the imaging-problem-list README and repeated in its domain notes on both branches.⁸⁹

Structure	Documented FHIR encoding
Exam Finding List	”DiagnosticReport containing a list of Observation objects, with a finding code on each Observation and a list of components with attribute codes and values (especially present/absent and change from prior)“
Imaging Problem List	”Report containing a list of Condition objects (labeled with the finding identifier), where each Condition object also contains a list of Observation objects which document which exams (DiagnosticReports) the finding type has been documented on, including the exam date and exam type (LOINC type)”

Field by field, the Exam Finding List mapping is close to mechanical. diagnosticReportId is the DiagnosticReport identifier, examInfo.studyLoincCode is its code, each findings[] entry is one Observation with findingCode as its code, each attributes[] entry is one component, and anatomicLocation is the bodySite the lineage class already has. The problem list mapping introduces one resource that has no OIDM counterpart, the FHIR Condition, standing for one finding type in one patient, and one container, “Report”, that is not a FHIR resource name.

What is actually implemented

Nothing. A search for DiagnosticReport or fhir across the extraction platform’s entire source tree on the development branch returns no matches. No FHIR resource classes exist anywhere in the current Python code, and no OIDM tool emits a FHIR resource.

The only real FHIR documents in the current repositories are two input samples, powerscribe-fhir.json and chest-ct-fhir.json, which are pre-transformation DiagnosticReports carrying contained Patient, ImagingStudy, and Observation resources.¹⁰ They are worth reading because they differ from the prescribed output in two instructive ways. Their finding Observations code bodySite with RadLex, which the prescribed mapping does not mention. And their components carry DICOM codes for series, instance, and SOP identifiers rather than presence and change-from-prior attribute codes. That is not a contradiction: the component pattern the specification describes applies to the Exam Finding List output, not to the reporting system’s input.

Piece	Status
CDE-labeled FHIR Observation pattern	Demonstrated in hand-built lineage samples and a lineage Pydantic class; no current code
Exam Finding List as DiagnosticReport plus Observations	Documented; implemented nowhere
Imaging Problem List as Conditions plus Observations	Documented; implemented nowhere
FHIR resources as pipeline input	Real, two samples, from a commercial reporting system
Longitudinal FHIR persistence of findings	A design note on an unmerged branch of a superseded prototype; see Imaging Persona

The open question underneath

The component pattern that every OIDM encoding uses is the one IHE’s Imaging Diagnostic Report profile declines to use. IDR states that Observation.component “is not used”, because FHIR limits components to values “not useful on their own” and using it “has the potential to significantly complicate queries”, preferring a root Observation whose hasMember references the associated observations. Since the deck names IDR as the Exam Finding List’s target representation, that disagreement sits directly under the mapping. It is set out in IHE IDR alignment, along with the other points where the two models differ.

Footnotes

1. “Open Imaging Data Model 2026 Status Update”, January 2026 ↩ ↩²

2. openimagingdata.org About page ↩

3. “Findings, CDEs, and Observations”, openimagingdata.org, 2023-06-24 ↩

4. The lung cancer screening DiagnosticReport, FHIRSamples ↩

5. The AI-produced finding Observation, FHIRSamples ↩ ↩²

6. The Lung-RADS assessment Observation, FHIRSamples ↩

7. Observation model, OpenImagingDataModel.py ↩

8. imaging-problem-list README, main branch ↩

9. imaging-problem-list domain model notes, dev branch ↩

10. powerscribe-fhir.json, imaging-problem-list sample data ↩