...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Diagnostic Report
Object name: diagnostic_report
...
...
...
...
...
...
...
...
HL7: optional
...
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).
...
e-health: no Implementation (covered by effective)
...
e-health: no Implementation (covered by effective)
...
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
...
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 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.
...
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.
...
| Table of Contents |
|---|
Data Structure
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 report | id | uuid | M | Unique identifier for current record | Approved | |
basedOn : [{ Reference(CarePlan | ImmunizationRecommendation| MedicationRequest | NutritionOrder | ServiceRequest) }] // What was requested | based_on | Reference(ServiceRequest) | O | e-Health: only one reference and only to Service Request is supported | Approved | |
- | origin_episode | Reference(EpisodeOfCare) | O | Episode of care during which Service Request, dispensed by Diagnostic Report, was initialised | HL7: no such field | Approved |
status : { code } // registered | partial | preliminary | final + | status | string | M | e-Health: only "final" value is supported | Approved | |
category: [{ CodeableConcept }] // Service category | category | [ codeable_concept ] | O | A code that classifies the category of diagnostic service which has been provided to a patient. | Approved | |
code: { CodeableConcept } // Name/Code for this diagnostic report | code | codeable_concept | M | Code 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 patient | subject | uuid | M | 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. | HL7: optional | Approved |
encounter: { Reference(Encounter) } // Health care event when test ordered | encounter | Reference(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 report | effective | effective_at | O | 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 | e-health: no Implementation | Approved |
effectiveDateTime: { dateTime } | effective_date_time | date_time | O | e-health: no Implementation (covered by effective_period by setting effective_period.start) | Approved | |
effectivePeriod: { Period } | effective_period | period | O | The 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 | date_time | M | 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 implemented | Approved | |
primary_source | boolean | M | 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_origin | codeable_context | O | Mandatory if primary_source == false Only "historical_record" value is supported | HL7: no such attribute | ||
recorded_by | Reference(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 Service | performer | 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 interpreter | results_interpreter | 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_organization | reference(Legal_entity)] | M | Organisation that is responsible for diagnostic report creation | |||
specimens: [{ Reference(Specimen) }] // Specimens this report is based on | specimens | [reference(Specimen)] | O |
|
| Approved |
result: [{ Reference(Observation) }] // Observations | result | [Reference(Observation)] | O | Observations that are part of this diagnostic report | e-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 implementation | Approved | ||
media: [{ BackboneElement }] // Key images associated with this report | O | 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). | e-health: no implementation | Approved | ||
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 implementation | Approved | ||
M | Reference to the image source. | e-health: no implementation | Approved |
{ |
string } |
// |
Clinical conclusion (interpretation) of test results | conclusion | string | O | 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 } // |
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 conclusionCodes for the clinical conclusion of test results | conclusion_code | codeable_concept | O | One or more codes that represent the summary conclusion (interpretation/impression) of the diagnostic report. | e-health: no implementation | Approved |
} // |
Entire report as issued | presented_form | attachment | 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 implementation | Approved |
conclusion: { string } // Clinical conclusion (interpretation) of test results
SNOMED CT Clinical Findings (Example)
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.
explanatory_letter | string | O | Text explanation of why diagnostic report was cancelled. This attribute is used only with entered_in_error status. | |||
cancellation_reason | codeable_concept | O | A code that classifies reason why diagnostic report was cancelled. This attribute is used only with entered_in_error status. | |||
Absent in FHIR | paper_referral | O |
Complex types
Executor
HL7 | Name | Type | M/O | Description and constraints | HL7 vs eHealth comparison result | Status |
|---|---|---|---|---|---|---|
- | type | string | M | reference, string | ||
- | value | one of reference(Employee) or string according to type | M |