Embedded Relative Links

In OLab, we have often made use of imagemaps and hotspots in our cases. This is particularly relevant for our Virtual EMR approach, which uses screenshots from a real EMR (displaying data on fictitious patients).

SeeĀ Better education & evaluation in an EMR (BeeEMR) for more on this.

To do this, we mapped the URLs of target Nodes to hotspots on the image, a technique that will be pretty familiar to those who have worked with imagemaps.

But the problem with this approach is that these target URLs are hard-coded to the current map. They do not work when the map is ported to another server, or even if a copy of the map is made on the same server.

The workaround is simply to update all the target URLs but there can be quite a lot of these and it is quite a nuisance. You can use the Find/Replace function the Node Grid editor to some extent to help with this but it is still tedious.

As a possible solution to this, we came up with the concept of Embedded Relative Links. While this was well described in our OLab3 dev channels, we never did manage to resolve the problem.

In OLab4, we have some additional possibilities which can be explored. One of the proposed changes is to have named Link shortcodes e.g. instead of having to type in a fully qualified URL, you would instead use a shortcode like this: [[LINK:xxxx]] where ‘xxxx’ is the name of the target Node.

To some extent, this would resolve the portability problem when migrating cases between servers because the named Link would still point to the correct target Node.

However, this does raise a deeper issue within the Player engine: when interpreting the set of target URLs associated with an imagemap, can the Player engine resolve the Embedded Relative Links, or can it only cope with hard-coded URLs?

This has yet to be resolved in the dev chain of fixes and improvements waiting to be resolved. Watch this space!