Schema: DiagnosticReport

Introduction

The headings below list the elements of the DiagnosticReport resource and describe how to populate and consume them.

Important: Any element not specifically listed below will not be populated or consumed.

Tip: You’ll find it helpful to read it in conjunction with the underlying DiagnosticReport profile definition.

DiagnosticReport Resource Elements

id

The logical identifier of the DiagnosticReport resource.

meta.profile

The DiagnosticReport profile URL.

Fixed value https://fhir.nhs.uk/STU3/StructureDefinition/CareConnect-GPC-DiagnostocReport-1

identifier

This will be populated with a globally unique and persistent identifier (that is, it doesn’t change between requests and therefore stored with the source data).

basedOn

A link to the ProcedureRequest that contains details of a request that was made. Where present this may include details of who requested the tests and why the test was requested.

As currently test requests are not submitted in a FHIR format this is not the original request but is currently used as a container to hold details that were present in the original request.

status

The status of the DiagnosticReport. In GP systems these are most likely to be ‘final’ however ‘preliminary’ reports are possible as for example, some work can be sub-contracted to other labs. If the system is not able to determine the status of a report then it should default to the ‘unknown’ value.

category

The general type of test report. A default value of Laboratory should be used if a more specific value is not available - for example, pathology, microbiology.

Consuming systems need to be aware that where more detailed categories are provided the categorisation may vary. How laboratories categorise in the UK is not consistent, and this needs to be taken into account if any type of filtering is being considered.

code

Due to the model that we have used, the clinical code that represents the name of the test/analyte or test set will sit in an observation resource at either the ‘Test group header’ or ‘Test result’ level.

subject

A reference to the Patient who the DiagnosticReport is about.

context

A reference to the Encounter profile representing the consultation the test report is associated to.

issued

The date and time that the DiagnosticReport was issued by the laboratory or other report provider.

performer

Reference to the resource for the Organization or Practitioner that produced the DiagnosticReport. A practitioner resource may be referenced here but only where an organization is reference is provided.

specimen

Reference to the specimen(s) on which these results were based.

result

Reference to the result(s) which are contained in the DiagnosticReport. This may contain references to standalone test results, test group headers (which then reference further results) or a mixture of both.

Test results which are part of a test group will not be referenced by this element, the reference will be to the test group which will in turn reference the test results.

In GP systems this will also contain a reference to an observation that contains the details of the time that the report was filed into the record. This will be identified as the observation.code element will be populated with the SNOMED code 37331000000100 for Comment note.

codedDiagnosis

A coded finding of the test report. Produced by the organisation that performed the tests.

conclusion

Clinical Interpretation of test results in a text format and notes written by performing organisation in addition to the interpretation. For example, the specimen has haemolysed or has leaked.

For clarity notes may be captured at a number of levels within a DiagnosticReport. There may also be notes related to the specimen, test group header or individual test result. It is the consuming systems responsibility to make sure all relevant notes are displayed to the user.