Federation of persistent/episodic compositions

[joostholslag]

@sebastian.iancu

Personally, I expect that in reality this won’t be easy to solve as the any of the above - I think there won’t be consensus, or cross-domain and cross-setting acceptance that such data persisted in one CDR in one organisation, will be actually (and suddenly) modified directly (or indirectly) by other orgsanisation.

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).

2. 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

3. 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.

@thomas.beale

Also true - even establishing what is ‘persistent’ content will require some whole-of-community agreements. But for a few things - medications, master problem list, allergies, vaccinations - I would think everyone will agree on these as being persistent content. with the same information design etc.

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.

@sebastian.iancu

I think for now it safer to go for a ‘union’ of federative query results, indicating properly the source of data, perhaps do some smart filtering on duplicates. Thus ‘show them all’ to the user. The next step would be to try out (occasionally) what Ian suggests as 3) and aim that on long term we should go for 1) where that global-data actually resides (somehow magically) by the patient.

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.