I think this was discussed some time ago, since most implementations have a different understanding of what “persistent” category is. Also I think the current spec is not clear about that, and there are not many examples. For instance, in the EHRServer, persistent means just one composition compliant with a persistent compo archetype is allowed per EHR. So using CREATE twice for a persistent compo will fail the second time.
One thing we need to do is actually define the “persistent” category, and what is valid and invalid inside that category. Based on that, we need to modify implementations accordingly.
Then I’m open to any categories in between event and persistent, or even defining subcategories for those, like persistent.single (my current interpretation of “persistent”) and persistent.episodic. This second approach for subcategories might need an extra attribute in the RM but doesn’t require to modify system’s logic.
This is an urgent matter that we were delaying for a while, and will help to implement more consistent rules between systems, a step forward interoperability 