availity logo

National Committee on Vital and Health Statistics

July 26, 2006

Washington D.C.

 I would like to thank the Committee for this opportunity; it is an honor and a privilege to again provide my thoughts on the National Health Information Network (NHIN), especially as it relates to commercial health plans and the proposed NHIN requirements.  My name is Jon McBride.  I am a computer scientist and the Chief Technology Officer of Availity, LLC.  I have worked across a broad spectrum of healthcare information technology (HIT), from clinical IT, electronic medical records, developing emergency department clinical systems, to global provider portals, to my current position, which deals with Provider-Payer collaborative IT.

I speak from my experience working with many commercial Payers across the country.  I understand that additional Payers were not able to testify today because of abbreviated preparation time.  I understand the importance and applaud the effort to march toward completing deliverables; I recommend that the committee consider providing additional venues for Payers to share their insights for the public record about proposed NHIN requirements.  The NHIN’s success depends, I believe, on the involvement of the Payers.

My employer, Availity, is an independent company created in Florida in 2001 by a joint venture between two large Health Plans: Humana (Inc) and Blue Cross Blue Shield of Florida.  One of the purposes for Availity’s creation was to provide a collaborative and secure Internet solution to Florida’s then-looming HIPAA compliance deadline. Another purpose was to improve Provider workflow and reduce healthcare costs by consolidating Provider portals.  The payers funded both the creation and operation of the consolidated portal, with no cost to the providers.  This Availity portal, in contrast to the batch legacy systems that continue to proliferate, provides real-time healthcare data exchange–which fundamentally improves healthcare.

In addition to its Payer-owners, today Availity connects to over 1000 Payers nationwide, including approximately 80% of the Payer market in Florida (by covered lives).  Using standard Internet technology, Availity securely services over 100,000 HIPAA compliant real-time requests every business day in the state of Florida, while processing well over 100 million total HIPAA compliant transactions per year nationwide.  Over 14,000 out of approximately15,000 Florida Provider sites are registered with Availity.  In addition, Availity is significantly expanding its operations into Texas, New Mexico, Oklahoma, and Illinois as Health Care Service Corporation (HCSC) joins the venture. This expansion should provide further economies of scale, reduced costs and provide more opportunities to develop and offer additional real-time technologies.

Since I last testified before the NCVHS just over a year ago, Availity has worked closely with Blue Cross Blue Shield of Florida and Humana on something called the Availity Care Profile, a payer based health record.  As a group, we determined to deliver technology that we believe has the potential to significantly improve healthcare.  Together we rolled up our sleeves to design, fund, develop, and deploy an application that securely accesses and delivers patients’ health information from their respective Payers to Providers, on demand.  This application delivers all claims information to Providers at the point of care, including physician visits, diagnoses, lab and radiology orders, and prescriptions.  Based on technology standards, including the ASTM Continuity of Care Record (CCR), the application relies on the federated data model that Availity has employed from its inception. We took the standards-based, federated approach so that we can quickly deploy the Availity Care Profile to additional Payers and stakeholders. The federated data model also allows data access even in disaster situations such as hurricane evacuations.  With just Humana and BCBSF participation alone, this potentially can help nearly 5 million lives in Florida by providing information at the point of care.

Many other payer and vendor initiatives are greatly furthering HIT, including a Minnesota project which, like Availity, supports multiple Payers. Other Payers in Louisiana, Tennessee, and South Carolina, are working to support similarly innovative projects.  I believe that this body should take time to examine some of these projects in detail. Let’s look for successes and lessons learned and try to relate them to the National Health Information Network.

Functional Requirements Assessment

NHIN Functional Categories (fig. 1):
  • Audit and logging
  • Authentication
  • Authorization
  • Confidentiality
  • Credentialing
  • Data access and update
  • Data content
  • Data filtering
  • Data mapping/translation
  • Data quality/data integrity
  • Data rendering
  • Data retrieval (pull)
  • Data routing
  • Data transmission (push)
  • Data usage
  • Identity/information correlation
  • Persistent data storage
  • Record location
  • Transient data

The approximately 1,000 requirements submitted by the NHIN consortia represent a great milestone for healthcare and embody a collaborative national effort.  A successful HIT project requires all of NHIN’s core requirements categories (fig. 1).  The details of each specific requirement merit consideration and clarification for inclusion in any final system. A published standard interface for operating with the NHIN may be the most practical approach to provide edge-to-edge connectivity, as long as certain functional requirements are met.

The following outlines some specific thoughts and observations on NHIN requirements which are or should be considered for inclusion:

  • Though Recovery was specified, Backup was not identified and should be included.
  • Data versioning should be a requirement different from logging; an exact recreation of a record as it existed at a particular point in time may be needed for many reasons, including legal and medical reviews.
  • Standards-based entry-points to the NHIN should be specified.
  • Master provider and master person indexes, or at least minimally specified standards, could be extremely useful and prevent duplication and errors at edge and other downstream systems.
  • Partitioning and de-identification of data for research purposes has very different requirements for storage and data structures to support identifiable transactional data and should be specified.
  • Opt-out rather than opt-in should be supported for certain functions of the NHIN, such as for public health and treatment purposes.
  • While it is important to move quickly to define network requirements, we should keep in mind that we should not outpace the privacy policies.  Although the ONC has said that the functions of the NHIN are technical and that privacy will be handled separately. There is a potential that the technical requirements may come in conflict with some of the policy issues unless these efforts are aligned appropriately.  I would have to question how far to specify functional requirements without dealing with many of the existing policy issues in a coordinated fashion.
  • Self-service and stakeholder education and training, though perhaps not a requirement, should be built into the system.

Conclusion

Despite the urgency behind the timeline of deliverables, we should allow ample time for additional Payers to weigh in on the NHIN requirements. The Payers have demonstrated through many actions their value to HIT.  The industry as a whole is busily working on other important initiatives such as implementation to support the National Provider Identifier (NPI), planning for the ANSI X12 v.5010, ICD-10 support, and other state and local initiatives – all of which present significant challenges. We should also complete the rollout of HIPAA, a precursor to the current important effort.  We should not leave behind a string of unfinished business as we attempt to bring about new business.  I urge the committee to formally review some of the existing efforts and successful network models in the course of shaping the NHIN.

Further, government and commercial entities should be held accountable to the same standards; we should not have a different set of rules and requirements for the privileged and the unprivileged, or for those older than 65 and those younger than 65, or for large facilities and small doctors’ offices. The concept of a national health network should be just that – national and singular in purpose: to improve healthcare for everyone.

Finally, the government should continue to convene the appropriate parties and take the lead on pushing the NHIN forward. Additionally, there must also be a focus on enforcing and managing existing national regulations and policies.  The NCVHS should assist or lead in mapping all of the various healthcare entities and their current roles in defining NHIN direction and priority.

Previous NCVHS Testimony by Jon McBride (abbreviated; edited; June 2005)

The formation of an NHII could be based upon [some existing] and other proven methodologies.  The NHII will likely evolve from existing networks and technologies and will not be revolutionary or installed in some massive system implementation.  As such, the evolution of the NHII should be incremental in a phased and structured approach.  The NHII must be open, not only in standards but in participation by all industry constituents.  NHII governance must consider and allow every size and configuration of those who access the NHII to participate in a collaborative manner per guidelines.

Based on evidence from Availity’s administrative experience in Florida, we believe that with enough Payer market share in other regions, providers will modify behavior towards more efficient workflows.  Market share drives adoption and utilization since there is an efficiency to be gained in the provider workflow; more patients being seen will be covered.  Then utilization will drive down costs, and the repeating cycle of improving the workflow can continue.  However, the administrative transactions are only the beginning of what can be interconnected.  The electronic health record can be created by appropriately combining the Provider-based electronic medical records, the Payer-based health records, and aspects of the consumer-based personal health record.  This does not necessarily mean that the records are stored in a centralized location, but rather that centralized record pointers could provide locating and accessing services.

Given privacy and other concerns, some may question the need for a National Health Information Infrastructure.  To those people I’d like to introduce Amy as a real world example of how sharing health care information could have made a difference.  Amy was 27 and pregnant with her first child when she developed an aneurysm near her spleen.  Unfortunately, Amy’s care providers did not or were not able to collaborate and share information to create a complete picture of her medical history.  Later it was determined that even though Amy’s lab and other diagnostic information was available, it was not shared.  She visited the same ER on two separate occasions before her obstetrician ordered an emergency delivery.  Sadly, baby Madeleine did not survive her mother’s aneurysm.  Surgical intervention was not immediate because Amy’s doctors did not collaborate and share information.  It is possible that with more medical information shared at each point of care, Madeleine would have survived.

In the National Health Information Infrastructure, Patients should control their data, and their personal data should remain private except in certain well-known and appropriate circumstances, perhaps such as the one Amy endured.  In Amy’s case, the ER physicians may have reviewed her history via the NHII and perhaps would have had a better chance of quickly making the correct diagnosis of SAA.

Finally then I have six key recommendations and requests on the creation of the NHII for the committee as follows:

Uniformity of laws and leadership established

Uniform application of laws and government leadership should be applied to the NHII as well as other national healthcare initiatives.  There are too many federal, state, and local laws and departments that conflict. Without one clear governing body any initiatives at the national level will be extremely complex if not impossible to support.  In addition, HIPAA needs to be completed so that it can be used as a building block for the NHII.  As the primary foundation and standards backbone, it is clear that until and unless the industry can do the easy part (ubiquitous delivery of administrative transactions) it will never be able to meet the challenge of the more complex clinical delivery, especially as a voluntary effort.

A Privacy model should be created

A user model and associated use-cases must be created to clearly define who administrates, controls, authors, accesses and edits health records.  The NHII governing body should consider the creation or selection of one or more “trusted” entities which is only responsible for servicing the requests for data, but does not necessarily store the data.

Patient participation in the NHII should be voluntary for patients, but opting in requires patients to follow the standards established for the NHII.  Consumers should therefore be represented on NHII governance boards.

Unique identifiers should be utilized

While implementation of the HIPAA National Provider Identifier is proceeding, the remaining HIPAA identifiers such as health plan and individual identifiers are critical to helping evolve healthcare interoperability. Registries that securely manage the digital identities of patients, providers, payers, and medical staff are a core requirement to the secure operation and adoption of a NHII.  Without unique IDs, locating records and communication will remain inefficient and prone to error.

Controlled medical vocabulary utilized

The usage of standardized data elements and concept/context management should be mandated by the NHII governing body. This will allow the data to remain meaningful across network boundaries.

Interoperability standards created

Interoperability standards including privacy and security requirements must be created at the national level.  Wherever possible and appropriate, existing standards should be leveraged.  For instance, the Internet must be uniformly embraced by all public-facing government healthcare entities as well as the remaining public entities.

Availity believes that in order to achieve the goals as stated for the NHII in the timeframe allotted, a line must be drawn in the sand for the planned obsolescence of technology.  This should happen with the creation of the NHII but also be an ongoing strategy of the governing body or bodies of the NHII.  Sunset and maintenance rules must be created and adhered to, perhaps tying funding with established timeframes.  The staged approach outlined in this response gives time for entities to become current.  A continuous rolling 10 year plan should be published with achievable milestones.

Federated model of networks

DHHS should create a federated model of regional networks, RHIOs and otherwise, which when connected make up the NHII.  The regional networks could apply for connectivity with the NHII based on meeting minimum interoperability requirements.  This would allow many networks to evolve in parallel, but driving towards to same requirements.