Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

Diagnostic Report

Object name: diagnostic_report

HL7
Name
Type
M/O
Description and constraints
HL7 vs eHealth comparison result
Status
identifier : { Identifier } // Business identifier for reportiduuidMUnique identifier for current record
Approved
basedOn : [{ Reference(CarePlan | ImmunizationRecommendation| MedicationRequest | NutritionOrder | ServiceRequest) }] // What was requested based_onReference(ServiceRequest)O

e-Health: only one reference and only to Service Request is supported

Approved
-origin_episodeReference(EpisodeOfCare)OEpisode of care during which Service Request, dispensed by Diagnostic Report, was initialised HL7: no such fieldApproved
status : { code } // registered | partial | preliminary | final +

DiagnosticReportStatus (Required)
statusstringM

e-Health: only "final" value is supported

Approved
category: [{ CodeableConcept }] // Service category

Diagnostic Service Section Codes (Example)
category[ codeable_concept ]OA code that classifies the category of diagnostic service which has been provided to a patient.
Approved
code: { CodeableConcept } // Name/Code for this diagnostic report

LOINC Diagnostic Report Codes (Preferred)
codecodeable_conceptMCode of diagnostic service which has been provided to a patient.
Approved
subject: { Reference(Patient | Group | Device | Location) // The subject of the report - usually, but not always, the patientsubjectuuidMThe 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.

HL7: optional
Part of Patient's collection in Mongo DB

Approved
encounter: { Reference(Encounter) } // Health care event when test orderedencounterReference(Encounter)O

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).


Approved
effective[x]: { } // Clinically relevant time/time-period for reporteffectiveeffective_atOThe 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 itselfe-health: no ImplementationApproved
effectiveDateTime: { dateTime }effective_date_timedate_timeO

e-health: no Implementation (covered by effective_period by setting  effective_period.start)

Approved
effectivePeriod: { Period } effective_periodperiodOThe time or time-period the observed values are related to. This is usually either the time of the diagnostic procedure execution or of specimen collection(s).


Approved
issued: { instant } // DateTime this version was madeissueddate_timeM

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.

OUGHT to be with time zone specified

e-health: date_time data type is implementedApproved

primary_sourcebooleanM

An indication that the content of the record is based on information from the person who administered the report. This reflects the context under which the data was originally recorded.

Reflects the “reliability” of the content.

HL7: no such attribute

report_origincodeable_contextO

Mandatory if primary_source == false

Only "historical_record" value is supported

HL7: no such attribute

recorded_byReference(Employee)M

Employee who is responsible for posting the report. 

This is not necessarily the employee of organisation responsible for issuing the report.

HL7: no such attribute
performer: [{ Reference(Practitioner | PractitionerRole | Organization| CareTeam) }] // Responsible Diagnostic Serviceperformer[583403544]O

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.

Need to know whom to contact if there are queries about the clinical report.

HL7: different data type (reference)
resultsInterpreter: [{ Reference(Practitioner | PractitionerRole | Organization| CareTeam) }] // Primary result interpreterresults_interpreter[583403544]O

The practitioner or organization that is responsible for the report's conclusions and interpretations.

Need to know whom to contact if there are queries about the results. Also may need to track the source of reports for secondary data analysis.

Might not be the same entity that takes responsibility for the clinical report.

When service set in code parameter has category diagnostic procedure or imaging and primary_source is true then must contain reference to a doctor employee from legal entity responsible for diagnostic report 

HL7: different data type (reference)

managing_organizationreference(Legal_entity)]MOrganisation that is responsible for diagnostic report creation

specimen: [{ Reference(Specimen) }] // Specimens this report is based on

O
e-health: no implementationApproved
result: [{ Reference(Observation) }] // Observationsresult[Reference(Observation)]OObservations that are part of this diagnostic reporte-health: no implementation (implemented on Observation level)Approved
imagingStudy: [{ Reference(ImagingStudy) }] // Reference to full details of imaging associated with the diagnostic report

O

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.

e-health: no implementationApproved
media: [{ BackboneElement }] // Key images associated with this report

OA 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).e-health: no implementationApproved
comment: { string } // Comment about the image (e.g. explanation)

O

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.

e-health: no implementationApproved
link: { Reference(Media) } // Reference to the image source

MReference to the image source.e-health: no implementationApproved

conclusion: { string } // Clinical conclusion (interpretation) of test results


conclusionstringO

Concise and clinically contextualized summary conclusion (interpretation/impression) of the diagnostic report.

Mandatory when service set in code parameter has category diagnostic procedure or imaging


Approved
conclusionCode: { CodeableConcept } // Codes for the clinical conclusion of test results

SNOMED CT Clinical Findings (Example)
conclusion_codecodeable_conceptOOne or more codes that represent the summary conclusion (interpretation/impression) of the diagnostic report.e-health: no implementationApproved
presentedForm: { Attachment } // Entire report as issuedpresented_formattachment O

Rich text representation of the entire result as issued by the diagnostic service. Multiple formats are allowed but they SHALL be semantically equivalent.

Gives laboratory the ability to provide its own fully formatted report for clinical fidelity.

e-health: no implementationApproved

explanatory_letterstringOText explanation of why diagnostic report was cancelled. This attribute is used only with entered_in_error status.


cancellation_reasoncodeable_conceptOA code that classifies  reason why diagnostic report was cancelled. This attribute is used only with entered_in_error status.

Absent in FHIRpaper_referralpaper_referralO


Complex types

...