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

add MS + textual constraint #72 #91

Merged
merged 2 commits into from
May 26, 2023

Conversation

f-peverali
Copy link
Contributor

@f-peverali f-peverali commented May 19, 2023

Dieser Pull Request soll eine Lösung zur Änderung der Appointment.specialty mit gelockerter Kardinalität bereitstellen, die dennoch durch textuelle Festlegung ein Verarbeiten/Rendering in geforderten Szenarien (Terminbuchung über Patientenportal) sicherstellt - wie in AG-Sitzung am 5.5. beschlossen.

@f-peverali f-peverali requested a review from jcaumann May 19, 2023 13:09
@f-peverali f-peverali linked an issue May 22, 2023 that may be closed by this pull request

**Bedeutung:** Kodierung der Fachrichtung des Termins

**Hinweis:** Falls eine Kodierung der Fachrichtung für den Termin angegeben werden kann, dann MUSS sie angegeben werden und exponiert werden können (eine Ausnahme bildet hier die fachrichtungs-unabhängige Terminplanung durch krankenhausinterne, zentrale Organisationseinheiten).
Copy link
Contributor

Choose a reason for hiding this comment

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

Alternative als Vorschlag:
Hinweis: Sofern aus den auf der Appointment-Ressource aufsetzenden Anwendungsfällen eine weitere Verarbeitung der Ressource durch einen menschlichen Nutzer nicht ausgeschlossen werden kann, MUSS das bestätigungsrelevante System mit dem Termin verbundenen Ressourcen (insb. Appointment.slot, Appointment.slot.schedule, Appointment.participant:AkteurMedizinischeBehandlungseinheit.actor) oder aus dem spezifischen Kontext verfügbare Informationen auswerten, um das Element Appointment.speciality mit einem sinnvollen Wert zu befüllen.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Verbesserung für den "Hinweis": Sofern aus den auf der Appointment-Ressource aufsetzenden Anwendungsfällen eine weitere Verarbeitung der Ressource durch einen menschlichen Nutzer nicht ausgeschlossen werden kann, MUSS das bestätigungsrelevante System mit dem Termin verbundenen Ressourcen (insb. Appointment.slot, Appointment.slot.schedule, Appointment.participant:AkteurMedizinischeBehandlungseinheit.actor) oder aus dem spezifischen Kontext verfügbare Informationen auswerten und das Element Appointment.speciality mit einem sinnvollen Wert kodieren (eine Ausnahme bildet hier zum Beispiel die fachrichtungs-unabhängige Terminplanung durch krankenhausinterne, zentrale Organisationseinheiten).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

wie oben umgesetzt

Copy link
Contributor

@jcaumann jcaumann left a comment

Choose a reason for hiding this comment

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

siehe alterativen Vorschlag (Kommentar)

@f-peverali f-peverali merged commit 9cb9ba7 into 3.0.0-rc2 May 26, 2023
@f-peverali f-peverali deleted the enhancement/Appointment.specialty-MS-constraint branch May 26, 2023 13:04
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.

Appointment.specialty auf 0..1 MS statt 1..1 (Kommentierung Stufe 3)
2 participants