Diagnostic Report Data Model

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 + 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
specimen: [{ Reference(Specimen) }] // Specimens this report is based on			O		e-health: no implementation	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

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