← Prev in month ← Prev in thread
Next in thread → Next in month →

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

From
Tim Grapes
Date
2012-05-04T12:36:00+00:00
ID
Thread
RE: [emergency-tep] Initial TEP Schema + GoToMeeting for 9AM meeting
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:
 [mailto:]  On Behalf Of  Wilkins, Brian M  Sent:  Friday, May 04, 2012 8:30 AM
To:  
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

office: 781-271-2332
cell: 603-973-1422
← Prev in month ← Prev in thread
Next in thread → Next in month →