There may be some advantages in routine application of uid at ENTRY level. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: [email protected] twitter: @ianmcnicoll
Co-Chair, openEHR Foundation [email protected] Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 13 December 2016 at 12:57, Thomas Beale <[email protected]> wrote: > > > On 13/12/2016 23:46, Seref Arikan wrote: >> >> My preferred scenario would be to have an identifier on every node indeed. >> Not having that, I could live with identifiers for at least some types, such >> as entry subtypes and a few more. If it cannot be UID, so be it. >> >> What is the meaning of overhead here? Processing time? Memory/disk space? >> According to which criteria the overhead is quantified as "quite a lot"? >> >> You can see I'm not really convinced here :) > > > perfectly reasonable ... But I actually did calculations a few years ago on > the overhead imposed by ISO 13606, which would force UIDs everywhere. It's > quite significant based on a reasonable sample of mixed EHR data, mainly > because Guids are much longer than a lot of values. I will try to locate > this. But it's not hard to replicate. > > When one is purchasing terabyte RAID 10 secure storage, adding another 20% > or even 10% starts to matter. > > - 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
