DiagnosticReport

Maturity Level	Security Category	Resource Category
3	Patient	Clinical

The findings and interpretation of diagnostic tests performed on patients, groups of patients, devices, and locations, and/or specimens derived from these. The report includes clinical context such as requesting and provider information, and some mix of atomic results, images, textual and coded interpretations, and formatted representation of diagnostic reports.

Resource Content

Name	Required	Type	Description & Constraints
identifier		Identifier[]	Business identifier for report
basedOn		Reference<CarePlan \| ImmunizationRecommendation \| MedicationRequest \| NutritionOrder \| ServiceRequest>[]	What was requested
status	✓	code	registered \| partial \| preliminary \| final +
category		CodeableConcept[]	Service category
code	✓	CodeableConcept	Name/Code for this diagnostic report
subject		Reference<Patient \| Group \| Device \| Location>	The subject of the report
encounter		Reference<Encounter>	Health care event when test ordered
effective[x]		*	Clinically relevant time/time-period for report
└─ effectiveDateTime		dateTime
└─ effectivePeriod		Period
issued		instant	DateTime this version was made
performer		Reference<Practitioner \| PractitionerRole \| Organization \| CareTeam>[]	Responsible Diagnostic Service
resultsInterpreter		Reference<Practitioner \| PractitionerRole \| Organization \| CareTeam>[]	Primary result interpreter
specimen		Reference<Specimen>[]	Specimens this report is based on
result		Reference<Observation>[]	Observations
imagingStudy		Reference<ImagingStudy>[]	Reference to full details of imaging
media		BackboneElement[]	Key images associated with this report
└─ comment		string	Comment about the image
└─ link	✓	Reference<Media>	Reference to the image source
conclusion		string	Clinical conclusion of test results
conclusionCode		CodeableConcept[]	Codes for the clinical conclusion
presentedForm		Attachment[]	Entire report as issued

Search Parameters

Name	Type	Description	Expression
code	token	The code for the report, as opposed to codes for the atomic results, which are the names on the observation resource referred to from the result	`DiagnosticReport.code`
date	date	The clinically relevant time of the report	`DiagnosticReport.effective`
identifier	token	An identifier for the report	`DiagnosticReport.identifier`
patient	reference	The subject of the report if a patient	`DiagnosticReport.subject.where(resolve() is Patient)`
encounter	reference	The Encounter when the order was made	`DiagnosticReport.encounter`
based-on	reference	Reference to the service request	`DiagnosticReport.basedOn`
category	token	Which diagnostic discipline/department created the report	`DiagnosticReport.category`
conclusion	token	A coded conclusion (interpretation/impression) on the report	`DiagnosticReport.conclusionCode`
issued	date	When the report was issued	`DiagnosticReport.issued`
media	reference	A reference to the image source	`DiagnosticReport.media.link`
performer	reference	Who is responsible for the report	`DiagnosticReport.performer`
result	reference	Link to an atomic result (observation resource)	`DiagnosticReport.result`
results-interpreter	reference	Who was the source of the report	`DiagnosticReport.resultsInterpreter`
specimen	reference	The specimen details	`DiagnosticReport.specimen`
status	token	The status of the report	`DiagnosticReport.status`
subject	reference	The subject of the report	`DiagnosticReport.subject`
study	reference	Studies associated with the diagnostic report	`DiagnosticReport.imagingStudy`

Scope and Usage

This resource is an event resource from a FHIR workflow perspective - see Workflow. It is the intent of the Orders and Observation Workgroup to align this resource with the workflow pattern for event resources.

A diagnostic report is the set of information that is typically provided by a diagnostic service when investigations are complete. The information includes a mix of atomic results, text reports, images, and codes. The mix varies depending on the nature of the diagnostic procedure, and sometimes on the nature of the outcomes for a particular investigation. In FHIR, the report can be conveyed in a variety of ways including a Document, RESTful API, or Messaging framework. Included within each of these, would be the DiagnosticReport resource itself.

The DiagnosticReport resource has information about the diagnostic report itself, and about the subject and, in the case of laboratory tests, the specimen of the report. It can also refer to the request details and atomic observations details or image instances. Report conclusions can be expressed as a simple text blob, structured coded data or as an attached fully formatted report such as a PDF.

The DiagnosticReport resource is suitable for the following kinds of diagnostic reports:

Laboratory (Clinical Chemistry, Hematology, Microbiology, etc.) Pathology / Histopathology / related disciplines Imaging Investigations (x-ray, CT, MRI etc.) Other diagnostics - Cardiology, Gastroenterology etc. The DiagnosticReport resource is not intended to support cumulative result presentation (tabular presentation of past and present results in the resource). The DiagnosticReport resource does not yet provide full support for detailed structured reports of sequencing; this is planned for a future release.

Background and Context

Diagnostic Report Names The words "tests", "results", "observations", "panels" and "batteries" are often used interchangeably when describing the various parts of a diagnostic report. This leads to much confusion. The naming confusion is worsened because of the wide variety of forms that the result of a diagnostic investigation can take, as described above. Languages other than English have their own variations on this theme.

This resource uses one particular set of terms. A practitioner "requests" a set of "tests". The diagnostic service returns a "report" which may contain a "narrative" - a written summary of the outcomes, and/or "results" - the individual pieces of atomic data which each are "observations". The results are assembled in "groups" which are nested structures of Observations (traditionally referred to as "panels" or " batteries" by laboratories) that can be used to represent relationships between the individual data items.

Boundaries and relationships

Note that many diagnostic processes are procedures that generate observations and diagnostic reports. In many cases, such an observation does not require an explicit representation of the procedure used to create the observation, but where there are details of interest about how the diagnostic procedure was performed, the Procedure resource is used to describe the activity.

In contrast to the Observation resource, the DiagnosticReport resource typically includes additional clinical context and some mix of atomic results, images, imaging reports, textual and coded interpretation, and formatted representations. Laboratory reports, pathology reports, and imaging reports should be represented using the DiagnosticReport resource. The Observation resource is referenced by the DiagnosticReport to provide the atomic results for a particular investigation.

If you have a highly structured report, then use DiagnosticReport - it has data and workflow support. Details about the request for a diagnostic investigation are captured in the various "request" resources (e.g., the ServiceRequest) and allow the report to connect to clinical workflows. For more narrative driven reports with less work flow (histology/mortuary, etc.), the Composition resource would be more appropriate.

Image and media representations of the report and supporting images are referenced in the DiagnosticReport resource. The details and actual image instances can be referenced directly in Diagnostic report using the "imaging" element or by indirect reference through the ImagingStudy resources which represent the content produced in a DICOM imaging study or set of DICOM Instances for a patient.

Referenced Elements

This resource is referenced by: