December 3, 2015
11 EST/10 CST/9 MST/8 PST
Attending: Amy Opalak, Chair, Prasad Chodavarpu, Editor; James Fiore, Jim Jahrling, Kirke Lawton, Vicki Lundmark, Jennifer Michael, Brenda Ruff, Tarang Shah and Valerie Smothers.
1 Review minutes
The minutes were accepted as submitted.
2 Discuss proposed revisions to specification
A Accuracy data type
Valerie noted that the ACCME and ABIM requested that we add DayMonth to the accuracy attribute so that they may indicate the day and month of a birthdate but not the year. She noted this change would affect other elements, but may not be relevant for other types of dates. Amy clarified this will be used to increase privacy. Kirke agreed with adding that option. James asked if they requested this for records matching purposes. Valerie confirmed. Amy added this will be an option for all other fields requiring date. Valerie mentioned the options were to change the current accuracy data or create a new accuracy attribute that includes all options. Amy asked the group if it would be helpful to indicate when one might use the day month accuracy element. Valerie would hesitate to add descriptive text, doesn’t want to be prescriptive. We could mention “day month may be useful for organizations seeking to have some privacy protection” under birthdate for the individuals subscribed. Amy suggested warning people not to use it in other fields. Prasad agreed. Kirke clarified the only time you would use this attribute is when you want to send a partial date. Valerie will describe intent in the specification, “accuracy may be used if full date is not available or can’t be shared” and list the valid values.
B Licensure entity
Valerie mentioned the proposed changes to licensure entity also relate to ABMS and FSMB needing to exchange data about licensure state. They previously used Licensure entity to convey the state, but some states have multiple boards. Prasad proposed using the same structure as disciplinary entity with two sub-elements: licensure entity name and contact information. Contact information would include the address where you can include the state. Valerie recently talked about the concept but not the specific solution with Cyndi at a meeting in Washington in October. Jim commented that Purvi was on vacation until next month and they were hoping to receive feedback about what they were using for transmitting licensing. He suggested tabling this until Purvi and Cyndi can add input. Valerie will confirm Cyndi and Purvi’s availability for a call in January. The topic will discussed again on the next call.
3 TSC updates on API development (see Use cases)
Valerie mentioned the Technical Steering Committee have been discussing guidelines for developing API’s and have agreed on some principles on their last call. The first one being to keep it lightweight, making sure API’s are easy to implement and ensuring extensibility of methods and perimeters. Prasad added they want to make sure there is support of service using different criteria. Valerie commented the standards are in XML, and the new work in JSON. The principles proposed support content negotiation; the person requesting data has to negotiate the content. The web service provider may only support XML or JSON. Prasad explained that if a service provider doesn’t support the requested format (XML or JSON), the requester gets a response saying that the format is not supported. The technical steering committee recommended future development work support both XML and JSON. Valerie added that persistent URL’s are included in the guidelines, too. Amy asked if the expectation was for the technical steering committee to turn over to each working group to develop API specifications. Valerie confirmed.
Kirke commented that the REST paradigm is radically different. In Salesforce, each system has dozens of URL’s to obtain specific things. He suggested using examples of use cases to show what this would look like. Valerie concurred. She noted we are dealing with sensitive data. The onus is on the web service provider as to what it is you are entitled to see. Prasad stated the use cases tend to be a singular level; however, once you get into multiple levels, there is a hierarchy from the top down. JSON may be needed eventually in the Professional Profile schema. Valerie noted not everything in XML will translate to JSON, we would have to determine certain conventions. There is no standard for representing dates in JSON. The technical steering committee was not thrilled with automated tools. She mentioned the next step is for the technical steering committee to develop guidelines. This group could develop something in parallel for JSON and propose as a new standards development effort. Prasad suggested having a pilot to see what JSON portion of the specification would look like. Amy asked if this was a potential topic for discussion at the annual conference. Valerie agreed API’s in general would work. Jim suggested including an hour or two hour working sessions digging through examples. Valerie added possibly at the technical steering committee portion of the conference. She will talk to Joel and the Executive Committee for their input and recommendations.
Valerie added further information to the API use cases, relevant specification and data elements and would welcome feedback.
Amy mentioned an upcoming international conference for the International Association of Regulatory Authorities in Australia on Sept 20. There are a couple of relevant topics to note and abstracts are due April 6. The themes include medical regulation, medical education, medical practitioners, and challenges for regulators of medical practices.
We will add DayMonth as a valid value for the accuracy attribute and include the following description: “accuracy may be used if full date is not available or can’t be shared.”
- Valerie will update the specification to reflect the decisions made.
- Valerie will confirm Cyndi and Purvi’s availability for a call to discuss LicensureEntity.
- Valerie will talk to Joel and the Executive Committee regarding recommendations for the meeting.