January 27, 2012
10 AM PST/12 PM CST/1 PM EST
Attending: Mike Zarski, chair; James Fiore, Jim Jahrling, Paul Jolly, Don Kooker, Kirke Lawton, Purvi Maniar, Alex Minkofsky, Brenda Ruff, Tarang Shah, Valerie Smothers.
James asked if Valerie maintained version control for the schemas so that one could view the entire history. Valerie commented she did not. She added that she does record changes within the specification.
1 Review minutesof last meeting
Mike asked if there were any comments on the minutes.
Jim commented that there was some confusion regarding item 4. ABMS had thought the new ScheduledUpdate element was in addition to the existing ReverificationDate element. Changing the name of the element will require changes to their product in production. He requested maintaining reverification date until they have a change their processes. Mike commented that the group would clarify later in the agenda.
The minutes were approved.
2 Review TSC compatibility recommendations
Mike reviewed the recommendations from the Technical Steering committee. If a new element is intended to replace an old element, the old element would be deprecated in the first revision and eliminated in the second. Valerie added that there was a risk benefit analysis that would be necessary when making decisions that would change the way existing parts of the specification are handled. Mike added that the group will make sure we follow the recommendations as we move forward.
3 Review updates to spec
Jim elaborated on the ABMS need to educate its customers on the element name change. They want to add reverification date back until they are able to do so.
Valerie commented that she could recreate version 1.4 of the schema for the ABMS. She recommended storing the version of the schema used for production locally to insulate the production system from further changes made as a result of the standards development process.
James recommended adding the capability for extensibility to the certificate issuance section of the standard. That would allow the ABMS to maintain the old name for the element until it is phased out.
Purvi asked if both elements would have the same data. James clarified that they would.
Mike agreed that recommendation would follow the intent of having the extensibility option available. You don’t have to compromise the integrity of the standard to add the element.
Jim agreed that was a good suggestion.
Valerie agreed to go ahead and add xsd any to certificate issuance.
4 Discuss areas for extensibility (see TSC recommendations)
Mike commented that we had an overview of this topic on the last call and that he wanted to give people time to think about it. We already have extensibility under the Member element; we’ve identified certificate issuance as an area for extensibility too. He asked the group if there are other areas we should consider. The group did not identify any other areas for extensibility at this time.
James emphasized that now XtensibleInfo is deprecated and should only be used for backward compatibility. Valerie will update the documentation to say so.
5 Discuss wording of elementclarifying MOC/OCC compliance
Valerie commented that this was an item discussed on the last call. Jennifer Michael proposed alternate wording via email; Valerie had requested removing the word type since that is used to denote datatypes in the XML schema.
Mike clarified that the new element would be CertificationMaintenance. The AOA was in agreement on the proposed wording of the element name. The proposed valid values are maintained and not maintained. Annette had looked at this from the credentialer’s perspective and was concerned with not maintained because of ambiguity. That could mean failing to maintain or not required to maintain. She had suggested in compliance or not in compliance.
James asked to clarify how he was interpreting. For ABMS boards, one element says certificate type is life time, time limited, or continuous. If person has a lifetime certificate, they won’t have this flag. If their certificate is continuous, he will use this element. If not maintained, the individual is not in compliance. If it is maintained, then they are meeting requirements.
Don commented that he interprets it differently. They intend to use on any type of certificate.
Mike asked if maintained/not maintained would still work. Don agreed it would. The group agreed to adding CertificationMaintenance with a value of maintained/not maintained.
The group went through questions for clarification submitted by Amy Opalek.
- EducationInfo.Degree (p. 18) – Since this is not a controlled list, and the multiplicity is 0-1, would it be acceptable to include dual degrees in this field (i.e., MD/PhD, BSN/MBA)? If so, would the discipline also include information for both (“medicine/law” for MD/JD)? Alternatively, should a separate Education element be created for each degree in the combined program?
Kirke commented that joint programs are really two degrees. In practice, they report degrees as two separate elements.
Mike commented that there are hybrid programs, but that’s not always the case. There is nothing distinctive about having gone through a program like that vs. someone getting degrees through two different programs.
Brenda commented that they would prefer that degrees be separate. MD would have to be split out in their database. For their purposes, separate is better.
- EducationInfo.Degree (p. 18) – Is there a preferred format for the degree name? Should both full title and abbreviation be included?
James commented that the abbreviation should be required. He questioned whether there should be an extra element for title. Purvi commented you could have both and the implementer could choose which to use. Kirke replied that they don’t want them to choose. He recommended using just abbreviation. James commented that unless Amy is requesting full title, we should not include it. They are all expecting the abbreviation, all punctuation removed.
- DisciplinaryInfo.BoardOrder (p.38) – Are there other types of adverse actions that could be placed in this element? For example, would sanction by an agency other than a board or information about a malpractice award be placed here?
James commented that the specification doesn’t restrict it any way. You could use it for other things. But it is intended for state licensing boards.
Jim commented that including malpractice may not be appropriate.
Mike asked if the contents of the element should be actions affecting the license.
Brenda agreed it should have something to do with the license.
Mike commented that there is a lack of specificity now.
James summarized that the group felt the element should be used specifically for actions against licenses by licensing boards. If there are additional uses Amy would like to request, she can put those in for future discussion. We should revise the documentation to reflect that decision.
- AcademicAppointmentInfo.FacultyAppointment.FacultyTrack (p. 58) – What kind of data should be stored here? Some examples would be helpful.
The group asked for Paul’s input but he was not available. Kirke agreed to direct Paul’s attention to the question and get examples.
- OccupationInfo.OccupationStatus (p. 67) – Are “retired” and “active” sufficient as the set of valid values? If so, then is this status meant to indicate current/former status?
The group agreed that Occupation is intended to mean current status.
Kirke commented he would have thought part time/full time. Also, if the status is not current and not retired, there is no way to indicate that.
James recommended seeing if Amy can present additional use case.
Valerie asked if anyone on the call was using occupation status now. No one was.
- PersonalInfo.Citizenship.pointInTime (p. 72) – Does appropriate use of the multiplicity of this element include dual citizenship? For example, could a record have more than two citizenship elements both with a pointInTime of “current”?
The group agreed that documenting dual citizenship was the original intention. James recommended making that explicit in the documentation.
Mike commented that the rest of Amy’s questions should carry over to the next meeting. The group can look at other questions in the interim.
James requested that soon after the call there be follow up on how ABMS boards will implement the professional profile and the modifications they need to have. Jim agreed to arrange a call for follow up.
Kirke questioned why we have tax provider number as well as unique id. They put national id in unique id field with different qualifier. He will write something up and submit it for consideration. He added that the specification examples have not yet been updated.
Mike asked if there were any proposals for the next agenda. None were submitted.
Don asked Valerie to get today’s decision into the spec asap. ABIM is about to start a project. Valerie asked for a deadline. Don replied next Friday.
Mike asked Valerie to provide an update on the annual conference. Valerie shared that there is a great program with keynotes form Peter Pronovost, a quality expert at Johns Hopkins, and Craig Campbell from the Royal College of Physicians and Surgeons of Canada. There will be an in-person meeting of the working group on May 2. In addition several presentations are related to the work of this group, including the Electronic Verification of Medical Education Credentials demonstration and the Data Exchange and Standards Implementation panel, which will include a presentation on Data Commons. Mike encouraged the group to recruit their colleagues to attend. Attending the conference will help our organizations better understand our work and the opportunities afforded by MedBiquitous standards.
- Valerie will make the following changes to the specification:
- add the capability for extensibility (xsd any) to the certificate issuance element.
- update the documentation to reflect that XtensibleInfo is deprecated.
- add add CertificationMaintenance with a value of maintained/not maintained.
- update board order to indicate that it is for actions against licenses by licensing boards.
- Make the use of PersonalInfo.Citizenship.pointInTime for dual citizenship explicit in the documentation.
- The following will be added to the implementation guide as best practices
- Joint degrees should be recorded separately using two EducationalInfo elements.
- Degree name should be abbreviation, all punctuation removed