July 24, 2008
11 AM EDT/5 PM CEST
1. Review minutes of last meeting
The group approved the minutes.
2. Review changes to specifications
Valerie and Ben noted that the following changes had been made:
Rachel commented that in the list of supported XHTML tags would be insufficient to support flash objects. The Object element needs attributes beyond data. Rachel will propose new attributes. Susan commented that they have some shockwave files. The current list does not include shockwave files. She will check on the file format that they use and provide a link to the example. Rachel commented that we would have to expand the parameters list for object to address that. JB commented that converting to regular flash file would simplify. Susan commented that the shockwave files probably won't be embedded. Not a deal breaker.
Decision: Hold off until we hear from Susan
3. Review proposed changes from working group
a. Embedding Activity Node Section within Activity Node Section (deeper hierarchy)
Valerie explained that this was a request from Inga who works with Casus. They use a three-tiered hierarchy, and this nesting capability would support their current structure.
Rachel agreed that the use case is quite credible. She has no problem with allowing nesting. JB asked if it introduced too much complexity. Ben commented that it will take some extra time to check for subsections. Rachel commented that it would not be difficult to code.
b. Allowing multiple references to media within VirtualPatientData elements (currently only 1 media ref allowed)
Rachel commented that she is happy to bow to the majority. Susan asked Rachel to explain. Rachel explained that the argument is architectural simplicity vs utility. Should media appear in one place only, the DAM, or in multiple places within the VPD as well? Jörn commented that he has no problem if we decide that media is at the dam level only. But if it is possible to include media in vpd, then one should be able to reference many media files, not just one.
Rachel asked Jörn to check with eViP group. We've made decisions in the past to go for architectural simplicity. That is often the best decision. We should try to persuade our colleagues. Jörn commented that it should not be a problem to support dropping media from vpd. Including it in xhtml is different. Jörn will talk with the evip group to see if we can convince them of the simpler model.
c. Evaluating counter rules at the activity node level rather than globally
Rachel explained that this suggestion and the next stem from Daden's work to create an mvp player in second life. Most of mvp is just fine. But they would like to have the option of evaluating counter rules only at certain activity nodes. For example, if a counter is related to patient health, you would normally trip a rule, if below 10, patient gets to go home. You may not want to evaluate that at most nodes. It will only evaluate on nodes where it is designed to do so. We could have a global rule attribute that could be disabled or enabled.
JB commented that it makes sense to have the rule be at the node level. We could keep global rules, but these could override. You would have to put something as to whether counter rule is enabled or disabled. Ben questioned whether this is redefining the rule at one node. Rachel disagreed, encouraging the group to view rules as properties of global counters, and turning them on or off as to whether they are evaluated. From an authoring point of view, start with it disabled. You would give authors 2 options: check globally, or check at these nodes only. Rachel suggested putting an extra tag in the counter rule section on each node - enabled =y or n. The attribute would be mandatory. Each counter would need to be in each node. Ben commented that a default could reduce the amount of xml floating around. The group agreed to have the default value be enabled.
d. Attaching counter deltas to links as well as nodes
Luke explained that Emily made that suggestion and distributed a document explaining the proposal. Many cases have a node that could be viewed as positive or negative depending on when you go to that node. If you discharge a patient before treating, that's a negative. After treatment, it's a positive. The value of the action is not intrinsic to the node. You could make copies of the node, but then architecture becomes more complex. Rachel commented that it is a good point. This would be in addition to the existing counter deltas. Ben agreed it would provide more flexibility, and without much more work. The group agreed.
4. Proposed meeting in Second Life to better understand use of Virtual Patients in Second Life
The group agreed it sounds like fun. Luke explained that you can go to Second Life and sign up, free. Then download the client, log in, and go! They have an orientation as well. Search on the map for St. George's. If they know your avatar name, they can invite you and transport you to the island. Valerie agreed to work with Luke to set up a date.
5. Open discussion
- We will hold off on incorporating shockwave files into the list of supported media until we hear from Susan.
- Allow nesting of Activity Node Sections
- Add the ability to evaluate counter rules at the activity node level.
- Add counter deltas to links.
- Rachel will propose new XHTML attributes for flash support
- Susan will check on the schockwave file format that they use and provide a link to an example.
- Jörn will talk with the evip group to see if we can convince them to drop the media element from the VirtualPatientData file.
- Valerie will work with Luke to set up a date.