Read on Twitter
There is no “properly” - only a set of options with various trades offs, so that is why options appraisal needed as part of process. Also, this isn’t purely a technical question because the best way to answer is to decide priorities. https://twitter.com/rslewissally/status/1296119451692277761
First, you could look at this through a lens of complexity. Is it complex (and not just complicated)? Well - some aspects simple really - eg data storage & usually we use PROM tools that are externally published and (sometimes) validated (depending on context used & “well-known”.
So you could use a simple database for storage - but actually it is more complicated - you’d need to link those PROM data to patient and events to understand the context in which those data can be interpreted. Eg “Let’s analyse data before and after that hip replacement”
And, you want data that’s self describing. Now you can do this with SQL but what about change semantics and versioning and we’d probably prefer to abstract our persistence using APIs / standards because while data won’t change, our architecture might well need to do so.
And, it isn’t only complicated but complex as well, as do we fully understand the domain space here - eg how we’ll trigger PROM collection, how we’ll want to extend to other sources of patient data from personal and home devices etc?
What about real-time analytics so we respond to events? And what about seamless services? Do we need to centralise to create a seamless service or, are we always going to have a heterogeneity of systems & so build flexible “systems” in the large? (Think Internet not a server).
So the best engineering approach here is to modularise and decouple - recognising issues that are orthogonal to one another - and then use those building blocks to solve a problem today, while building systems that can flex and adapt to our changing needs.
So I would say your data definitions are independent of your persistence mechanism, independent of the software that creates those data, and independent of the software that uses and processes those data.
So the data architecture is a small (and relatively simple) cog in the wider data architecture required. Lots of options even here but all will need to support self-describing data for longevity, immutability and awareness of context.
Lots of options and no “proper” way, but we should have a set of principles and task smaller teams to build and help us learn.
Actually I wouldn’t care much if one group stored one type of data in an openEHR repo, one stored FHIR questionnaires in a FHIR repo, one created a FHIR facade on a SQL database. But as a developer I want a seamless view across all of those options.
The persistence is less important than the self describing “data-first” approach. The paradox is that people are now arguing implementing things using “standards” is ‘for the future’ and slow, but it actually would allow multiple teams to work in parallel with minimal need...
... for constant coordination [which always slows down work]. We should adopt approaches that speed up our work, and my observation is that this still isn’t happening.
See this from 2017: https://wardle.org/clinical-informatics/2017/10/19/data-driven.html and suggested critical foundational building blocks: demographics/identity https://wardle.org/platform/2019/10/18/demographics-patient-identity.html and appointments/scheduling https://wardle.org/platform/2019/10/18/appointments-scheduling.html
None of this requires a new PAS, or changing codes in different systems, because we need to be thinking in terms of national abstractions not concretions such as organisational boundaries or systems.
