Federation of persistent/episodic compositions

Agreed, but: it’s more acceptable if the other organisation only edits a new version of that data, and then tells the federation service about this new version. That way the organisation only need to trust the particular federation service, for a specific composition, coming from a specific organisation, that tells you there is a new version of your data. That should scale reasonable well.

And in the end we really need to start trusting other organisations to edit data that is highly relevant for my organisation.
So the use case that gets mentioned most in NL is ACP (resuscitation policy). What you want is:

  1. prevention of undesired treatment. E.g. GP records no more hospital admission, patient collapses, neighbours call ambulance, ambulance doesn’t know about the ACP info from the GP and brings to hospital anyways. Patient dies in hospital after getting invasive procedures and ranking up cost. Everybody unhappy. What you need for this is to have the ACP information available in the care network of the patient. In our region of the Netherlands, involved parties are ambulance, gp, hospital, home care nurse (potentially more). What you need to prevent this is:
    A) the ACP information available to all parties in the network.
    B) be able to trust that information

To achieve A and B, you have the following requirements:

  • all parties need to have an application that can process the ACP data
  • a common data format for ACP data
  • a common understanding of the semantics of that data
  • verification of the source and authenticity of data
  • guarantees about the (clinical) trustworthiness of the data
  • know the information is current
  • a shared access policy to control operations on that data
  • a trustable networking protocol
  • to know the source of truth (depending on variables for episodic data)
  • easily shift this source in case of a change in patient situation (e.g. responsibility for ACP decisions shift from GP to specialist in case of hospital admission)
  • (probably more?)

And you want it in a data centric and distributed way, for reasons not specific to ACP data (briefly mentioned above in my reply to Pablo saying each hospital wants a copy of the data).

  1. You want to have synergies in recording the data to save cost and labour. e.g. no longer each party having to manually update its version of the data.
    This will require most of the above requirements to a more stringent degree

  2. Increased clinical alignment/agreement on the content of the meaning. This may require additional functionalities like video calls, scheduling meetings etc.

As an approach for this project, given there will be many similar ones:
I think you need to

  1. determine the parties in the clinical network, pragmatically a region for now (free text)
  2. Agree on scope and goals (free text)
  3. Agree on a data set and its semantics for ACP data (archetype/template)
  4. Agree on ways of working that guarantees production of data according to those semantics
  5. Define and enforce an access policy that guarantees those ways of working. E.g. regio code that specifies user X can for patient Y write compositon.acp if that user is a doctor, is employed by an organisation that is a party in the federation (for this use case) and the doctor X is at this moment responsible for managing the ACP data for patient Y. More info: access control for openEHR 'resources'

In this way you can scale by the use case. And different use cases can have different results of these four steps.

And the proposal above also downsizes the size of the community Thomas describes, without creating issues on the other requirements. But off course creating cross community issues.
But I feel it’s the only way to make timely progress. Because already this list I disagree with, since a problem list is definitely episodic to me. As explained in the post above. And I can see the same reasoning go for the other compositions, although less convincingly.

For event data definitely this union of a query is where we should focus the federation spec. I’m even ok with keeping persistent/episodic compositions out of scope of the current version of this version of the federation spec. But anyways it’s to me use full on thinking about the challenges and solutions around federating persistent/episodic data.
I wouldn’t like to do what Ian suggests to sync data across CDRs, I think the risk (technical and clinical) of issues is not worth the benefits, maybe outside of niche use cases or highly controlled scenarios. I also feel there shouldn’t be a global universal truth of data location. At the very least it should be a location per patient (otherwise you end up with something like the country, EU, UN managing that, the horror…) And even a truth per patient is highly problematic. Because, at least in NL law there’s a responsibility for individual doctors and care organisations for that data. And you can’t make good on that responsibility if you can’t control the data. And you can’t control it if it’s not in a CDR under your control. Solving this by trying to trust a central authority requires enormous governance issues making it extremely slow, and it doesn’t scale. History has proven it’s not been possible, and little reason to expect this to change.