Difference between revisions of "Interim Final Rule Possible Responses"

Latest revision as of 13:58, 1 April 2012

This is a draft of much of the content to be included in a response from WorldVistA to the ONC regarding the meaningful use criteria.

Please feel free to use any of these points when writing your own comments to the ONCHIT. It will be especially useful there there are a number of comments echoing the same general points.

If you think of new points to add in your comments to the ONC, please share them with the group here so that others can pick them if they agree and add to what I hope will be a numerous response from this community.

Multiple responses are important to show that there is a sizable and diverse community of open source advocates who are engaged and care about what gets thrust upon us.

Lab -

The ONC suggested that the lab and ePrescribing interfaces were “some of the most mature implementation specifications” to be used. We would like to note that they are a long way from being mature.

HL7 ver. 2.* might be used for transmitting data from labs, but the labs do not stick to the standard and have their own unique variations. The lab tests are not consistently coded so that mapping them to comparable tests for graphing, etc., is difficult at best.

When you make an interface for a lab, you have made an interface with one lab, and there is almost no crossover to another lab.

The labs helped to fund ELINCS, but are unwilling to conform to what was developed. This work needs to be continued, a consensus developed and the standard adopted, quickly.

In addition, for reporting to public health agencies, the use of SNOMED and UCUM is a recommended. LOINC is already used for reporting for many public health agencies although inconsistent in its Application. LOINC needs to be added to this list.

ePrescribing -

For ePrescribing, one constructed interface to a service provider, is one constructed interface to one service provider. It does not give you any help with working with a competitor. This drives up development costs and limits competition. As previously noted, calling lab and ePrescribing interfaces “some of the most mature implementation specifications” is very premature and shows a lack of understanding of the depth of the problem.

We are not sure what the intended meaning of “complete data set integrated with RxNorm” is, but we feel that without an authoritative incorporation of brand names into the mapping of RxNorm to a databases such as First Databank and Medispan, there is not only incomplete database integration, but what is available with RxNorm is incomplete.

SureScripts is a virtual monopoly which has blessed a few drug databases with an oligopoly. The drug IDs of the drug databases do not map with RxNorm, so to make interfaces to ePrescribing services, you either suffer greatly matching up formularies to the drug database or pay a premium to be sold a mapped database. These databases should be mapped to RxNorm or replaced by RxNorm codes and at a minimum, the mapping should be maintained by the NLM.

Considering the oligopoly of the pharmacy databases, it is no surprise that they are prohibitively expensive. SureScripts controls the user interfaces. The testing process is so slow as to further limit competition and innovation and raises costs.

PQRI and Quality Reporting -

PQRI uses NDC codes for reporting and yet, physicians offices do not know the NDC code of the drug that their patients prescriptions will be filled with. A bottle with 100 brand name tablets will have a different NDC code than a bottle with 30 of those same tablets and there is no way to know what sized bottle a brand name will be dispensed from when patients go to a pharmacy. Even more problematic are generics as you will not even know what company the drug will have been supplied by. If RxNorm is the standard elsewhere, it should be the standard for PQRI as well.

We applaud the limited quality reporting requirements for phase I and implore the ONCHIT to work hard to provide a standard interface for all quality reporting and to work for consistency in reporting requirements, especially throughout HHS. Changing what needs to be reported causes great consternation and expense for some of the most undeserved by the demands placed on CHC, Federally Qualified Health Centers, and recipients of funds from Medicaid.

A spread sheet of some of the quality measures that may be demanded by different organizations is attached. There are literally thousands and they change. Using a consistent set of data elements that can be mixed and matched to create quality reports and using the same reporting tool would help this problem greatly. Please do not allow unlimited escalation of quality reporting, particularly by HHS and affiliates, as Meaningful Use moves forward.

Alerts -

Please do not restrict how providers of EHRs solve the issues of meeting the standards. For example, stating that a PopUp or sound is required for alerts limits options for other alternatives and innovation.

Drug Interactions and Alerts -.

The drug databases that compile the interactions are very expensive and yet very important for good care. We feel the federal government should be providing these databases by purchasing licenses to them for the country much as it did for SNOMED and that they should be provided, mapped to RxNorm, through the NLM.

CCR & CCD -

We congratulate the ONC for recognizing the CCR as its penetration is greater than that of the CCD. The CCR standard is much easier to implement and the CCR does not provide the problems with incompatibility between systems that that are engendered by the possibility of including proprietary elements in the CCD.

The CCR also requires the actor and source be provided for each element which allows them to be consolidated into a single document or into a personal health Record more easily. The same is not true for the CCD. However, we do feel that keeping a CCD, without proprietary elements, is important for exchanges where CDA is used.

The conversion of a well coded CCR into a level 2 CCD is already possible using an open source tool. We anticipate that an XSLT transform to create a CCD level 3 from a CCR, which is the current goal of some work being done by Ken Miller of Solventus as an open source project funded by Oroville Hospital in California, should make it easily possible for healthcare providers to transmit either a CCR or a CCD or both soon.

Auditing of all Patient Data and Printing -

The requirement that all entries into a database of any type and that all printing be Recorded is nearly impossible to control considering the operating system capability to circumvent the copying and printing of data.

For example, the request for capturing everything that has been printed may not be possible because of the use of the print screen option in at the operating system level. Also printing from any MS Windows based Computerized Physician Order Entry Graphic User interface program is not an "atomic operation" that can necessarily be monitored, i.e., it is a multiple step process and is difficult to audit and it would be difficult to do for any system to audit.

Secure transmission of health data:

We do not feel confident that we understand exactly what they are asking for, i.e., is only IPSec acceptable, etc., but we do believe this would be implemented at the operating system or hardware level. For the VistA EHR, this happens at the level of the interaction between the MUMPS implementation and the operating system. This needs to be clarified because even the NHIN is not using IPSec for transmission security. NHIN is using HTTPS and tunneling which are encrypted and secure integrity protected links.

Certificating Entities:

We are hopeful that there is no intent for only one entity to be designated to certify meaningful use. That will stifle innovation in testing methods and create a bottleneck in the process. It would also create an monopoly with all of the potential objectionable consequences that that might entail.

Nancy Anthracite

As I understand it the documents say that you could possibly start your own open source certification process. However, obtaining the funds and personnel to form a certification body in the open source world is far more difficult than with proprietary dominated EHR groups like HIMSS and CCHIT.

Proprietary EHR companies can explicitly lock-in customers when F/OSS ones mostly cannot. This is a competitive disadvantage for F/OSS companies and society since the un-informed, un-sophisticated customer likely does not know or care and is likely to respond to a sales pitch. The 'noise effect' and the Prisoners Dilemma applies here. Proprietary companies long term probably need to serve far fewer customers to make the same or more money as F/OSS companies.

This is a problem. A private transaction between two private parties is one thing, paying for such a transaction with taxpayer money is another.

Since interoperability is like fusion power (always just out of reach, we REALLY mean to do it THIS time!(tm)) these taxpayer funded transactions hold the possibility of keeping practitioners and taxpayers in perpetual servitude using their own money whereas with F/OSS EHR software and companies that is much less likely to be the case.

Ignacio Valdes, MD, MS