notification (legacy)

/in /door

Let op: deze methode is nu legacy. Er worden geen verdere uitbreidingen of verbeteringen gedaan aan deze methode.

Voor nieuwe ontwikkeling, gebruik Notify als opvolger van deze methode. Deze methode heeft in basis dezelfde structuur, dus overstappen zou eenvoudig moeten zijn, maar het bevat meer notificatie typen en betere validate en feedback.

Ysis kan geïnformeerd worden van wijzigingen. In reactie haalt Ysis dan de gegevens op bij het Bronsysteem.

Inleiding

De meeste integraties tussen Ysis en andere zorgsystemen werken momenteel met een Notify/Fetch pattern. Het idee is dat het bron systeem een signaal geeft naar het afnemende systeem. Het afnemende systeem haalt deze gegevens vervolgens op.
Dit heeft een aantal voordelen ten opzichte van ‘push’ methoden:

  • Het bronsysteem hoeft zich niet te verdiepen in de businesslogica, validaties en mapping van het afnemende systeem. Het afnemende systeem heeft zelf de controle over het valideren en verwerken van de gegevens.
  • De meeste zorgsystemen hebben al een API om gegevens op te halen, deze kan (her)bruikt worden, zodat er minder custom software nodig is voor elke individuele integratie.
  • Door het ‘notify’ principe is schaalbaarheid eenvoudig. Ysis bijvoorbeeld plaatst alle binnenkomende notifies op een queue, die continue wordt verwerkt: dit maakt het eenvoudig om piekbelastingen op te vangen zonder dat de API vertraagd.
  • Het is ook eenvoudig om – als er bij het afhandelen van de notify fouten ontstaan – deze operatie eenvoudig te herhalen.

Opmerkingen:

  • De meeste Notificatie typen zijn 1:1 (bijvoorbeeld administratieve gegevens: er is per patiënt maar 1 set). Het is dan voldoende om aan Ysis alleen het BSN door te geven. Een identifier, mutatietype, en timestamp zijn dan niet vereist (hoewel een timestamp altijd prettig is in verband met logging van mutaties). Uitzonderingen zijn rapportages, metingen en berichten: hier zijn de aantallen te groot en worden we graag geïnformeerd over welk rapport is gewijzigd, en of het een nieuw rapport, een gewijzigd rapport of een verwijdering betreft.
  • De identifier is een vrije waarde die in Ysis als ‘external identifier’ bij de gegevens wordt opgeslagen. Het is wel belangrijk dat de waarde uniek is binnen de patiënt, en dat latere mutaties op hetzelfde gegevens ook weer dezelfde identifier bevat.

Zie de WSDL voor de exacte specificatie van de input en output.
WSDL: https://acceptatie1-webservice.ysis.nl/wsdl/connect.wsdl
Endpoints:
Acceptatie1: https://acceptatie1-webservice.ysis.nl/webservice
Acceptatie2: https://acceptatie2-webservice.ysis.nl/webservice
Productie: https://webservice.ysis.nl/webservice
Voorbeeld Requests:
Voorbeeld voor administratieve gegevens.
“Administratieve gegevens zijn gewijzigd voor Patient 123456782”

<soapenv:Body>
   <med:notificationRequest>
      <med:bsn>123456782</med:bsn>
      <con:change>
         <con:notificationType>ADMINISTRATIVE</con:notificationType>
         <con:timestamp>2016-12-15T16:20:31.000+01:00</con:timestamp>
      </con:change>
   </med:notificationRequest>
</soapenv:Body>

Voorbeeld voor rapportages.
“Rapportage met ID 12345 voor patiënt 123456782 is verwijderd”

<soapenv:Body>
   <med:notificationRequest>
      <med:bsn>123456782</med:bsn>
      <con:change>
         <con:notificationType>REPORT</con:notificationType>
         <con:identifier>12345</con:identifier>
         <con:mutationType>DELETE</con:mutationType>
         <con:timestamp>2016-12-15T16:20:31.000+01:00</con:timestamp>
      </con:change>
   </med:notificationRequest>
</soapenv:Body>

Voorbeeld Response
“notificatie ontvangen (resulteert daarna in Ysis tot een actie om de gegevens op te halen)”

<SOAP-ENV:Body>
   <record:notificationResponse xmlns:admin=etc.>
      <record:status>OK</record:status>
      <record:log>Notification Received.</record:log>
   </med:notificationResponse>
</SOAP-ENV:Body>

“deze patiënt is niet bekend in Ysis: er wordt vanuit Ysis verder geen actie ondernomen om de gegevens op te halen.”

<SOAP-ENV:Body>
   <record:notificationResponse xmlns:admin=etc.>
      <record:status>OK</record:status>
      <record:log>No  medical record found that matches your query.</record:log>
   </med:notificationResponse>
</SOAP-ENV:Body>

“Geen valide BSN: (voldoet niet aan de BSN 11-proof validatie).”

<SOAP-ENV:Body>
   <record:notificationResponse xmlns:admin=etc.>
      <record:status>FAILED</record:status>
      <record:log>Client Error: Not a valid BSN.</record:log>
   </med:notificationResponse>
</SOAP-ENV:Body>