Follow-up testimony to questions from the subcommittee
Jon A. McBride II, Chief Technology Officer, Availity
June 21, 2005
National Committee on Vital and Health Statistics
Subcommittee on Privacy and Confidentiality
June 7-9, 2005
I would like to thank the subcommittee of the NCVHS for allowing myself and Availity the opportunity to testify regarding the national health information network (NHIN) on June 7th, 2005. I believe that your interest in hearing testimony from the “front lines” will bolster the fact that there are some very progressive and successful technology endeavors in healthcare across the nation.
I am following-up to specifically answer two questions that were posed to me from the subcommittee and hope that this assists in your information gathering efforts.
How [can the handling of patient privacy be managed with today’s technology]?
I believe that this question should be broken into two components, 1) business-rules (aka healthcare domain expertise and practical use-cases) and 2) technology.
With respect to business-rules on how to manage patient privacy, simple written policies and procedures stating who can access what and when must be created. This can and should be done absent technology (or at least setting technology aside for a moment). There exist regulatory requirements as well as precedent in the business practices of healthcare. These can be systematically converted into formal use-cases, which is one methodology for transferring business-rules into software or technology. Furthermore, any business-rule gaps that exist today can quickly be addressed once the business rule or need is identified.
The business-rules must drive the technology solutions, not vice-versa. In fact one of the questions asked by the subcommittee of the first panel of June 7th was (paraphrased): “if an employer had an applicant sign a health record release, how would Winona Health [panelist on Integrated Health Systems] handle the request?” As we examine this question, I believe that this same inquiry is valid in a “paper world” or current healthcare environment. There is very likely a rule or policy that exists absent technology on how to address this situation. If a paper release form was delivered from the would-be employer to a paper-based hospital, how would the workflow be handled exactly? This is how use cases are created and can then begin to define how technology can assist or replace component pieces of the workflow achieving the desired result, albeit accelerated, just as a manual paper process. This is an important prerequisite to the second component of this answer, technology.
Regarding technology, many mature rules-engine software applications exist today. They innately provide the ability to convert business rules into executable software. Additionally, the rules-engine applications mitigate business-rule conflicts (e.g. where the same condition is met, differing outcomes are defined). Identification of these conflicts is very difficult to do manually in complex systems. Business-rule software conversion is how Availity and hundreds of other healthcare IT entities turned the HIPAA rules into reality. This was necessary to ensure that the millions of electronic healthcare transactions processed each day conform to HIPAA and other regulatory requirements.
Finally, some high-level least-common-denominator business-rules of what is expected should be created at the national level for healthcare privacy. This would allow the creation of uniform software rules across the country which would improve interoperability and be a candidate for “certifying” vendors. These rules need to be finite and consistently applied and not subject to interpretation (to address the issues experienced with the implementation of HIPAA). Community-level business practices can and should exist, but well-chosen and necessary business-rules from the national level should preempt other rules. Otherwise requests from one community network to another or requests from an employer to different community networks would be so complex that they would become ineffective and could do more harm than good.
One example of how this is being dealt with by Health Plans in particular is through collaboration in the creation of business-rules for eligibility request through CAQH-CORE. While this effort is fantastic, the government should endorse or create leadership to promote a single vision and direction. The network is capable of so much more than administrative transactions.
Availity would be glad to provide more examples or answer any further questions regarding this subject.
Should the Internet be used [or embraced] in building the NHIN? (Is the Internet secure enough?)
Yes, the Internet should be used as the technical foundation for building the NHIN. This does not mean that there will be no challenges to overcome. However, the Internet and associated technologies are being developed and improved upon by countless Fortune 500++ technology companies as well as governments and universities.
The reach of the Internet also cannot be ignored. If we are to include rural and/or under-funded healthcare communities in the vision of the NHIN, the Internet is extremely cost effective and highly available. The more the Internet is used in general, the less the cost to participate. The Internet is only the backbone however, and other applications and technologies can be created to exist on top of the Internet as necessary and appropriate.
The Internet is not secure enough to be the NHIN backbone without constant attention. The entire technology community must continue to stay on guard from those with nefarious intent – technologies which protect security must always stay ahead of technologies that would cause harm. No matter what backbone the NHIN is ultimately built upon, there will be those people who will attempt to exploit its weaknesses, inside and outside. An extremely large group of people and entities remain vigilant in protecting the Internet already.
Embracing the Internet as the foundation for the NHIN would allow healthcare the opportunity to stay synchronized with evolving technology rather than be relegated to aging, inefficient and costly proprietary legacy systems.
There is a successful Internet model in Florida, the fourth largest healthcare state in the United States, which has been working effectively and securely since 2001. This Internet model now services over 90% of the Florida Physician sites, including all Florida Hospitals. Availity welcomes the opportunity to assist and explore how we can help answer questions and improve healthcare in other parts of the country. We are happy to share our lessons learned.
Availity is an independent LLC created in Florida in 2001 by a joint venture between two large Health Plans, Humana and Blue Cross Blue Shield of Florida. One of the purposes for the creation of Availity was to provide a collaborative Internet solution to the looming HIPAA compliance deadline in the State of Florida. The idea was that by collaborating on and consolidating Provider portals, Provider workflow could be improved and healthcare costs could be reduced.
Eligibility and benefits, authorizations, claim statuses, and of course claim submissions and remit advice was available securely online; and all of this was provided and at no cost to Providers which was another appreciated efficiency. In addition to our Payer-owners, today Availity has connectivity to over 1000 Payers nationwide including real-time connectivity to a total of 10 Payers that represent approximately 58% of the private Payer market in Florida. By offering functionality via these Payer connections to Providers across the state of Florida, Availity services over 90,000 portal users and 400 vendor partners. This has resulted in 14,000 out of 15,000 Provider sites using Availity in Florida in some way, shape or form – over 90% of Provider sites in the state representing approximately 40,000 Providers. On behalf of our users, Availity submits over 9 million HIPAA compliant transactions to Payers each month, and is on a run rate to exceed 100 million HIPAA compliant transactions in 2005.