Guidance for populating and consuming investigations data in GP Connect

Introduction

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

DiagnosticReport resource elements

id

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

The logical identifier of the DiagnosticReport resource.

meta.profile

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

The DiagnosticReport profile URL.

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

identifier

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.

basedOn

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.

status

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.

category

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.

code

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.

subject

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

A reference to the Patient who the DiagnosticReport is about.

context

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

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

issued

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

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

performer

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.

specimen

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

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

result

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.

codedDiagnosis

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

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

conclusion

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:

effective

Data type: Period

Out of scope for the current iteration.

imagingStudy

Data type: Reference

Out of scope for the current iteration.

image

Data type: BackboneElement

Out of scope for the current iteration.

presentedForm

Data type: string

Out of scope for the current iteration.