ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 27 Next »

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 reportiduuidM

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 ]O

Approved
code: { CodeableConcept } // Name/Code for this diagnostic report
LOINC Diagnostic Report Codes (Preferred)
codecodeable_conceptM

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)

Approved
effectivePeriod: { Period } effective_period[date_time]O

e-health: no Implementation (covered by effective)

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[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 interpreterresults_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.

HL7: different data type (reference)

managing_organizationreference(Legal_entity)]O


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

conclusionstringOConcise and clinically contextualized summary conclusion (interpretation/impression) of the diagnostic report.
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.
Approved
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

Complex types

Executor

HL7
Name
Type
M/O
Description and constraints
HL7 vs eHealth comparison result
Status
-typestringMreference, string

-value

one of reference(Employee) or string according to type

M


  • No labels