Hi all! The issue (and some possible solutions/workarounds) is now described at https://openehr.atlassian.net/browse/SPECPR-279
Feel free to add information, comments etc there. //Erik Sundvall 3 nov. 2018 kl. 15:12 skrev GF <gf...@luna.nl<mailto:gf...@luna.nl>>: Either it is solve using standardised basic Archetypes or via the RM. The RM route is the preferred one. When thinking about it, then… Data in any Patient Record is either: - de novo data stored at a session - re-used pre-existing data (Reported data, used data in processes, etc.) This data is pre-existing data that is re-used. When querying for a concept it must be possible to restrict it to new data and/or re-used data. Again this can be solved via standardised basic Archetypes or the RM. The RM is the best option. Gerard Freriks +31 620347088 gf...@luna.nl<mailto:gf...@luna.nl> Kattensingel 20 2801 CA Gouda the Netherlands On 3 Nov 2018, at 12:23, Thomas Beale <thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote: I've just been thinking more about this problem. I agree we need to fix it, and it seems fairly likely adjusted rules for forming paths and storing archetype markers in data will be needed. But... the archetype structure mentioned is a hack for getting around the lack of order-tracking attributes in the RM. We've had a look at this before (e.g. here<https://openehr.atlassian.net/wiki/spaces/spec/pages/60358659/RM+additions+for+workflow+process>) but I would suggest we need to think soon about additions to the ENTRY class or package to properly model requester and receiver meta-data. - thomas _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
