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

["Grapes, Timothy" <Timothy.Grapes@sesolutions.com>]

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: emergency-tep@lists.oasis-open.org [mailto:emergency-tep@lists.oasis-open.org] On Behalf Of Wilkins, Brian M
Sent: Friday, May 04, 2012 8:30 AM
To: emergency-tep@lists.oasis-open.org
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

bwilkins@mitre.org

office: 781-271-2332

cell: 603-973-1422