Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Sv translation
languagefr


Note

La version SNC du 24.05.2024 intègrera diverses adaptations apportées au service Web (API). Les abonnements de fichiers ne sont pas concernés par ces modifications. Veuillez lire attentivement les informations ci-dessous. Le cas échéant, vous devrez également procéder de votre côté à un certain nombre d’adaptations.

Dans l’optique d’une évaluation de faisabilité, vous devrez également tenir compte de la matrice de changement d’API.


Info
titleInhaltTable des matières

Table of Contents


DescriptionEndpoints concernésObjets/éléments/valeurs concernés
1

Annulation du groupe principal genre de partenaire «Institutions de soins ambulatoires dispensés par des médecins»

Le champ d’activité «Institutions de soins ambulatoires dispensés par des médecins» sera supprimé. Les numéros RCC des organisations concernées seront désormais gérés et livrés avec les numéros RCC des personnes relevant du domaine d’activité «Médecins». Cette annulation sera régie selon la feuille de route suivante:

  • 08.12.2023: à partir de cette date, il sera possible d’adresser une demande de masquage spécifique au mandant auprès de SASIS SA si le client le souhaite.
  • 24.05.2024: cette version concrétisera l’annulation pour tous les mandants restants. Si le client le souhaite, cette annulation pourra être reportée jusqu’en octobre 2024 sur demande adressée à SASIS SA.
  • 31.10.2024: à cette date, l’annulation devra être finalisée pour tous les mandants.

Remarque: la variante choisie s’applique à chaque mandant pour l’ensemble des outils (service Web RCC, RCC version intégrale, RCCo Web, EDI RCCo export, application RCCo [outil admin]).

Ancien: les organisations relevant du groupe principal genre de partenaire «Médecins» étaient gérées et livrées sous le champ d’activité «Institutions de soins ambulatoires dispensés par des médecins» (Id=700).

Nouveau:les adaptations apportées sont les suivantes:

  1. Les fournisseurs de prestations qui étaient jusqu’ici livrés sous le champ d’activité «Institutions de soins ambulatoires dispensés par des médecins» (Id=700) le seront désormais sous le champ «Médecins» (Id=502).
  2. Avec le filtre DoctorFacilitiesForOutpatientNursing dans l’endpoint api/v1/numbers, plus aucun fournisseur de prestations ne peut être trouvé.
  3. Avec le filtre Doctors dans l’endpoint api/v1/numbers, les fournisseurs de prestations qui relevaient jusqu’ici du domaine d’activité 700 sont également trouvés.
  4. Dans l’endpoint api/v1/businessscopes, le champ d’activité 700 n’est plus livré.

Les particularités ci-après demeurent applicables:

  1. Aucun champ d’activité parent n’est livré pour les médecins.
  2. La structure, les contenus et la livraison du champ d’activité restent inchangés.
  3. La structure, les contenus et la livraison de l’activité économique principale (businessActivity) restent inchangés.

Exemple de réponse d’un numéro d’organisation dans l’endpoint api/v1/clearingNumbers: cf. lien

api/v1/clearingNumbers

api/v1/numbers

api/v1/businessScopes

clearingNumber.businessScope
2

Historisation technique des admissions pour d’autres groupes principaux genre de partenaire

Comme déjà annoncé pour la version du 08.12.23, les admissions à pratiquer à charge de l’AOS feront désormais l’objet, à partir de la version EAC, d’une historisation technique avec dates de début et de fin pour d’autres groupes principaux genre de partenaire. 

Ancien: l’admission cantonale à pratiquer à charge de l’AOS était livrée avec historisation technique (dates de début et de fin) pour les groupes principaux genre de partenaire «Médecins», «Dentistes» et «Psychologues-psychothérapeutes».

Nouveau: l’admission cantonale à pratiquer à charge de l’AOS sera désormais également livrée avec historisation technique (dates de début et de fin) pour les groupes principaux genre de partenaire ci-après: pharmacies, laboratoires, physiothérapeutes, infirmiers/infirmières, sages-femmes, ergothérapeutes, logopédistes, organisations d’aide et de soins à domicile, diététiciens/diététiciennes, centres de remise de moyens et d’appareils, entreprises de transport et de sauvetage, établissements de cure balnéaire, neuropsychologues, podologues, chiropraticiens. 

api/v1/clearingNumbers

clearingNumber.admissions

3

Historisation technique du type d’admission pour tous les groupes principaux genre de partenaire

Comme déjà annoncé pour la version du 08.12.23, le type d’admission (clearingNumberLaw) avec les valeurs LAMal&LCA, LCA, LAMal&LCA partielle, LAA/AM/AI fera désormais l’objet, à partir de la version EAC, d’une historisation technique avec dates de début et de fin pour tous les groupes principaux genre de partenaire. 

Ancien: le type d’admission était livré avec historisation technique (dates de début et de fin) pour les groupes principaux genre de partenaire «Médecins», «Dentistes» et «Psychologues-psychothérapeutes».

Nouveau: le type d’admission est livré avec historisation technique (dates de début et de fin) pour tous les groupes principaux genre de partenaire.

api/v1/clearingNumbers

clearingNumber.clearingNumberLaws

4

Correction de la livraison des données pour les liens entre numéros RCC et C d’une même personne

Si une personne dispose à la fois d’un numéro RCC et d’un numéro C, l’information est indiquée sous CareProvider.EmployeeNumbers.

Ancien: en raison d’un bug, seuls les liens enregistrés via le nouveau portail RCC en ligne étaient indiqués. Les rapports de travail hérités n’étaient pas transmis. 

Nouveau: le bug a été corrigé. Tous les liens entre numéros RCC et C d’une même personne sont livrés sous CareProvider.employeeNumbers.

api/v1/clearingNumbers

api/v1/employeeNumbers

clearingNumber.careProvider.EmployeeNumbers

employeeNumber.careProvider.EmployeeNumbers



5

Livraison de la date de décès du fournisseur de prestations

Ancien: les numéros RCC de personnes / les numéros C n’étaient ni comparés avec la mention d’une date de décès dans la CdC, ni automatiquement suspendus. En cas de suspension manuelle suite à un décès, le motif de fin indiqué pour ces numéros était «Décès» (valeur d’énumération TERMINATION_BY_DEATH de l’énumération CLEARING_NUMBER_VALIDITY_END_REASON_TYPE). Les dates de décès des fournisseurs de prestations n’étaient ni gérées, ni livrées dans le service Web RCC.

Nouveau: en cas de saisie d’une date de décès dans la CdC, les numéros RCC et C des personnes qui se sont enregistrées dans le portail en ligne sont automatiquement suspendus avec le motif de fin «Décès» (valeur d’énumération TERMINATION_BY_DEATH de l’énumération CLEARING_NUMBER_VALIDITY_END_REASON_TYPE) et la date de décès est consignée. La date de décès est alors mentionnée avec le motif de fin «Décès» dans le service Web.

api/v1/clearingNumbers

api/v1/employeeNumbers

clearingNumber.careProvider.careProviderParties.party.deathDate (numéros (numéros RCC de personnes)

employeeNumber.careProvider.careProviderParties.party.deathDate (numéros C)

6

Système tarifaire pour les établissements médico-sociaux: BESA, RAI/RUG et Plaisir ne sont plus livrés.

Ancien: pour le système de tarification des établissements médico-sociaux (NURSING_HOME_FLAT_RATE), les valeurs BESA, RAI/RUG et Plaisir étaient relevées et livrées. 

Nouveau: les valeurs BESA, RAI/RUG et Plaisir ne sont plus livrées pour le système de tarification des établissements médico-sociaux (NURSING_HOME_FLAT_RATE).

api/v1/clearingNumbers

api/v1/tariffSystems

clearingNumber.tariffSystems.tariffSystem

7

Numéro de compte marqué comme déprécié

Ancien: l’entité clearingNumber.account.accountNumber n’était pas marquée comme dépréciée dans Swagger.json.

Nouveau: l’entité clearingNumber.account.accountNumber est marquée comme dépréciée dans la documentation Swagger. Autrement dit, l’interprétation de cette entité n’est pas recommandée et celle-ci sera supprimée dans une version ultérieure.

Contexte: l’IBAN constitue la seule information de paiement saisie par les fournisseurs de prestations. Les données émises sous clearingNumber.account.accountNumber ne sont pas fiables à 100%.

api/v1/clearingNumbersclearingNumber.account.accountNumber
8

Données de base dans l’endpoint api/v1/healthservices désormais sans validFrom 

Ancien: dans l’endpoint Healthservices pour les méthodes de certification, les valeurs de champ validFrom, startDate, endDate et isValid dans la réponse API étaient, contrairement à la définition Swagger, livrées à la fois sur l’objet racine et sous l’entité Affiliation correspondante.

Nouveau: les champs startDate, endDate et isValid sont officiellement intégrés dans la documentation Swagger. Le champ validFrom restant exclu de la documentation Swagger, il n’est plus livré. La propriété Affiliation est livrée sans les valeurs de champ startDate, endDate, validFrom et isValid conformément aux dispositions contractuelles.

Extrait de la réponse du point d’accès api/v1/healthservices pour une méthode de certification: cf. Exemple - Données de base dans l’endpoint api/v1/healthservices désormais sans validFrom 

api/v1/healthservices

Schémas/contrats swagger.json ci-après:

HealthServiceCertifier

9

Traductions pour l’activité économique principale chez les médecins 

Ancien: aucune traduction de l’énumération businessActivity n’était émise. Les traductions devaient être effectuées par les intégrateurs à l’aide de la ressource Mapping Abo Files - Webservice dans les FAQ Webservice RCC.

Nouveau: les traductions de l’énumération businessActivity sont désormais directement émises avec businessActivityTranslations.

api/v1/clearingNumbersclearingNumber.businessActivity.businessActivityTranslations
10

Reformulation des traductions en cas d’auto-dispensation

Ancien: les traductions pour l’auto-dispensation dans nameTranslation sous facilityType «DOCTOR_FACILITY» étaient les suivantes:

  • DE: «Selbstdispensation voll»,
  • FR: «Auto-dispensation intégrale (médicaments)»,
  • IT: «Autodispensazione integrale (medicamenti)»

Nouveau: les traductions dans nameTranslation sous facilityType «DOCTOR_FACILITY» sont définies comme suit: 

  • DE: «Kantonale Bewilligung zur Selbstdispensation»
  • FR: «Autorisation cantonale de propharmacie»
  • IT: «Autorizzazione cantonale per l’autodispensazione»
api/v1/clearingNumbers

clearingNumber.careProviderBusinesses.facilities.nameTranslations




11

Annulation du déclenchement de mutations en cas de modification de la valeur isValid

Ancienen raison de problèmes d’intégration rencontrés par certains intégrateurs, la version du 08.12.23 proposait une solution temporaire consistant à actualiser la date de mutation lorsque la valeur isValid change. Cf. à ce propos «Complément important» au point 9 Augmentation du nombre de mutations des Release Notes pour le 08.12.23.

Nouveau: comme déjà annoncé pour la version du 08.12.23, cette solution a été mise en œuvre à titre temporaire et sera supprimée avec la présente version. La date de mutation n’est plus actualisée lorsque la valeur isValid change. En d’autres termes, les modifications des valeurs contenues dans l’entité isValid ne conduisent plus à des mutations de clearingNumber.modifiedTime.

api/v1/clearingNumbers

clearingNumber.modifiedTime
12

Correction du contrat Swagger concernant le format «date-heure» 

Ancien: le format date-heure était documenté dans Swagger pour les entités énumérées ci-dessous. Cependant, la réponse présentait le format date.

  • StartDate
  • EndDate
  • RecognitionDate
  • EquivalencyDate
  • Birthdate
  • DeathDate
  • ModifiedTime

Cf. par ex. contract BaseValidity: lien

Nouveau: le format date est documenté dans Swagger pour les entités énumérées. Cf. par ex. contract BaseValidity: lien

api/v1/careProviderCertification

api/v1/clearingNumbers

api/v1/employeeNumbers

api/v1/healthServices

api/v1/healthservices/comments

api/v1/numbers/list




Schémas/contrats swagger.json ci-après:

BaseValidity

Responses.Contract.BaseValidityContract

Responses.Contracts.ValidityPeriods

13

Représentation alternative des propriétés d’entités multi-héritées au moyen de https://redocly.com/redoc/

Ancien: la représentation par Swagger-UI des propriétés d’entités multi-héritées était parfois incorrecte/incomplète.

Nouveaudans le cas d’entités multi-héritées, la représentation de leurs propriétés au moyen de Swagger est lacunaire. Plus précisément, les propriétés desdites entités ne sont pas toutes représentées dans Swagger-UI, mais Swagger offre la possibilité de tester des requêtes individuelles. L’outil Redocly (https://redocly.com/redoc/) est mis à disposition en tant que GUI alternative en plus de Swagger-UI. Les entités json sont toujours représentées ici avec toutes leurs propriétés. La vue json peut être activée sous /ApiGateway/docs:

Environnement d’intégration: https://int.zsrnext.ch/ApiGateway/docs

Système live: https://zsrnext.ch/ApiGateway/docs

Tous

Tous

14

Augmentation du nombre de mutations

Les adaptations vont entraîner une hausse du nombre de mutations.

api/v1/clearingNumbers

api/v1/employeeNumbers

clearingNumber.modifiedTime

employeeNumber.modifiedTime