Diagnostic Report Data Model

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 +


DiagnosticReportStatus (Required)

status

string

M

e-Health: only "final" value is supported

Approved

category: [{ CodeableConcept }] // Service category


Diagnostic Service Section Codes (Example)

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


LOINC Diagnostic Report Codes (Preferred)

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
Part of Patient's collection in Mongo DB

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: { instant } // DateTime this version was made

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

[Diagnostic Report Data Model#Executor]

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

[Diagnostic Report Data Model#Executor]

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

link: { Reference(Media) } // Reference to the image source

M

Reference to the image source.

e-health: no implementation

Approved

conclusion: { 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 } // Codes for the clinical conclusion of test results


SNOMED CT Clinical Findings (Example)

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

presentedForm: { Attachment } // 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

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

paper_referral

O

-

type

string

M

reference, string

-

value

one of reference(Employee) or string according to type

M