The question is in how far should openehr define a system. Should also describe an archival system? Should it describe also how to handle physical deletion? And why should it describe that?
It can become harder for system-builders to reach OpenEHR conformance. I think this is a wrong direction. OpenEHR defines a logical semantic flexible datastructure. And a query language. It does not even define on which way to achieve that. The technical details are implementers business. I think OpenEHR does not need a deletion flag, as I wrote before, that is describing a technical solution for archiving. I must excuse myself,I am not able to participate more in this discussion this week because I am onholiday Best regards. Bert Op ma 6 nov. 2017 15:40 schreef Bert Verhees <[email protected]>: > For the first scenario, changing a care plan, or stopping it, I wouldn't > think of calling it logical deleting it but bring it into another state: > stopped, or something like that. > > The second is in fact physical removing it from the Ehr and then saving it > somewhere in some form. In the openehr standard is, as far as I know not a > facility to do this. In fact the second scenario is, as I see it, from the > openehr point of view the same as the third. > > Bert > > Op ma 6 nov. 2017 15:11 schreef Thomas Beale <[email protected]>: > >> >> >> On 04/11/2017 18:38, Bert Verhees wrote: >> >> But also apart from that. The discussion is if a standard should >> facilitate an inactive patient (logical deleted) to still remain in the >> active clinical information system with a special flag or that he should be >> transferred to an archive system. This is the question which is important >> to decide if a standard should define a "deleted" flag. >> >> I think such a flag is a technical flag to organize some way of archiving >> data. It has no additional semantic meaning and should not belong in a >> standard defining semantic structures. >> >> >> just to be clear, we are talking about (at least) 3 different things: >> >> - *logical content deletion*, e.g. I want to 'wipe out' my second >> homeopathic Care Plan that is no longer relevant because I stopped >> believing in homeopathy >> - *archival of EHR*: I want to move the EHR to an archive system that >> allows access, querying (or at least extraction), but separate from >> operational EHRs >> - *physical deletion of EHR from entire system*: nuke this EHR >> >> The delete marker in the current model only applies to the first one. >> >> To support archival, we need to know what we think the archival workflow >> will be. Let's say we defined that, then I can imagine adding a new Boolean >> flag to EHR_STATUS called e.g. archived or ready_for_archival or similar. >> THis flag would prevent the system from 'seeing' the EHR even if it was not >> yet in the physical archive, and it would enable an archival admin process >> to know that it really can archive this EHR. When you think about it, a >> flag won't be enough, it needs to be some sort of signed 'consent for >> archiving' concept. >> >> For the third scenario, another flag may make sense like >> 'ready_for_deletion', but again, we need to study the needed workflow in >> detail to really know what changes to the models are needed. >> >> - thomas >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
