Skip to content

Commit 33a324c

Browse files
oijaureguioijauregui
committed
split pages
1 parent 35ada0d commit 33a324c

12 files changed

Lines changed: 438 additions & 420 deletions

‎ig-src/input/pagecontent/use-case-actors-obligations.md‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
## Use Cases based on Actors and Obligations
2+
A number of actors and use cases have been identified as a minimal set of functionalities that are needed to support the use of the EHDS Imaging Report specification. These use cases are described in the following figure.
3+
4+
TBD: harmonize with the actors and transactions page and add obligations
5+
6+
<figure>
7+
{% include ehds-actors-usecases.svg %}
8+
<figcaption>Figure: EHDS Imaging Report Functional Use Cases</figcaption>
9+
</figure>
10+
<br clear="all"/>

‎ig-src/input/pagecontent/use-case-data-formats.md‎

Lines changed: 127 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,127 @@
1+
## Use cases based on Data Formats
2+
The EHDS Imaging Report specification supports the use of different data formats for the representation of imaging reports, that introduce increasing level of structure to the data exchanged.
3+
4+
### Renderable format with basic metadata
5+
Comprised of a `Bundle` of type collection containging a `DiagnosticReport` with a reference to a PDF (or other renderable format) attachment through .presentedForm, the `ImagingStudy` resource/s that is the object of the report, and the `ServiceRequest` that representd the original order for the study, and the `Patient` to whom the report belong. Other resources are also allowed, to encode other elements of the report environment, as specified by this IG. A `DocumentReference` resource wrapper pointing to the `Bundle` is be used to encode the elements uses as search parameters to fullfil functional requirments of the ACCESS actor.
6+
Note that no `Composition` resource is used in this case, and the `DiagnosticReport` is used as the main resource to represent the report.
7+
This level of structure allows to have a human readable report (the PDF) that can fullfill the requirements of the DISPLAY actor, while also having some basic metadata about the report and its connection with the imaging study and service request.
8+
9+
```mermaid
10+
classDiagram
11+
class DocumentReference {
12+
+subject : Reference~Patient~
13+
+date : dateTime
14+
+type : CodeableConcept
15+
+category : CodeableConcept
16+
+content: Bundle
17+
...
18+
}
19+
20+
class Bundle {
21+
<<type: collection>>
22+
23+
}
24+
25+
class DiagnosticReport {
26+
<<main resource>>
27+
+presentedForm : Attachment~PDF~
28+
+imagingStudy : Reference~ImagingStudy~
29+
+basedOn : Reference~ServiceRequest~
30+
...
31+
}
32+
33+
class ImagingStudy {
34+
<<optional in Bundle>>
35+
+identifier : StudyInstanceUidIdentifierEuImaging
36+
...
37+
}
38+
39+
class ServiceRequest {
40+
<<optional in Bundle>>
41+
+identifier : AccessionNumberIdentifierEuImaging
42+
...
43+
}
44+
45+
class PDF {
46+
<<attachment>>
47+
+contentType : "application/pdf"
48+
+data : base64Binary
49+
}
50+
51+
DocumentReference --> Bundle : content
52+
Bundle --> DiagnosticReport : entry
53+
Bundle --> ImagingStudy : entry (optional)
54+
Bundle --> ServiceRequest : entry (optional)
55+
DiagnosticReport --> PDF : presentedForm
56+
DiagnosticReport --> ImagingStudy : imagingStudy
57+
DiagnosticReport --> ServiceRequest : basedOn
58+
```
59+
60+
### Section-strucured report with processable narrative
61+
Building on top of the previous data format, the `DiagnosticReport` is exchanged alongside with a `Composition` as entries of a `Bundle` of type `document`. Both `DiagnosticReport` and `Composition` encode the same information, but the `Composition` can be used for display purposes, especially the narrative sections of the report, while the `DiagnosticReport` can be used for the interpretation of the structured data. The `DocumentReference` resource wrapper, as in the previous case, as interface layer to surface search paramenters that allow finding and retrieving the report.
62+
In this case the .pdf looses relevance, as the narrative of the `Composition` can adapt dinamycally to different display contexts. However, the .pdf can still be included as an attachment in the `DiagnosticReport` for archival purposes, or for use cases where a human readable report is needed without the need for structured data. Creators of this type of report must ensure a tight consistency between the narrative of the `Composition` and the .pdf, as they are both intended for display purposes.
63+
This data structure is the one that should be utilizaed to map the existing implementations that utilizes HL2 V2 messages or DICOM SR containing a CDA or other .xml or .html file as the report content.
64+
This level of structure allows to have a PROCESSOR actor that can interpret the structured data and the narrative (as it is exchagned in a machine readable format).
65+
66+
```mermaid
67+
classDiagram
68+
class DocumentReference {
69+
+subject : Reference~Patient~
70+
+date : dateTime
71+
+type : CodeableConcept
72+
+category : CodeableConcept
73+
+content : Bundle
74+
...
75+
}
76+
77+
class Bundle {
78+
<<type: document>>
79+
}
80+
81+
class Composition {
82+
<<first entry - for display purposes>>
83+
+section : BackboneElement[]
84+
+section.text : Narrative
85+
...
86+
}
87+
88+
class DiagnosticReport {
89+
<<for structured data>>
90+
+presentedForm : Attachment~PDF~ (optional)
91+
...
92+
}
93+
94+
class ImagingStudy {
95+
...
96+
}
97+
98+
class ServiceRequest {
99+
...
100+
}
101+
102+
class Observation {
103+
<<findings / measurements>>
104+
...
105+
}
106+
107+
class PDF {
108+
<<optional attachment>>
109+
110+
}
111+
112+
DocumentReference --> Bundle : content
113+
Bundle --> Composition : entry[0]
114+
Bundle --> DiagnosticReport : entry
115+
Bundle --> ImagingStudy : entry
116+
Bundle --> ServiceRequest : entry
117+
Bundle --> Observation : entry
118+
DiagnosticReport --> ImagingStudy : imagingStudy
119+
DiagnosticReport --> ServiceRequest : basedOn
120+
DiagnosticReport --> Observation : result
121+
DiagnosticReport --> PDF : presentedForm (optional)
122+
DiagnosticReport --> Composition : composition
123+
```
124+
125+
### Fully structured report
126+
This case builds on top of the previous one, but in this case the findings and impressions of the report are coded (ideally a standard clinical or radiology domain terminology) and encoded in FHIR `Observation` and `Condition` resources. This allows to have a fully computable report that can be easily integrated with other data sources, and that can be used for advanced use cases such as clinical decision support, research, etc. The `Composition` resource is still used for display purposes, but the narrative of the sections can be generated dynamically based on the coded data, and the .pdf looses relevance in this case.
127+
It is expected that most systems will not be able to produce this level of structure in the short term, but it is important to have it as a long term goal, as it allows to fully leverage the potential of the FHIR format for imaging reports.

‎ig-src/input/pagecontent/use-case-ihe-idr-alignment.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
## Alignment between IHE IDR and EHDS Imaging Report IG
2+
This Specification is being aligned with the {{iheIDR}}, as detailed in [Imaging Report](imaging-report.html), and it is expected that implementations of this IG can be conformant with the IHE IDR profile. An IDR resource might not be valid against this is specification, as this is model includes further Europe-specific contrainst.
3+
The main difference between the two specifications are that the IHE IDR profile is focused on the exchange of imaging reports with a resource-level acces, while this IG also enables the exchange of imaging reports with a document-level access, through the use of the `DocumentReference` resource as a wrapper for the `Bundle` containing the report. The second difference is that this IG has a tigher integration between the imaging report and imaging study, achievend through the [IHE MADO (Manifest-based Access to DICOM Objects) profile](https://euridice.org/mado/), while the IHE IDR profile is more agnostic in this regard.
4+
The alignment between the two specifications is being achieved through a close collaboration between the teams working on both specifications, and through the use of common resources and data structures where possible.

‎ig-src/input/pagecontent/use-cases.md‎

Lines changed: 5 additions & 140 deletions
Original file line numberDiff line numberDiff line change
@@ -1,146 +1,11 @@
1+
{% include variable-definitions.md %}
2+
13
# Use Cases
24
This page explains the use cases that are supported by the specification. It also describes the actors involved in these use cases and their obligations.
35
There are a number of angles to look at the use cases. One is based on the different user/system actors involved and their obligations. Another is based on the different data formats that are supported. Also, the way how this specification is connected with the IHE MADE profile, and with the EHDS API specification are explained from a functional perspective.
46

5-
## Use Cases based on Actors and Obligations
6-
A number of actors and use cases have been identified as a minimal set of functionalities that are needed to support the use of the EHDS Imaging Report specification. These use cases are described in the following figure.
7-
8-
TBD: harmonize with the actors and transactions page and add obligations
9-
10-
<figure>
11-
{% include ehds-actors-usecases.svg %}
12-
<figcaption>Figure: EHDS Imaging Report Functional Use Cases</figcaption>
13-
</figure>
14-
<br clear="all"/>
15-
16-
## Use cases based on Data Formats
17-
The EHDS Imaging Report specification supports the use of different data formats for the representation of imaging reports, that introduce increasing level of structure to the data exchanged.
18-
19-
### Renderable format with basic metadata
20-
Comprised of a `Bundle` of type collection containging a `DiagnosticReport` with a reference to a PDF (or other renderable format) attachment through .presentedForm, the `ImagingStudy` resource/s that is the object of the report, and the `ServiceRequest` that representd the original order for the study, and the `Patient` to whom the report belong. Other resources are also allowed, to encode other elements of the report environment, as specified by this IG. A `DocumentReference` resource wrapper pointing to the `Bundle` is be used to encode the elements uses as search parameters to fullfil functional requirments of the ACCESS actor.
21-
Note that no `Composition` resource is used in this case, and the `DiagnosticReport` is used as the main resource to represent the report.
22-
This level of structure allows to have a human readable report (the PDF) that can fullfill the requirements of the DISPLAY actor, while also having some basic metadata about the report and its connection with the imaging study and service request.
23-
24-
```mermaid
25-
classDiagram
26-
class DocumentReference {
27-
+subject : Reference~Patient~
28-
+date : dateTime
29-
+type : CodeableConcept
30-
+category : CodeableConcept
31-
+content: Bundle
32-
...
33-
}
34-
35-
class Bundle {
36-
<<type: collection>>
37-
38-
}
39-
40-
class DiagnosticReport {
41-
<<main resource>>
42-
+presentedForm : Attachment~PDF~
43-
+imagingStudy : Reference~ImagingStudy~
44-
+basedOn : Reference~ServiceRequest~
45-
...
46-
}
47-
48-
class ImagingStudy {
49-
<<optional in Bundle>>
50-
+identifier : StudyInstanceUidIdentifierEuImaging
51-
...
52-
}
53-
54-
class ServiceRequest {
55-
<<optional in Bundle>>
56-
+identifier : AccessionNumberIdentifierEuImaging
57-
...
58-
}
59-
60-
class PDF {
61-
<<attachment>>
62-
+contentType : "application/pdf"
63-
+data : base64Binary
64-
}
65-
66-
DocumentReference --> Bundle : content
67-
Bundle --> DiagnosticReport : entry
68-
Bundle --> ImagingStudy : entry (optional)
69-
Bundle --> ServiceRequest : entry (optional)
70-
DiagnosticReport --> PDF : presentedForm
71-
DiagnosticReport --> ImagingStudy : imagingStudy
72-
DiagnosticReport --> ServiceRequest : basedOn
73-
```
74-
75-
### Section-strucured report with processable narrative
76-
Building on top of the previous data format, the `DiagnosticReport` is exchanged alongside with a `Composition` as entries of a `Bundle` of type `document`. Both `DiagnosticReport` and `Composition` encode the same information, but the `Composition` can be used for display purposes, especially the narrative sections of the report, while the `DiagnosticReport` can be used for the interpretation of the structured data. The `DocumentReference` resource wrapper, as in the previous case, as interface layer to surface search paramenters that allow finding and retrieving the report.
77-
In this case the .pdf looses relevance, as the narrative of the `Composition` can adapt dinamycally to different display contexts. However, the .pdf can still be included as an attachment in the `DiagnosticReport` for archival purposes, or for use cases where a human readable report is needed without the need for structured data. Creators of this type of report must ensure a tight consistency between the narrative of the `Composition` and the .pdf, as they are both intended for display purposes.
78-
This data structure is the one that should be utilizaed to map the existing implementations that utilizes HL2 V2 messages or DICOM SR containing a CDA or other .xml or .html file as the report content.
79-
This level of structure allows to have a PROCESSOR actor that can interpret the structured data and the narrative (as it is exchagned in a machine readable format).
80-
81-
```mermaid
82-
classDiagram
83-
class DocumentReference {
84-
+subject : Reference~Patient~
85-
+date : dateTime
86-
+type : CodeableConcept
87-
+category : CodeableConcept
88-
+content : Bundle
89-
...
90-
}
91-
92-
class Bundle {
93-
<<type: document>>
94-
}
95-
96-
class Composition {
97-
<<first entry - for display purposes>>
98-
+section : BackboneElement[]
99-
+section.text : Narrative
100-
...
101-
}
102-
103-
class DiagnosticReport {
104-
<<for structured data>>
105-
+presentedForm : Attachment~PDF~ (optional)
106-
...
107-
}
108-
109-
class ImagingStudy {
110-
...
111-
}
112-
113-
class ServiceRequest {
114-
...
115-
}
116-
117-
class Observation {
118-
<<findings / measurements>>
119-
...
120-
}
121-
122-
class PDF {
123-
<<optional attachment>>
124-
125-
}
7+
{% include use-case-actors-obligations.md %}
1268

127-
DocumentReference --> Bundle : content
128-
Bundle --> Composition : entry[0]
129-
Bundle --> DiagnosticReport : entry
130-
Bundle --> ImagingStudy : entry
131-
Bundle --> ServiceRequest : entry
132-
Bundle --> Observation : entry
133-
DiagnosticReport --> ImagingStudy : imagingStudy
134-
DiagnosticReport --> ServiceRequest : basedOn
135-
DiagnosticReport --> Observation : result
136-
DiagnosticReport --> PDF : presentedForm (optional)
137-
DiagnosticReport --> Composition : composition
138-
```
139-
### Fully structured report
140-
This case builds on top of the previous one, but in this case the findings and impressions of the report are coded (ideally a standard clinical or radiology domain terminology) and encoded in FHIR `Observation` and `Condition` resources. This allows to have a fully computable report that can be easily integrated with other data sources, and that can be used for advanced use cases such as clinical decision support, research, etc. The `Composition` resource is still used for display purposes, but the narrative of the sections can be generated dynamically based on the coded data, and the .pdf looses relevance in this case.
141-
It is expected that most systems will not be able to produce this level of structure in the short term, but it is important to have it as a long term goal, as it allows to fully leverage the potential of the FHIR format for imaging reports.
9+
{% include use-case-data-formats.md %}
14210

143-
## Alignment between IHE IDR and EHDS Imaging Report IG
144-
This Specification is being aligned with the {{iheIDR}}, as detailed in [Imaging Report](imaging-report.html), and it is expected that implementations of this IG can be conformant with the IHE IDR profile. An IDR resource might not be valid against this is specification, as this is model includes further Europe-specific contrainst.
145-
The main difference between the two specifications are that the IHE IDR profile is focused on the exchange of imaging reports with a resource-level acces, while this IG also enables the exchange of imaging reports with a document-level access, through the use of the `DocumentReference` resource as a wrapper for the `Bundle` containing the report. The second difference is that this IG has a tigher integration between the imaging report and imaging study, achievend through the [IHE MADO (Manifest-based Access to DICOM Objects) profile](https://euridice.org/mado/), while the IHE IDR profile is more agnostic in this regard.
146-
The alignment between the two specifications is being achieved through a close collaboration between the teams working on both specifications, and through the use of common resources and data structures where possible.
11+
{% include use-case-ihe-idr-alignment.md %}

‎igs/imaging-r4/input/pagecontent/use-case-actors-obligations.md‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
## Use Cases based on Actors and Obligations
2+
A number of actors and use cases have been identified as a minimal set of functionalities that are needed to support the use of the EHDS Imaging Report specification. These use cases are described in the following figure.
3+
4+
TBD: harmonize with the actors and transactions page and add obligations
5+
6+
<figure>
7+
{% include ehds-actors-usecases.svg %}
8+
<figcaption>Figure: EHDS Imaging Report Functional Use Cases</figcaption>
9+
</figure>
10+
<br clear="all"/>

0 commit comments

Comments
 (0)