This page is part of the FHIR Specification (v0.11: DSTU 1 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

Resource DiagnosticReport - Content 4.16

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

The resource name as it appears in a RESTful URL is [root]/diagnosticreport/

A diagnostic report is used for 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.

The Diagnostic Report 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 Diagnostic Report is not intended to support:

• Cumulative Result presentation
• Genetic Sequencing and related reports

Comments on the suitability of this resource and/or requirements analysis for that would be welcome through the community input above.

The actual atomic result data are delegated to the common Observation Resource to make it easier to reuse them in a wider context.

There is a wide variety of names associated with the various parts of a diagnostic report. Doctors request for "tests" or "results" to be done. What the diagnostic service returns is variously called the "tests" or "results" or the "report". The individual data items are called "results" or "tests" both collectively and individually. Collections of individual data items are sometimes called "batteries" or "panels", which have various implications in different contexts. 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 contains a "narrative" - a written summary of the outcomes, and "results" - the individual pieces of atomic data. The results are assembled in a "group" which is a nested structure that can be used to define relationships between the individual data items.

Resource Content 4.16.1

<DiagnosticReport xmlns="http://hl7.org/fhir">
 <!-- from Resource: extension, narrative, and contained -->
 <status value="[code]"/><!-- 1..1 registered|interim|final|amended|cancelled|withdrawn § -->
 <issued value="[dateTime]"/><!-- 1..1 Date this version was released § -->
 <subject><!-- 1..1 Resource(Patient|Group|Device) The subject of the report § --></subject>
 <performer><!-- 1..1 Resource(Organization) Responsible Diagnostic Service § --></performer>
 <reportId><!-- 0..1 Identifier Id for external references to this report § --></reportId>
 <requestDetail>  <!-- 0..* What was requested -->
  <encounter><!-- 0..1 Resource(Encounter) Context where request was made --></encounter>
  <requestOrderId><!-- 0..1 Identifier Id assigned by requester --></requestOrderId>
  <receiverOrderId><!-- 0..1 Identifier Receiver's Id for the request --></receiverOrderId>
  <requestTest><!-- 0..* CodeableConcept Test Requested --></requestTest>
  <bodySite><!-- 0..1 CodeableConcept Location of requested test (if applicable) --></bodySite>
  <requester><!-- 0..1 Resource(Organization|Practitioner) Responsible for request --></requester>
  <clinicalInfo value="[string]"/><!-- 0..1 Clinical information provided -->
 </requestDetail>
 <serviceCategory><!-- 0..1 CodeableConcept Biochemistry, Haematology etc. § --></serviceCategory>
 <diagnosticTime value="[dateTime]"/><!-- 1..1 Effective time of diagnostic report § -->
 <results>  <!-- 1..1 Results grouped by specimen/kind/category -->
  <name><!-- 1..1 CodeableConcept Name/Code for this group of results --></name>
  <specimen><!-- 0..1 Resource(Specimen) Specimen details for this group --></specimen>
  <group><!-- 0..* Content as for DiagnosticReport.results Nested Report Group --></group>
  <result><!-- 0..* Resource(Observation) An atomic data result --></result>
 </results>
 <image><!-- 0..* Resource(Media|ImagingStudy) Key images associated with this report --></image>
 <conclusion value="[string]"/><!-- 0..1 Clinical Interpretation of test results -->
 <codedDiagnosis><!-- 0..* CodeableConcept Codes for the conclusion --></codedDiagnosis>
 <representation><!-- 0..* Attachment Entire Report as issued --></representation>
</DiagnosticReport>

Alternate definitions: Schema/Schematron, Resource Profile

Terminology Bindings 4.16.1.1

Path	Definition	Type	Reference
DiagnosticReport.status	Codes providing the status of an observation	Fixed	http://hl7.org/fhir/observation-status
DiagnosticReport.requestDetail.requestTest	Codes for tests/services that can be performed by diagnostic services	Example	http://hl7.org/fhir/vs/diagnostic-requests
DiagnosticReport.requestDetail.bodySite	Codes describing anatomical locations. May include laterality	Example	http://hl7.org/fhir/vs/body-site
DiagnosticReport.serviceCategory	Codes for diagnostic service sections	Incomplete	http://hl7.org/fhir/vs/diagnostic-service-sections
DiagnosticReport.results.name	Codes used to identify individual and panel diagnostic items	Incomplete	http://hl7.org/fhir/vs/report-names
DiagnosticReport.codedDiagnosis	Diagnoses codes provided as adjuncts to the report	Example	http://hl7.org/fhir/vs/clinical-findings

Notes: 4.16.2

• This resource includes some elements that relate to the ordering cycle (request identifiers); these are only included to the degree that it is useful for the final report to refer back to the orders. For explicit support of the ordering cycle, see the Order, OrderResponse, and DiagnosticOrder resources.
• If the diagnostic procedure was performed on the patient directly, diagnosticTime is the time it was peformed. If specimens were taken, the diagnostically relevant time can be derived from the specimen collection times, but since the specimen information is not always available, and nor is the diagnostically relevant time always exactly the specimen collection time (e.g. complex timed tests), the reports must always include a diagnosticTime element. Note that v2 messages often carry a diagnostically relevant time without carrying any specimne information.
• A report always contains a base group for individual results. As a minimum, this contains the name of the report itself. The base group can then contain a mix of results and sub-groups. The group has a code that indicates the nature of the grouping (e.g. organism isolate/sensitivity or antibody functional testing).
• There is rarely a need for more than two levels of groups. Known uses of 3 levels include the antibody code for a goup of antibody related test, or the organism code for a group of isolate/sensitivities, or a set of perinatal measurements on a single fetus.
• Applications consuming diagnostic reports must take careful note of updated reports, and ensure that withdrawn reports are appropriately handled.
• For applications providing diagnostic reports, a report shouldn't be final until all the individual data items reported with it are final or amended. If a report is withdrawn, all the results should be withdrawn by replacing every result value with the Concept "withdrawn" in the internal terminology "Special values" (url = "http://hl7.org/fhir/special-values"), and setting the conclusion (if provided) and the text narrative to some text like "This report has been withdrawn" in the appropriate language. A reason for withdrawal may be provided in the narrative.

Search Parameters 4.16.3

Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.

Name / Type	Description	Paths
_id : token	The logical resource id associated with the resource (must be supported by all servers)
code : token	a coded diagnosis on the report	DiagnosticReport.codedDiagnosis
date : date	the clinically relevant time of the report	DiagnosticReport.diagnosticTime
group : token	name /code of a group in the report
identifier : token	an identifier for the report	DiagnosticReport.reportId
issued : date	when the report was issued	DiagnosticReport.issued
name : token	the name/code of the report	DiagnosticReport.results.name
performer : reference	who was the source of the report (organization)	DiagnosticReport.performer
requester : reference	who made a request that lead to the report	DiagnosticReport.requestDetail.requester
result : reference	link to an atomic result (observation resource)	DiagnosticReport.results.result
service : token	which diagnostic discipline/department created the report	DiagnosticReport.serviceCategory
specimen : reference	the specimen details	DiagnosticReport.results.specimen
status : token	The status of the report	DiagnosticReport.status
subject : reference	the subject of the report	DiagnosticReport.subject
test : token	a test requested that the report is in response to	DiagnosticReport.requestDetail.requestTest