General and Items 1 & 3 Issues (David Aronow)

Three other issues I want us to chew on:

1. Some terms that might be MVR in one context may not be MVR in another context. For example “Uncertain” might be an MVR for why there is not date of last tetanus immunization (patient not sure if it was 5 or 15 years ago), but not be an MVR in the case of treatment response (where it is the actually legit value). True, curators might craft the first case to be a value of “Patient Uncertain of Date” and the latter as “Uncertain Treatment Response”. I would just caution against us trying to create a catalog of terms that are MVR and those that are not – I think the same term could be a permissible value in a variety of CDE, both MVR and not.
2. Recommendation #1 speaks of “Grid level” – I often do not know what that means. Can we use other language to explain the scope we intend for the MVR? Maybe along the lines of “ MVR are defined in terms of vocabulary and CDE, which are the currency of exchange between information systems, not in terms of application or database design and implementation.” (Yes, I think ‘implementation’ is important).
3. Recommendation #3 – I actually think it is not an architecture issue how MVR work, but a VCDE issue. Just like some terms may or may not be MVR in certain settings, there will be many configurations of CDE-associated MVR CDE, not just a small number of stock ones. So I think MVR CDE associated with other CDE should be explicitly specified and named as MVR for that CDE. I don’t like the syntax suggested in the CDC Implementation Guide: EXACT DATA ELEMENT NAME_MVR, it will get too long and clunky, but I like the approach, and used simplified MVR CDE names in my recommendation examples.