Stream: implementers
Topic: FHIR & event sourcing
nicola (RIO/SS) (Jan 30 2017 at 12:17):
We think about architecture to support patient, physician and some other indices for big city. Event sourcing looks promising: so every EHR produce log of events about data changes and our service aggregates and merges this streams into snapshots - FHIR Resources and serves by REST API. Question is about events format and granularity: {patientCreated, resource json} or on element level {telecomChanged, patientid, from, to}. Does anybody think about this? This seems similar to messaging, but on more lower level.
Ewout Kramer (Jan 30 2017 at 14:21):
Just thinking out loud: It seems you need to reflect the intent of the REST call: so a PUT updates all and needs full patient granularity, whereas a PATCH may need to have smaller granularity?
nicola (RIO/SS) (Jan 30 2017 at 15:15):
One idea is to use transaction log (i've described in my post - https://medium.com/@niquola/fhir-history-transactions-subscriptions-70d4f04607e0#.dzqob7u0z), which consists of transactions for everything - create patient, update, patch etc. And yes we need PATCH - for small changes and better merge process (less conflicts and data loss)
Ewout Kramer (Jan 30 2017 at 15:20):
We have introduced PATCH in the spec....
Ewout Kramer (Jan 30 2017 at 15:20):
Both as the PATCH http verb and the $patch operation!
nicola (RIO/SS) (Jan 31 2017 at 17:21):
We've discussed PATCH Resource with @Grahame Grieve :)
Grahame Grieve (Feb 06 2017 at 03:53):
yes. implementation and write up coming today
Last updated: Apr 12 2022 at 19:14 UTC
