Tc 4.0.1

[f-peverali]

Version Upgrade Template

Version: TC 4.0.1

Date: tbd.

Description

This is a Pullreuqest that requires an increase in the Version number. Therefore, multiple outside-github, related Task have to be performed and checked.

All jobs with an x in the boxes were performed to the best of knowledge.

Pre-Merge Activities

• This PR refers to a versioned Branch with a name and a version number in the form of N.n.n, e.g. "TC_3.2.1".

• This PR has a clean meaningful commit history. Minor commits or commits without description have been squashed, at the latest now.

• The ./github/workflows/main.yml refers to the correct Firely Terminal and SUSHI Version.

  Firely Terminal Pipeline 0.4.0.

  SUSHI Versions 3.5.0.

• By running the Release_Publish.py script, release version and date was updated accordingly. The script ran without errors.

• Eventually, increase the dependency of to newer Basis Modul (package and sushi-config)

• New Release Notes were created, alined to the commit history and cleaned. In Github, go to

  • -> Releases then -> Draft a new release with the Modul Name and Version, then
  • -> Target the main-Branch and ->enter a new Tag according to the Version, then click.
  • Click -> Generate Release notes , ->Adjust them if necessary and -> Copy/Paste the Details in the RealeaseNotes.md of the very Branch you want to merge.
  • Finally -> Save as Draft

Merge and Publishing

• With the updated Version, Dates, and Release Notes (as described above) with the last committ into the Branch you want to merge.
• In GitHub -> Actions the ->CI (FHIR Validation) workflow terminates successfully.
• Add the Approve / the PR gets positively reviewed by a colleague.
• Merge (without squash) the PR, delete the Branch.

Post-Merge Activities

• Go to the corresponding SIMPLIFIER Project and -> Github -> Reimport the project.
• Go to the corresponding SIMPLIFIER Project and -> Packages -> Expand the Dropdown for Create -> Create new package for the project.
  • With the corresponding version number, and
  • The Release notes (from above) and a compare-link to the previous Release.
  • Unlist the old package by -> clicking on the old package, -> go to Administration and -> click on Unlist
• Publish the previously drafted Release, including version number, on GitHub.
• Provide / Archive the IG in the corresponding gh-pages branch of the GitHub project.
  • Checkout the Branch (no need to merge it later).
  • Export from Simplifier via -> Guides -> Expand the Modul ... -> Export
  • Unpack the zip, remove the packages folder (because its kinda big), and move everything else to a (version corresponding) new folder in the branch folder structure.
  • Update the file index.html and check rendering
  • commit the branch.
• If ISiK Basismodul was updated all depending Modules should be updated with a renewed dependency to the incremented Basismodul version - possibly including and closing technical corrections

Finished

[f-peverali]

issues (1): Mir fehlt hier ein motivierender Satz, warum dieses Profil spezifiziert wird in ISiK im Sinne der DOkumtnation von Auswahl- und Designentscheidungen. Das gilt für alle Profile in diesem CpS. Auch für "triviale" Entscheidungen SOLL zumindest 1 motivierender Satz im Code vorgehalten werden
(2) Analog für jede einzelne Interaktion im CpS

suggestion: Im Sinne der DOkumentation reicht eine solche Motivation als Comment (d.h. muss nicht zwingend in der Simplifier Tabelle gerendert werden. Siehe dazu auch gematik OSPO guidelines : https://wiki.gematik.de/display/OSPO/FHIR+Policy#FHIRPolicy-DocumentationofDesignDecisions

examples:

• Für Patient: "Motivation: Eine Patienteninstanz muss für so gut wie jeden Versorgungsprozess im Krankenhaus abrufbar sein."
• Für Account: "Motivation: Abrechnungsprozesse sollen durch das Account-Profil unterstützt werden."
• Für Organization : "Motivation: ..."
• etc.