Mit dem SNC-Release vom 24.05.2024 werden diverse Anpassungen am Webservice (API) vorgenommen. Die File-Abos sind von den Anpassungen nicht betroffen. Bitte lesen Sie folgende Informationen aufmerksam durch. Es sind eventuell Anpassungen auf Ihrer Seite notwendig.
Beachten Sie für eine Feasibility-Beurteilung ebenfalls die API Change Matrix.
Inhalt
| 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:
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:
Folgende Besonderheiten bleiben bestehen:
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ämtliche Beziehungen 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 validFromBisher: 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 ÄrztinnenBisher: 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:
Neu: Die Übersetzungen in nameTranslation unter facilityType "DOCTOR_FACILITY" lauten:
| 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 | Korrektur des Swagger Contracts betreffend "date-time"-FormatBisher: Bei unten gelisteten Entitäten wurde in Swagger das Format date-time dokumentiert. Die response enthielt jedoch das Format date.
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-UI teilweise 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 |