This Visualisation Guidance page aims to give guidance about which of the structured elements available in a diagnosticreport SHALL be minimally visualised and in what kind of structure they SHALL be minimally presented to safely understand them.

This is not a guidance page on the actual report, the thumb of rule here concerning the referenced elements is: this is to be visualized IF they are available in the report. Please refer to the other pages in this guide for guidance on how to construct the report. It is up to a human inspection to finally judge the quality of the report that is visualized following the rules on this page.

PLEASE NOTE: This page does NOT aim to give exhaustive guidance how any user friendly presentation should be like when the structured elements are structurally integrated in a patient dossier - that is considered the domain of any consuming system.

PLEASE NOTE: Whenever a specific element is given infra (e.g. '.identifier') without extra explication, it is implied any sub elements of this element that are available SHALL be displayed. Also, if the element repeats, the repeats SHALL be visualized.

Considerations concerning a creation of a federal visualisation tool:

• It is highly RECOMMENDED that any initiative towards a general visualisation investigates possibilities by using the FHIR narrative. This can take the form of tuned narrative templates as is described e.g. in the Java FHIR Hapi libraries.
• Any mechanisms that automate visualisation SHALL also run a technical validation against the used FHIR profiles before returning any visualisation. An automated mechanism SHALL NOT return any visualised form of a laboratory report when a technical validation contains errors.
• Visualisation SHALL be in such a way the information is presented in a tabular fashion.

General information (DiagnosticReport)

Status

• .status

Identifier(s) of the reports

• .identifier

One general title

• .code

Extra category(ies) applicable to this report

• .category

Effective(Time of the specimen collection - is overruled when collection time is given in .specimen element.)

• .effective[x]

Issue date of this report

• .issued

General conclusions based on this report

• .conclusion
• .conclusionCode

Time of prescription(DiagnosticReport.basedOn)

It is fully expected the original prescription may not be exhaustively available in the report. However, if available, the following elements SHALL be visualised

Identifier(s)

• .identifier

Authored on

• .authoredOn

Patient(DiagnosticReport.subject)

It is fully expected a patient may not be exhaustively available in the report. However, if available, the following elements SHALL be visualised

Identifier(s)

• .identifier

Name(s)

• .name

Birthdate

• .birthDate

Telecom

• .telecom

Address

• .address

Performer(DiagnosticReport.performer)

It is fully expected the performer(s) (here it is assumed they are of the Practitioner and/or Organization type) may not be exhaustively available in the report. However, if available, the following elements SHALL be visualised

Identifier(s)

• .identifier

Name(s)

• .name

Telecom

• .telecom

Address

• .address

Results interpreter(DiagnosticReport.resultsInterpreter)

It is fully expected the results interpreter(s) (here it is assumed they are of the Practitioner and/or Organization type) may not be exhaustively available in the report. However, if available, the following elements SHALL be visualised. If this is the same entity as the performer supra, this MAY be omitted for readability purposes.

Identifier(s)

• .identifier

Name(s)

• .name

Telecom

• .telecom

Address

• .address

Specimen(DiagnosticReport.specimen)

Identifier(s)

• .identifier

Status

• .status

Type

• .type

Received time

• .receivedTime

Parent specimen (It is possible a specimen refers to a parent specimen(s), from which it originated. In that case the specimen SHALL clearly state this by giving the identifier(s). The actual parent specimen(s) SHALL be visualized as seperate specimen.)

• .parent.identifier

Collection details (All subelements available under the .collection element SHALL be visualized when available (e.g. when they were collected, the method of collection etc.)

• .collection

Processing details (All subelements available under the .processing element SHALL be visualized when available (e.g. a specific procedure that was done)

• .processing

Condition

• .condition

Notes (Any free text note to explain something concerning the specimen)

• .note

Observation(DiagnosticReport.observation)

As a general guidance concerning the visualisation of the observations any visualisation mechanism SHALL take note an observation MAY have components (.component element) and an observation MAY have member observations (.hasMember element). If any of these structures exists, a visualisation mechanism SHALL present these structures in a hierarchical fashion. Cfr. infra for specific guidance in specific reports

When visualizing a CodeableConcept:

• Visualisation mechanisms SHALL display the value given in CodeableConcept.text
• If that is not available, it SHALL display a value given in CodeableConcept.coding.display (if there are multiple .coding and one has the .userSelected flag: it SHALL take that)

Status (For readability purposes a status of 'final' MAY be hidden)

• .status

Category (NB remark supra 'When visualizing a CodeableConcept')

• .category

Code (NB this is the main code to identify the Observation. When an Observation is used as a title, it may happen no actual code is available in the .code element but this title will be available in the .code.text element.) (NB remark supra 'When visualizing a CodeableConcept')

• .code

Effective time (the clinically relevant time of of the observation)

• .effective[x]

Issued time (time this observation was made available)

• .time

Performer (observation.performer)

It is fully expected the performer(s) (here it is assumed they are of the Practitioner and/or Organization type) may not be exhaustively available in the report. However, if available, the following elements SHALL be visualised

For readability purposes, it is RECOMMENDED to only visualise the performer here when it is available and different from the performer in the root of the diagnosticreport

• Identifier(s)

  • .identifier

• Name(s)

  • .name

• Telecom

  • .telecom

• Address

  • .address

Value (Special attention SHALL be given to also correctly visualize any unit)

• .value[x]

Data absent (NB remark supra 'When visualizing a CodeableConcept')

• .dataAbsentReason

Interpretation (NB remark supra 'When visualizing a CodeableConcept')

• .interpretation

Reference Range

• .referenceRange

Bodysite (NB remark supra 'When visualizing a CodeableConcept')

• .bodySite

Method (NB remark supra 'When visualizing a CodeableConcept'

• .method

Specimen (observation.specimen)

• .identifier

Notes

The .note element MAY contain an author and a time. The author MAY be omitted for readability purposes if it is the same as the performer of the Observation (when the performer is omitted already because it is the same as the performer in the DiagnosticReport it follows the author of the note, in case it is again the same is also omitted)

• .note

Extra visualisation guidance concerning antibiogram

A typical structure in an antibiogram is a 'master' observation that has a member Observation for each culture. Each of these members will have a member list for all the susceptibilities of that culture.

The rules around hierarchical fashion as described supra apply here but the visualisation for an antibiogram SHALL be to visualise these susceptibility lists in columns. (Giving the name of the antibiotic only once and expressing the different susceptibilities for the different cultures as columns that are cleary marked to which culture they apply) This means for readibility purposes, only the .interpration element is considered from the susceptibility Observation.

Example:

[...]
Culture	1.Morganella morganii    
	2.Escherichia coli
	
Antibiogram							1			2
			Ampicilin				R			S
			Trimethoprim+Sulfamethoxazole		S			S
			Nitrofurantoin				R			S
			Cefuroxime				R			S
			Gentamicin				S			S
			Colistin				R			S
[...]

Extra visualisation guidance concerning reports only available as pdf

A report that does not contain any structured information concerning the observations is not considered to be a structured Belgian laboratory report but technically, the format still allows for this. A proper visualisation for the results in those kind of reports is the rendering of the pdf that will live in the .presentedForm element.