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.