Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tc 4.0.1 #441

Open
wants to merge 190 commits into
base: main-isik-stufe-4
Choose a base branch
from
Open

Tc 4.0.1 #441

wants to merge 190 commits into from

Conversation

f-peverali
Copy link
Contributor

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

simoneOnFhir and others added 29 commits September 20, 2024 17:17
Vollständiges Refactoring des CapabilityStatements. Überführung der Dokumentation zu Suchparametern in den FSH-Code und Abgleich mit IG Prosa
SubscriptionTopic-Extension wiederhergestellt
* rest
* mode = #server
* resource[+]
* type = #Patient
Copy link
Contributor Author

@f-peverali f-peverali Sep 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

simoneOnFhir and others added 30 commits November 5, 2024 14:42
* fix: backport dependency adjusted to r4 only package (was r4 & r4b)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants