I worked with event sourcing in juridical context. The concept would also do in clinical context because not only the state is important but also how we get there.
So it could make the data-version system of OpenEhr superfluous. That would be a relief. But on the other hand, it should not occur very often that versions are stored.
A lot of queries are about state, and what I saw in an event store storage was shadow databases that stored the current states when applicable.
I wonder if an event store adds something to OpenEhr. I can imagine one strong point. Event stores can handle long lasting transactions. Sometimes in banking and business there are transactions that can take days, but more often, minutes or hours.
OpenEhr does not really support that. When the Composition is ready, it will be stored in a microsecond transaction.
More ideal would be that different parts of a Composition would be prepared for transaction immediately after they occur. Then it becomes possible to store not finished Compositions, cq events (f.e. Observations ), for the case something happens which makes it impossible to finish the Composition, even when the client systems goes offline.
Another use case for long lasting transaction in clinical context is that Compositions really can take hours or days before they are completed. For example, labs can take longer time, but semantically, (one could argue) , they belong to the composition in which is the clinical context for the lab.
Block chain can also be a great help in such situations.