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.
Related to - suggest we merge.
I agree the issues are related, but are about different topics. I also see some comments on the other issue that might be related to this one. The 88 was created more thinking about missing terms in the terminology (in 2012!), and this one is about defining the scope of “persistent” category, and maybe adding a new category for stuff persistent in an episode. But, we also need to consider Code24 solution, where they use folders for episodes, so “episode persistent” might not really be strictly needed, it was just something DIPS interpreted and used the current “persistent” that way.
I suggest we close as a duplicate of this one, because this one is wider in scope and covers that one entirely. Readers of this issue should be instructed to read the discussion under 88 as well.
Conceptually, I don’t find marking episode-related compositions as “persistent” appealing. Either another category is needed, as has been discussed (like episode-persistent), or those should be “event” categories and linked to episode in another way.
The original does actually deal with a slightly different issue - what does ‘process’ term mean. The conversation that followed did overlap with this PR. I have suggested that we can resolve 88 by a very minor documentation change, then carry on the discusson re ‘episode persistence’ here
To try to tie this off, I think we have consensus that we need to add a new term here
I propose adding ‘episodic’