Hi, in EHRBASE it was decided to add support for CONTRIBUTION or EHR_STATUS and FOLDER.
I’m in charge of designing the conformance tests and test cases to verify such service and found a couple of cases I would like to discuss with the community.
‘incomplete’ EHR_STATUS
When committing CONTRIBUTIONs we will have VERSION<EHR_STATUS> inside, and VERSION has lifecycle_state which can be incomplete, complete or deleted.
What would it mean to have an ‘incomplete’ EHR_STATUS? Is that even valid?
Updating EHR_STATUS and losing data
If we create an EHR providing an EHR_STATUS that has PARTY_SELF.external_ref, that will contain the ID of the patient associated with the EHR.
Then if we commit a CONTRIBUTION with VERSION<EHR_STATUS> and that EHR_STATUS has a NULL external_ref in the PARTY_SELF, or a different ID, the previous PARTY_REF/OBJECT_ID will be overwritten.
Should the update process just create a new version of the EHR_STATUS without the information that was previously there?
What I see is: if we want to update, for instance, is_modifiable on an EHR, we will need to provide the full PARTY_SELF each time to avoid losing patient IDs.
(I know we are not really losing anything because of versioning but when querying we will get just the latest versions).
Thanks,
Pablo.
PS: something we detected is change_type create/delete shouldn’t be supported when committing a CONTRIBUTION with VERSION<EHR_STATUS>.
You might be correct that this is not necessary for EHR_STATUS but I can think of a few ‘edge-cases’.
Needing to update an external identifier will not be all that unusual, and an audit-trail of what went before would be useful. Just as for Compositions, I would presume that any existing data should be kept unless it is incorrect.
So that should never happen unless it is intended that the ‘current’ EHR_STATUS actually has a null - difficult to think why that might be, though.
I agree that’ incomplete’ seems like a stretch here but there might be situations where an EHR_STATUS record has been started but for some reason is not ready to ‘go-live’ and be visible/queryable - similar conceptually to an incomplete Composition - not ‘normally’ queryable or available ? some mandatory attributes not populated.
I’ll not argue it is a compelling use-case but keeping the same behaviour as for compositions and folders feels worthwhile.
I guess it is valid at this time (according to versioning mechanism and considering also scenario Ian described), but it will make no sense and render the EHR in an unusable state (as EHR.ehr_status is mandatory). I suggest to raise this issue in SEC group, perhaps others will find it also problematic and adding an invariant to prevent such situation is a solution …
Yes, that should be the way to go, I guess we cannot prevent such thing by writing specifications. Of course, this might also make your EHR unusable, but in this case, where you depend on having a external_ref, I guess a constraint in an EHR_STATUS archetype might be the solution … or am I wrong?
At Code24 we don’t use/store data in external_ref, our EHRs are completely decoupled (and anonymized) from their corresponding ACTORs, the logical link being stored in a separate encrypted patient-index.
If, from REST Api perspective, you would like to update only one field (on API level, while the system is still creating versions as openEHR requires it), then we should investigate PATCH method… but that’s something else, perhaps an answer to a question that you did not asked
Better does allow you to populate EHR_STATUS other_details with archetyped data which is then equeryable via AQL but there is no validation of the instance data structure, which isa gap - we could do with a way of supporting EHR_STATUS archetypes, and even templates.
I’m not sure @pablo if I fully understand your question.
My suggestion was that, if you want to impose some conditions regarding external_ref, it can be done via archetype constraints.
This is on my personal wishlist since a long time. We will definitely have this eventually in EHRbase for EHR_STATUS, Folders, Other_Details in Feeder_Audit etc.
