Questions about CONTRIBUTION of VERSION<FOLDER>

Implementation Platform
#1

Hi all,

I’m designing some new test cases for the openEHR conformance verification, now for the commit of CONTRIBUTIONS with FOLDERS.

The first question is about modification: could an internal FOLDER be modified by a CONTRIBUTION without the full directory structure in it?

That has the consideration that in order to modify an internal FOLDER (not directory) it’s uid should be set, which is optional by the spec.

Second question is about the delete change type, which can be broken into two cases:

  1. Can the EHR.directory be deleted?

  2. Can an internal FOLDER be deleted? (which has the same implications as the MODIFICATIONS: the uid is required for deleting)

What do you think?

Thanks a lot,
Pablo.

PS: I shared this some time ago but it’s good to bring this up since it has to do with this topic. I have proposed some extra operations on the REST API to deal with internal FOLDERs, not just the directory https://wiki.vitagroup.ag/display/ETHERCIS/FOLDER+related+decisions+-+internal+implementation%2C+API+and+conformance

#2

An important aspect when we talk about FOLDER, is whether or not we speaking for RM 1.1 (or later). In the past the directory used to be mandatory, so you could not delete it, but nowadays this is possible.

FOLDERs can be deleted, but this works the same as deleting COMPOSITIONs.

Support of EHR.folders has to be added to REST Api specs, that is true, it is somehow planned and will be in upcoming release.

#3

Well a FOLDER structure is just a hierarchy. Let’s say the hierarchy is in a certain state at time 1, with some particular tree structure of FOLDERs, plus some COMPOSITION refs. Now you make changes to that structure, which could be to delete FOLDERs, add FOLDERs, add or delete refs to COMPOSITIONs, or make changes to any FOLDER.details. Then you save those changes as part of a CONTRIBUTION - which could also include new COMPOSITIONs, changes to COMPOSITIONs etc.

Now, today we have EHR.directory (0…1 tree), and also EHR.folders (0…N trees), each of which the above description applies to. So you could modify directory, and say 2 of the folders trees, as well as other content in the EHR, all in one CONTRIBUTION.

Contribution is really just a change set concept.

Note that how your implem stores changes is its business. It could store diffs, if it’s really smart, or it can just store the full structures. To store diffs, an implementation would need to diff the new content with the current version and store that. None of this is visible at the interface level.

#4

Yes, I’m talking about ehr.directory 0…1

So can we delete an internal folder without sending the whole directory?

I don’t think that’s possible, since the only versioned folder is the directory. This is different than how compositions work.

The proposal I started already has operations to work directly with internal folders, but requires all folders to have an uid set. If this is scheduled to discuss is the near future, I would like to participate done I’ll have more time because of my vacations :slight_smile:

#5

Since v1.1 the directory is just a VERSIONED_FOLDER, containing other FOLDERs, with or without uid being set to them. There is support for more VERSIONED_FOLDERs, not just the directory.

Changing something in the static content of a versioned FOLDER, even if that change is also a subFOLDER will require a new version of the top (VERSIONED_)FOLDER container.

Your suggestion with structures with FOLDERs using uid is nice and useful, we also have something similar. From my perspective the assumption is that the tree will be build on runtime using FOLDERs persisted in EHR, so it is an application level functionality - thus I’m not sure if we have to change anything in the specs. Perhaps we can have an implementation guide or describe it as a complex example.

#6

Thanks @sebastian.iancu I see in the latest spec there is a new EHR.folders, I guess we are not working yet with the latest RM. I think with the previous version of the spec only the EHR.directory had the capacity of being VERSIONED_FOLDER and the rest of the subfolders were not versioned.

I guess with the latest RM, any top level and subfolder could be a VERSIONED_FOLDER. If that is correct, how versioning works when updating a subfolder? I mean: versioning a subfolder will “trigger” the versioning of any ancestor folder that is also versioned. Do we have that process described somewhere?

Maybe versioning only at the top level was there to prevent this domino effect.

I didn’t get that, not sure what ‘build on runtime’ means. From what I understand as ‘runtime’ is anything that happens with the system running, not a design or clinical modeling thing. In that context , any EHR creation, FOLDER creation, COMPOSITION commit, etc. happens at runtime.

My proposal is only about using the FOLDER.uid to be able to operate (create, move, delete, add items) at a specific FOLDER level, without the need of sending the full EHR.directory structure each time a client operates with a FOLDER of an EHR (which was required by previous versions of the spec).

I think we need to specify how to operate over FOLDERs, and how that affects versioning, at the spec level, I don’t think this is ITS. But maybe I misunderstood what you tried to explain.

1 Like
#7

A FOLDER structure is just a tree. The EHR has a ref to a VERSIONED_FOLDER, which is just a VERSIONED_OBJECT. There’s no ‘versioning’ inside, just as there is no versioning inside a CLUSTER/ELEMENT tree - it’s just normal data.

Versioning, as for COMPOSITIONs or anything else, is just of the whole tree.

1 Like
#8

Ah sorry, wrong choice of words, I guess related to me using other platforms. Perhaps ‘on the application level’ (instead of ‘on runtime’) would be closer to what I’ve meant say.

1 Like
#9

Yep :slight_smile:

In fact in the ‘latest’, EHR has two relationships with VERSIONED_FOLDER, one for directory 0…1, and one for folders 0…*.

https://specifications.openehr.org/releases/RM/latest/UML/diagrams/RM-ehr.svg

Gotcha! I was thinking about VERSIONs of a FOLDER and wrote VERSIONED_FOLDER.

What I don’t understand is: in ‘latest’ RM we can have many VERSIONED_FOLDER in the EHR. What happens if VERSIONED_FOLDER<1> has a VERSION with FOLDER<1> and another VERSIONED_FOLDER<2> has a VERSION with FOLDER<2> and that FOLDER<2> has FOLDER<1> as subfolder.

If a new VERSION for FOLDER<1> is created inside VERSIONED_FOLDER<1>, does that affects FOLDER<2> and the VERSIONED_FOLDER<2>?

Let me draw a picture to be more clear. I’m not sure if that situation could happen. I guess so, because a FOLDER can have (AFAIK) any other existing FOLDER as a subfolder.

1 Like
#10

IMG_20201204_174520
IMG_20201204_1745202688×1512 547 KB

I’m trying to figure out if FOLDER F5 can have a reference to FOLDER F2, even though those are on different VERSIONED_FOLDERs.

And if that reference could happen, what happens to F5 if F2 is affected by a change, like deleting it or adding items or subfolders to it.

1 Like
#11

This cannot occur, because FOLDER - FOLDER relationship is composition, i.e. containment (RM UML here).

A FOLDER can only have one parent. However, more than one FOLDER can point to some other VERSIONED_OBJECT, normally a VERSIONED_COMPOSITION, by reference.

1 Like
#12

Good point, I’m not sure if all implementations are using the parent attribute for folders or just using the FOLDER.folders to represent parents-child relationships, but not sure if child-parent are represented

I need to check the spec about the folders to be sure that usage of the parent is clear.

1 Like
#13

Could you help me understand this. I read that a folder can have only one parent: defined in the parents’ folders attribute, right?

But a folder also has an items attribute that has (a list of) OBJECT_REF. This OBJECT_REF can be a LOCATABLE_REF right?
Since FOLDER inherits from LOCATABLE, can a LOCATABLE_REF in F5 point to FOLDER F2?
And can this LOCATABLE_REF ‘be’ a DV_EHR_URI? And thus point to a specific version of the FOLDER F2?
Or what is the relationship between LOCATABLE_REF and DV_EHR_URI?

#14

Well a FOLDER is contained in another FOLDER, so it can’t be contained in another FOLDER. I.e. FOLDER - FOLDER relationship is not a reference (such as an id), it’s containment, so you don’t need any ‘parent’ attribute to ensure this - it’s just the same as an ELEMENT or a CLUSTER can only be contained by one CLUSTER in the ‘items’ relationship.

1 Like
#15

Yes you could use this method to point to some FOLDER in another hierarchy, if you really wanted to do that for some special purpose.

1 Like