| Nr. | Beschreibung | Betroffene Endpoints | Betroffene Objekte/Element/Werte |
|---|
| 1 | Rückbau Partnerart-Obergruppe «Einrichtungen der amb. Krankenpflege durch Ärzte & Ärztinnen»Der Business Scope «Einrichtungen der amb. Krankenpflege durch «Ärzte & Ärztinnen» wird entfallen und die entsprechenden ZSR-Nr. von Organisationen werden neu zusammen mit den ZSR-Nr. von Personen im Business Scope «Ärzte und Ärztinnen» geführt und ausgegeben. Dieser Rückbau erfolgt mittels folgender Roadmap: - 08.12.2023: Ab diesem Zeitpunkt besteht die Möglichkeit, auf Kundenwunsch ein mandantenspezifisches Ausblenden bei der SASIS AG zu beantragen, das pro Kunde jederzeit konfiguriert werden kann.
- 24.05.2024: Mit diesem Release wird der Rückbau für alle restlichen Mandanten umgesetzt. Auf Kundenwunsch kann dieser Rückbau auf Antrag bei der SASIS AG bis Oktober 2024 pro Kunde verzögert werden.
- 31.10.2024: Auf dieses Datum erfolgt der Rückbau bei allen Mandanten
Hinweis: Die gewählte Variante gilt pro Mandant für die gesamte Toolchain (ZSR Webservice, ZSR Vollversion, ZVR Web, ZVR EDI Export, ZVR AdminTool). Bisher: Organisationen der Partnerart-Obergruppe «Ärzte und Ärztinnen» wurden mit dem Business Scope «Einrichtungen der amb. Krankenpflege durch Ärzte & Ärztinnen» mit der Id=700 geführt und ausgeliefert. Neu: Es werden folgende Anpassungen vorgenommen: - Leistungserbringer, die bisher unter dem businessScope «Einrichtungen der amb. Krankenpflege durch Ärzte & Ärztinnen» mit der Id=700 ausgeliefert wurden, werden neu im businessScope «Ärzte & Ärztinnen» mit der Id=502 ausgeliefert
- Für den Filter DoctorFacilitiesForOutpatientNursing im Endploint api/v1/numbers werden keine Leistungserbringer mehr gefunden.
- Für den Filter Doctors im Endpoint api/v1/numbers werden neu ebenfalls die Leistungserbringer mit dem biserhigen businessScope 700 gefunden
- Im Endpoint api/v1/businessscopes wird der businessScope 700 nicht mehr ausgeliefert
Folgende Besonderheiten bleiben bestehen: - Für Ärzte und Ärztinnen wird weiterhin kein parentBusinessScope ausgeliefert
- Die Struktur, Inhalte und Auslieferung des businessScope bleibt wie bisher
- Die Struktur, Inhalte und Auslieferung der businessActivity (wirtschaftliche Haupttätigkeit) bleibt wie bisher
Beispiel für die Response einer Organisationsnummer im Endpoint api/v1/clearingNumbers siehe: Link | api/v1/clearingNumbers api/v1/numbers api/v1/businessScopes | clearingNumber.businessScope |
| 2 | Zulassungen fachlich historisiert für weitere Partnerart-ObergruppenWie bereits für den Release vom 08.12.23 angekündigt, werden wir mit dem EAC-Release für weitere Partnerart-Obergruppen die Zulassung zu Lasten OKP (admission) neu mit Beginn- und Ende-Daten fachlich historisiert ausweisen. Bisher: Die kantonale Zulassung zu Lasten OKP wurde für die Partnerart-Obergruppen "Ärzte und Ärztinnen", "Zahnärzte und Zahnärztinnen" und "Psych. Psychotherapeuten und Psychotherapeutinnen" mit Beginn- und Ende-Datum fachlich historisiert ausgeliefert. Neu: Die kantonale Zulassung zu Lasten OKP wird neu zusätzlich für folgende Partnerart-Obergruppen mit fachlichen Beginn- und Ende-Daten fachlich historisiert ausgeliefert: Apotheken, Laboratorien, Physiotherapeuten, Pflegefachpersonen, Hebammen, Ergotherapeuten, Logopäden und Ergotherapeutinnen, Spitex, Ernährungsberater und Ernährungsberaterinnen, Abgabestelle für Mittel und Gegenstände, Transport- und Rettungsunternehmen, Heilbäder, Neuropsychologen und Neuropsychologinnen, Podologen und Podologinnen, Chiropraktoren und Chiropraktorinnen. | api/v1/clearingNumbers | clearingNumber.admissions |
| 3 | Zulassungstyp fachlich historisiert für alle Partnerart-ObergruppenWie bereits für den Release vom 08.12.23 angekündigt, werden wir mit dem EAC-Release für sämtliche Partnerart-Obergruppen den Zulassungstyp (clearingNumberLaw) mit den Werten KVG&VVG, VVG, Teil-KVG&VVG, UVG/MV/IV, neu mit Beginn- und Ende-Daten fachlich historisiert ausweisen. Bisher: Der Zulassungstyp wurde für die Partnerart-Obergruppen "Ärzte und Ärztinnen", "Zahnärzte und Zahnärztinnen" und "Psych. Psychotherapeuten und Psychotherapeutinnen" mit Beginn- und Ende-Datum fachlich historisiert ausgeliefert. Neu: Der Zulassungstyp wird für sämtliche Partnerart-Obergruppen mit Beginn- und Ende-Datum fachlich historisiert ausgeliefert. | api/v1/clearingNumbers | clearingNumber.clearingNumberLaws |
| 4 | Korrektur der Datenlieferung bei Beziehungen zwischen ZSR- und K-Nummern derselben PersonVerfügt eine Person sowohl über eine ZSR- wie auch eine K-Nummer, wird die Information unter CareProvider.EmployeeNumbers ausgewiesen. Bisher: Aufgrund eines Bugs wurden nur jene Beziehungen ausgewiesen, welche über das neue ZSR-Online-Portal hinterlegt wurden. Legacy-Anstellungsverhältnisse wurden nicht übermittelt. Neu: Der Bug wurde behoben. Es werden sämtlicheBeziehungen zwischen ZSR- und K-Nummern, welche zu derselben Person gehören, unter CareProvider.employeeNumbers geliefert. | api/v1/clearingNumbers api/v1/employeeNumbers | clearingNumber.careProvider.EmployeeNumbers employeeNumber.careProvider.EmployeeNumbers
|
| 5 | Lieferung Todesdatum des LeistungserbringersBisher: ZSR-Nummern von Personen und K-Nummern wurden nicht mit dem Eintrag eines Todesdatums im ZAS abgeglichen und auch nicht automatisch sistiert. Bei manuellen Sistierungen aufgrund von Todesfällen wurde der Beendigungsgrund "Tod" (Enumerationswert TERMINATION_BY_DEATH der Enumeration CLEARING_NUMBER_VALIDITY_END_REASON_TYPE) gesetzt und für diese Nummern ausgewiesen. Ein Todesdatum des Leistungserbringers wurde weder geführt noch im ZSR Webservice ausgeliefert. Neu: ZSR- und K-Nummern von Personen, die sich im Online-Portal registriert haben, werden bei einem Eintrag eines Todesdatums im ZAS mit dem Beendigungsgrund "Tod" (Enumerationswert TERMINATION_BY_DEATH der Enumeration CLEARING_NUMBER_VALIDITY_END_REASON_TYPE) automatisch sistiert und das Todesdatum festgehalten. Das Todesdatum wird in diesen Fällen nebst dem Beendigungsgrund "Tod" im Webservice ausgegeben. | api/v1/clearingNumbers api/v1/employeeNumbers | clearingNumber.careProvider.careProviderParties.party.deathDate (ZSR-Nummern von Personen) employeeNumber.careProvider.careProviderParties.party.deathDate |
| 6 | Tarifsystem Pflegeheime: BESA, RAI/RUG, Plaisir werden nicht mehr ausgeliefertBisher: Für das Tarifsystem Pflegeheime (NURSING_HOME_FLAT_RATE) wurden die Werte BESA, RAI/RUG und Plaisir erhoben und ausgeliefert. Neu: Für das Tarifsystem Pflegeheime (NURSING_HOME_FLAT_RATE) werden keine Werte BESA, RAI/RUG und Plaisir mehr geliefert. | api/v1/clearingNumbers api/v1/tariffSystems | clearingNumber.tariffSystems.tariffSystem |
| 7 | Kontonummer als Deprecated dokumentiertBisher: Die Entität clearingNumber.account.accountNumber war im Swagger.json nicht als "deprecated" dokumentiert Neu: Die Entität clearingNumber.account.accountNumber wird in der Swagger-Dokumentation als "deprecated" dokumentiert. Das heisst, die Interpretation dieser Entität wird nicht empfohlen und die Entität wird in einem Nachfolge-Release entfernt. Hintergrund: Als Zahlungsinformation wird ausschliesslich die IBAN von den Leistungserbringern erfasst. Die ausgegebenen Daten unter clearingNumber.account.accountNumber sind nicht zu 100% zuverlässig. | api/v1/clearingNumbers | clearingNumber.account.accountNumber |
| 8 | Stammdaten im Endpoint api/v1/healthservices neu ohne validFrom Bisher: Im Endpoint healthservices für Zertifizierermethoden wurden entgegen der Swagger-Definition in der API-Response die Feldwerte für validFrom, startDate, endDate und isValid sowohl auf dem Root-Objekt als auch unter der zugehörigen Entität affiliation geliefert. Neu: Es werden die Felder startDate, endDate und isValid offiziell in die Swagger-Dokumentation aufgenommen. Das Feld validFrom ist weiterhin nicht Teil der Swagger-Dokumentation und wird nicht mehr geliefert. Das Property affiliation wird ohne die Feld-Werte startDate, endDate, validFrom und isValid gemäss Contract geliefert. Auszug aus Response vom Endpoint api/v1/healthservices für eine Zertifizierermethode siehe: Link | api/v1/healthservices | Folgende swagger.json Schemas bzw. Contracts: HealthServiceCertifier |
| 9 | Übersetzungen für wirtschaftliche Haupttätigkeit bei Ärzten und Ärztinnen Bisher: Es wurden keine Übersetzungen der Enumeration businessActivity ausgegeben. Die Übersetzungen mussten von Integratoren mit Hilfe von Mapping Abo Files - Webservice in den ZSR Webservice FAQ vorgenommen werden. Neu: Die Übersetzungen der Enumeration businessActivity werden neu mit businessActivityTranslations direkt ausgegeben. | api/v1/clearingNumbers | clearingNumber.businessActivity.businessActivityTranslations |
| 10 | Umbenennen der Übersetzungen bei SelbstdispensationBisher: Die Übersetzungen für Selbstdispensation in nameTranslation unter facilityType "DOCTOR_FACILITY" waren: - de: "Selbstdispensation voll",
- fr: "Auto-dispensation intégrale (médicaments)",
- it: "Autodispensazione integrale (medicamenti)"
Neu: Die Übersetzungen in nameTranslation unter facilityType "DOCTOR_FACILITY" lauten: - de: Kantonale Bewilligung zur Selbstdispensation
- fr: Autorisation cantonale de propharmacie
- it: Autorizzazione cantonale per l'autodispensazione
| api/v1/clearingNumbers | clearingNumber.careProviderBusinesses.facilities.nameTranslations
|
| 11 | Rückbau der Auslösung von Mutationen bei Änderung des isValid-WertesBisher: Aufgrund von Integrationsproblemen einzelner Integratoren wurde mit dem Release von 08.12.23 als vorübergehende Lösung das ModifiedDate aktualisiert, wenn sich der Wert bei isValid änderte. Siehe dazu "Wichtige Ergänzung" zu Punkt 9 Erhöhte Anzahl Mutationen der Release Notes für den 08.12.23. Neu: Wie bereits für den Release vom 08.12.23 angekündigt, wurde dies als temporäre Lösung umgesetzt und wird mit diesem Release zurückgebaut. Das Mutationsdatum wird nicht mehr aktualisiert, wenn sich der Wert bei isValid ändert. Das heisst, dass Änderungen von Werten in der Entität isValid zu keinen Mutationen der clearingNumber.modifiedTime mehr führen. | api/v1/clearingNumbers | clearingNumber.modifiedTime |
| 12 | Bisher: Bei unten gelisteten Entitäten wurde in Swagger das Format date-time dokumentiert. Die response enthielt jedoch das Format date. - StartDate
- EndDate
- RecognitionDate
- EquivalencyDate
- Birthdate
- DeathDate
- ModifiedTime
Siehe z.B. contract BaseValidity: Link Neu: Bei den gelisteten Entitäten wird in Swagger das Format date dokumentiert. Siehe z.B. contract BaseValidity: Link | api/v1/careProviderCertification api/v1/clearingNumbers api/v1/employeeNumbers api/v1/healthServices api/v1/healthservices/comments api/v1/numbers/list
| Folgende swagger.json Schemas bzw. Contracts: BaseValidity Responses.Contract.BaseValidityContract Responses.Contracts.ValidityPeriods |
| 13 | Alternative Property-Darstellung von mehrfach vererbten Entitäten mittels https://redocly.com/redoc/Bisher: Properties von mehrfach vererbten Entitäten wurden von Swagger-UIteilweise nicht korrekt d.h. nicht vollständig abgebildet. Neu: Die Darstellung mittels Swagger ist bezüglich Property-Darstellung von mehrfach vererbten Entitäten lückenhaft d.h. es werden nicht alle Properties von Entitäten in Swagger-UI angezeigt, dafür bietet Swagger die Möglichkeit Einzelabfragen testen zu können. Als alternatives GUI wird Redocly (https://redocly.com/redoc/) zusätzlich zu Swagger-UI zur Verfügung gestellt. Entitäten von json werden hier immer mit allen Properties dargestellt. Die Ansicht des json kann unter /ApiGateway/docs aufgerufen werden: Integrationsumgebung: https://int.zsrnext.ch/ApiGateway/docs Live-System: https://zsrnext.ch/ApiGateway/docs | alle | alle |
| 14 | Erhöhte Anzahl MutationenDie Anpassungen führen zu einer erhöhten Zahl von Mutationen. | api/v1/clearingNumbers api/v1/employeeNumbers | clearingNumber.modifiedTime employeeNumber.modifiedTime |
