Interim Final Rule Possible Responses - Revision history

NeilArmstrong: Added a glossary link to record~

2012-04-01T13:58:19Z

Added a glossary link to record~

← Older revision		Revision as of 13:58, 1 April 2012
Line 103:		Line 103:
	The CCR also requires the actor and source be provided for each element which		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		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		health [[record~\|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		feel that keeping a CCD, without proprietary elements, is important for
	exchanges where CDA is used.		exchanges where CDA is used.
Line 113:		Line 113:

	The requirement that all entries into a database of any type and that all		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		printing be [[record~\|Record]]ed is nearly impossible to control considering the operating
	system capability to circumvent the copying and printing of data.		system capability to circumvent the copying and printing of data.

NeilArmstrong: Added glossary link to Application~

2012-02-23T00:28:27Z

Added glossary link to Application~

← Older revision		Revision as of 00:28, 23 February 2012
Line 34:		Line 34:
	In addition, for reporting to public health agencies, the use of SNOMED		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		and UCUM is a recommended. LOINC is already used for reporting for many
	public health agencies although inconsistent in its application. LOINC needs		public health agencies although inconsistent in its [[application~\|Application]]. LOINC needs
	to be added to this list.		to be added to this list.

Ivaldes1 at 17:09, 6 March 2010

2010-03-06T17:09:40Z

@@ Line 140: / Line 140: @@
 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

Ivaldes1: Fixed typos. -- IV

2010-03-06T16:42:16Z

Fixed typos. -- IV

← Older revision		Revision as of 16:42, 6 March 2010
Line 54:		Line 54:

	Considering the oligopoly of the pharmacy databases, it is no surprise that		Considering the oligopoly of the pharmacy databases, it is no surprise that
	they are prohibitively expensive. ~~In addition, and Sure Scripts~~ controls the		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.
	user interfaces. The testing process is so slow as to further limit
	competition and innovation and raises costs.

	PQRI and Quality Reporting -		PQRI and Quality Reporting -
Line 92:		Line 90:
	Drug Interactions and Alerts -.		Drug Interactions and Alerts -.

	The drug databases that compile the interactions are very expensive and yet		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
	very important for good care. We feel the federal government should be		as it did for SNOMED and that they should be provided, mapped to RxNorm, through the NLM.
	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 -		CCR & CCD -
Line 104:		Line 99:
	does not provide the problems with incompatibility between systems that that		does not provide the problems with incompatibility between systems that that
	are engendered by the possibility of including proprietary elements in the		are engendered by the possibility of including proprietary elements in the
	CCD.		CCD.

	The CCR also requires the actor and source be provided for each element which		The CCR also requires the actor and source be provided for each element which
Line 113:		Line 108:

	The conversion of a well coded CCR into a level 2 CCD is already possible		The conversion of a well coded CCR into a level 2 CCD is already possible
	using an open source tool.		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.
	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 -		Auditing of all Patient Data and Printing -

Ivaldes1: Fixed typos. -- IV

2010-03-06T16:34:41Z

Fixed typos. -- IV

← Older revision		Revision as of 16:34, 6 March 2010
Line 32:		Line 32:
	standard adopted, quickly.		standard adopted, quickly.

	In addition, for reporting to public health agencies, the use of ~~the~~ SNOMED		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		and UCUM is a recommended. LOINC is already used for reporting for many
	public health agencies although inconsistent in its application. LOINC needs		public health agencies although inconsistent in its application. LOINC needs
	to be added to this list.		to be added to this list.
Line 39:		Line 39:
	ePrescribing -		ePrescribing -

	For ePrescribing, ~~and~~ interface to a service provider is an interface to one		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.
	service provider. It does not give you any help with working with a
	competitor~~, driving~~ up development costs and ~~limiting~~ competition. As
	previously noted, calling lab and ePrescribing interfaces “some of the most
	mature implementation specifications” shows a lack of understanding of the
	depth of the problem.

	We are not sure what the intended meaning of “complete data set integrated		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		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		brand names into the mapping of RxNorm to a databases such as First Databank
	and Medispan, there is not only ~~not complete~~ database integration, what ~~there~~		and Medispan, there is not only incomplete database integration, but what is available with RxNorm is incomplete.
	is available with RxNorm is incomplete.

	~~Sure Scripts~~ is a virtual monopoly which has blessed a few drug databases with		SureScripts is a virtual monopoly which has blessed a few drug databases with
	an oligopoly. The drug IDs of the drug databases to do not map with RxNorm,		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		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		matching up formularies to the drug database or pay a premium to be sold a

Ivaldes1 at 16:24, 6 March 2010

2010-03-06T16:24:29Z

New page

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 the 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, and interface to a service provider is an interface to one
service provider. It does not give you any help with working with a
competitor, driving up development costs and limiting competition. As
previously noted, calling lab and ePrescribing interfaces “some of the most
mature implementation specifications” 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 not complete database integration, what there
is available with RxNorm is incomplete.

Sure Scripts is a virtual monopoly which has blessed a few drug databases with
an oligopoly. The drug IDs of the drug databases to 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