Wanted: a business model for information exchange

The HITECH portion of the American Recovery and Reinvestment Act included lots of financial incentives for health care providers to adopt and “meaningfully” use health information technology such as electronic health record systems. It also directed the Office of the National Coordinator for Health IT within HHS to perform a variety of activities “consistent with the development of a nationwide health information technology infrastructure that allows for the electronic use and exchange of information.” (P.L. 111-5, §3001(b)). What is not explicit in the HITECH Act is what funding, if any, should be specifically allocated to establishing or operating such an infrastructure. There seems to be an assumption that at some point one or more private sector organizations will either directly provide infrastructure services used for health information exchange or manage the information flow among health information exchange participants, either under contract on behalf of the federal government or on their own. However, to expect the private sector to step in and provide infrastructure services, even using the Internet, there needs to be a revenue source or other business opportunity to attract service providers. This is hardly an insightful observation, but the lack of attention to incentives for infrastructure, security, monitoring, and other necessary services seems destined to slow health IT adoption.

As noted last week by Dr. John Loonsk — currently chief medical officer for contractor CGI Federal but formerly a member of the management team within the Office of the National Coordinator responsible for developing the Nationwide Health Information Network (NHIN) — in the absence of federal-level coordination of infrastructure development efforts, and, Dr. Loonsk argues, stimulus funding dedicated to those efforts, health information exchange capabilities may be provided separately and incompatibly at regional or state levels, frustrating the widespread interoperability goals the NHIN is intended to achieve. If health IT will really produce anything like the cost savings so often projected, some portion of any savings to be realized could be allocated to paying health information exchange participants, on either a transactional or per-record basis. In theory the amount of money involved could be quite small and still provide the necessary financial incentive to potential service providers. In the early 1990s When the U.S. automated teller networks first made their regional networks interoperable, each ATM transaction generated just 12 cents for the parties involved — 7¢ to the acquirer, 5¢ to the issuer — but that provided enough incentive to achieve widespread interoperability within a couple of years. Not insignificantly, the process of linking regional networks was greatly facilitated by the fact that virtually all of them were using the same technologies, including computing platforms and telecommunications protocols.

Having a financial incentive built into health information exchange could simultaneously foster greater adoption and help participating entities maintain compliance with various privacy and security requirements. If, for instance, the holder of a health record was entitled to a payment each time the record was accessed or information from it was sent to a requester, not only would record holders have an incentive to make the data available for exchange, but by logging each transaction in order to generate billing records, the record holder would also produce an accounting of disclosures as required under HIPAA.

To date, entities exchanging health information purportedly as part of the NHIN are not actually under any sort of monitoring or oversight by any NHIN governing authority, although the provision for such monitoring is included in the Data Use and Reciprocal Support Agreement that has been executed by MedVirgina, the Social Security Administration, and other early adopters of the NHIN technical solution components. Without such monitoring place, the NHIN in “limited production” as it now stands is simply pairs of exchange partners using an agreed-upon messaging format to send information over the Internet between instances of gateway application software that can send and receive those messages. Without a set of services layered on top of that public infrastructure, there will be neither the framework within which new service providers can make their capabilities available nor any means to establish the sort of quality of service and other performance levels commonly associated with purpose-specific network infrastructure today.

New health data breach notification rules go into effect

The rules contained in the HITECH Act requiring HIPAA-covered entities, business associates, and non-covered entities that provide personal health records (PHR) to disclose breaches of personal health information go into effect on September 23. The draft rules were published as interim guidelines in April, and the final version of the disclosure rules was published by HHS last month, with a corresponding rule covering PHR breaches published by the FTC at the same time. The rules will greatly expand the scope of organizations subject to breach disclosure requirements, although HHS did include a provision in the rules that unauthorized disclosure is not considered a breach under the regulations unless it causes or has the potential to cause significant harm to individuals whose data is disclosed. This exception is troubling to privacy and consumer advocates because it introduces a measure of subjectivity into what seemed to be an objective requirement (the harm provision was not part of the language in the HITECH Act), and it raises the possibility that organizations who suffer disclosures will understate the risk in order to avoid having to comply with the rules.

The rules still apply only to unsecured data — in HITECH legalese that means data that is not rendered “unreadable, unusable, or indecipherable” — so tomorrow also serves as an unofficial deadline by which organizations holding personal health information should implement encryption for their data at rest as well as data in transit. It remains to be seen whether major PHR vendors like Google Health and Microsoft Healthvault will add record encryption to the set of security and privacy protection measures they already have in place.

New proposed flow and intermediary roles for health data

Word coming out of the Health IT Standards Committee last week is that the panel has approved a framework for the transmission of patient data from providers to federal government agencies such as the Centers for Medicare and Medicaid services. The proposal came out of a progress report from the committee’s Clinical Quality Workgroup presented on September 15. The process for gathering and reporting the quality measures (as shown in the image at right) involves the use of two intermediaries between sender and receiver: the first would be a health information exchange or other data collection and aggregation service provider, while the second would be responsible for processing and reporting quality data from the health records being transmitted.

While the usual emphasis in this space is on security and privacy issues (several of which are relevant to a multi-entity transaction flow such as this one), just as noteworthy for this proposal is the possibility that it represents a business opportunity for participation in health information exchange efforts. One of the big unanswered questions in the health IT debate is what incentive private-sector players will have to facilitate, enable, or provide health information exchange services. To date, no one has proposed any sort of revenue generation model whereby service providers or data owners might be paid on either a per-transaction or per-record basis for responding to health data requests, yet the overall success of health information exchange depends on high levels of participation. The incentives included in the Recovery Act are designed to offset the costs of acquiring and implementing electronic health record systems, and are therefore targeted at health care providers. What is less clear is how health information exchanges, such as the ones envisioned to link large numbers of providers together using the NHIN or other infrastructure, will be compensated for their services. Some of the key technical roles being proposed for health information exchange seem to present a need for service providers to fulfill the roles. The health data quality intermediary featured in the HITSC proposal is one such opportunity; others might include local or regional health information exchange operators that offer connectivity to health IT infrastructure, software-as-a-service or cloud-based EHR solutions offering access to small physician practices or other health care providers unwilling to implement their own local EHR systems, and credential issuers (in the form of security token services) that would provide identification and authentication claims to data requesters in a federated authentication model.

Contributions to CSI Alert on Claims-Based Identity Management

The September issue of the Computer Security Institute Alert focuses on claims-based identity, and includes articles by CSI Alert Editor Sara Peters, policy expert Charles Cresson Wood, “Privacy Professor” Rebecca Herold, and SecurityArchitecture.com’s own Stephen Gantz. Claims-based approaches to identity management have received increasing levels of attention in the past couple of years, helped in part by Microsoft’s incorporation of a claims-based architecture in .Net 3.0, and fueled in particular by needs to balance privacy protections and minimalization of information disclosure with identification, authentication, and authorization in widely distributed or federated environments.

Health information exchange outside HIPAA

The Social Security Administration (SSA) has essentially been the first government adopter of the Nationwide Health Information Network (NHIN), going into production early this year with an information exchange with MedVa to receive medical records in support of disability claims. By all accounts, this first effort has been an unqualified success, reducing the time to retrieve and process the needed documentation from weeks or months to under an hour. SSA is now in the process of looking for ways to expand the number of medical record sources it can access to do benefit eligibility determinations more efficiently. According to an announcement last week, one option under serious consideration is tying into Microsoft’s HealthVault personal health record system. There are a lot of interesting aspects to this potential relationship, but one aspect that may be a bit unusual in the overall health information exchange context is that prospect of having an end-to-end exchange of electronic medical records completely outside the coverage of HIPAA. Neither Microsoft nor SSA is a covered entity under HIPAA, and there’s even some debate whether PHR vendors like Microsoft, Google, myPHR, and others fall under the category of “business asssociate” either. An information exchange between Microsoft and SSA would fall outside the scope of HIPAA and the Privacy Act, and would only be subject to the breach disclosure requirements in the Health Information Technology for Economic and Clinical Health (HITECH) Act. If nothing else, the evolution of health IT in such a direction largely outside the existing regulatory and legal framework governing personal health information only highlights the need to address patient privacy protections explicitly, rather than as an adjunct to laws focused primarily on organizational entities.