May 31, 2007
11 AM EDT
Attending: Rachel Ellaway (co-chair), JB McGee (co-chair), Susan Albright, Peter Greene, Yanko Michea, Josh Simon, Valerie Smothers, Arnold Somasunderam, and Dan Walker.
1 Welcome new members
JB welcomed new members. JB asked Josh to introduce himself. Josh is working with Yanko at University of Connecticut as the developer for the VP initiative. He's writing the code.
2 Recap from annual meeting
The plugfest allowed developers to show where they were with development. There was a great deal of interest in the session. The session went through Tufts, Edinburgh, and Pitt status. The working group meeting provided a chance to catch people up with the progress of the Miami meeting and the status of the spec. Rachel went to Boston following the meeting and spent time with Dan and added some items to the spec.
3 Getting validation, feedback and improvements in from first wave implementers
- Update from Tusk
- Update from Karolinska
- Other feedback
JB clarified that we were hoping to get initial feedback from implementers on this call. Web Sp will incorporate VP architecture on the next version. JB asked Yanko to describe where they are with development efforts. Yanko commented that the meeting was interesting as a reflection point. They have been working with the latest version of the spec but are confused about the status of the standard. They are waiting to see what happens. How long they will wait is a big question. Josh added that they have three main components: an interface to enter data, an activity model developer, and a basic player. It complies with previous versions of the standard. They are looking for ways to make the system unique. They found a good visual tool for the activity model. The other is natural language processing, parsing free text case reports.
Josh explained that people are lazy and don't want to reenter data from a case report. UCLA has been working on a medical language processing tool. He wants to take case reports, run through a program, and import that into the MVP standard. He's still in the beginning phases. Yanko added that they have 400 cases, and it would be interesting to import. Rachel commented that none of that was in the spec. The spec presupposes that the VP exists. It's a transport mechanism. What Yanko and Josh described was authoring. Josh clarified that the end result would be that a free text report would be converted to MVP XML. Peter added that import and export from an authoring system is one use case; reading and running a vp is another. It's easier to create systems that read a standard rather than play it properly. It's hard to say you're creating an authoring system that support all forms of VP.
4 Review of updated schemas, specifications, changes and questions
The group focused on the question of a player specification. Rachel commented that developing the player that can support everything will be difficult. There are many variations and possibilities. Peter added that if you can't say what the player has to do to support the standard, you are talking about different levels of conformance. Rachel commented that the standard has edges, some of it is about options with presentation. Peter agreed that presentation is scoped out. He added that SCORM ran into trouble with recognizing partial conformance; just run these two api functions, not the full 22. They eliminated that partial conformance at the next version.
JB returned to the issue of the player and whether that is part of the spec and what the expectations are. Rachel added there are external and internal parts. Externally there are triggers. The content package triggers what happens next. Then the activity model has an internal process. We also need to talk about the form of the content package. Peter commented that at the start we thought we could scope the player out. His sense is that we can't leave out a core set of internal functionality. The player has to open the activity component, find the first node, find associated DAM nodes, etc. A narrative description could be made of what a player has to do. There will be many variations of players. It would be difficult to understand what to do with the XML without a player spec. For transferring content, there needs to be an understanding of the player, too.
JB responded asking if we need to spec out what the player has to do to get things running. It should be specified somewhere, but where should that exist. Should that be in the overall VP spec, a separate spec? JB asked if anyone disagreed with that. Susan asked what good is opening it up if you can't progress through the full activity. Rachel added you need to load the first part of the activity model and then get it running. This ties back to will there be specific named files or type files, etc. There needs to be some internal logic. Rachel asked if this would be best practice as opposed to a spec. JB asked if that should be embedded in the player or should we tell everyone how the player interprets the data.
Peter added that we discussed whether to include a functional player that's a part of the standard. Even if you say the standard is the XML pieces, you still have to create those files in a way that conforms to what the player needs. Schema can't make sure you've included all the proper references to DAM. The standard must say how different XML bits and pieces relate to one another, and that XML must be designed in such a way that player knows what to do. Rachel agreed that was necessary for interoperability. Rachel pointed out that we need to test it.
Peter added that if we can get away with minimally modifying content packaging, that leaves many options open. If we create special resource types, that's similar to what scorm did. If we want to create our own types for activity model etc, we'll need our own schema. If we were willing to have consistent names, that would help. Valerie commented on naming. In the current model, where multiple virtual patients can be included in a package, you can't have unique names for the activity model because there are multiple. Rachel said perhaps what you need is an identifiable start point. It may be we want an internal reference. Maybe the first activity can reference the other activities. Tags can go back to root file. Peter added that if we can use content packaging without defining where the player has to look for those, that would be great. Otherwise, we create our own xml file. There may be additional rules for identifying the root. Maybe the first thing is find activitymodel.xml. Harcoded within it could be links. If node references dam node, where does it get file name?
JB commented that maybe we are going down a path Susan and Dan have encountered. He asked if they have a sense how this could work. Dan commented that at this point he's just trying to get basic functionality. He's exporting three files always with a standard name and parsing the xml. JB commented that we could come up with many complex situations for the player. Peter commented that part of that is the hard work of creating a standard. If something is conformant, it must be specific. Peter suggested for this iteration using those default names for the files. In the next version if we need a global state model we can have a globalstate.xml file that marshalls things. We can defer that to when we are ready. Dan asked if they would have three files: activitymodel.xml, virtualpatientdata.xml, and dataavailabilitymodel.xml. Valerie clarified you still need the content package for the media resources. Rachel offered another way to go was just one xml file. It might be really large. But there will always be a manifest.xml anyway. No question about where to find different components. We don't need to add types to content package schema.
JB asked if that settled the player spec issue. Rachel commented that there should be two levels of specification: schema plus supporting documentation. Presentation issues should go into guidelines; what the files are named and how to handle should go in spec. Yanko encouraged keeping it at the functional level. Dan commented he would benefit from guidelines and best practices. Dan hasn't reviewed the latest spec. There were a few instances where he hadn't considered things the player needs to do. He would benefit from having some kind of functional spec. Peter added we should come up with that and have debate around what's normative and what isn't. Susan added they can design a player for tusk, but if they are defining one to work against a standard to know what the must haves are. Minimal functionality should be defined. Stay away from presentation. Rachel commented one starting point is legacy systems. We should pull those together and turn it into spec. Valerie agreed to create a page on the wiki. JB asked if tufts could be a good starting point. Dan agreed. Peter asked if current database of content will be moved to XML, or will the player be able to go against a database. In the first pass, they are exporting to XML; the player reads XML. There may be an abstraction layer at some point. JB and Rachel commented that they both planned to import content into a database and run it from there.
5 Disseminating and engaging as widely as possible
JB suggested having additional working group meetings instead of developer meetings. The group agreed to have the next call June 21, 10 AM EDT.
- We will have one virtual patient in a content package, with consistent naming for components.
- We will develop a functional spec for the player that defines minimal functionality.
- We will have additional working groups meetings instead of developers calls. The next meeting will be June 21 at 10 AM.
- Valerie will create a wiki page for the player specs.
- Dan will contribute a description of Tufts player functionality to the wiki.
- Valerie will update the current spec based on the groups' decisions.
- Valerie will update the ANSI announcement and submit.