Skip to end of metadata
Go to start of metadata
  • LicenseInfo.License – It would be helpful to include the following additional information as sub-elements of License:
    • Profession – the name of the profession for which the license entitles practice (using health professions names outlined in ANSI/MEDBIQ LO.10.1-2008 Appendix 2)
    • Jurisdiction – the name of the country or state/province in which the license entitles practice (using a standard code for country or state/province)


  • EducationInfo and TrainingInfo –These two elements are predominantly the same and could be collapsed into a single element.  Any attributes that differ between the two could be handled with additional sub-elements.  Places where the two elements differ in the current standard highlight inconsistencies and a US-physician-centric focus:
    • EducationInfo.Degree  or .Certificate vs. TrainingInfo.[] – In some countries a degree is awarded upon completion of postgraduate training as well as undergrad.  For example, in India, one might be awarded an MBBS upon completion of the basic medical program and an MD upon completion of postgraduate training.
    • EducationInfo.[] vs. TrainingInfo.ProgramInfo.Accreditation – Accreditation of the professional degree program is worth capturing too.
    • EducationInfo.Degree.discipline vs. TrainingInfo.ProgramInfo.Specialty – Conceptually, these two sub-elements are very similar and could be merged.  Alternatively, Specialty could be a sub-element of Discipline in a combined Education/Training element.
    • EducationInfo.InstitutionInfo vs. TrainingInfo.ProgramInfo.InstitutionInfo – InstitutionInfo is more appropriately placed as a direct sub-element of EducationInfo.  Since only one institution per program, and one program per training, is allowed, InstitutionInfo could be a direct sub-element of TraningInfo.
  • EducationInfo.Degree & EducationInfo.Certificate – If these two elements are an either/or pair, then they should be combined under a single “qualification” element.  The separation of these elements necessitates that the standard list both as Optional, preventing the enforcement of what should be a required field.  The Type attribute of the Certificate element could be expanded to include undergraduate and graduate degrees in a combined element.
  • OccupationInfo and AcademicAppointmentInfo – It is evident from both the descriptions of these two elements (suggesting the user could use either one or both elements to describe the same concept) and the content of their sub-elements that they are fundamentally the same and should be combined in some way.  Their separation adds confusion and confounds standardization. 
  • FacultyAppointment, ChairAppointment, DivisionOrSectionAppointment, AdministrativeAppointment – The concepts and sub-elements of each of these are so similar that they merit combination with an added sub-element that indicates the type of appointment.  The latter three are especially indistinct from each other. 
  • ChairAppointment.ChairType, DivisionOrSectionAppointment.DivisionOrSectionAppointmentType – The “term” attributes of each of these elements could be elevated to its own element, since the duration of the appointment is independent from whether or not the appointment is jointly held.
  • PersonalInfo.TaxNumber – Aside from the added level of restriction in the personalInfo element, the use of which is not clearly defined, this element seems redundant to the Member.UniqueID element.  A social security number could, for example, be listed under UniqueID with a domain of and a localidentifier of SSN.
  • No labels