View source for Interim Final Rule Possible Responses

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.  In addition, and Sure Scripts 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