-
Notifications
You must be signed in to change notification settings - Fork 2
Phil Connectathon Presentation
Eric Haas edited this page Dec 12, 2019
·
16 revisions
- Cigna: https://ttbfdsk0pc.execute-api.us-east-1.amazonaws.com/dev
- Ref implementation ( Logica ): https://davinci-alerts-receiver.logicahealth.org/fhir/$process-message
- WildFhir (Aegis): http://wildfhir4.aegis.net/fhir4-0-0
- Ref implementation (HealthLX/Logica)
- Audacious Inquiry (Keith Boone): (converted ADT v2 to Da Vinci Notification Messages)
- Health eData Inc (Eric Haas): Flask app facade using Synthea generated data from FHIR reference Servers - pending
- Aegis (Richard Ettema): <...link to ts resources>
Message Successfully Sent to all Servers
Logica Reference Client UI
Audacious Inquiry ADT to FHIR Notification Transform
Cigna Server UI
Client Issues:
- Issue with Cigna server no metadata endpoint so some clients like Logica or hapi Java Client will not connect out of box.
- Issue with Java Client expectation for http response for message without response message (see below)
- discussion with Java client authors about this behavior
- Established that for notifications (vs for example requests) will be synchronous messaging with no response message ( just an http +/- OperationOutcome ).
- Asynchronous case may arrive, if there is a need to batch a large number of messages (1000's). In that case, the bulk data guidance should be used.
- However, for batching smaller number of messages can use transaction bundles synchronously.
Guide only covers the "happy path". Errors are covered in the $process-message
documentation in the FHIR specification. Polled the participants to determine if more guidance is needed.
In addition to basic guidance in FHIR specification for $process-message
:
-
200
,202
,204
+/- OperationOutcome all ok for successful transactions- Issue : what does widely use Java client want?
-
401
,404
+/- OperationOutcome no point in retry -
429
+/- OperationOutcome retry but slow down traffic -
500+
+/- OperationOutcome - server issues may retry a few times
-
MessageHeader.author
definition mentions device, but choice of Device not available: Tracker pending - Messaging section states that all messages expect response message which is not how notifications is written. For notification - only expect either only an http response or an OperationOutcome Tracker pending
-
Encounter.type
may not be known when send notification. -
Keith review 1/2 million v2 ADT's only.
- 10% had PV1-4 (Admission Type) codes
- 20% had PV1-18 (Patient Types) codes
FYI 'Encounter.reasonCode' codes at time of ADT
- 4% had PV2-3 (admit reason) codes
- ~50% had PV2-3 (admit reason) free text
Preferred options if data is not available is to use the appropriate “unknown” concept code from the value set SNOMED
- alternative is to create a new profile for Da Vinci Notifications
- good new is forced clients to create own
- for next time will have some basic test data available