Update Clinician Messages

[pauljohanneskraft]

Update Clinician Messages

♻️ Current situation & Problem

We may want to slightly update how clinician messages are created to make them more appropriate (e.g. changing the text so that it is actually clinician-facing rather than patient-facing).

We also decided to add the clinician's name to the PDF, so this is also included in this PR.

⚙️ Release Notes

Add a bullet point list summary of the feature and possible migration guides if this is a breaking change so this section can be added to the release notes.
Include code snippets that provide examples of the feature implemented or links to the documentation if it appends or changes the public interface.

📚 Documentation

Please ensure that you properly document any additions in conformance to Spezi Documentation Guide.
You can use this section to describe your solution, but we encourage contributors to document your reasoning and changes using in-line documentation.

✅ Testing

Please ensure that the PR meets the testing requirements set by CodeCov and that new functionality is appropriately tested.
This section describes important information about the tests and why some elements might not be testable.

Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[pauljohanneskraft]

@arkadiuszbachorski Please let me know, if you think these actions make sense - if not, I'm open to changing them! In general, I'd think of them to be able to be performed without the use of the type and/or reference properties. You may still parse them, which is the case anyways by using the models package, but not really make any use of them, since they may easily be used differently in the future (e.g. by adding new enum cases or different properties becoming important while grouping messages).

There are now three action property values the frontend will need to be able to deal with:

• users/$userId$ to show the patient detail page with the Information tab selected
• users/$userId$/appointments to show the patient detail page with the Appointments tab selected
• users/$userId$/medications to show the patient detail page with the Medications tab selected

Let me know if you (dis)agree with this! 😊

[arkadiuszbachorski]

I need more descriptive messages. If we plan to rely on title and description only, without dashboard doing any parsing nor customization on top of messages, "This patient" is not distinct enough. We'll have notifications in context of specific patient and out of context (all patients, all notifications). Therefore, notification message must contain distinctive patient name or e-mail.

For example createInactiveForClinician:

This patient has been inactive for 7 days. => John Doe has been inactive for 7 days.

[pauljohanneskraft]

I need more descriptive messages. If we plan to rely on title and description only, without dashboard doing any parsing nor customization on top of messages, "This patient" is not distinct enough. We'll have notifications in context of specific patient and out of context (all patients, all notifications). Therefore, notification message must contain distinctive patient name or e-mail.

For example createInactiveForClinician:

This patient has been inactive for 7 days. => John Doe has been inactive for 7 days.

Sounds good, works for me - for everything beyond the title and description, the action property already contains the userId, so we could show user information based on that. But that would be additional (e.g. a picture or something like that) and is currently not planned.