CCHIT vs FOSS pre-meeting issues

I am preparing for the meeting tomorrow with CCHIT and FOSS. I had previously used Google Moderator to get a feel for what my communities position on this issue is. Moderator allows for the same question to get posted again and again, so often the same idea was represented twice. So ignoring duplicates and ideas that got less than 12 votes (arbitrary), here are the positions that garnered the most support:

“To avoid data lock-in (FOSS or proprietary) CCHIT should provide a focus on interoperability.”
Tim Cook, Brazil/US

“CCHIT should drastically lower the costs for the certification of FOSS Health IT systems in recognition of their status as a public good.”
Fred Trotter, Houston

“CCHIT must find a way to protect the interests of the “original developer”. If an individual contributes/creates a FOSS EHR, and then a second party gets that codebase CCHIT certified, under the current system, only the second party benefits.”
Fred Trotter, Houston

“CCHIT should certify FOSS projects. Multiple companies could pool resources for certification purposes, and all the users of the project would benefit from the certified status, as long as they used the tested codebase.”
Fred Trotter, Houston

“CCHIT should move towards higher level certification mechanisms that do not focus on black-box certification.”
Fred Trotter, Houston

“FOSS licenses provide a “right to modify” to the end user. This is fundamentally incompatible with the idea that a certain codebase is “certified” in the way that CCHIT currently understands it.”
Fred Trotter, Houston

“Create a separate-but-equal CCHIT certification for FOSS Health IT software. It should be much cheaper and recognize the differences in the FOSS model. It should be much less expensive.”
Fred Trotter, Houston

“CCHIT charges should be based on an ability to pay. Smaller companies &/or community projects (i.e OS) should not disadvantaged and innovation should not be discouraged because of cost.”
Tim Elwell, New York

“Under the current model, CCHIT certification cannot jump vendors, so if a FOSS EHR user uses the “right to fire” implied in a FOSS license, they would lose CCHIT certification during that process. Thus certification is currently a lock-in mechanism.”
Fred Trotter, Houston

“CCHIT should re-publish the software licenses of the CCHIT software. Proprietary or otherwise. Further, the practice of removing bankrupt EHR companies from the list must be halted, they should be listed with a license status of defunct.”
Fred Trotter, Houston

“CCHIT should certify application modules. If it can be proven that the certified module’s software code base has not changed, others may incorporate the certified component in their application – license permitting – without recertification.”
Tim Elwell, New York

“CCHIT should consider releasing the certification criteria themselves under Creative Commons or GNU Documentation license. This would allow the FOSS community to develop our own certification methods and systems based on CCHIT standards”
Fred Trotter, Houston

“CCHIT should allow for automated testing of FOSS codebases. For instance a mechanism to prevent the re-testing of FOSS EHRs whose sourcecode had not changed, when the relevant criteria had not changed.”
Fred Trotter, Houston

“Successful FOSS projects share revenue with 3rd party companies who resell the software More companies make for a better supported and longer lasting product. CCHIT should charge each a smaller % of cert fees to support this business model.”
Greg Caulton , Boston