The specification never had a concrete definition of the context for the persistent COMPOSITIONs. From the narrative descriptions and examples given in the spec, the most natural context is the EHR, meaning that there could be only one instance (with many VERSIONs) of a persistent COMPOSITION per EHR.
Recently, Bjorn mentioned they were using persistent COMPOSITIONs having many instances of them on the same EHR, associated to different episodes of care.
Thomas mentioned "..'persistent' ust refers to the notion that the content of a Composition remains valid over the lifetime of the EHR. Conceptually, this is true of problem list, Rx list, family history etc, in a way that it is not true for recorded vital signs, reported smptoms and so on. 'Persistent' doesn't require there to be only one of any kind of list."
I think that last part is not explicitly stated in the specifications, and should be.
Also Thomas mentioned the issue of not having just unified medication list in the EHR could cause problems, but that is not the case for multiple problem lists and other types of lists conceived as persistent, like allergies. "... So I'd say that the 'problem list' concept here has to be understood as not related directly 1:1 with the patient but related 1:1 only with providers, or types of providers. Ideally there would be only one for each type of care (CV versus obstetric r whatever) but maybe even this is not true."
Again, I think if we want, for instance problem list, to be more related to each provider than to one patient, we need to state that on the specs, and maybe add examples showing just how that would work.
Ian mentioned he could see at least two different medication lists for inpatients and outpatients. And also mentioned different providers might have different allergy lists for the same patient.
I'm not sure if I see the point of something that is diagnosed by one professional, not being in a list of the same type of data, like allergies, for other professionals. Even the medication processes, that are very different for inpatient or outpatient, and also we could add for prolonged treatments and chronic medication, at the end if the patient is taking a drug that should be part of his/her medication list.
And two concepts were mentioned: persistent over a lifetime and persistent over an episode (Thomas / Ian).
And the reason of having persistent COMPOSITIONS by Thomas: "The original reason for marking Compositions as persistent or event was to be able to find the persistent ones quickly...".
Sebastian Iancu mentioned they use FOLDERs to represent episodes, and inside those they can have persistent COMPOSITIONS that are persistent for that episode.
Based on what was discussed here (full discussion) https://openehrspecs.slack.com/archives/C2BSBP10C/p1558327074005500
We need: (not in order)
1. clarify the concept of persistent and give correspondent examples of what is possible (now all examples are one persistent of each type per EHR).
2. check current requirements for episodic data, per-provider data and per-patient data.
3. think of relaxing the idea of persistent or define other categories maybe "episode-persistent" / "provider-persistent", leaving "persistent" for patient-persistent (one type of list per EHR)
4. analyze Ian's comment about having the COMPOSITION category being defined in the archetype and that being mandatory.