In past years, there has been a lot of focus on making virtual scenarios and virtual patients portable between systems. No organization wants to put a lot of effort and resources into creating a set of scenarios for their learners, only to find that they cannot be used because the systems cannot play them any more. A huge waste of effort and resources.
Indeed, this problem was the genesis of the Open Educational Repositories (OER) initiatives that we saw a few years ago. We like to think that the Virtual Patients community was ahead of its time in generating things like this eViP repository several years ago: https://virtualpatients.eu
This project was largely the stimulus for the creation, under the auspices of Medbiquitous (https://www.medbiq.org), of the ANSI/Medbiq Virtual Patient standard. (https://www.medbiq.org/medbiquitous_virtual_patient) This standard provided the means by which cases could be ported between servers. For VP players who are compliant with the MVP standard, you can also port virtual scenarios between different systems.
Given that many virtual patient players do not last very long, this portability of cases and being able to take your content to another server or system was a mitigation against the risk that your own system went bust.
We are pleased to note that OpenLabyrinth is now one of the longest lasting systems, over 16 years old, and is also the most compliant with the MVP standard.
As we move onwards to OLab4, we will continue to support the MVP standard as far as possible, although we now note that its format does inhibit the migration of more advanced scenario features and functions.
The WAVES Project, http://wavesnetwork.eu, has been exploring this aspect of portability as part of its wide reaching mandate. In particular, they have created a very useful document describing some of the challenges with the MVP standard. Hosted on GitHub, this is a live document that will continue to evolve: https://github.com/wavesnetwork/mvp-standard/blob/master/FAQ.md
Integration of systems remains a challenge. The impetus now seems to be leaning away from portable content and reusable objects. SCORM was widely heralded but not widely adopted. Now the focus seems to be more on the ability to explore activity streams across a broader range of tools and platforms. This is why, in OLab4 and in the WAVES Project, we are furthering the use of xAPI and the LRS as a common data repository where you can aggregate activity metrics, no matter what educational platform the learner is using.
It is important to stress that current virtual patient systems and the MVP standard are not yet, in general, ready for the higher levels of integration described in this paper. However, the effort involved in extending virtual patient systems to facilitate the intermediate level of model integration does not seem to be obstructive. A graphical user interface component to handle the what-if-node manipulation of model parameters and display the simulation results is of primary importance along with a standard mechanism to manage pre-generated data in virtual patient packages. The advanced level of integration poses a more significant challenge. Many models available today have been implemented using scientific tools such as MatLab (Mathworks) or specific numerical libraries. This limits their portability in virtual patient packages. A viable strategy might be to host the solver on a remote server, but this conflicts with the self-containment rule of content of a virtual patient package, raises security concerns, and requires the maintenance of an additional service. These considerations will fuel further research as suggested by this paper (SSM Step 4).