DiagnosticReport

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. Refer to the US Core DiagnosticReport profile for Report and Note exchange.

Schema

Elements

Name	Required	Type	Description
identifier		Identifier[]	Business identifier for report Details Identifiers assigned to this report by the performer or other systems. Usually assigned by the Information System of the diagnostic service provider (filler id).
basedOn		Reference< CarePlan | ImmunizationRecommendation | MedicationRequest | NutritionOrder | ServiceRequest >[]	What was requested Details Details concerning a service requested. Note: Usually there is one test request for each result, however in some circumstances multiple test requests may be represented using a single test result resource. Note that there are also cases where one request leads to multiple reports.
status	✓	code	registered | partial | preliminary | final + Details The status of the diagnostic report.
category		CodeableConcept[]	Service category Details A code that classifies the clinical discipline, department or diagnostic service that created the report (e.g. cardiology, biochemistry, hematology, MRI). This is used for searching, sorting and display purposes. Multiple categories are allowed using various categorization schemes. The level of granularity is defined by the category concepts in the value set. More fine-grained filtering can be performed using the metadata and/or terminology hierarchy in DiagnosticReport.code.
code	✓	CodeableConcept	Name/Code for this diagnostic report Details A code or name that describes this diagnostic report.
subject		Reference< Patient | Group | Device | Location >	The subject of the report - usually, but not always, the patient Details The subject of the report. Usually, but not always, this is a patient. However, diagnostic services also perform analyses on specimens collected from a variety of other sources.
encounter		Reference<Encounter>	Health care event when test ordered Details The healthcare event (e.g. a patient and healthcare provider interaction) which this DiagnosticReport is about. This will typically be the encounter the event occurred within, but some events may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission laboratory tests).
effective[x]		dateTime, Period	Clinically relevant time/time-period for report Details The time or time-period the observed values are related to. When the subject of the report is a patient, this is usually either the time of the procedure or of specimen collection(s), but very often the source of the date/time is not known, only the date/time itself. If the diagnostic procedure was performed on the patient, this is the time it was performed. If there are specimens, the diagnostically relevant time can be derived from the specimen collection times, but the specimen information is not always available, and the exact relationship between the specimens and the diagnostically relevant time is not always automatic.
issued		instant	DateTime this version was made Details The date and time that this version of the report was made available to providers, typically after the report was reviewed and verified. May be different from the update time of the resource itself, because that is the status of the record (potentially a secondary copy), not the actual release time of the report.
performer		Reference< Practitioner | PractitionerRole | Organization | CareTeam >[]	Responsible Diagnostic Service Details The diagnostic service that is responsible for issuing the report. This is not necessarily the source of the atomic data items or the entity that interpreted the results. It is the entity that takes responsibility for the clinical report.
resultsInterpreter		Reference< Practitioner | PractitionerRole | Organization | CareTeam >[]	Primary result interpreter Details The practitioner or organization that is responsible for the report's conclusions and interpretations. Might not be the same entity that takes responsibility for the clinical report.
specimen		Reference<Specimen>[]	Specimens this report is based on Details Details about the specimens on which this diagnostic report is based. If the specimen is sufficiently specified with a code in the test result name, then this additional data may be redundant. If there are multiple specimens, these may be represented per observation or group.
result		Reference<Observation>[]	Observations Details [Observations](observation.html) that are part of this diagnostic report. Observations can contain observations.
imagingStudy		Reference<ImagingStudy>[]	Reference to full details of imaging associated with the diagnostic report Details One or more links to full details of any imaging performed during the diagnostic investigation. Typically, this is imaging performed by DICOM enabled modalities, but this is not required. A fully enabled PACS viewer can use this information to provide views of the source images. ImagingStudy and the image element are somewhat overlapping - typically, the list of image references in the image element will also be found in one of the imaging study resources. However, each caters to different types of displays for different types of purposes. Neither, either, or both may be provided.
media		DiagnosticReportMedia[]	Key images associated with this report Details A list of key images associated with this report. The images are generally created during the diagnostic process, and may be directly of the patient, or of treated specimens (i.e. slides of interest).
id		string	Unique id for inter-element referencing Details Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
extension		Extension[]	Additional content defined by implementations Details May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
modifierExtension		Extension[]	Extensions that cannot be ignored even if unrecognized Details May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself). There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
comment		string	Comment about the image (e.g. explanation) Details A comment about the image. Typically, this is used to provide an explanation for why the image is included, or to draw the viewer's attention to important features. The comment should be displayed with the image. It would be common for the report to include additional discussion of the image contents in other sections such as the conclusion.
link	✓	Reference<Media>	Reference to the image source Details Reference to the image source.
conclusion		string	Clinical conclusion (interpretation) of test results Details Concise and clinically contextualized summary conclusion (interpretation/impression) of the diagnostic report.
conclusionCode		CodeableConcept[]	Codes for the clinical conclusion of test results Details One or more codes that represent the summary conclusion (interpretation/impression) of the diagnostic report.
presentedForm		Attachment[]	Entire report as issued Details Rich text representation of the entire result as issued by the diagnostic service. Multiple formats are allowed but they SHALL be semantically equivalent. "application/pdf" is recommended as the most reliable and interoperable in this context.

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

Inherited Elements

Name	Required	Type	Description
id		string	Logical id of this artifact Details The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes. The only time that a resource does not have an id is when it is being submitted to the server using a create operation.
meta		Meta	Metadata about the resource Details The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource.
implicitRules		uri	A set of rules under which this content was created Details A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc. Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of it's narrative along with other profiles, value sets, etc.
language		code	Language of the resource content Details The base language in which the resource is written. Language is provided to support indexing and accessibility (typically, services such as text to speech use the language tag). The html language tag in the narrative applies to the narrative. The language tag on the resource may be used to specify the language of other presentations generated from the data in the resource. Not all the content has to be in the base language. The Resource.language should not be assumed to apply to the narrative automatically. If a language is specified, it should it also be specified on the div element in the html (see rules in HTML5 for information about the relationship between xml:lang and the html lang attribute).
text		Narrative	Text summary of the resource, for human interpretation Details A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety. Contained resources do not have narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a "text blob" or where text is additionally entered raw or narrated and encoded information is added later.
contained		Resource[]	Contained, inline Resources Details These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently, and nor can they have their own independent transaction scope. This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again. Contained resources may have profiles and tags In their meta elements, but SHALL NOT have security labels.
extension		Extension[]	Additional content defined by implementations Details May be used to represent additional information that is not part of the basic definition of the resource. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
modifierExtension		Extension[]	Extensions that cannot be ignored Details May be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself). There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

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.

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.

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.

Referenced By

• CarePlan
• ChargeItem
• ClinicalImpression
• Communication
• CommunicationRequest
• Condition
• Contract
• DeviceRequest
• DeviceUseStatement
• FamilyMemberHistory
• GuidanceResponse
• ImagingStudy
• Immunization
• MedicationAdministration
• MedicationStatement
• Procedure
• RequestGroup
• RiskAssessment
• ServiceRequest
• SupplyRequest