Representing Pathology reports in NEHTA Clinical Documents

Jun 12, 2012

This is the 3rd post in a series focusing on the representation of pathology reports in NEHTA clinical documents. The context of this work is that a clinical system is assembling a clinical document for some kind of summary report - a discharge summary, an event summary, or a referral - and document will include a set of pathology reports. The context doesn’t include a clinical user quoting from a pathology report by copying and pasting into a clinical document, but where the system is assembling the document (usually following some human guidance). Also, the context of this is not for a lab generating the original reports - this is only about reuse for those systems that wish to do so. Finally, a note for my US readers: here in Australia, “Pathology” includes all clinical lab disciplines, not the narrower usage it has in USA.

It’s possible to properly and completely represent a pathology report in a NEHTA clinical document. In the previous posts (here, and here), I’ve explained how to convert common narrative formats to a CDA narrative. In this post, I deal with how to represent the full report safely. If the source pathology report is fully conformant to AS 4700.2 (the relevant Australian standard), then this is relatively straight forward. To the degree that the source deviates from AS 4700, then this is either more difficult, or not safe (any display/usage of the report is similarly affected).

Parts of a Pathology Report

There are four major parts to a pathology report in a NEHTA Clinical document:

  • Metadata - identifies the type of report etc
  • CDA representation - the report as represented in CDA narrative
  • Native representation - original content as provided by the lab (i.e. PDF)
  • Atomic data

The first two parts are mandatory. The other two are optional. This post doesn’t deal with atomic data at all - we’re going to ignore that part for now (if there’s enough interest, I’ll do a follow up post on that).

With regard to the two presentation formats, the CDA representation is required as part of CDA. The native format is provided because the CDA representation is never going to be able to reproduce the full page layout of the pathology lab report, and under some circumstances,a clinical system won’t be able to safely transform the pathology report into the limited capabilities of the CDA narrative. Alternatively, you might have a URL reference to where the report might be available to a suitably authorised user.

So it follows that the following combinations of presentation exist:

  • you don’t have a presentation format at all, and nor do you have a link. So there’s probably not a lot of point putting the report into the CDA document
  • you have a reference to where the report can be available. Build a CDA narrative with the link in it () and add it as a native representation with a reference
  • you have a CDA narrative (e.g. built from PIT) and there’s either no original format, or the original format offers nothing in addition to the CDA Narrative - so just use the CDA narrative
  • You have an original format - probably a PDF - and no CDA narrative. In this case, you include the original format, and a constructed narrative that is just a pointer to the original
  • you have both - a CDA narrative, and an original form. Put both in, and ensure that the CDA narrative contains a link to the native format.

See below for technical details of how to render these in CDA.For the reader of the document, this is relatively consistent: for the lab report, they get a display of it’s contents if one is available, and a link to click to get the full version of the report, if that is available.

The important point is that you only include the CDA narrative form of the report if you are confident that it’s correct. You can be confident it’s correct and safe if:

  • the lab provided a PIT or text representation (TX or FT) - you can transform these to CDA narrative with confidence
  • the lab provided a CDA Narrative form themselves (though none of them are doing that for now or the forseeable future)
  • the lab provided an HTML form, and you know that you can convert the html correctly for that lab

If the report is provided as PDF, or RTF, you can print the document to a TIFF image, and include the TIFF image as the narrative - but I recommend against that, since the TIFF image may be a multi-page one, and support for this is variable. For instance, it’s allowed in the pcEHR, but I doubt that the portal will provide a multi-page TIFF viewer, being as it depends on a browser (I haven’t actually checked).

If the report is provided as purely atomic data, you may be able to safely convert it to CDA narrative - it depends on whether you are able to safely display it to the user at all, which is not an easy problem. If you can, feel free to include this as the CDA narrative.

Metadata

The following table summarises the metadata that a report has:

Item Description Required? V2 Source
Report Name Identification of the pathology test performed, sometimes including specimen type yes OBR-4
Diagnostic Service The diagnostic service that performs the examination no OBR-24
Report Status The status of the pathology test result as a whole. yes OBR-25
Test Result Date Time The clinically relevant time of the pathology test yes OBR-7

The report actually has additional metadata around requesting and so forth, but it’s all optional, and I’ve left it out of this analysis. There are also a whole lot of additional fields related to atomic data which I’ve also left out, and that too is all optional.

So there’s 3 pieces of data that you have to provide: the name of the report – which may be a code, the status of the report, and the date time of the observation, which is usually when specimen was collected. These pieces of data should be easily extractable from the source pathology report.

Status might be a problem. The allowed values are:

Registered No result yet available
Interim This is an initial or interim result: data may be missing or verification has not been performed
Final The result is complete and verified by the responsible practitioner
Amended The result has been modified subsequent to being Final, and is complete and verified by the pathologist
Cancelled/ Aborted The result is not available because the examination was not started or completed

This is a subset of the options allowed for OBR-25, though it matches the list used by Australian laboratories. I’ve heard that not all pathology companies actually provide a status for their report. Perhaps you can assume that they are final – that might be possible in a particular context (but then how do they handle amended reports?). If the pathology report itself can’t be bothered to say what’s status is, then you’ll have to use a nullFlavor on the report status code in the CDA document.

CDA representation

So to properly represent a report in CDA, you need a CDA representation, and report name, status, and date/time. In addition, you might have a diagnostic service, a native representation, and/or a source link.

This CDA fragment shows what this looks like in the actual XML:

<component>
 <section>
  <code code="102.16144" codeSystem="1.2.36.1.2001.1001.101"
     displayName="Pathology Test Result" />
  <title>Pathology Test Result</title>
  <text>
   [CDA narrative]
  </text>
  <entry>
   <observation classCode="OBS"moodCode="EVN">
     <id [you need to put something here that will be same each time
     you reuse this same pathology result. It could be sourced from the
     pathology report identifiers]/>
    <code [report name, code or original text]/>
    <value mediaType="[media type of native representation or text/html for url]">
     <reference value="[either a full URL, or the name of the native 
        representation which is found in the package]" />
    </value>
    <entryRelationship typeCode="COMP">
     <observation classCode="OBS"moodCode="EVN">
      <code code="310074003" codeSystem="2.16.840.1.113883.6.96"
       displayName="pathology service" />
      <value xsi:type="CD" [diagnostic service code/text] />
     </observation>
    </entryRelationship>
    <entryRelationship typeCode="COMP">
     <observation classCode="OBS"moodCode="EVN">
      <code code="308552006" codeSystem="2.16.840.1.113883.6.96"
       displayName="Report Status" />
      <value xsi:type="CD" code="[report status]" displayName="[text]"
       codeSystem="1.2.36.2001.1001.101.104.16501" />
     </observation>
    </entryRelationship>
    <entryRelationship typeCode="COMP">
     <observation classCode="OBS"moodCode="EVN">
      <code code="103.16605" codeSystem="1.2.36.1.2001.1001.101"
       displayName="Pathology Test Result DateTime" />
      <effectiveTime value="[report date]"/>
     </observation>
    </entryRelationship>
   </observation>
  </entry>
 </section>
</component>