Fix workflow: replace problematic find command with safer file deletion

Author: oijauregui

.github/workflows/deploy-to-repos.yml

@@ -53,14 +53,13 @@ jobs:
       - name: Sync R4 content
         run: |
           # Remove all content from target repo except .git
-          find ./r4-repo -mindepth 1 -name '.git' -prune -o -type f -delete
-          find ./r4-repo -mindepth 1 -name '.git' -prune -o -type d -empty -delete
+          find ./r4-repo -mindepth 1 -maxdepth 1 ! -name '.git' -exec rm -rf {} +
 
           # Copy imaging-r4 content to root of target repository
           cp -r ./igs/imaging-r4/* ./r4-repo/
           
-          # Ensure hidden files are copied too
-          cp -r ./igs/imaging-r4/.* ./r4-repo/ 2>/dev/null || true
+          # Ensure hidden files are copied too (excluding .git)
+          find ./igs/imaging-r4 -name ".*" -not -name ".git" -not -name "." -not -name ".." -exec cp -r {} ./r4-repo/ \; 2>/dev/null || true
 
       - name: Commit and push R4 changes
         working-directory: ./r4-repo
@@ -123,14 +122,13 @@ jobs:
       - name: Sync R5 content
         run: |
           # Remove all content from target repo except .git
-          find ./r5-repo -mindepth 1 -name '.git' -prune -o -type f -delete
-          find ./r5-repo -mindepth 1 -name '.git' -prune -o -type d -empty -delete
+          find ./r5-repo -mindepth 1 -maxdepth 1 ! -name '.git' -exec rm -rf {} +
 
           # Copy imaging-r5 content to root of target repository
           cp -r ./igs/imaging-r5/* ./r5-repo/
           
-          # Ensure hidden files are copied too
-          cp -r ./igs/imaging-r5/.* ./r5-repo/ 2>/dev/null || true
+          # Ensure hidden files are copied too (excluding .git)
+          find ./igs/imaging-r5 -name ".*" -not -name ".git" -not -name "." -not -name ".." -exec cp -r {} ./r5-repo/ \; 2>/dev/null || true
 
       - name: Commit and push R5 changes
         working-directory: ./r5-repo

igs/imaging-r4/FHIR-eu-imaging-r4.xml

@@ -1,3 +1,10 @@
+
+
+{% assign hl7EuBase         = "[HL7 EU Base](https://hl7.eu/fhir/base/)" %}
+{% assign hl7EuMpd          = "[HL7 EU MPD](https://hl7.eu/fhir/mpd/)" %}
+
+
+
 {% assign ehnImaging        = "[eHN Imaging Studies and Reports](https://health.ec.europa.eu/publications/ehn-guidelines-medical-imaging-studies-and-reports_en)" %}
 {% assign ehnImagingGuidelines = "[eHN Imaging Studies and Reports](https://health.ec.europa.eu/publications/ehn-guidelines-medical-imaging-studies-and-reports_en) guidelines" %}
 {% assign ehnImagingHtml    = '<a href="https://health.ec.europa.eu/publications/ehn-guidelines-medical-imaging-studies-and-reports_en">eHN Imaging Studies and Reports</a>' %}
@@ -10,12 +17,12 @@
 {% assign iheIid            = "[IHE-IID](https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_IID.pdf)" %}
 {% assign iheIDR            = "[IHE-IDR](https://build.fhir.org/ig/IHE/RAD.IDR/)" %}
 
-{% assign hl7EuBase         = "[HL7 EU Base](https://build.fhir.org/ig/hl7-eu/base-r5/)" %}
-{% assign hl7EuExtensions   = "[HL7 Europe Extensions](https://build.fhir.org/ig/hl7-eu/extensions-r5/)" %}
+{% assign hl7EuExtensions   = "[HL7 Europe Extensions](https://hl7.eu/fhir/extensions/)" %}
 {% assign hl7EuLabs         = "[HL7 EU Laboratory Reports](https://build.fhir.org/ig/hl7-eu/laboratory/branches/master/index.html)" %}
 {% assign hl7EuHdr          = "[HL7 EU Hospital Discharge Reports](https://build.fhir.org/ig/hl7-eu/hdr/index.html)" %}
 {% assign hl7EuEps          = "[HL7 Europe Patient Summary](https://build.fhir.org/ig/hl7-eu/eps/)" %}
 
+
 {% assign ArgImg            = "[Argonaut Imaging](https://github.com/sync-for-science/imaging)" %}
 
 {% assign DICOMwebWado      = "[DICOMweb-WADO](https://www.dicomstandard.org/using/dicomweb/retrieve-wado-rs-and-wado-uri/)" %}

igs/imaging-r4/input/includes/fhir-resources.md

@@ -5,26 +5,27 @@ This section describes the approach taken in the specification related to obliga
 
 The specification recognizes the following actors:
 
-* ImManifestProvider - provides the imaging studies manifest.
+* BundleReportEuImagingCreator - creates the imaging studies report.
 * BundleReportEuImagingProvider - provides the imaging studies report.
 
 #### Provider obligations
-The ImProvider provides the information. In this case this means that it has to provide the information defined in the eHN Guidelines that are further refined by Xt-EHR in the Xt-EHR logical model. 
+The BundleReportEuImagingProvider provides the information. In this case this means that it has to provide the information defined in the eHN Guidelines that are further refined by Xt-EHR in the Xt-EHR logical model.
 
-All data elements in the Xt-EHR model are mapped onto one or more FHIR elements (see the mapping section in the spec). In order to ensure that the provider populates these data elements, a requirement/obligation is placed on each FHIR element referred to in the mapping.
+All data elements in the Xt-EHR model are mapped onto one or more FHIR elements (see the [mapping section](xtehr-mapping.html) in the spec). In order to ensure that the provider populates these data elements, a requirement/obligation is placed on each FHIR element referred to in the mapping.
 
 The obligation used has the following fields:
+
+| Field | Value |
+|-------|-------|
 | code	| SHALL:populate-if-known |
-| actor |	ImManifestProvider or BundleReportEuImagingProvider |
+| actor |	BundleReportEuImagingCreator or BundleReportEuImagingProvider |
 | documentation | list of XtEHR paths that map on this obligation |
 
 This means that the provider SHALL populate these fields it has the information.
 
-
-#### Using obligations in resources
+<!-- #### Using obligations in resources
 The obligation extensions will be placed in the profiles. In order to make the profiles clear and concise, for each profile with obligations, sub-profiles will be created.
 
 The main profile will have the structural constraints. The actor specific sub-profile will only hold the obligations placed on the actors.
 
-For ImProvider based profiles, the obligations will in the 'documentation' field, indicate the source Xt-EHR requirement the obligation was derived from.
-
+For BundleReportEuImagingProvider based profiles, the obligations will in the 'documentation' field, indicate the source Xt-EHR requirement the obligation was derived from. -->

igs/imaging-r4/input/includes/variable-definitions.md

@@ -1,6 +1,6 @@
 ### FHIR representation of the report
 
-This guide is part of the HL7 EU suite of report related implementation guides that also includes ,  and .
+This guide is part of the HL7 EU suite of report related implementation guides that also includes {{hl7EuLabs}}, {{hl7EuHdr}} and {{hl7EuEps}}.
 
 
 

igs/imaging-r4/input/pagecontent/design-consideration-actors-obligations.md

@@ -4,7 +4,7 @@ One of the choices made in the IG is the structure of the Composition resource.
 
 * Leave it open for users of the implementation guide.
 * Follow the structure of the presented form (rendered document).
-* Follow the structure of the {{ehnImagingGuidelines}}.
+* Follow the structure of the {% raw %}{{ehnImagingGuidelines}}{% endraw %}.
 * Adopt the structure defined in IHE-IDR.
 
 Linking the structure of the composition of the presented form will cause difficulties as it requires importers of such documents to understand and properly represent such structure which might place undue burden on such import process.

igs/imaging-r4/input/pagecontent/design-consideration-composition-diagnosticreport.md

@@ -4,8 +4,8 @@ This IG describes a large set of different resources. Using FHIR search operatio
 
 The goal of this IG is to provide information on Imaging Reports and Imaging Studies. Although it will allow for other ways to access information, the main "data entrypoints" are the resources that represent these resources.
 
-Each imaging study is represented by a _single_  resource.  
-Each imaging report is represented by a  resource. There might be more than one instance of the , when the status of the report changes. All of these will have the same `identifier`. The  holds the structured representation of the report. The  represents a rendering of the data in the report. All structured data present in the  SHALL also be present in the . This specification suggests a set of sections for the Composition which implementers are RECOMMENDED to follow.
+Each imaging study is represented by a _single_ {{ImagingStudy}} resource.  
+Each imaging report is represented by a {{DiagnosticReport}} resource. There might be more than one instance of the {{DiagnosticReport}}, when the status of the report changes. All of these will have the same `identifier`. The {{DiagnosticReport}} holds the structured representation of the report. The {{Composition}} represents a rendering of the data in the report. All structured data present in the {{DiagnosticReport}} SHALL also be present in the {{Composition}}. This specification suggests a set of sections for the Composition which implementers are RECOMMENDED to follow.
 
 
 
@@ -29,6 +29,6 @@ classDiagram
   note for ImagingStudyEuImaging "entry point for study"
 ```
 
-When modelling the IG, it is assumed that information related to the report will be gathered by starting at the  and information related to the imaging study from the .
+When modelling the IG, it is assumed that information related to the report will be gathered by starting at the {{DiagnosticReport}} and information related to the imaging study from the {{ImagingStudy}}.
 
-All information related to the report will referred to from the . All important structured information used for searching will be referred to from the . The structure of the  is subject to change and less formal on the meaning on referred to resources. When possible, such references will be made from the .
+All information related to the report will referred to from the {{Composition}}. All important structured information used for searching will be referred to from the {{DiagnosticReport}}. The structure of the {{Composition}} is subject to change and less formal on the meaning on referred to resources. When possible, such references will be made from the {{DiagnosticReport}}.

igs/imaging-r4/input/pagecontent/design-consideration-composition-structure.md

@@ -1,7 +1,7 @@
 ### Representing Healthcare Professionals
 
-When referring to healthcare professionals, the  include information on the professional as well as on the organization the professional is associated with (e.g. information recipient, author, resultValidator, etc.). In FHIR a healthcare professional is represented as a `Practitioner`. As a healthcare professional can be employed by multiple organizations, a different resource,`PractitionerRole` models the relationship between the healthcare professional and an organization.
-For the representation of healthcare professionals, organizations and the relations between them, this implementation guide uses the profiles defined by :
+When referring to healthcare professionals, the {% raw %}{{ehnImagingGuidelines}}{% endraw %} include information on the professional as well as on the organization the professional is associated with (e.g. information recipient, author, resultValidator, etc.). In FHIR a healthcare professional is represented as a `Practitioner`. As a healthcare professional can be employed by multiple organizations, a different resource,`PractitionerRole` models the relationship between the healthcare professional and an organization.
+For the representation of healthcare professionals, organizations and the relations between them, this implementation guide uses the profiles defined by  {% raw %}{{hl7EuBase}}{% endraw %}.:
 
 ```mermaid
 classDiagram
@@ -28,4 +28,4 @@ classDiagram
     SrcResource --> EuPractitionerRole
     EuPractitionerRole --> EuOrganization: organization
     EuPractitionerRole --> EuPractitioner: practitioner
-```
+```

igs/imaging-r4/input/pagecontent/design-consideration-data-entrypoints.md

@@ -2,14 +2,14 @@
 
 Key images can be represented in two ways:
 
-* ImagingSelection
-* DocumentReference
 
-ImagingSelection if more DICOM oriented and only relates to DICOM identifiers. DocumentReference is more image oriented and also contains information on the size, duration, etc. aspects of the image.
+* ImagingSelection (Implemented in this R4 IG by the [ImagingSelectionEuImaging](StructureDefinition-ImagingSelectionEuImaging.html) profile on top of a `Basic` resource with a cross-version extension backporting the R5 ImagingSelection structure)
+* DocumentReference
 
+ImagingSelection is more DICOM oriented and only relates to DICOM identifiers. DocumentReference is more image oriented and also contains information on the size, duration, etc. aspects of the image.
 The {{ehnImagingGuidelines}} requires information on the size, format, duration etc., data elements that are provided on the `Attachment` field on `DocumentReference`. If these fields are critical, DocumentReference fits more closely. In US Core the R4 `Media` resource is used to represent key images. This resource later merged into the FHIR R5 `DocumentReference`.
 
-As this IG has an FHIR R5 and R4 representation, `DocumentReference` is an easy fit but in other sections of this specification, ImagingSelection is used (e.g. to state that an image can from a Procedure Phase).
+As this IG has an FHIR R5 and R4 representation, `DocumentReference` is an easy fit but in other sections of this specification, `ImagingSelection` is used (e.g. to state that an image can from a Procedure Phase).
 
 The `ImagingSelection` resource points to a DICOM data. The DICOM instance data also holds the data required by the {{ehnImaging}}. So the client can retrieve the information from the DICOM source data.
 
@@ -30,20 +30,15 @@ That leaves the question in what way are these resources linked into the overall
 ```mermaid
 classDiagram
     direction TD
-    class ImKeyImagingSelection{ 
-        <<ImagingSelection>>
-        studyUid
-    }
-    class ImKeyImagingInstanceSelection{ 
-        <<ImagingSelection>>
-        studyUid
-    }
-    class ImKeyImagingSerieSelection{ 
-        <<ImagingSelection>>
-        studyUid
-        instance.uid
+
+
+    class ImagingSelectionKeyImageEuImaging{ 
+        <<Basic as ImagingSelection>>
+        extension[ImagingSelection].extension[studyUid].value
+        extension[ImagingSelection].extension[instance].extension[uid].value
         instance.sopClass
     }
+
     class DocumentReferenceKeyImageEuImaging{ 
         <<DocumentReference>> 
         modality
@@ -60,13 +55,15 @@ classDiagram
         <<Composition>>
         section[keyimages]
     }
-    CompositionEuImaging --> DocumentReferenceKeyImageEuImaging: section[keyimages].entry
-    CompositionEuImaging --> ImKeyImagingSelection: section[keyimages].entry
+    class DiagnosticReportEuImaging{
+        <<DiagnosticReport>>
+    }
+    CompositionEuImaging --> DocumentReferenceKeyImageEuImaging: section[findings].entry[keyimages]
+    CompositionEuImaging --> ImagingSelectionKeyImageEuImaging: section[findings].entry[keyimages]
+    DiagnosticReportEuImaging --> DocumentReferenceKeyImageEuImaging: extension[finding]
+    DiagnosticReportEuImaging --> ImagingSelectionKeyImageEuImaging: extension[finding]
 
     DocumentReferenceKeyImageEuImaging --> ImageData: content.attachment.url
     DocumentReferenceKeyImageEuImaging <|-- ImKeyImageInstanceSerieDocumentReference
     DocumentReferenceKeyImageEuImaging <|-- ImKeyImageInstanceDocumentReference
-    ImKeyImagingSelection <|-- ImKeyImagingSerieSelection
-    ImKeyImagingSelection <|-- ImKeyImagingInstanceSelection
-    
-```
+```