I apologize in advance for the forthcoming wall of text. Since our discussion of school IDs, I’ve been going through ECFMG’s variables for sharing through the Data Commons and mapping them to MedBiq elements. Since some of what I found overlaps with Len’s issue from today’s conference call, I thought I’d send along my observations now. We’re only dealing with about 30 variables from ECFMG into the Data Commons at the moment, and most map very cleanly to the MedBiq elements. But there are a few areas where I have some questions…
- Country of Birth: ECFMG collects country information along with its date of birth and decease records. Country of birth can be different from citizenship at time of birth (for example, in the case of children of diplomats), so they are captured separately. It may make sense to use the CountryOfResidence element in PersonalInfo to pass these data, but it would require that there be a subelement to indicate a date. Alternatively, we could use the Address element of PersonalInfo, with the same issue of being unable to define a date of validity.
- Address: Along the same lines as the above, we store a date of validity with our physician contact addresses. As I mentioned on the call, we tend to lose track of our physicians immediately after we’ve certified them and never hear from them again. So, very often, our contact information is terribly out of date. In fairness to people who are receiving our data, we’d like to be able to indicate how old our contact information is. For some physicians, this date may be decades prior to the date on which we’re sending the data.
- Native Language Category: One of the data points that we use in our IMG research is our native language category. This variable has three possible values: English, Not English, and Unknown. Admittedly, this is not very useful. I’d like to make a recommendation to our staff to start collecting language data in a more useful way, and I’d like to use the MedBiq standard as a guide. However, I think that the Language element in PersonalInfo, while definitely more specific than our Language Category, could be more specific still. We discussed before what existing controlled vocabulary we could use as a reference for languages – I mentioned the MARC language codes, and you said you would be more likely to go with the XML language datatype. I think we should definitely include some kind of standard coding scheme in Professional Profile. For our purposes, it would also be useful to have an indicator of whether each language is a native language or not. Technically, all of our certified physicians have demonstrated English proficiency, whether or not they are native speakers. We may also want to go as far as including in the Language element attributes for speaking, reading, or writing, as optional qualifiers/attributes, since this is a common presentation on CVs.
- ECFMG Certificate: In addition to being used for specialty certification for physicians and nurses, I think the CertificationInfo container can be used for ECFMG certification data. I didn’t want to bring this issue up on the call, because it may take a bit of time to explain and sort out. ECFMG has a lot less data to worry about than specialty boards, but there are still a couple of places where things don’t line up with the standard precisely:
- CertificationOrganization and CertificationBoard: The naming of these elements is counterintuitive in our case. If I understand the element descriptions correctly, ECFMG would be listed under the CertificationBoard element rather than the CertificationOrganization, since we do the evaluation and issue the certificate, even though we more “organization” than “board”. As far as I know, there’s no organization approving ECFMG’s certification process the way that ABMS or ABNS approves their certifying boards/agencies. Since CertificationOrganization is optional, we would leave this blank. Is this OK?
- CertificateStatus: For the most part, our ECFMG Certificate statuses line up with the CertificateStatus options already available in the Professional Profile spec. Our statuses are Certified, Not Certified, Suspended, or Revoked. I guess we could use “Active” for Certified. Only “Not Certified” is not included in the list of possible values in the MedBiq spec, and I recommend we add this as a valid value. As the standard is now, it would not be clear to a data recipient whether the absence of a status indicates that the professional is not certified or the data provider has no information on status. I think this status has value as a definitive statement that the individual has never been certified by our agency. Since there would be no instances of CertificateIssuance in this case, there would be no need to have the “Not Certified” as an option in the CertificationStatus element.
- Our Suspended CertificateStatus comes with an end date or “suspended until” date. Should we use the CertificateIssuance.ScheduledUpdate element to pass this info?
To clarify what I was referring to at the very end of the call – there’s a “restrictions” attribute on the PersonalInfo element and several subelements that I think could be used in a variety of other places in the schema. I would put this attribute in the same category as Len’s “source” data and the “date of validity” attributes I mentioned above. These are all basic metadata elements that we see in Dublin Core (source, date, rights) and other standards, and I think they could all be used as qualifiers/attributes on just about any individual data element or container.
Let me know if you think any of this should be brought up with the Working Group.
Thanks again for your patience,