emergency-tep — archive

RE: [emergency-tep] Initial TEP Schema + GoToMeeting for 9AM meeting

From: Tim Grapes
To: [email protected]
Date: Fri, 04 May 2012 12:36:00 -0000

Thanks Brian! Let’s use this like to review the info and your list, as well as some research results from last time. 1. Please join my meeting. https://www1.gotomeeting.com/join/219777384 Meeting ID: 219-777-384 GoToMeeting® Online Meetings Made Easy™ Thanks , Tim Timothy Grapes SE Solutions 703.304.4829 ____________________________________________________________________________________________________________________________________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Wilkins, Brian M Sent: Friday, May 04, 2012 8:30 AM To: [email protected] Subject: [emergency-tep] Initial TEP Schema Here is the initial TEP Schema for discussion at 9:00. There were a few changes that I made on the fly that seemed to make sense that we should discuss. 1. In Client, clientUniqueID element added 2. In Client, personalID element added 3. In Client, closestRelativeGuardianContactInformation was unbounded in ERM, but only 1 in Data Dictionary 4. In ClientEncounter, NDMSPatient is restricted string, but could be Boolean like Client:securitySupervisionNeeds 5. In ClientCare, temperatureScale element added 6. In ClientCare, strokeScaleType element added 7. In ClientCare, contaminationRadiationContagionStatus was changed to a Boolean like Client:securitySupervisionNeeds 8. In Location, Country element added 9. In CIQ, address information was compressed to single address element of type Location 10. Should telephoneNumber and cellphone in CIQ be changed to primaryPhoneNumber and secondardPhoneNumber or should there just be a optionally unbounded phoneNumber (work, cell, home, work cell, etc) 11. Should phone number format be restricted? 12. Should emailAddress format be restricted? 13. In couple of instances, a default enumeration list was specified, but we allowed for some to create/add their own values…Not sure how to capture that when using a value list. 14. There were many instances of ValueLists that only required/restricted to one value. Should we create a new ValueList type restricted to just one value of the possible values available at the ValueList url? Thanks. Brian Wilkins Senior Software Systems Engineer The MITRE Corporation [email protected] office: 781-271-2332 cell: 603-973-1422