| N° | Description | Endpoints concernés | Objets/é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: - 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).
- Avec le filtre DoctorFacilitiesForOutpatientNursing dans l’endpoint api/v1/numbers, plus aucun fournisseur de prestations ne peut être trouvé.
- 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.
- Dans l’endpoint api/v1/businessscopes, le champ d’activité 700 n’est plus livré.
Les particularités ci-après demeurent applicables: - Aucun champ d’activité parent n’est livré pour les médecins.
- La structure, les contenus et la livraison du champ d’activité restent inchangés.
- 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 partenaireComme 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 partenaireComme 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 personneSi 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 prestationsAncien: 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 | 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/clearingNumbers | clearingNumber.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. lien | 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/clearingNumbers | clearingNumber.businessActivity.businessActivityTranslations |
| 10 | 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 isValidAncien: en 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 | 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. Nouveau: dans 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 mutationsLes adaptations vont entraîner une hausse du nombre de mutations. | api/v1/clearingNumbers api/v1/employeeNumbers | clearingNumber.modifiedTime employeeNumber.modifiedTime |
