Correct modelling inconsistency of every EXTRACT_CHAPTER being related to a single Entity


In the current specification, the EXTRACT_CHAPTER class has a mandatory entity_identifier attribute, which identifies the entity (usually patient or other demographic entity) whose data are contained in the chapter. However, a more flexible use of the model would allow some chapters to be used for purposes like common demographics.

The modelling of entity_identifier is also problematic. Within the EXTRACT_ENTITY_MANIFEST class, it is hard-modelled to consist of openEHR-style Ehr id and subject ids, but it would be more practical to use String identifiers, and also to allow more kinds of identifier.

The method of reference from EXTRACT_CHAPTER to EXTRACT_ENTITY_IDENTIFIER is also impractical, particularly in serialised expressions of an extract.


Thomas Beale
December 2, 2015, 12:38 PM

GENERIC_EXTRACT_ITEM.other_details - yes, you right, this is now changed - I've included this under SPECRM-14, since it corresponds better to that CR.

Re: the manifest reference - the property EXTRACT_ENTITY_MANIFEST.item_list can be used to directly specify Uids of items to be put in the Extract. Normally EXTRACT_SPEC.criteria would be used, but this property allows specific Uids to be stated. So it's not part of the Extract data containment structure, but rather part of the defnition of what is in the Extract.

Why is EXTRACT_CONTENT_ITEM.uid mandatory: this is needed to ensure every Extract item is referenceable within the Extract. It could be a copy of the X_VERSIONED_OBJECT.uid for openEHR Extracts, but doesn't have to be.

Heath Frankel
December 7, 2015, 10:42 PM

From where in the EXTRACT are the EXTRACT_ITEMs referenceable? Are you suggesting that the item_list reference these EXTRACT_ITEMs rather than the items themselves?

I still question why we need to mandate uid. I think we need to try and make a basic extract as simple as possible.

I also wonder why is_primary needs to be mandatory?

Thomas Beale
December 7, 2015, 11:11 PM

Re: uid, if EXTRACT_CONTENT_ITEM.uid is not there, we can't reference items within the Extract. We want to be able to do this if they are shared demographic entities, so that EHR data objects can point to them. If you look at fig 10 ( you can see the uids on the yellow EXTRACT_CONTENT_ITEM objects.

I think you are suggesting that we should just use the uid on X_VRESIONED_OBJECT, which would work, and remove it from EXTRACT_CONTENT_ITEM? If we do that, then there is no uid on GENERIC_CONTENT_ITEM (it was inherited from EXTRACT_CONTENT_ITEM), so we'd have to put one on GENERIC_CONTENT_ITEM, so that these items are referenceable in non-openEHR Extracts. We could make those uids optional if you want.

Would this work?

The is_primary flag is just a Boolean, so it's always there in materialised objects; it's only for XML that it might be optional; if we make it optional, we need to state a default, which is also the case for all the other Booleans. We can do that - do you want to suggest some sensible defaults?

Heath Frankel
December 7, 2015, 11:15 PM

No, I am simply saying do not mandate uid. It already exists from LOCATABLE as optional, why not just leave it as is.

Let's leave Booleans as is.

Thomas Beale
December 7, 2015, 11:32 PM

Done and uploaded - see links under 'Activity' tab.



Thomas Beale

Raised By

Thomas Beale


Affects versions