Skip to end of metadata
Go to start of metadata

Meeting Information

Date:

6 September 2012

Time:

9 AM PDT/10 AM MDT/11 AM CST/12 PM EDT

Attending: Mike Zarksi, chair; James Fiore, Jim Jahrling, Paul Jolly, Don Kooker, Purvi Maniar, Amy Opalek, Brenda Ruff, Valerie Smothers.

Agenda Items

1 Review minutes

The group noted one typo which was corrected. The minutes were approved.

2 Review updated specification and schema

Valerie reviewed the updates made to the specification.

  • Profession and Jurisdiction were added to License element
  • TrainingInfo was eliminated
  • A new model for EducationInfo was created with the following new elements: Accreditation, ProgramName, ProgramID, DisciplineOrSpecialty. EducationStatus changed to Status and valid values were expanded. GraduationDate changed to CompletionDate.  DiplomaIssuedDate changed to CompletionDocumentIssuesDate.

Paul questioned use of abbreviation for identifying a state as a jurisdiction. He asked if we should state that codes are preferred.

Amy commented that there are a couple of countries that don’t have codes. She doesn’t think they have a code for Kosovo yet. There is a code people have been using in the interim.

Valerie asked what is being done now.

James commented that they don’t exchange license information with anyone other than surgeons.  They collect state code and license number and expiration date. The country is free text. Until they get a feed from FSMB to automate the license, it is a manual process to verify. He added that he was willing to adopt whatever we suggest.

Valerie commented that in the implementation guide we can recommend using USPS codes for state or province. She will change the specification to say name or abbreviation of the state. The group agreed to keep the word Educational in the element name for EducationalCertificate and agreed with the changes to ProgramType values.

James added that the word education should be added back to the status element to distinguish that from certification status. The group agreed.

3 Discussed proposed data model changes

a NationalID

Valerie presented the proposal for a NationalID type that includes attributes for country name, country code, id type, restrictions, and truncated to indicate if the ID has been truncated.

Paul asked if we need another element for id type since we have unique id. Amy commented that some people have a national id that is not a tax number or passport number. In India they give a national id to everyone.

Valerie commented that we could make the id type optional. Paul agreed that sounded ok.

Purvi commented that she would prefer to have social security number as a type.

James commented that he can see the distinction between unique id and national id, and he understood why it was requested. He was fine with the change if ABMS was fine with the change. He questioned if further work was needed on unique id

Purvi commented that she thought we would keep tax number as is and add country to it. Valerie commented that wouldn’t represent passport or alien numbers or other types of national identifiers.

Purvi commented that they are using the tax number element. They would have to change how they exchange info. That would be more work. She is not sure everyone is ok with that. Jim agreed it would be a lot of extra work.

James commented that he thought they were working to include version 2 changes for Jan 2013. Purvi commented that tax number was not discussed at that time.

Don commented that from his perspective it’s not a problem when they go to new version of the spec. They will need some overlap time. But it’s not a major change.

Purvi offered to go back and discuss this with Jen. Jim agreed they would like more time to evaluate. He offered to get an answer before the next call.

b OccupationInfo (see Amy's example)

The group reviewed the proposed revision to the OccupationInfo model that would include academic appointments. The revision makes Academic Appointment Details a subelement of OccupationInfo. James asked if you would repeat OccupationInfo for each academic appointment. Valerie replied that if the academic appointments were at the same institution, you would not need to repeat OccupationInfo.

Amy added that the Occupation element should be a general description. Paul suggested Bureau of labor and statistics general names, like physician executive.

James clarified that the changes had not yet been made to the spec or schema. Valerie replied that was correct. James proposed putting the proposal out to people who are using this element. We don’t have good data on who is using which elements. It would be good to have a survey on what node types are being used by which organizations. Valerie agreed to create a survey. James recommended relating results back to the members of the committee and following up with ones who have not responded. It would be a significant change to the standard. Amy added that we should ask who they are exchanging the data with and why.

Mike recommended focusing on occupation info and academic appointment.

4 Open discussion

Valerie commented that a call for abstracts for MedBiquitous 2013 would be announced soon.

Amy recommended creating an event in linked in so that linked in users can indicate they are attending.

Decisions

  • Implementation guidelines will indicate that USPS codes are preferred values for state or province jurisdiction.
  • Revisions to educational Program types were approved.

Action Items

Valerie will update the specification as follows:

  • The Jurisdiction StateOrProvince documentation will be updated to indicate that a name or abbreviation is valid.
  • The Certificate element under EducationalInfo will be changed back to EducationalCertificate.
  • Status will be changed back to EducationStatus
  • Jim and Purvi will further discuss the proposed NationalID

Valerie will create and distribute a survey of implementers that asks about use of Occupation Info and Academic appointment. She will make the purpose of the survey clear ( to facilitate in gauging the impact of proposed specification changes on implementers). The survey will also ask who the participants are exchanging data with and why. Valerie will follow up with those who fail to respond.

  • No labels