2008-11-20

Meeting Information

Attending: JB Mcgee, co-chair; Jörn Heid, Valerie Smothers, Dan Walker.

Agenda Items

1. Review minutes of last meeting

The minutes were approved.

2. Review specification and schema updates

• Attribute requirements and defaults
• Replace TrueFale and OnOff types with xsd boolean

Valerie reviewed the most recent updates to the specification and schemas. Several attributes are now required, others have been given default values. In addition, TrueFalse and OnOff datatypes have been replaced with the xsd: boolean datatype.

3. Alternative path for extensible elements (see Jorn's email)

Jörn had suggested allowing an alternate path for Xtensible info elements so that if an extension is not supported, alternate text could be displayed. If you point to an extension, like QTI, and player doesn't support, what does the player do? He's suggested an alternative target referenced from the DAMNode. If player doesn't support, it would display another VPDtext.

In campus, they do not support qti, but other systems do. When he plays virtual patients with QTI questions, his system shows an empty page. It would be nice to have xhtml without interaction.

JB asked if an alternative path would have the same functionality. Jörn commented that it could, but it wouldn't have pictures. Dan commented that he hasn't worked on player in almost a year.  If there is no alternate path, the player could fall back on its own message.

JB asked if we need the alternate. The player should have an error message built in anyway. Jörn replied that it would just be the question and the answer for those that don't support the extension.  JB clarified that it would provide an alternate way to see the data in the extension. He guessed that few would employ this capability. Jörn replied that they have exports from different systems, some support qti. At the moment, their system does not support. They have questions qti does not support. He wrote vpd text to render question in simple xml. But he can't import questions until he fully supports QTI text. He doesn't want to lose the information about the question.

JB commented that if you carry that to other things that players don't support, that involves losing a lot of features because systems are so different. You need to modify cases to play them appropriately. By building an alternate path for extension, you could need that for every element in spec.  Jörn replied that it would be better to let the item path point to something not in xtensible info  but have an xtensible info path that points to special extension. Only those players capable of qti would use the extension.  Others would use the alternate path.

JB commented that there is no way to predict what xtensible info will be used for.

Dan added that if their player had an element that was not defined, he could define his own extension and an alternate path for those special items. He can degrade the experience gracefully.

Jörn added that alternate path would be optional. If you are moving xtensible info, the alternate item may be played instead.

Dan added that it could help simplify the process for importing a virtual patient into a new system.

JB added that this may be valuable if we limit it to xtensible info. Dan agreed - it would  prevent losing the experience and bridge the gap between systems. JB added that for them, xtensible info is becoming important.

Jörn commented that itempath could point to xtensible info, and alt path could point to vpdText. Or item path could point to vpdText, alt path could point to xtensibleInfo.

Valerie asked if alternate text would be required?

Dan replied that he would want the preferred behavior in item path. Then go to alt path as a second option. The group agreed to implement this change.

4. Test suite and conformance implications (see Jorn's email and TSC discussion)

Jörn commented that the test suite should be a n optional tool and not tied to conformance.

5. Simplification of specification

JB commented that he, Peter, and Rachel discussed the complexity of the specification at a recent meeting. If you are making an authoring system and enabling an export to be imported back in to your own system, that's easy. Not everyone will use all features. For a player to predict a way that is relevant to the case, what the author expected, for every type of case, is not realistic. It's  too much for player to play back in meaningful fashion. We could have Level 1 compliance -  a subset of the specification. This would not preclude handling everything. We would have larger set of compatible cases.

Jörn commented that their system has export that may be level 1 compliant. It is just information about vpd text, interview item, one path referencing special items. Everything more complex, like rules, is not exported by all systems. There are no exports that use those additional features. Dan asked what level 1 traits would be. JB replied that is for us to decide. The way the spec is now will not allow cases to be freely exchanged between institutions.

Jörn commented that you have to decide which elements will be in level 1 compliance. The spec itself has lots of optional elements. It's easy to make a simple export. Most systems do not support such tools like triggers. Dan commented that we could divide some of that functionality to be used as xtensible info. Then basic functionality would be supported by all players. And every export would conform on a basic level.

Jörn added that the player must be capable of all special features. An independent player playing the virtual patient is an important use case.

Valerie commented that MedBiquitous has generally been advised to avoid different levels of compliance for specifications and instead to focus on what is core functionality and data.  

Dan commented that if we did pare down the spec, there are things he would confine to xtensible info. The trouble with that approach is that we will see different implementers extending in their own way. Could we have more community oriented extensions? More advanced systems will have extensions akin to what we've defined together.

Jörn recommended looking at the systems in evip -some already support advanced functionality. Their system supports vocabularies, not free text, and there is no difference technically between physical exam, interview, etc.  Those systems already on the market won't fully support features like rules, network, etc.. 95% of systems won't support the full spec, but systems about to be programmed may take this as the basis for implementation.

JB recommended scheduling an interim call and sending an email that says what we will be talking about: a potential change to a level 1 type spec, and whether we need a face to face meeting before the annual meeting in April.

6. Open discussion

Decisions

• We will add alternative path to the spec
• We will schedule an iterim call to discuss developing a simplified, more level 1 type version of the spec.

Action Items