Search loading...


Explore and Make use of Nationally Defined Messaging APIs



Guidance for populating and consuming investigations data in GP Connect


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

DiagnosticReport resource elements


Data type: Id Optionality: Mandatory Cardinality: 1..1

The logical identifier of the DiagnosticReport resource.


Data type: uri Optionality: Mandatory Cardinality: 1..1

The DiagnosticReport profile URL.

Fixed value


Data type: Identifier Optionality: Mandatory Cardinality: 1..*

This MUST be populated with a globally unique and persistent identifier (that is, it doesn’t change between requests and therefore stored with the source data). This MUST be scoped by a provider specific namespace for the identifier.

Where consuming systems are integrating data from this resource to their local system, they MUST also persist this identifier at the same time.


Data type: reference Optionality: Required Cardinality: 0..*

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.


Data type: Code Optionality: Mandatory Cardinality: 1..1

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.


Data type: CodableConcept Optionality: Required Cardinality: 0..1

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.


Data type: CodableConcept Optionality: Mandatory Cardinality: 1..1

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.

As this item is mandatory in FHIR then suppliers should populate it with the SNOMED ConceptID 721981007 for Diagnostic studies report.


Data type: Reference(Patient) Optionality: Mandatory Cardinality: 1..1

A reference to the Patient who the DiagnosticReport is about.


Data type: reference Optionality: Required Cardinality: 0..1

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


Data type: instant Optionality: Mandatory Cardinality: 1..1

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


Data type: Reference (Practitioner/Organization) Optionality: Required Cardinality: 0..*

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.


Data type: Reference Optionality: Required Cardinality: 0..*

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


Data type: Reference Optionality: Required Cardinality: 0..*

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.


Data type: codeableConcept Optionality: Required Cardinality: 0..*

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


Data type: string Optionality: Required Cardinality: 0..1

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.

Elements not in use

The following elements MUST NOT be populated:


Data type: Period

Out of scope for the current iteration.


Data type: Reference

Out of scope for the current iteration.


Data type: BackboneElement

Out of scope for the current iteration.


Data type: string

Out of scope for the current iteration.

All content is available under the Open Government Licence v3.0, except where otherwise stated