ZSR (public)

Page tree


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.BeschreibungBetroffene EndpointsBetroffene 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:

  1. 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
  2. Für den Filter DoctorFacilitiesForOutpatientNursing im Endploint api/v1/numbers werden keine Leistungserbringer mehr gefunden.
  3. Für den Filter Doctors im Endpoint api/v1/numbers werden neu ebenfalls die Leistungserbringer mit dem biserhigen businessScope 700 gefunden
  4. Im Endpoint api/v1/businessscopes wird der businessScope 700 nicht mehr ausgeliefert

Folgende Besonderheiten bleiben bestehen:

  1. Für Ärzte und Ärztinnen wird weiterhin kein parentBusinessScope ausgeliefert
  2. Die Struktur, Inhalte und Auslieferung des businessScope bleibt wie bisher
  3. 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-Obergruppen

Wie 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-Obergruppen

Wie 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 Person

Verfü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 Leistungserbringers

Bisher: 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 ausgeliefert

Bisher: 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 dokumentiert

Bisher: 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/clearingNumbersclearingNumber.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/clearingNumbersclearingNumber.businessActivity.businessActivityTranslations
10

Umbenennen der Übersetzungen bei Selbstdispensation

Bisher: 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-Wertes

Bisher: 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"-Format 

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

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 Mutationen

Die Anpassungen führen zu einer erhöhten Zahl von Mutationen.


api/v1/clearingNumbers

api/v1/employeeNumbers

clearingNumber.modifiedTime

employeeNumber.modifiedTime

  • No labels