2010-01-14

Meeting Information

Attending: JB McGee, co-chair; Susan Albright, Jörn Heid, Litsa Mitsopoulou, Valerie Smothers, Dan Walker, Luke Woodham

Agenda Items

1 Review minutes of last meeting

The minutes were approved.

2 Review profiling efforts

Branching

JB commented that he went through the schemas and the Labyrinth spreadsheet and identified 4 fields where there is overlap. They can write a profile that addresses how branching systems use key elements, like positions on the map. The two systems have different features and handle multiple choice questions differently. He offered to have something out by the next call. He added that he would get in touch with Rachel to discuss the profile.

Global

Dan commented that he and Nabil are trying to get together week after next. Dan has created a spreadsheet based on Jörn's linear spreadsheet. In looking at it, there are some discrepancies between Tufts and WebSP related to virtualpatientdata.xsd, but not too many. There is one minor difference on the DAM. They take advantage of navigate global, where WebSP uses links. That is the biggest discrepancy to him. He questioned the purpose of the profile. He added that the profiles seems to focus more on activity model. Perhaps that is where the emphasis should be. He isn't sure what kind of constraint Nabil's system provides.

JB commented that there would be value in ability to exchange cases between similar systems.  The original incentive for profiles was that within a certain family of Virtual Patient tools exchanging cases would be easier. This idea stems from the eVip experience in exchanging cases. He encouraged Dan to use that as guiding principal for what goes in the profile. One point to consider would be should the global profile be using navigate global all the time?

Dan commented he is still wondering if there is a profile. He isn't sure that VPD commonalities should go in the profile. Dam and activity model should be the focus. JB commented that with certain elements it won't matter whether they are in the profile or not. That is part of the profiling process. If we are trying to enable exchange, the more you can specify about what is exchanged, the better.

Valerie added that profile developers should keep in mind how the profile will be used in the certification process. As part of certification, a virtual patient package conforming to the profile will be imported into the system. The import should be fairly easy and without data loss.

JB explained that the profile needs to produce a minimum that should be readable and appear in a logical way. The representation of data does not need to be identical, but the activity should be perceived by the user as similar.

Susan questioned who would make the judgement as to what data is important and what data is not. JB commented that was the work of the profile developers. You have the opportunity to make that decision.

Dan recommended that profiles be based on the Activity Model. The approach to navigation is what distinguishes one profile from another. Constraining virtual patient data is inappropriate. He added that profile developers should also think about triggering, which is not on the current spreadsheet he uploaded to the wiki.

JB agreed triggering should be added. The ultimate goal is for the user to know if a case will work in their system.

JB asked Valerie if the profile should be geared for developers or end users. Valerie replied that it should be geared for developers seeking to comply with the profile. A separate marketing piece to explain the use of profiles to end users can be developed as well.

Linear

Jörn commented that they use qti in their systems, and that might be a point where there are problems exporting and importing. He's imported casus cases; its working for them. The import is  not difficult. Both systems have same linear approach. Some stylesheets map Campus XML elements to Casus elements. That generates a Campus import in their database. It's more difficult for other systems.

JB asked if it was automated. Jörn replied that it is. All systems in evip have an import feature that is mostly automated. For some, there are adjustments for special things. But it is 80-90% automatic. Their system is completely automatic, but it only works when both systems are linear. For open labryrinth cases, they need to make systems linear. The concept is broken, but the data is there.

JB added that was the incentive for the profile.

Jörn added that they can import the types of QTI questions used by casus. Extensions might be a problem.

Dan asked Jörn if they export QTI from their system. Jörn replied yes. QTI was too complicated to implement completely. They export their question types and import the types used by casus. Dan commented that their systems are very similar. He would like to see a sample Campus export to test. He added that they anticipate using QTI. They allow users to embed quizzes.  

Virtual Worlds

Luke commented that he agreed with many of Dan's points. In terms of element use, pivote and ariadne have different navigation models. Pivote uses navigate global and doesn't use activity model links. Ariadne is based around open labyrinth and uses links heavily. There is not a lot of commonality in the mvp elements used. It will be difficult to transfer from one to another as an automated process. They are hoping to come up with common extensions that might allow for chat to be encoded in MVP. The question is can they link that in to ariadne. The likelihood of transferring cases is low.

JB asked if extensions would meet minimum requirements for a profile. He added that it may be a better approach to share extensions and not designate as a profile.

Luke added that he cannot easily see translating form navigate global to links, or vice versa. Virtual patient data elements, such as diagnostic tests, could be translated. It would be interesting to talk with Dan and see the commonalities between Tufts and Pivote.

Dan commented that Nabil's model is more of a hybrid.

JB added that we are not locked down with these profile designations. If there is something different that would bring in a larger number of systems, that would be preferable.

Dan commented that there may be a guided global profile.

3 Using QTI and other existing specs with MVP

Jörn commented that QTI is a spec for questions and summation. In campus and casus, they use knowledge questions. The VP author can add question that points to external knowledge, etc. To put in MVP, they use QTI as an extension in DAM. He added alternative path so that you can point to QTI parts or just point to VPDtext for systems that do not support QTI - that provides an html version of the question. The Linear approach mostly uses knowledge questions. Its for interactivity, knowledge checking, and does not determine the learner's path through the content.

JB commented there is an impression that QTI is hard to work with and is complex. Jörn replied it is not easy. There is an example on the wiki. The problem is the different question types. They are using long menu items which are not supported by QTI; they extend QTI. He added that the Linear profile should not request implementation of QTI.

JB asked if we should consider workarounds for QTI.

Dan commented that if a standard already exists, it doesn't make sense to reinvent the wheel. If Tufts wants to import QTI, they have time to learn spec, but if they don't, he can still get a text representation of the element using alternative path.

Jörn added that export of QTI is easy. There are templates for multiple choice. The problem is the import because there are so many question types. If a system has question type you do not have, that is difficult.

JB asked if question types could be part of the profile? The group agreed they could. Valerie added that could be on a checklist for conformance. We would not be able to verify using schema as we do not have rights to change IMS schemas.

4 Activity at ICVP/MedBiquitous meeting

Valerie summarized that the group could have a meeting duing the lunch on Tuesday April 27. JB commented the group should have lunch first and then eat. Valerie will find out if we can get a separate room. Valerie asked JB if there would be an interest in presenting to the full delegation. JB agreed a 10 minute presentation in the lunch room would be ideal. Then the full group can meet elsewhere.

JB asked who would attend. Jörn, Litsa, and Luke all said they would attend. Luke was unsure if he could attend.

5 Open discussion

JB encouraged the profile groups to continue working offline.

Decisions

The group will explore profiles based on activity model (branching, linear, global navigation, possibly hybrid)

Action Items

The group will continue with profile development, identifying how the activity model would be restricted for each profile. Profiles will ultimately include a set of schemas that are further restricted to reflect each profile. Profiles may also include a checklist of items that are beyond the scope of the XML schemas.