The PIVOTE system was designed by Daden Ltd. to allow virtual patients to be played in Second Life by multiple avatars. In particular, the platform that is currently most used for PIVOTE is Second Life. A user is able to navigate through a Second Life case through interactions in the virtual world environment.
The system consists of a web application, written in Perl, which processes the bulk of the case logic. Scripts written in Second Life respond to actions from in-world users, trigger in-world responses and send HTTP requests to the PIVOTE application. The response to this request is then displayed in-world to users.
PIVOTE uses the MVP XML files as its native data storage format, as opposed to having a separate database. As a consequence there is no need for any import and export procedures to construct the MVP xml files. The MVP files are stored on the web server running the PIVOTE application. There is not currently an automated process for constructing an MVP and SCORM-compliant package from the system, but this can easily be achieved by manually constructing the package using the existing case MVP files.
Fig 1 PIVOTE System Architecture
The main component of the PIVOTE system is a web application. The data relating to cases/scenarios is stored as XML in an MVP format, and there is no database. Actions in Second Life generate HTTP requests which are sent to the web application. The web application queries the XML based on the request, processes any logic such as rules and counters and dynamically generates a web page which is returned over HTTP in response to the request, and subsequently displayed in the virtual world.
The PIVOTE system can support both text based options and consequence navigation (branching) and a model which allows actions to be carried out in any order (global).
Fig 2 Text based controller screen
The text-based navigation is carried out using a controller object in Second Life, and is similar to navigation in the branching VP systems such as OpenLabyrinth and vpSim. Users are presented with some information and a number of options. They can choose the option by clicking the numbered buttons on the controller, and the case navigates to the relevant part of the case.
It is felt by many that this functionality does not take advantage of the virtual world environment, and offers a less satisfactory experience for VPs of this sort than a web-based system. For this reason it is likely that examples of this sort of navigation are unlikely to be commonly used in PIVOTE cases.
Fig 3 screenshot of PIVOTE scenario
The bulk of the navigation in a PIVOTE case is carried out using the Second Life environment. Users control a character/avatar who can move around and interact with the system. Each action navigates to a new node in the case. In Fig 3 above, there are a number of objects visible on the table and a static mannequin (far right of the picture) which represents the virtual patient. Clicking on any of these objects or on the patient constitutes an action, and triggers the PIVOTE system to navigate to a new node in the case. Similarly, using the Second Life chat interface to talk to the mannequin constitutes an action.
There are no restrictions in terms of links as to which actions can be carried out/nodes can be visited and in which order. All nodes/actions are flagged as being globally accessible at all times. The only logic that is applied to availability of nodes is applied upon visiting a node/performing an action, where a conditional rule can be applied to redirect the user to alternative content should a condition not be met. For example, take the situation where a user needs to order a test and check the test results. Both "Order test" and "View results" are available to the user at any stage. However, a rule can be applied which will be activated should a user attempt to view the results before ordering the test, which will redirect the user to a node saying that "You cannot view results. You must order the test first" or words to that effect.
Data is displayed to users of the PIVOTE system through two methods. It is either displayed on the controller screen as a web page, or output to the text chat interface as plain text.
All relevant data is stored, interpreted and represented in PIVOTE as plain text. There is no distinction made between different types of data, and other elements such as InterviewItem or DiagnosticTest are not used. Not only does the system not distinguish between different types of data, it also does not store data elements as anything other than VPDText, so there is unlikely to be sufficient information for other systems to make automated procedures to separate data into categorised types.
Additional data relating to the chat actions regarding trigger phrases and the patient's responses are stored as extensions to MVP, as a proprietary version of AIML (Artificial Intelligence Markup Language). Although there is little possibility of other systems interpreting this data directly in this format, it is stored discretely from other text content, so could potentially be transposed to InterviewItem or VPDText as appropriate as part of Import/Export procedures.