Draft Information Standard Image Availability v1.0.0-alpha.2

This page is a trial to translate Dutch pages into English with the use of AI. The semantics are incorrectly translated in some areas and hence this page cannot be used to refer to the informatiestandaard. Find the most recent Dutch version using this link. Landingspagina.

1 Introduction

1.1 General

Specialist medical diagnostics and treatment for a patient are increasingly taking place across several hospitals. Here, radiological examinations from healthcare institutions where the patient has been may be relevant for a radiologist or treating physician in the next healthcare institution. Timely, complete and reliable availability of relevant, previously performed radiological examinations increases the quality of care in terms of content and throughput time. This information standard describes the information requirements of the functional requirements for the timeline of radiological examinations performed in the Netherlands. This so-called "radiological examination timeline" is described by the Dutch Society of Radiology (NVvR) in the functional requirements for nationwide availability of radiological examinations.

The functional design (FO) describes the transactions, transaction groups, systems, system roles and business roles of healthcare providers or patients for all exchange scenarios (called use cases in this document) from the information standard. Before that, it gives the requirements for accessing and making data available. Chapter 2 further details what a use case entails. For each use case, further details are described.

For more information on information standards and how they are developed, see the Nictiz webpage for information standards. For the explanation of terms appearing in the FO, please refer to the glossary of terms on the Nictiz website.

1.2 Target group

The target audience of this FO consists of:

• Product managers, architects, designers, builders and testers from XIS and PACS vendors, regional organisations, NEN and Nictiz;
• Representatives of patients, radiologists and other healthcare providers.

1.3 Frameworks & principles

1.3.1 Directive and process

This information standard is based on the quality standard and the functional requirements of the NVvR.

The Quality Standard Image Availability states that availability of previous examinations (images and reports) in addition to the most up-to-date is relevant in any care process, where images play a role. Regardless of the care process, in which imaging plays a role, availability of all previous radiological examinations of a patient is the professional standard of the radiologist.

Consulting the radiological exam timeline and images and reports can be part of the following care processes, as described in the Quality Standard Image Availability:

• radiological examination
• regular reference
• emergency referral
• multidisciplinary consultation (MDO)
• parallel or shared treatment

The quality standard describes the radiological process as follows:

The attending physician makes a request for radiological examination and this request is made reviewed. The lab technician receives the patient and ensures that radiological images are taken appropriately. The radiologist assesses the images and makes a diagnosis and/or determines the course of a disease and/or treatment based on interpretation of radiological examination and comparison of that examination with previous radiological examinations. The findings, conclusions and recommendations, the radiologist records them in a radiological report, which is an integral forms part of the radiological examination. This report comes (with images if required) available to the attending physician. This is the radiological care process.

For each process step to take place properly, safely and responsibly, it is essential for patients, treating physicians, lab technicians and radiologists that all previously internally and/or externally produced radiological examinations are optimally integrated, simultaneous and available in the same format in their own working environment. This is the radiological examination timeline that is both created and used and supplemented during the radiological care process.

Figure 1: NVvR image availability process radiological examination from request to authorisation report, adapted from Quality Standard Image Availability v0.9999.

Figure 2: Addendum or corrigendum, adapted from Quality Standard Image Availability v0.9999.

Figure 3: Reassessment, adapted from Quality Standard Image Availability v0.9999.

1.3.1.1 Performance and speed at urgency

The speed of availability of an image with report from the timeline should be comparable to current performance within a hospital.

For exact requirements on performance, please refer to the quality standard.

1.3.2 Scope Information Standard

The scope of the information standard covers the functional descriptions and dataset for the data exchanges resulting from consulting external examinations within the radiological care process.

This first version of the information standard Image Availability covers the provision and consultation of radiological images and reports. The ambition is to extend the scope to non-radiological images and reports in the near future.

The primary target group consists of healthcare providers within specialist medical care (MSZ) institutions in the Netherlands at:

• university medical centres;
• hospitals;
• radiotherapy centres;
• population survey (RIVM);
• categorical hospitals;
• inpatient rehabilitation centres;
• non-clinical rehabilitation centres;
• independent treatment centres.

1.3.3 Infrastructure

Infrastructure specifications are beyond the scope of this information standard.

1.3.4 Deployment of zibs and further development

For the development of this information standard, the starting point is to implement as many existing healthcare information building blocks (zibs) as possible and supplement them as needed. The intention of zibs is to implement reusable building blocks for single capture and multiple use. Zibs are therefore building blocks in many collections other than Image Availability. These other collections are partly already under development (in BgZ, Oncology, Birth Care, etc.). In addition, zibs will also be the basis of research and quality accountability. So the zibs to be implemented will also be building blocks for these other processes. At the same time, these building blocks used in other standards can also be used in this information standard.

Therefore, the zibs should be implemented in the systems in a way that facilitates reuse for purposes other than Image Availability. The goal is reuse in all areas of healthcare, not just implementation of Image Availability. The Image Availability information standard cannot specify or qualify use outside Image Availability, but use outside the scope of Image Availability is the goal.

1.3.5 Generic features

The following generic functions are addressed outside this information standard to simplify implementation:

1. Consent (from the patient)
2. Identification & authentication (of the healthcare provider, healthcare provider and patient)
3. Localisation (findability of patient data)

Consultation consent for the timeline and/or radiological examinations (images and reports) is assumed. This may be through pre-given patient consent, ad hoc given patient consent or an authorisation procedure in the case of an emergency scenario where break-the-glass is applied. How this consent is given and verified is beyond the scope of this information standard.

1.4 Qualification

Based on this FO and the associated dataset, a qualification script will be prepared. The preparation of qualification scripts falls outside the scope of this FO. For more information, see the website page on Nictiz qualifications.

2 Usecases

A use case is a specific description of a practical situation in healthcare in which the exchange of information is described for a concrete situation on the basis of actors (people, systems) and transactions (what information is exchanged when). A use case is a description of a step in the healthcare process in which the information need in that step is described. An information standard can consist of one or more use cases. Each use case links to a scenario in ART-DECOR. When different use cases use the same scenario, a different classification may be desired, e.g. based on process. In this FO, each use case is analysed and developed.

2.1 General

The image availability information standard provides for sending metadata for report and image and consulting timeline data, report and image and has five use cases:

1. Radiologist makes report data available towards timeline
2. Radiologist makes image data available towards timeline
3. Radiologist/Treasurer consults timeline data
4. Radiologist/Treasurer consults report
5. Radiologist/Treasurer consults image

These use cases are described individually in the following paragraphs.

Images and reports belonging to the same investigation must be shown under the same investigation at all times.

2.2 Usecase 1: Make report data available for timeline

2.2.1 Purpose and Relevance

To provide a complete timeline, the query point will need to have sufficient information available from previous investigations for this timeline data. To achieve this, a source system (usually an EHR) that wants to make a report or image available will need to make it known to a registry that is retrievable by the query point. The source system does this by sending metadata of the report or image to the registry. Depending on the infrastructure, the report itself may also be sent along. The image itself is not sent along and becomes available from the source system. This is described in more detail in the TO. Usually this is an automated process.

2.2.2 Process and Context (pre- and post-process)

2.2.2.1 Preprocess

• "Completing examination (authorising report)" precedes this. See section 1.3.1 Guideline and process for the radiological examination process from request to authorisation report.

2.2.2.2 Process

• The source system sends the investigation data from the report to the registry tbv the timeline.

2.2.2.3 Postprocess

• The report of the examination is recorded in the register.
• The report and of the study is available to all systems that can retrieve timeline data.

2.2.3 Business roles and UML activity diagram

Business role (actor)	Company role description
Source system	Makes report data available
Register	Receives report data

2.2.4 Information transfer

2.2.4.1 Systems & System Rolls

Systems:

• Source system of the steering organisation
• Register

System roles:

• Steering System Source
  • ReportDataBased Disclosure System (BBS-VGB)

• Receiving System Register
  • ReportDataReceivingSystem (BBS-VGO)

2.2.4.2 Transactions & Transaction Groups

The exchange of data between the different system roles is done on the basis of transactions, a collection of transactions (e.g. a question-and-answer message) forms what is known as a transaction group.

For details of the transactions taking place between system roles, see the technical message specification in ART-DECOR.

2.2.4.3 Coherence of business roles, activities, transactions, system roles and transaction groups

Transaction group	! Transactions	! System role	! System	! Business role	! Publication
Availability of report data for timeline	Availability of report data for timeline	BBS-VGB	Source system	Radiologist	V1.0.0-alpha.2
	Received Report Data	BBS-VGO	Registry	System	V1.0.0-alpha.2.

2.3 Usecase 2: Make image data available for timeline

2.3.1 Purpose and Relevance

To provide a complete timeline, the query point will need to have sufficient information available from previous investigations for this timeline data. To achieve this, a source system (usually an EHR) that wants to make a report or image available will have to make it known to a registry that is retrievable by the query point. The source system does this by sending metadata of the report or image to the registry. Depending on the infrastructure, the report itself may also be sent along. The image itself is not sent along and becomes available from the source system. This is described in more detail in the TO. Usually this is an automated process.

2.3.2 Process and Context (pre- and post-process)

2.3.2.1 Preprocess

• "Completing examination (authorising report)" precedes this. See 1.3.1 Guideline and process for the radiological examination process from request to authorisation report.

2.3.2.2 Process

• The source system sends the research data of the image to the registry tbv the timeline.

2.3.2.3 Postprocess

• The image of the study is registered in the register.
• The survey image is available to all systems that can retrieve timeline data.

2.3.3 Business roles and UML activity diagram

Business role (actor)	Company role description
Source system	Makes image data available
Register	Receives image data

2.3.4 Information transfer

2.3.4.1 Systems & System Rolls

Systems:

• Source system of the steering organisation
• Register

System roles:

• Steering System Source
  • BeneficiarySystem (BBS-BGB)

• Receiving System Register
  • ViewDataReceivingSystem (BBS-BGO)

2.3.4.2 Transactions & Transaction Groups

The exchange of data between the different system roles is done on the basis of transactions, a collection of transactions (e.g. a question-and-answer message) constitutes what is known as a transaction group.

For details of the transactions taking place between system roles, see the technical message specification in ART-DECOR.

2.3.4.3 Coherence of business roles, activities, transactions, system roles and transaction groups

Transaction group	! Transactions	! System role	! System	! Business role	! Publication
Make image data available for timeline	Make image data available for timeline	BBS-BGB	Source system	Radiologist	V1.0.0-alpha.2.
	Received Image Data	BBS-BGO	Registry	System	V1.0.0-alpha.2.

2.4 Usecase 3: Consult Timeline Data

2.4.1 Purpose and Relevance

By consulting the "radiological exam timeline" in their own working environment, the radiologist / treating physician gains insight into previously performed radiological examinations of the patient. This is essential for the proper, safe and responsible running of the radiological care process. Availability of previous examinations (images and reports) in addition to the most current ones is relevant in any care process, where images play a role.

If desired, only radiological examinations available at one patient's healthcare facility can also be shown on the timeline (see patient journey 2).

For consulting the timeline, patient consent (prior or ad hoc, in- or explicit) is assumed. In case the patient is in a life-threatening situation, unresponsive and no prior consent has been recorded, a break-the-glass procedure should be followed.

2.4.1.1 Patient journey

1. Regular referral (adapted from Quality Standard Image Availability)

Patient X with a known history reports to the GP with persistent complaints of fatigue. Based on her history and physical examination, the GP decides to request several blood tests and an X-ray of patient X's lungs at hospital A. The GP discusses the results of the tests with patient X. The blood values are normal, but the report from the radiologist at hospital A states that some was seen on the chest radiograph, and that further investigations should be considered. The GP suggests a referral to the pulmonologist. Given the waiting times, patient X chooses hospital B rather than hospital A. Pulmonologist B at hospital B receives patient X at her surgery. She listens to the patient's complaints and reads the results of previous investigations. She also consults the radiological exam timeline.

2. Consult studies from specific healthcare provider (adapted from Quality Standard Image Availability)

In 2018, patient Y falls off his bicycle and goes to A&E. Breathing hurts a lot. A&E doctor A has his chest X-rayed at hospital A. He is found to have several bruised ribs. In 2020, patient Y is referred to hospital B by his GP because he has persistent cough symptoms. Pulmonologist B orders an image of his lungs. Radiologist B, who reviews the images, sees a white spot on the lung. This could be a tumour but also a scar. Earlier examination may be more conclusive. Patient Y states that he has been to hospital A before. The radiologist consults the "radiological exam timeline" for hospital A and sees the 2018 chest radiograph. Radiologist B can compare the white spot on the lung with the 2018 photo and reports to the pulmonologist that it is most likely a scar.

2.4.2 Process and Context (pre- and post-process)

2.4.2.1 Preprocess

• The radiologist / attending physician has a treatment relationship with the patient.
• The radiologist/treating physician wants to involve previously performed radiological examinations to arrive at a better and more complete assessment, report and advice, than would be the case without it.

2.4.2.2 Process

• The radiologist / attending physician consults the "radiological exam timeline"

2.4.2.3 Postprocess

• The radiologist / treating physician gets the timeline available in his own working environment as part of his workflow and integrated in the local patient record (EPD) as well as in the patient's image file (PACS).
• The radiologist / treating physician sees all internal and external (from one or more healthcare providers) radiological examinations performed once in the timeline.
• The radiologist/treating physician may consult the images and reports of the examinations shown as the next step.

2.4.3 Business roles and UML activity diagram

Business role (actor)	Company role description
Radiologist	Makes timeline data available
Radiologist / treating physician	Consults timeline data

2.4.4 Information transfer

2.4.4.1 Systems & System Rolls

Systems:

• PACS/EPD of the consulting organisation
• PACS of the providing, producing organisation

System roles:

• Consulting System EPD / PACS
  • TimelineDataAdvisory System (BBS-TDR)

• Providing system PACS (producing organisation)
  • TimelineDataProvisioningSystem (BBS-TDB)

2.4.4.2 Transactions & Transaction Groups

The exchange of data between the different system roles is done on the basis of transactions, a collection of transactions (e.g. a question-and-answer message) forms what is known as a transaction group.

For details of the transactions taking place between system roles, see the technical message specification in ART-DECOR.

2.4.4.3 Coherence of business roles, activities, transactions, system roles and transaction groups

Transaction group	! Transactions	! System role	! System	! Business role	! Publication
Consult timeline data	Consult timeline data	BBS-TDR	PACS/EPD	Radiologist/Treasurer	V1.0.0-alpha.2.
	Make available timeline data	PACS	Radiologist	V1.0.0-alpha.2.

2.5 Usecase 4: Consult Report

2.5.1 Purpose and Relevance

The radiologist / attending physician consults relevant reports to arrive at a better and more complete judgement, report and advice, than would be the case without it. This is essential for the proper, safe and responsible conduct of the radiological care process. Availability of previous examinations (images and reports) alongside the most up-to-date ones is relevant in any care process, where images play a role. The radiologist/treating physician consults the report via the radiological exam timeline. Consultation of reports via the timeline assumes patient consent (prior or ad hoc, in- or explicit).

2.5.1.1 Patient journey

4. Regular referral (continuation of patient journey 3 from use case 3)

Radiologist B at hospital B reviews the CT thorax taken of patient X, consults the radiological exam timeline, sees that a thoracic radiograph was recently taken at hospital A and that her analysis and conclusion are in line with what radiologist A has included in the report. She produces the CT thorax report with her findings for pulmonologist B. Based on all the additional examination, pulmonologist B makes a diagnosis and the decision is made to treat with radiotherapy.

2.5.2 Process and Context (pre- and post-process)

2.5.2.1 Preprocess

Via timeline:

• Usecase 3 Consult timeline data.
• The radiologist / attending physician sees on the timeline a previous examination of which he wants to consult a report.

Off timeline:

• The radiologist / attending physician is aware of a previous examination of which he wishes to consult a report.

2.5.2.2 Process

• The radiologist / attending physician consults the report via the radiological exam timeline.

2.5.2.3 Postprocess

• The radiologist / attending physician sees the consulted report in its own working environment in its own format.

2.5.3 Business roles and UML activity diagram

Business role (actor)	Company role description
Radiologist	Provides report
Radiologist / treating physician	Consults report

2.5.4 Information transfer

2.5.4.1 Systems & System Rolls

Systems:

• PACS/EPD of the consulting organisation
• PACS of the providing, producing organisation

System roles:

• Consulting System EPD / PACS
  • ReportRepresentativeSystem (BBS-VR)

• Providing system PACS (producing organisation)
  • ReportingSystem(BBS-VB)

2.5.4.2 Transactions & Transaction Groups

The exchange of data between the different system roles is done on the basis of transactions, a collection of transactions (e.g. a question-and-answer message) forms what is known as a transaction group.

For details of the transactions taking place between system roles, see the technical message specification in ART-DECOR.

2.5.4.3 Coherence of business roles, activities, transactions, system roles and transaction groups

Transaction group	! Transactions	! System role	! System	! Business role	! Publication
Consult Report	Consult Report	BBS-VR	PACS/EPD	Radiologist/Treasurer	V1.0.0-alpha.2
	Make report available	BBS-VB	PACS	Radiologist	V1.0.0-alpha.2.

2.6 Usecase 5: Consult Image

2.6.1 Purpose and Relevance

The radiologist / treating physician consults relevant images to arrive at a better and more complete assessment, report and advice, than would be the case without it. This is essential for the proper, safe and responsible running of the radiological care process. Availability of previous examinations (images and reports) alongside the most up-to-date ones is relevant in any care process, where images play a role. The radiologist/treating physician consults images via the radiological exam timeline. For consulting images via the timeline, patient consent (prior or ad hoc, in- or explicit) is assumed.

2.6.1.1 Patient journey

3. Regular referral (continuation of patient journey 1 from use case 3)

Lung specialist B consults the radiological examination timeline and retrieves the examination from hospital A. Together with the patient, she reviews the chest radiograph from hospital A and what radiologist A saw on it. She decides to request a CT thorax to better determine what is in the lungs, and what can be ruled out.

2.6.2 Process and Context (pre- and post-process)

2.6.2.1 Preprocess

Via timeline:

• Usecase 3 Consult timeline data.
• The radiologist / attending physician sees on the timeline a previous examination whose images he wants to consult.

Off timeline:

• The radiologist / attending physician is aware of a previous examination whose images he wishes to consult.

2.6.2.2 Process

• The radiologist / attending physician consults the images via the radiological exam timeline.

2.6.2.3 Postprocess

• The radiologist / treating physician sees the retrieved images in his own working environment.

2.6.3 Business roles and UML activity diagram

Business role (actor)	Company role description
Radiologist	makes images available
Radiologist / treating physician	Consulting images

2.6.4 Information transfer

2.6.4.1 Systems & System Rolls

Systems:

• PACS/EPD of the consulting organisation
• PACS of the providing, producing organisation

System roles:

• Consulting System EPD / PACS
  • BeeldRaadpleeggendSysteem (BBS-BR)

• Providing system PACS (producing organisation)
  • ViewBroadcastingSystem (BBS-BB)

2.6.4.2 Transactions & Transaction Groups

The exchange of data between the different system roles is done on the basis of transactions, a collection of transactions (e.g. a question-and-answer message) constitutes what is known as a transaction group.

For details of the transactions taking place between system roles, see the technical message specification in ART-DECOR.

2.6.4.3 Coherence of business roles, activities, transactions, system roles and transaction groups

Transaction group	! Transactions	! System role	! System	! Business role	! Publication
View Image	Consult Image	BBS-BR	PACS/EPD	Radiologist/Treasurer	V1.0.0-alpha.2.
	Available image	BBS-BB	PACS	Radiologist	V1.0.0-alpha.2.

2.7 Usecase 6: Steering Image

Usecase PUSH is described in NEN standard but is not yet included in quality standard. As long as this usecase is not part of the quality standard, it cannot be part of the information standard either.

2.7.1 Purpose and Relevance

The use of the radiological exam timeline is guiding the desired functionality. However, the completeness and completeness of the timeline is subject to applicable data exchange laws and regulations. To exchange data by querying the timeline (pull), it is necessary in non-life-threatening situations that the patient has given prior consent to make the images available on a timeline of a requesting healthcare provider. Where this consent is explicitly lacking, in some cases permission to send data (push) can be assumed, making exchange via push possible.

In addition, healthcare providers may not yet have the appropriate IT infrastructure and applications for making images and reports available or able to retrieve them on a timeline.

For these cases, the NEN standard Image Availability describes a data exchange based on push. This allows healthcare providers who cannot (yet) offer data on or request data via the timeline to actively send data, and allows healthcare providers in general to send images and reports based on presumed consent. The active sending of images can also be done via an invitation to retrieve data (e.g. with a link), see Usecase 2: Consult Image.

2.7.2 Process and Context (pre- and post-process)

2.7.2.1 Preprocess

• Permission to make radiological studies available on the timeline is explicitly missing or healthcare provider does not have access to the timeline
• The radiologist / attending physician contacts the healthcare provider where radiological examinations of the patient are available
• The radiologist / treating physician requests images to be sent

2.7.2.2 Process

• The radiologist sends images to the radiologist / treating physician

2.7.2.3 Postprocess

• The radiologist / treating physician sees the sent images in his own working environment.

2.7.3 Business roles and UML activity diagram

Business role (actor)	Company role description
Radiologist / treating physician	Sends images
Radiologist	Receives images

2.7.4 Information transfer

2.7.4.1 Systems & System Rolls

Systems:

• PACS of the steering, producing organisation
• PACS/EPD of the receiving organisation

System roles:

• Steering system PACS (producing organisation)
  • BeeldSteeringSystem (BBS-BS)

• Receiving System EPD / PACS
  • ViewBoostingSystem (BBS-BO)

2.7.4.2 Transactions & Transaction Groups

The exchange of data between the different system roles is done on the basis of transactions, a collection of transactions (e.g. a question-and-answer message) forms what is known as a transaction group.

For details of the transactions taking place between system roles, see the technical message specification in ART-DECOR.

2.7.4.3 Coherence of business roles, activities, transactions, system roles and transaction groups

Transaction group	! Transactions	! System role	! System	! Business role	! Publication
Send Image	BBS-BS	PACS	Radiologist	Draft V0.4.0.
	Received image	BBS-BO	PACS/EPD	Radiologist/Treasurer	Empty

2.8 Usecase 7: Send Report

'Usecase PUSH is described in NEN standard but is not yet included in quality standard. As long as this usecase is not part of the quality standard, it cannot be part of the information standard either.

2.8.1 Purpose and Relevance

The use of the timeline of images and reports guides the desired functionality. However, the completeness and completeness of the timeline is subject to applicable data exchange laws and regulations. The exchange of data via querying the timeline (pull) requires the patient's prior consent to make the images available on a requesting healthcare provider's timeline. If this consent is explicitly lacking, in some cases permission to send data (push) can be assumed, making exchange via push possible. In addition, healthcare providers may not yet have the right IT infrastructure and applications in place for making images and reports available or able to request them on a timeline. For these cases, this standard describes a data exchange based on push. This allows healthcare providers who cannot (yet) offer data on or retrieve data via the timeline to actively send data, and allows healthcare providers in general to send images based on presumed consent. The active sending of reports can also be done via an invitation to retrieve data (e.g. with a link), see Use_case 3: Consult Report.

2.8.2 Process and Context (pre- and post-process)

2.8.2.1 Preprocess

• Permission to make radiological studies available on the timeline is explicitly missing or healthcare provider does not have access to the timeline
• The radiologist / attending physician contacts the healthcare provider where radiological examinations of the patient are available
• The radiologist / treating physician requests a report to be sent

2.8.2.2 Process

• The radiologist sends a report to the radiologist / attending physician

2.8.2.3 Postprocess

• The radiologist / treating physician sees the sent report in his own working environment.

2.8.3 Business roles and UML activity diagram

Business role (actor)	Company role description
Radiologist / treating physician	Sends reports
Radiologist	Receives reports

2.8.4 Information transfer

2.8.4.1 Systems & System Rolls

Systems:

• PACS of the steering, producing organisation
• PACS/EPD of the receiving organisation

System roles:

• Steering system PACS (producing organisation)
  • ReportingSteeringSystem (BBS-BS)

• Receiving System EPD / PACS
  • ReportReceivingSystem (BBS-BO)

2.8.4.2 Transactions & Transaction Groups

The exchange of data between the different system roles is done on the basis of transactions, a collection of transactions (e.g. a question-and-answer message) constitutes what is known as a transaction group.

For details of the transactions taking place between system roles, see the technical message specification in ART-DECOR.

2.8.4.3 Coherence of business roles, activities, transactions, system roles and transaction groups

Transaction group	! Transactions	! System role	! System	! Business role	! Publication
Send Report	BBS-VS	PACS	Radiologist	Draft V0.4.0.
	Received Report	BBS-VO	PACS/EPD	Radiologist/Treasurer	Empty

3 Additional information

3.1 Notes/requirements for functionality of systems

3.1.1 Unity of language

For unity of language, SNOMED is used as much as possible.

3.1.2 IHE standard

The information standard and workflow is based on the [Integrating the Healthcare Enterprise (IHE)] standard. The exact profiles and transactions used are described in more detail in the Technical Design.

3.1.3 Information link image and report

Images and reports are inextricably linked. At the information layer, this link is represented by the relationship between report and investigation: an investigation with the status "Completed" or "Modified" must always contain a report. For emergency care, images can also be made available before the investigation is reports. At the application layer, image, report and examination are linked by means of a unique ID (within radiology, the accession number).

3.2 List of terms

Comprehension	Description
ART-DECOR	international platform for developing, capturing and managing healthcare information standards.
EPD	Electronic Patient Record
FO	Functional Design
IHE	Integrating the Healthcare Enterprise
NEN	Netherlands Standard
NVvR	Dutch Society of Radiology
PACS	Picture Archiving and Communication System
TO	Technical Design
zibs	Healthcare information building blocks
Care provider	Healthcare providers are all persons who may have a treatment relationship with a patient.

5 Release Notes

Version	Date	Author(s)	Description	Organisation
1.0.0-alpha.2	9 February 2024	Wai-Lam Wong and Taco Spitters	Addition Registration usecases. New value lists used for DepartmentSpecialty and AnatomicalLocation to align with the IHE MCWG proposed value lists for practiceSettingCode and AnatomicalRegion. See release notes for further changes.	Nictiz
1.0.0-alpha.1	1 July 2023	Wai-Lam Wong and Taco Spitters	FO-wiki: 1) Textual adjustments. 2) Pictures added at UC4 and UC5. UC4 and UC5 are not yet technically developed, therefore not yet fully described in ART-DECOR. 3) Added links to ART-DECOR. ART-DECOR: 1) Clean-up of the Consult and Make Available scenarios UC1, UC2, UC3. Removed all items not actually exchanged in this version via XCA-I.	Nictiz
0.4.0	8 December 2022	Wai-Lam Wong and Anne van der Kant	Second draft version for consultation	Nictiz