Skip to end of metadata
Go to start of metadata

Meeting Information

Date:

February 7, 2008

Time:

11 AM EST

Attending: Susan Albright, Ben Azan, Rachel Ellaway, Peter Greene, JB McGee Debbie Sher, Valerie Smothers, Dan Walker.

Agenda Items

1 Review of minutes 

Valerie reviewed the minutes and discussion of the last call. Rachel commented that SCORM packaging and XHTML we should revisit today. They are both listed in our agenda.

2 Technical items from Rachel's email of Jan 21
a. Ordering of elements
Peter provided a context for the technical issues. We've found a bunch of people doing vps with a lot of commonality. We wanted a spec to support several of the major systems. One is very gamelike - Rachel's. Rachel put a lot of time in taking the draft standard and getting them into labyrinth for import and export. KI is doing the same; Tufts, too. There are cases in such work where it's not clear what do. These questions are arising from those implementations.

Rachel has discussed several issues with Ben. These issues that need to be resolved. With ordering, that may be an XML nuance. She has been putting them in any odd order. That's not conformant with the current schema. Dan commented he's fine with the order. He puts them in order on export. Rachel suggested making a note for implementers.

b. Optionality of core demographics
Patient ID, name age and sex are now required, Rachel feels they should be optional. Everyone agreed. Ben commented that the container element, core demographics should be optional, too.

c. Age data type
Age now uses the XML duration data type. Programmatically a string could be converted. JB asked why integer was not used. Valerie commented that for pediatric patients it's important to indicate hours or days old. JB agreed. Rachel recommended adding information about the duration type to a FAQ o implementation guide.

d. Metadata location
Rachel asked about the Metadata element in Virtual Patient Data. Do you need it in VPD at all if it is referenced from the Manifest? The group agreed to reference within the manifest. Valerie then questioned where it should be placed within the manifest. There is metadata at the package level but also at the organization level. Schawn Thropp of ADL has recommended putting metadata at the organization level.

Susan commented that educommons was able to open Tufts content within their system. It would be an interesting question to ask them, whether they import metadata from the organization level or from the package level. Dan will ask.

Peter added that in SCORM you can have metadata at any number of levels. You can embed XML or reference an external file. Dan commented that what he remembers about educommoons is that they ignore metadata at the root level and look at resources.

The group agreed to make a decision about metadata placement pending feedback from the TSC and other SCORM experts.

e. author diagnoses vs diagnosis
Rachel asked about Author diagnoses. Are there occasions where there is more than one and where it is helpful to have them as separate elements? JB added there can be alternate diagnoses. Susan commented that they do CT scans and find multiple diagnoses for patients. There can be multiple diagnosis phases as well. JB recommended having one diagnosis and an attribute that indicates whether it is an author diagnosis.

f. VPD Text data type and parsing troubles
The group then discussed the XHTML encoding problems that Rachel experienced. She needed to URL encode because she couldn't import xhtml into her authoring system. When authors wrote content, the complexities of enforcing XHTML input were great. Peter clarified that authors are putting text in a text box, and they may include formatting tags. Rachel clarified that she didn't have time to convert. Peter commented that lots of scripting packages have tools to address such difficulties.

JB commented that this is an authoring system function. Rachel commented that at this stage, she was unable to get XHTML blocks. It was breaking. So she did a URLencode, then URL decode. She's not suggesting that we recommend this. Dan commented he encountered the same thing. He escaped opening brackets on tags so that they would not be tagged. Rachel commented that given the effort required, she could not output xhtml. Peter asked if we want to back off to get something workable. She suggested flagging to look at offline.

g. Media id and location
h. Triggering nodes
i. Links with images (Proposal: Images As Links in MVP.doc )

3 Implementing SCORM
a. Packaging
b. API calls (initiate, terminate, completion, success status, score?)

Which parts of scorm do we want to make required? What content? Ben commented he's been trying to make it as simple as possible. He will send out an example package he made. There will be an organization with one item, the launchable resource. You wrap the player in an html file that enables the player to interface with the LMS. The question of what the player should be required to report back to the LMS is still open.

Rachel commented that the most important thing is to make it validate. She has no intention of using scorm. There are two principles use cases - exchange between VP systems, running packages in LMS without a VP system. Most are using their own systems rather than looking to SCORM. Ben asked if tracking success would be important. JB commented that doing it on a node makes sense. R achel commented that they aren't tracking success now. That's a binary model. Theirs is much fuzzier. Susan asked what does success mean? Rachel agreed that educationally it is a tricky concept. Susan commented that at some point they have to address it for cme. Rachel commented that some activities can be done more than once for formative evaluation. Ben explained that a success attribute was what he was considering. If you reach node with links to no other node except first one, that would constitutes completion. Susan clarified that they have two modes. One is Self assessment, where the user takes a virtual patient over and over. The other is summative. Rachel commented that given the huge varieties in uses of virtual patients, initiate and terminate reflect our abstraction. We can come back to it at the next meeting. Rachel is unavailable, so we will try to reschedule. If that's not possible, we will keep the 21st.

4 eViP update
5. Virtual Patient meetings and sessions at annual conference
6. Virtual Patient Poster at annual meeting (*slice poster,* template*)*
 

Decisions

  • The schema will continue to enforce the order of elements in an XML document.
  • Core demographics and its subelements will be made optional.
  • XML Duration datatype will continue to be used for age.
  • The manifest will reference metadata rather than the virtual patient data file.
  • Instead of having author diagnoses as a separate element, an author diagnosis attribute or element will be added to the diagnosis element to indicate when a diagnosis is the author's diagnosis. (note, we need to mode what the expected player behavior is with regards to that data)

Action Items

  • Dan will contact Educommons to see how their LMS handles different levels of metadata. Do they import package level metadata to describe a course? Do they import Organization level metadata to describe a course?
  • Ben will update the specifications to reflect the decisions made on the call.
  • The group will revisit the use of XHTML to see if it is workable.
  • The group will revisit SCORM on the next call.
  • No labels