2009-07-17

Meeting Information

Attending:  JB McGee, Rachel Ellaway, co-chairs; Susan Albright, Ben Azan, Valerie Smothers, Dan Walker, Luke Woodham.

Agenda Items

1. Recap April working group meeting in Baltimore

JB  and Rachel summarized the decisions made at the meeting in Baltimore. The working group agreed to group virtual patients into commented heights so that exploratory or branching cases could be more easily exchanged and repurposed. Exchanging virtual patients up the same type is much easier than exchanging virtual patients of different types. In addition, the group agreed to vote on the finalization of the specification in preparation for submitting it to the standards committee. The group also agreed to start working on developing application profiles of the group's JB described as the next piece of work. Valerie added that active participants had confirmed their interest in continuing to participate in these development efforts. She agreed to create a survey monkey survey with questions about approval of the spec and moving to a profiling activity.

2. Review revised specifications and suggestions for substantive changes

Valerie described that there have been stylistic and illustrated changes to the specifications but no substantive changes. She has made suggestions for a few substantive changes, the most significant of which is removing the requirement for a player to be in the content package. This would be enacted by switching from a SCORM content aggregation model to a SCORM resource package. SCORM resource packages have no organization and no scos. Her reason for this recommendation was that currently there is no conformant player and no developer meets the bar for conformance.

JB commented that it is important for the first incarnation of the specification to have a positive effect on the learning community. We don't want to have an effective player included just for conformance. Rachel agreed that it was a practical solution. Valerie commented that she also recommended moving to the fourth edition of SCORM, which is the most recent. Rachel commented that support for the SCORM model learning management systems is idiosyncratic. JB agreed that he thought SCORM would be implemented more by now.

JB asked Dan if Tufts was still pursuing a player. Dan said yes, he recently came back to that work. Javascript player is on the horizon. JB asked if he had a problem with dropping player requirement. Dan commented that would be fine. It is a fundamental change in thinking.

Everyone agreed to ballot the specification within the working group after the substantive changes are made.

3. Identify profiles to begin developing and next steps

JB asked Valerie whether application profiles were developed in other working groups. Valerie answered that other working groups had developed implementation guidelines, some of which specify which elements to use under which circumstances. For example, the learning objects working group developed guidelines indicating which metadata elements to use for continuing medical education and which to use for undergraduate medical education, etc. She thought it would be entirely appropriate for the working group to move on to the task of profiling, in particular because this step would be necessary in order to make the specification useful to learning technology customers, i.e. University seeking virtual patient cases or software. We may want to say that a software or virtual patient package meets a particular profile of the virtual patient spec.

Rachel agreed that we need to create application profiles. Half of the implementation is the application profile. We could develop new schemas expressly for the profiles that further restrict what's already there. She added we would need to some implementation testing. JB questioned whether we should have guidelines were profiles. Rachel argued that guidelines would result in variable implementations without the ability to test for conformance. We have to do profiles. JB agreed. Some users will focus on one type of virtual patient case and will not care about other types. Rachel added there's also the step of validation.

Dan asked how one would implement an application profile. Rachel commented that we would take the existing specification and add rules including required elements and controlled vocabularies. For the branching model, many of these would relate to the activity model. For schema-based model, many will concentrate more on the dam. Dan asked if we would need to specify the application profile within the package. Rachel said we would need to see if we go to that level of specification. JB asked if it would have to conform to the profile. Rachel commented we would need to see the direction that our work takes in order to answer this question.

Susan commented that yesterday she and Dan started looking at the other tools. Different types of virtual patients aren't as straightforward as she once thought they were. Open labyrinth is more linear than she imagined. Profiles aren't as clear cut as she thought it was. She agreed that campus and open labyrinth were significantly different. Luke agreed. The activity model is fundamental and open labyrinth at other systems do very little in the activity model and leverage the virtual patient data more.

Rachel asked Valerie it was necessary to survey the working group in order to move to doing this work. Valerie replied that it was not necessary. The group agreed to work on outlining a statement of work.

Susan commented that eViP's work should be able to inform the development of application profiles. Luke said that eViP does have an application profile document provides information about the decisions. Rachel asked them to check to see if he could circulate that document to the working group. Rachel and JB agreed to work on putting a statement work together. That and the eViP materials would be the basis for the next call.

4. Discuss compliance and certification

Valerie questioned whether conformance would be conforming to the profile of the specification. Rachel commented that he tool or case would need to conform to the base specification first, then to the profile. She asked Valerie to describe any current certification efforts.

Valerie explained that currently MedBiquitous has a MedBiquitous XML program which recognizes implementers. The form is available on the website (http://www.medbiq.org/std_specs/conformantsw/application/index.cfm) it ask software developers to indicate whether they import or export conformant XML, whether they make XML available via a web service or exposed directory, or whether they can receive conformant XML via a web service. Within each of those, it then asked developers to indicate whether the XML is validated against a MedBiquitous XML schema, whether it supports the multiplicity of the standard, and if there any exclusions. Rachel asked if anyone had submitted their information yet. Valerie replied that no submissions have been received.

Rachel commented that we had discussed certification previously, this sheer cost of developing certification or conformance tools similar to what had been developed for SCORM was well beyond the means of MedBiquitous. There have been some tools developed by eViP however. One was developed by Karolinska Institute. The commented that there was also a tool developed by Heidelberg. It checks conformance with the eViP profile and indicates why a package isn't conforming. Rachel commented that it is a bit tighter than the specification and would need to be rolled back. Rachel commented that these tools together with the documentation process already established would be helpful.

JB questioned what would happen with a virtual patient case that was mainly extensions to the specification. Rachel commented that as long as it implemented the extensions and conformant way, it would still be considered conformant. Valerie questioned whether use of extensions should be added to the form on the MedBiquitous website.

The group agreed that we should come up with something that would be helpful to the user interested in downloading virtual patient cases. An effective conformance process would also drive implementation and provide a level of guarantee that something would work. But profiles would be necessary to further define this process.

The group agreed to put certification on the agenda for next meeting.

5. Open discussion

Decisions

• The group will have a survey regarding moving the specification to the standards committee.
• The group will begin working on application profiles.

Action Items

• Valerie will make the substantive changes she suggested to the specifications.
• Valerie will create a survey asking the group if they approve the spec and wish to move to a profiling activity.
• Rachel and JB will begin developing a statement of work for the application profiles.
• Luke will circulate eViP application profile to the working group pending permission.