We just kicked out a new minor version release. For those of you who are running your own OpenLabyrinth servers, you can download this new version from https://github.com/olab/Open-Labyrinth/releases/tag/v3.2

For most of us who don’t have to deal with that level of geekiness, you can simply check out the new features at http://demo.openlabyrinth.ca/ – you may need a login to see many of the features that are oriented towards case authors.

In OpenLabyrinth v2, there was a useful little feature where you could place a bookmark anywhere in a lengthy case and then return to that same point earlier. This feature had lain dormant in OpenLabyrinth v3 for some time but now, good news…

Bookmarks are back. If you click the [bookmark] button on the right side of a case node, you can leave a bookmark in the case, to which you can return later. And, as an enhancement over the old version, now any scores that you had accumulated to that point are now restored. If you take a look at the Session Report at the end of the case, your data and pathways from the two parts of the case are merged into a single session.

This will be particularly useful for our longer cases. Try it out and let us know what you think.

A few small things to note when using Bookmarks:

1. This only works for registered Users (the system has to know who you are to maintain continuity between such sessions).
2. When you click on the [bookmark] button, don’t expect any fancy bells & whistles to go off. OLab just quietly notes your current place.
3. To resume a bookmarked case, click on the menu Labyrinths | My Labyrinths and then scroll or search through that list. Any case where you left a Bookmark will have an orange [Resume] button, as well as the usual green [Play] button.
4. A User can only leave one bookmark per case but can leave bookmarks in as many cases as they like.
5. When you Resume a case from a bookmark, the bookmark is immediately cleared.

As a case author, if you want to prevent use of Bookmarks, simply remove the [bookmark] button from the Skin for that case.

We have a few changes coming over the next 2-3 weeks in our server setups and apologize for any inconvenience caused.

The development box at http://demo.openlabyrinth.ca/ is running on a Dell server that is now getting a bit elderly. We will be moving it to a virtual server farm for better reliability and capacity. And speaking of capacity, the disk is rather full as well so we will be adjusting this as well.

[Update on disk space: I found a whole pile of old unneeded files and deleted them. Much more disk space now. I hope we also see a small improvement in OLab3 performance.]

So those who are doing dev work at demo.olab3 might find that server down intermittently during this changeover.

For our production servers, we will take a more formal and smooth migration approach with proper announcements.

So, we have recently described some new ways to find good virtual patient cases on a single OpenLabyrinth server. But wouldn’t it be nice to be able to search across multiple servers at once, just as Google does?

In techie terms, searching multiple servers at the same time is called ‘federated search’. There have been some discussions about ways in which we could do this. Indeed, a group at AUTh in Greece have developed a promising federated search tool for virtual patients, within their Melina+ content management software: http://www.meducator.net/?q=fi/content/melina-open-source-content-management-system-medical-educational-resources – this is a work in progress and shows how difficult this is to do.

We have posted some of our exemplar cases in a Google Docs spreadsheet, as we told you recently. https://docs.google.com/spreadsheet/ccc?key=0AmgSucgM9Y3NdGdZMFFteGdJN1RDUkhXRTdVbllON0E&usp=drive_web#gid=0

Google Docs allows us to collaboratively annotate and post such examples, but this is not federated search. Do you have any suggestions on how we could improve the discoverability of our cases? Please contact us.

Ok, so we just looked at some simple ways to find case materials, in the previous post. But consider the following situation: how will you find a case on, say, non-ischemic chest pain? If you use the simple search tools already, you probably won’t find anything, unless the author happened to use that same phrase in the case description.

Furthermore, what search terms will you use for this? Chest pain covers a variety of different diagnoses and ICD9 codes – you might be looking for chest wall pain, pleurisy, pericarditis, Bornholm’s costochondritis, pneumonia, fractured ribs, or just a case that covers some of these in its differential. The number of synonyms makes things tough… and if the author has used a different term, such as ‘pleurodynia’, to describe their case, you will be out of luck.

We have been working on semantic search tools for OpenLabyrinth. (We are nearly there and hope to have a test release soon). With semantic search, it is more able to understand the concept you are searching for, rather than the exact phrase. A semantic search engine, along with semantic indexing of the case materials, allows you to search for the concept of chest pain, and has access to predefined vocabularies so that it can group these various symptoms along with chest pain. This should pull up a much bigger list of relevant cases.

Because the semantic indexing is applied to all the nodes within the case, you are also not dependent on the case author having inserted all the right metadata about the case in the description or title or keywords.

We will post more about this when our semantic indexing tools are online. In the meantime, if you have comments or suggestions about this, please contact us.

Great news! We now have hundreds of virtual patient cases spread across our various OpenLabyrinth servers on all sorts of topics.

The bad news is “we have hundreds of… all sorts of topics” – so how the heck do you find something that fits your needs? After all, you don’t want to write your own case, if someone else has already invented that wheel. Well, we have a number of things to help you out, and even more exciting, a number of powerful tools on the way. But we are also interested in your needs and perspectives on this, so please feel free to contact us if you have some suggestions on how to improve this.

Coming soon are some interesting capabilities, using semantic indexing, which should make our case materials much more discoverable.

The first tip that we have for our current users is that there are two simple Search tools in OpenLabyrinth. If you use the Search box in the top left corner of the main page (you must be logged in to see this), this will search labyrinth titles and the description field, which makes it much more flexible and will find a greater range of cases.

If you click on the menu Labyrinths | My Labyrinths, you will see a table of current cases on this server. This table can be sorted on a number of columns, which sometimes helps to find a case when you might remember roughly how recently you created it but cannot remember the name. There is also a search field within the table frame on the right side. This only searches by labyrinth title but will match any part of the title. It is also an iterative search and will start to show matching titles as soon as you have typed at least 3 characters.

More on finding cases shortly…

Counter values can be displayed on each node, and these can be turned on or off for each counter on each node. You can also directly refer to the value of a Counter within the text of a node by using its wikiref e.g. [[CR:1234]], and the Counter value will be inserted into the node’s text. It will vary according to the current value of the Counter.

We have also developed a method to embed the Counter’s value within an image, somewhat similar to a Skin. These are known as Counter Displays – select this feature from the left side menu when editing a case.

For an example of how these work, check out this case: http://demo.openlabyrinth.ca/renderLabyrinth/index/307

While they are powerful, creating Counter Displays is a bit finicky. We have created an addendum to the main User Guide – you can download it from here.

For those who are used to working with web sites and uploading images, they will find it pretty easy to do this with OpenLabyrinth. But for some faculty, a bit of guidance about what is appropriate and allowed, we created a wee how-to case: http://demo.openlabyrinth.ca/renderLabyrinth/index/499 – ‘Picture this‘ There are some pointers about copyright law, workarounds and how to effectively embed images into your pages.

This case is also featured in our series of Examples:  https://docs.google.com/spreadsheet/ccc?key=0AmgSucgM9Y3NdGdZMFFteGdJN1RDUkhXRTdVbllON0E&usp=sharing 

UPDATE: On 16Mar2017, Teya our project coordinator created a nice simple YouTube video with the steps on inserting an image into an OpenLabyrinth node:

As you saw last week, we are making a group of cases available to help authors to create better cases.

This week we would like to highlight ‘Decisions, decisions‘ – this walks case authors through the important principle of creating meaningful decision points in their cases.

This case is also featured in our series of Examples:  https://docs.google.com/spreadsheet/ccc?key=0AmgSucgM9Y3NdGdZMFFteGdJN1RDUkhXRTdVbllON0E&usp=sharing – you can also download a zip file example of the case from there.

Extending on the last post, we are gradually making available more and more example cases to show what can be done with OpenLabyrinth.

Because these cases are to be found on many different servers, we have been looking for a way to link to these, along with enough metadata about the cases so that you can find what you need. For the moment, we have decided just to use a simple Google Docs spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AmgSucgM9Y3NdGdZMFFteGdJN1RDUkhXRTdVbllON0E&usp=sharing

Sorry about the messy long link.

On that sheet, you will find direct links to the cases so you can play them. For many of them, there is also a link to Medbiq format zip file so you can download the case for use on your own OpenLabyrinth server.