HL7 Australia Implementation Guide: home

RCPA Cancer Protocols IG (v0.1.0: Release 1 Draft). This is the current published version based on FHIR R3. See the Directory of published versions

Understanding this Guide

This guide explains how to represent a diagnostic report that provides a consistent representation of a histological analysis of a Colorectal resection, using a FHIR based representation, wrapped in HL7 v2. This page describes how this is specified.

Diagnostic Reports in FHIR

For reporting of Diagnostic Reports, FHIR provides 2 resources:

The DiagnosticReport represents the fundemental unit of work of a pathology service, 'the report'. It identifies the patient, the lab, the doctor who originally requested the work, the type of report, the date it was issued, and the report itself (say, as a PDF document). In addition, the report has a set of links to Observation resources, which carry atomic data associated with the report.

Observations have a code/value pair. The code identifies the what the atomic data item is. Values are typically a string, a code, or a quantity. Observations also carry a set of related data, such as interpretation flags. Because atomic data can be grouped into 'panels', an observation may have a set of related observations instead of a value; in this case, the code indicates the type (meaning) of the panel.

This is a very flexible structure; it can be used in an infinite number of different ways to represent the same content. This guide defines the right way to represent a Colorectal report - that is, what atomic observations to include, what codes they should have, and what their values can be.

RCPA/CAP Colorectal Structured Report

The process starts with the Colorectal Structured report developed jointly by the RCPA and CAP, and published by the RCPA.

This document is written by pathologists, for pathologists; it specifies what to report, how to report it consistently, and provides 'terms' (text representation of codes) that the pathologists should use for the individual items. It provides the clinical knowledge and agreements on which this implementation guide builds.

Colorectal Logical Model

The first thing to do is simply to convert the published document to a formal information model. What this does is:

  • Defines elements for each of the atomic concepts described in the document
  • Gives the elements a unique name that identifies the element consistently
  • Assigns a value domain to the element that defines what values it can have
  • Provides a 'Value Set' that specifies what codes can be the valid values for the element (if the elemnt has a code type)
  • Formalises the rules about the rules about relationships betwen the elements (e.g. if you have an X, then you need to say Y about it)

In this implementation guide, that's called the 'Colorectal Logical Model'. This is a FHIR content model that simply captures all the knowledge list above. It's not what is actually exchanged - that will come later (below).

See the FHIR Logical model for the Colorectal report.


A 'model' is all well and good, but what really makes it real and useful is to provide some examples. That both helps test out the the logical model and the clinical content it is based on is correct, and it helps concrete thinkers understand the abstract model.

Since the the logical model is defined, and it implies a format, we'll just go right ahead and use it to provide some examples. 11 of them, in this case, taken from real pathology reports, and de-identified.

See the 11 examples in XML or JSON (pick your flavor of preference).


That's all well and good, but these still aren't "FHIR Resources" - you can't upload them to a FHIR server, and leverage all the good stuff that FHIR represents (software, services, validation tools, community). What we have to do now is convert all this stuff to FHIR resources.

We do that by defining a formal mapping in a computable mapping language that defines how the a set of data in the shape of the Colorectal Logical Model is transformed to a set of FHIR resources. Because we have a computable transform for this, we can do the following:

  • Build summary mapping tables
  • Automatically create FHIR profiles
  • Convert the examples to a set of FHIR examples

Note that implementers don't need to pay any attention to the details of the mapping language. Of course, if you had content available in the colorectal logical format, and you had software that could execute the mapping language, you might be interested then - but both are unlikely (though the FHIR project does provide such software in several languages).

But if you're interested in the formal mapping anyway, it's provided here. If you look at it, you'll see that it's highly detail orientated.

Observation Profiles

Given that in FHIR, atomic data items are represented as Observation resources, and the colorectal report describes a set of data items to report, it follows that the 'describing how a Colorectal report looks in FHIR' is 'a set of rules for Observation resources'. In FHIR, a set of rules for a resource is called 'a profile'.

It follows, then, that the outcome of the Colorectal Logical Model to FHIR is a set of profiles on the Observation resource. Since there's around 100 elements, there's around 100 profiles. These two summary tables help users navigate the list of profiles:

Each profile is represented using 2 different tables:

  • Differential: The rules that the profile applies to the Base resource
  • Snapshot: The structure of the Base resource once the rules are applied

Building a FHIR Colorectal report means building a list of observations that conform to the rules described in these profiles.


Given that we have a mapping, we can transform the Colorectal examples we started with to a set of FHIR resource based examples.

See the 11 examples in XML or JSON (pick your flavor of preference).

As a matter of publishing convenience, the examples show the DiagnosticReport and related resources (mostly Observations) packaged in a Bundle (the standard FHIR mechanism for putting a group of individual resources in a single file without losing their identity).

Note that the resource based examples are more verbose than the Colorectal logical model examples. That's inevitable because the FHIR examples are based on generic content models that (a) can be read by any FHIR system and (b) can be processed independently without loss of context (e.g. that's why "subject" is repeated on all the observations independently).

Wrapping FHIR resources in v2 messages

Because existing distribution arrangemnts are based on v2 messaging, it is agreed that the reports will be distributed in a V2 message. To do this, take a FHIR bundle containing the Colorectal report (as shown in the examples, in XML format (review), and embed it in a v2 message, as shown in Colorectal Report - HL7 V2.4 examples.