2009-09-17

Meeting Information

Attending: Rachel Ellaway, co-chair; Susan Albright, Jeroen Donkers, Jörn Heid, Valerie Smothers, Luke Woodham

Agenda Items

1 Review minutes of last call

The minutes were approved.

Jeroen asked about the specification profiles. Rachel commented that we would discuss that later in the agenda.

2 Standards development update

Valerie informed the group that the specification had been submitted to the standards committee for review. The review will end October 15, after which the specification will undergo a public review and ballot. Rachel questioned how long these steps would take. Valerie replied that the public review would last a minimum of 45 days and that the ballot would last a minimum of 30 days (correction - it will last a minimum of 6 weeks).

Rachel encouraged committee members to review the specifications and make any concerns heard either through the public review or balloting process.

3 Discussion of profiling progress

Rachel reviewed that we discussed profiling at the meeting in Baltimore in May. Many of our systems implement the specification in different ways. No one has a master system that does it all. Profiles would allow for more harmonious interoperability. An application profile takes a standard and adds further detail, rules, and requirements. It cannot do anything other than add to the base requirement. For example, an application profile can make optional elements mandatory, create restricted lists where fields are open, and add additional elements through xtensible info. Healthcare LOM is an example of an application profile; it takes IEEE LOM, adds a 10^th section and additional elements.

On the last call, we identified a number of different profiles:

• Schema design/string of pearls  - a series of steps through an activity, with options at each step (campus, casus)
• Branching (open labyrinth, vpsim)
• Global navigation (Tufts, WebSP)
• Native player (pivote, VPSim) 
  Rachel commented that we are looking for a report from each group. She and JB are discussing what should be in the branching profile.

Susan commented that talks could contribute to both string of pearls and global navigation. Rachel replied that was fine. Susan asked if there was a protocol for creating a profile. Rachel commented that the protocol was informal. The first step may be to share cases and see where data exchange fails, in other words, doesn't give you the richness that you were expecting.

Jeroen commented that campus has two types of players -- the classic and card player. The cardplayer would be global navigation. He recommended asking Jörn for advice. Jorn agreed that campus would be both string of pearls and global navigation. Jeroen added that he did not think a profile was necessary for the native player. Rachel commented that she agreed, but JB thought it might require a profile. The group can consider and see if they want to come up with one.

Luke agreed with Rachel that it probably wouldn't be affected by a native player profile. The bigger issue is identifying which of the other three models it uses for navigation.

Rachel commented that she brought up moving to the current version of the specification at the eViP meeting at AMEE. The majority in attendance were academic and didn't say much. She did make it clear that he would not take much to come up to the latest version, but that there would be a lot to gain. Lou commented that he did not attend AMEE, but they did produce a VP package conformant with the latest version of the specification with some help from Valerie.

Susan offered to speak with Jörn sometime next week.

Valerie commented that it might be good to outline the protocol that the profile groups should follow. She and Rachel suggested the following:

• Identify which elements each tool uses in its export and identify common elements used among the different tools.
• Identify any places where developers use a restricted list instead of a more open field.
• Note what each developer is putting in Xtensible info and see if there is overlap.
• Note what data you are not putting in the export at all.

Rachel noted that one of the things she and JB are discussing is the ability to have a shared extension for describing the visual components of the authoring system. This would include XY coordinates. Valerie commented that Vue has an XML spec that could be useful. Rachel commented that they plan to learn from Vue but not use their spec as is.

Rachel asked that preliminary reports be given by each group on the next call. The report could be written or verbal but should include what elements may go in a profile so that we can start documenting that. Valerie recommended that we identify a point person for each profile.

• Schema design/string of pearls  - (campus, casus) Jörn will take the lead on schema design/string of pearls.
• Branching (open labyrinth, vpsim) Rachel and JB will take the lead on branching.
• Global navigation (Tufts, WebSP) Susan will take the lead on global navigation.

For the native player, Luke commented that the pivot player and Second Life has some branching in some global navigation. Valerie questioned whether it virtual worlds profile may be helpful. Rachel commented that she is releasing the Ariadne Second Life player soon and that of virtual worlds profile would be helpful. In addition, Parvati Dev's group has worked with the commercial system Forterra, and Parvati is looking to move to a service-based architecture.

• Virtual World profile (Ariadne and Pivote) Luke agreed to work with Rachel and provide the report.

Valerie agreed to e-mail each reporter just to clarify their role.

Jörn asked Rachel for details on the backslash issue. Rachel replied that whenever she tried to use Jörn's packages on her Macintosh computer, it contained a series of files with the backslash character. The packages were unreadable for her. Jörn asked Rachel to take a screenshot so that he could look into it further.

4 Discuss compliance and certification

Valerie provided an overview of her ideas regarding a compliance and certification program. The idea is to make it easy for consumers to identify what is conformant and how it will work with regards to importing, exporting, and playing virtual patient cases.

Applicants must indicate if packages validate against the schemas, the SCORM tests suite, and if there any parts of the specification that they do not support. MedBiquitous staff will reviewed the application and request access to the tool to perform a series of tests, including importing and playing cases, exporting and validating cases, and playing test cases and standalone players. MedBiquitous staff would also research and the exclusions or problems.

Rachel commented that in addition to verifying compliance, third parties may be looking for guarantees of compliance. She did express concern whether MedBiquitous had enough resources to complete this kind of certification process. Susan asked how it would be handled for systems that both export and play conformant cases. Valerie commented that they would indicate multiple types conformance, i.e. player and export. Rachel added that the suite of applications may be what is certified.

Rachel commented that after the initial completion of the standard, eight or nine different systems were likely to come forward to request certification. She asked how MedBiquitous would handle this. Valerie commented that it would take resources to support the effort, but that it should be done in a timely fashion, within 30 days.

Joeroen asked whether there should be two levels of conformance, full and partial. No system does everything. How do we label things that are partially conformant but do so in a consumer friendly fashion?

Luke added that the term meaningful when applied to playing cases could be problematic. In the eViP, they had to define what meaningful use meant. There definition ultimately was that it would be quicker to repurpose the data than to create a case from scratch. Luke will forward information on this.

Jeroen added that eViP also indicates levels of conformance. Only the highest level of conformance has meaningful use.

5 Discuss Jörn's suggestion for API

Jörn commented that the XML schema is good and transferring information. He has been thinking about the structure of virtual patient API would take. This would provide interoperability with learning management systems. That way, if you want to do formative assessment, the API could provide a standard way of giving the event to the JavaScript engine. Before every player develops its own API, we can develop a common model.

Susan commented that it sounded interesting. She will ask Dan to look at Jörn's suggestion.

Rachel commented that the changes to version 0.55 move to the specification away from the SCORM runtime to the SCORM resource package. That in turn removed JavaScript controls for callback and tracking. She's not sure how the Jörn's suggestions for API relate to our approach to SCORM and the impending rollout of SCORM 2.0. She asked Jörn create a more specific suggestion that indicates how the specification might change. Jorn replied that this would be an extension for future development, an API for communicating with the LMS. Rachel commented that it could be addressed in profiling work.

6 Open discussion

The working group's next call is October 23. We will look for reports from the four profiling activities, and Valerie will send minutes with a reminder.

Decisions

We will add a virtual worlds profile.

Action Items

The following people will work with their colleagues and provide preliminary profiling reports for the next call:

• Jörn - schema/string of pearls
• Rachel and JB - Branching
• Susan - global navigation
• Virtual worlds - Luke

Valerie will send an email reminder to each.