T1

Part III: External Dependencies and Open Issues

 

Security: Identity, Authentication, and Authorization

Trust is the essential glue enabling transfer of medical records, and distrust is a key defense against their misuse. All the hardware and software in the world will not provide adequate defenses against users who are allowed to have copies of records from your institution, if those users fail to protect the records properly, or if they actively misuse those records. It is thus critical to provide the holder of any given set of records enough information to enable them to answer the question "Do I trust the person making this request, and the institution they work for?"

In a large network, it will be impossible for every possible pair of sender and receiver of a request to know one another in advance. Particularly for remote queries, some sort of transitive trust will be necessary—"If I trust Institution A, I trust Institution A's employees." To make such a judgment, the requestor must be able to identify Institution A. In addition, the recipient of the request may need to review one or more queries, after the fact; it is essential, in this case, that the recipient be able to communicate quickly and effectively with the sender of the request. Being able to provide the time, date, entity identifier and person identifier will make such reviews considerably simpler, quicker and cheaper than merely having a transaction ID and requiring the counterparty to look it up in order to discover those identifiers on their own.

The federal HIPAA Privacy and Security Rules and applicable state laws provide the baseline for the Markle Connecting for Health Common Framework, although in some cases greater privacy protections and individual rights are recommended by the CFH Policy Subcommittee. In no instance does the Common Framework permit less protection of personal health information than those required by federal or state law; however, participation in an SNO is not a surrogate for determining whether a Participant is a HIPAA Covered Entity or is in compliance with the HIPAA regulations. Importantly, the Common Framework permits SNO Participants to establish and follow their own more protective data management, privacy and security policies and procedures. In addition, some customization may be necessary at the SNO and Participant level to ensure consistency and compliance with applicable state laws. In addition to HIPAA, Markle Connecting for Health recommends (but does not require) use of the use of the Common Criteria (ISO 15408) to analyze the security procedures of the SNO and of each participating entity.

In addition to HIPAA requirements, the transitive trust model requires reliable reporting of identity between parties participating in a record exchange, which in turn requires the issuing of identifiers for employees, and the maintenance of an authentication and authorization systems. Identifiers, authentication, and authorization are all required by HIPAA; what the Common Framework specifies are the reporting requirements necessary for transitive trust, plus the additional policies related to the transitive trust model, as laid out in “Authentication of System Users” in The Markle Connecting for Health Common Framework: Resources for Implementing Private and Secure Health Information Exchange.

These reporting requirements have three levels:

1. Reporting of SNO identity for inter-SNO communications
2. Reporting of entity identity (the HIPAA-mandated identity)
3. Reporting of the identity of the individual who authorized the query.²¹

Reporting of SNO Identity: As noted above, the Common Framework assumes a 'thin NHIN'; the NHIN is a network of networks, with no NHIN-wide services required other than basic connectivity. Both the data and the contextual functions required for inter-SNO transfers of data rely on capabilities provided by the aggregate group of SNOs. There are no "top-level" service providers required.²² In particular, we do not envision a single top-level identity service. Instead, individual health care entities will use the identifiers mandated under HIPAA, and the SNOs are required to provide an invariant name, expressed as a URI,²³ that is unique within the NHIN.²⁴ In practice, the URI will also be the URL of the SNO, thus using the Domain Name System as the basic guarantor of uniqueness.

Reporting of Entity Identity: In the case of inter-SNO communications, it is not enough to know which SNO has dispatched a message; the source entity (e.g., clinic, hospital, lab) must also be identified. In practice, this identifier will be the HIPAA-mandated National Provider Identifier (NPI),²⁵ plus a human-readable name of the institution.

Reporting of Individual Identity: In the case of inter-SNO communications, it is not enough to know which SNO and entity has dispatched a message; the requesting individual must also be identified. There is no person equivalent of the NPI under HIPAA; therefore some form of username or employee ID unique within the domain of a particular NPI must be reported, along with the human-readable name of the person making the request.

One possibility we explored but did not require was the additional reporting of the role of the requesting individual, e.g., clerk, admitting physician, etc. The reporting of such roles would be valuable in cases where the institution receiving the request wanted to limit responses to queriers with certain roles. However, the reporting of roles today is not universally adopted, and where it is in use, the definitions of the roles themselves are variable between institutions. If role-based access becomes important to the operation of the NHIN, considerable work will need to be done to standardize the expression of such roles.

As noted above, the reporting of these three identifiers—SNO, entity, person—serves two separate functions. The first is to allow judgment about whether to honor a given request for records, based on past expectations. The second is to simplify future audits should a particular transaction or set of transactions come under suspicion.

Based on the transmission of these identifiers, there are four conceptual levels of record exchange:

1. Within a single entity
2. Between entities in a SNO
3. Between entities in different SNOs
4. Requests from an entity not affiliated with a SNO

Within an Entity: Because this takes place beneath the level of SNO-wide traffic, these transactions are governed by the entity alone, and raise no SNO-wide identity reporting requirements.

Between Entities in a SNO: These transactions are governed by SNO-wide policies, but in all cases, the entity making a request, either to the RLS or to other entities, must report its NPI and the username and name of the person making the request. Because both sender and receiver are part of the same SNO, we presume that most of these requests will be routine, and will be subjected to a routine level of scrutiny.

Between Entities in Different SNOs: These transactions are not governed by any mutual contractual obligations, as entities in a single SNO are. Instead, they are governed by HIPAA and other national regulations and by the adoption of the Common Framework by each SNO. In all cases, the entity making the request must report the SNO of which it is a member, its NPI, and the username and name of the person making the request Because sender and receiver of a query are not part of the same SNO, we assume these queries will be relatively rare (in comparison to the volume of local traffic), and should be subjected to a higher level of scrutiny.

Requests from an entity not affiliated with a SNO:²⁶ The entity making a request to the SNO must report its NPI and the username and name of the person making the request. Because the sender is not part of the any SNO, we presume that most of all requests will be regarded as unusual, and will be subjected to the highest level of scrutiny.

Preventive Security: Encryption and Certificate Exchange

Preventive security encompasses defenses against outside attack, insider misuse of data, accidental loss or deletion, and so on. Outside the issues particular to identity, authentication and authorization, preventive security involves defending against access to data by unauthorized parties, misuse of data by authorized parties, unauthorized alteration of data, and accidental disclosure or deletion of data.

As noted above, the principal governing requirement for security is HIPAA, which describes administrative, physical, and technical safeguards required for securing data. In addition to HIPAA requirements and the policy requirements of Identity, Authentication, and Authorization, the Common Framework makes the following two specific security requirements:

• SSL/TLS Encryption: All traffic within and between SNOs will be encrypted using Secure Socket Layers 3.0 (SSL) or Transport Layer Security v 1.0 (TLS)
• Exchange of SNO Certificates Between Pairs of SNOs: Each ISB must have an SSL certificate, and any two ISBs planning to exchange data must each have the other's certificate. (This is implicit in the required asynchronous data exchange pattern between ISBs.)

Note that making each new SNO exchange credentials with all current SNOs will become problematic as the NHIN grows large.²⁷ We believe, however, that exchange of certificates between pairs of SNOs is the proper model for the NHIN in its early years, for two reasons: first, the number of SNOs (and therefore of ISBs needing certificates) will be small. Second, the trust of the participants in the system is a critical predictor of its success--a system that is technically feasible but unpalatable to real-world institutions will simply fail.

Taken together, we believe that requiring that each new entrant announce itself to the existing members, and requiring some formal per-pair handshake, will not be technically onerous for a network containing even a hundred separate SNOs (something that would occur in 2008 at the earliest), and would be beneficial in terms of assuring participants that the network contained no unknown actors. It will also provide a better environment for actually watching trust develop, thus providing experience valuable to the design of any later-stage certificate brokering system.²⁸

Two proposed but not currently adopted questions around encryption merit further examination: the encryption of data as stored on a disk, and the special issues involved in handling SSNs.

With regards to encryption, there is considerable work being done on on-disk encryption, where the contents of every file are stored in an encrypted format, and are only able to be decrypted when running in a trusted environment (e.g., with proper user authentication.) This means that should hardware containing information on patients be physically stolen (as happened frequently in recent years), the material contained would not be available to the holders of the physical disk without their also having access to the password or any other required forms of identification. Though such systems are not so widely adopted today that we feel comfortable mandating their use as part of the Common Framework, the increasing threat of identity theft, coupled with the increasingly large aggregated data sets being generated by the health care industry, means that continued attention needs to be paid to the possibility of including such a requirement.

The use of SSNs also creates a special set of problems. A patient's SSN can be a valuable tool in improving match accuracy, and is in use in many medical record systems. However, the SSN is also a weak and poorly designed authentication token, and a key input to identity theft and other forms of personal intrusion. As a result there are good reasons to both use and not use SSN, and while there are health information networks in operation today which require its use, there are others that forbid it.

It is clear that the rise in identity theft is going to lead to some regulation of the use of SSNs, whether industry-by-industry, state-by-state, or on a national level. As a result, any SNO implementing an RLS must take special care in deciding whether to use SSN as a match field, and, if so, must take special care in protecting the SSN, never returning the SSN when a match is made, even if an SSN was submitted for a patient, so as to prevent fishing. Though use of the last 4 digits of the SSN is on the rise, this is simply re-creating the original difficulty. An attacker who has the last 4 digits of a full SSN, but only needs to report those 4 digits to gain access to material, has the same advantage as an attacker who has the full SSN when the full SSN is required.²⁹

Reactive Security: Auditing and Logging

In addition to preventive security, procedures need to be in place for detection of security breaches and other misuse of data. While detection is an important part of securing any system, it is especially vital in the health care system. Health is not money, and health care is not banking—where many industries can tolerate a relatively high degree of inconvenience in their user transactions, health care cannot. Waiting a couple of days to get a new ATM card is an inconvenience; waiting a couple of hours to get data on a patient's allergies can be fatal.

Because of this, there is a presumption towards disclosure in cases where a physician reports a critical need for the data, a presumption reflected in, for example, Break the Glass modes of access. In addition to preventive measures against accidental or intentional misuse of data, maintaining a good log of the use of the system, and periodically auditing that log to look for negative events or patterns is critical.

While preventative security requires a high degree of standardization, so that everyone can, for example, use the same encryption scheme, reactive security requires less standardization. Instead, the ability to detect and react to events after the fact requires policies that set a minimum level of technical requirements, which requirements can be met in ways most compatible with the rest of a particular SNO's technological choices.

For the first phase of this work, we have specified two sets of policies regarding reactive security:

1. Logging and Auditing
2. Managing breaches

Logging and Auditing: It is essential that information about all relevant transactions that touch clinical data be logged, so that the system can be periodically audited, and so that, should there be misuse of data, the events leading up to that misuse can be examined, and it is essential that these logs be immutable, so that once written, they cannot be edited or deleted (in order to prevent sophisticated attackers from removing traces of their work.) The other essential constraint is that such logs not contain the full record being transmitted, so that the logs themselves do not become an alternate target for attackers looking for clinical information. The Common Framework policies regarding logging and auditing are contained in Markle Connecting for Health, “Auditing Access to and Use of a Health Information Exchange.”

Managing Breaches: In addition to preventing breaches of identifying or clinical data where possible, every SNO needs a set of policies for reacting to such breaches where they occur, and these policies will necessarily differ between cases such as accidental disclosure, suffering from a successful external attack, or having an authorized employee misuse data. The Common Framework policies regarding breaches of information are contained in “Breaches of Confidential Health Information” in The Markle Connecting for Health Common Framework: Resources for Implementing Private and Secure Health Information Exchange.

External Standards

Though the Markle Connecting for Health prototype is obviously standards-based, rather than assuming homogeneity of underlying technology, we are principally a consumer of standards rather than a producer of them. Much of the prototype work was an attempt to avoid setting standards where possible, either by designing a system tolerant of multiple standards (as with the separation of clinical message contents from their delivery envelope) or by taking advantage of existing standards.

Many of the technical issues requiring standardization were solved by adopting Web Services standards; there are two cases where that has not been sufficient:³⁰

1. Coordinating asynchronous communication between SNOs
2. Making assertions about the individuals responsible for a request

In the case of coordinating asynchronous communications, the obvious standard to use is WS-Addressing.³¹ In the case of assertions about the identity of requesting individuals, the obvious standard to use is SAML 2.0.³² In both cases, the standard as proposed has not been widely adopted, nor has it been implemented in many key Web Services platforms. WS-Addressing is also not yet an official standard, despite two years of work.

Our solution in both cases has been to narrowly and provisionally adopt those parts of the two standards most compatible with our goals, but to make it clear in the documentation and in the headers of the messages that these are provisional standards and may change.

Beyond the issues having to do with Web Services generally, there are two additional sources of standards that any working system will require. The first, of course, is clinical standards. Though the model we have designed for requesting and receiving data is insensitive to what data is being carried—lab results, medication lists, radiology reports, etc.—the system as a whole requires good clinical standards, in order to be able to support increasing automation of record handling and exchange, decision support, and other clinical functions. Our goal here has been to design a system that is insensitive to what the actual standards are, so that when and as they arise, they can be used in this network model without significant re-engineering. It is our hope that the increased attention to health care IT will result in improved definition and adoption of clinical standards.

In the multi-region test of the proposed Markle Connecting for Health architecture, we tested the exchange of both medication history and laboratory results. For the medication history standard, we adopted an XML serialization of the NCPDP standard, covered in the “Medication History Standards.” The expression of the lab results were taken from the ELINCS standard, though our work revealed some areas where the proposed standards may need to be modified to cover a larger potential range of uses. The laboratory standards we used are documented in the “Laboratory Results Standards.”

Medical history and laboratory results are essential parts of any working medical network, but they cover only a small fraction of the currently available data types, and as the health care industry continues to embrace IT, the number of data types will grow. As a result, Markle Connecting for Health will continue to look to external designers and validators to guide our adoption of clinical standards.³³

The other required source of external standards is naming. Naming, which is to say the creation and assignment of identifiers, is in many ways more complex than standardization, since the two key requirements of naming—uniqueness³⁴ and permanence³⁵—generally require sophisticated schemes for generating and maintaining those identifiers. The key concept in naming is the namespace; any given identifier needs to be unique in a particular namespace, which is the conceptual superset of all such identifiers. Any NHIN will require a namespace for all SNOs; each SNO will need to manage the namespace of its member entities; and each entity will need to manage the namespace of its employees and other individuals who may have access to the records IT system.

In all these cases, we have used existing namespaces where possible. For uniqueness of SNOs, we have relied on the fact that each SNO must register a URL, and that all URLs are globally unique; for entity naming, we have assumed the use of the HIPAA-mandated NPI; and for person identification within an entity, we have assumed that the HIPAA-required security measures will guarantee the presence of unique identifiers for employees and others with system access.

We believe that these choices will take care of the basics of naming participant institutions and individuals for the early NHIN. However, there are a number of ways in which naming could become more complex over time. In particular, if our architecture succeeds, there will be a number of third parties who are not themselves covered entities under HIPAA, and will therefore lack an NPI, but will nevertheless need identification in the context of the NHIN (e.g., service providers for translation or off-site storage of clinical records.) Some way of assigning names compatible with the NPI may need to be designed. Our current solutions to naming should therefore be regarded as provisional, with future examination of additional requirements for naming being part of later phases of work.

Open Issues

The Common Framework is a work in progress; we have attempted to provide the starting technical and policy framework necessary for creating an interoperable nationwide health information network. Given the size of the task, however, such a framework necessarily leaves open technical issues, which will need to be addressed in subsequent iterations.

What follows is a brief list of such issues. Note that the list only addresses concerns that are largely or solely technological; issues such as financial structures or incentives, while vital, are out of the scope of this document.

Subscription to Data Sources

The basic transactions modeled here are request/response—ask for and receive a record. There are obviously cases where an institution wants to subscribe to a particular data source, and receive updates when the data at that source is updated or modified.

As we have seen from the growth of http-based subscription models in other domains (e.g., the Atom syndication format³⁶), it is possible to model subscription models by using timed or triggered updates from the data host, or timed or triggered requests from the requestor. Working out which of these patterns are most appropriate in what situations is still to be done.

Aggregated Record Access

The basic transactions modeled here are requests for one individual's records. Use cases such as data quality and biosurveillance require the delivery of aggregated data from the source entities. Current programs have a mix of direct access (e.g., CDC's Biosense program) and hierarchical access (e.g., reports to State entities who in turn report to CDC.) While the interfaces required by the Common Framework provide a method for both direct and hierarchical aggregation of records, and that such aggregation does not require and should not use the RLS, it is not clear what role, if any, the SNO should play in providing or managing those interfaces, including especially whether the ISB should provide an interface for aggregate queries, or some other SNO-wide interface should be provided, or no such interface should be provided above the level of the individual entities.

This is an especially complex and important set of questions, as it involves balancing improved measurement and observation of the health care system with risks to patient privacy, and because many of the entities with the right to access aggregate data are not covered by HIPPA, making the regulatory framework for assumptions about privacy and security more complex.

Federated Trust

Though we have adopted a transitive trust model (to trust Institution A means to trust their employees, and to trust that A manages identifiers, authentication, and authorization well), the growth of the NHIN will put that system under some strain. There is considerable work being done on federated trust models, where information and assertions about authentication and authorization are more fully described and communicated between parties. Future work on the NHIN will need to consider this work, and, if it proves viable, figure out how to implement it within the NHIN itself.

Patient Authentication and Access

One core goal of the Common Framework is to make it simpler for patients to gain access to their own records. We believe that the network as designed lowers the cost and raises the effectiveness of providing access to patient data; however, many hurdles still exist before there is widespread use of patient-facing access points to clinical data. A key hurdle is authentication. There is no obvious way to allow a patient to authenticate their own identity outside the context of a relationship with existing care providers; the hurdle this poses could potentially be overcome if there were a way to authenticate patients directly. Examination of possible direct patient authentication solutions may be a valuable area of inquiry. These issues are also addressed in “Patients Access to Their Own Health Information,” part of The Markle Connecting for Health Common Framework: Resources for Implementing Private and Secure Health Information Exchange.

Third Party Participation

There is currently no mechanism for allowing entities not covered under HIPPA direct access to the NHIN. Possible rationales for allowing such access would be third-party data cleaning or warehousing solutions; third party format translations, and secure repositories acting on behalf of the patient. Presently, any third party connected to the system must be a sub-contractor to a single entity or SNO, so that the legal liability remains with that entity. There may need to be a framework for allowing third party participation in a way that increases the flexibility of the network without decreasing security.

Multi-SNO Patient Lookup

There is no national interface for search in the system as envisioned. This is to preserve the partitioning of clinical data, so as to prevent major privacy spills. However, such a system also requires the requesting party to have enough information to know which remote SNO to query. As the number of participating SNOs grows large, this requirement could become problematic, but a single national interface for lookup could be a significant risk to privacy, by making fishing easier. As the network grows, understanding how to balance effectiveness with privacy protection in multi-SNO lookups will be critical.

National Services

The NHIN as currently envisioned has no national services separate from the ISB interfaces. With the spread of National Provider Identifier numbers, increased complexity of multi-SNO lookups, data translation requirements, etc, there may be some services best provisioned for the NHIN as a whole. Some mechanism for providing these services, probably by providing for modified ISB-style interfaces, will need to be designed so that these services, should they be required, are broadly interoperable from launch.

Response Time and SLAs

The Common Framework Technical prototype was designed to demonstrate interoperability among diverse actors. Significant optimizations remain to be performed in order to reduce the systems response time, and profiling will be required before Service-Level Agreements can be implemented (agreements that promise, for example, sub-5 second response time for standard queries.)

Metadata and Request Filtering

The state of medical data is currently quite variable, and there is no obvious way to suddenly and dramatically increase the quality of that data, either by providing it in more structured formats or by increasing the accuracy of the fields. However, as the number of data sources grows, clinicians could find themselves moving from a world of little to no data to seeing a flood of data. Some way of pre-filtering the incoming data will be required, ideally by being able to specify relevant data types (e.g., medication history, radiology, etc), but such filtering will require relatively clean and well-formatted metadata, and must respect policy constraints such as the separation of demographic from clinical data in the system. Understanding how to improve metadata, how to integrate it in a way that respects policy constraints, and how to extract value from semi-structured data as it currently exists will be vital to future work on the NHIN.

Stemming Proliferation of Duplicate Records

As we move to a world where more data is shared, duplicate records will proliferate. Hospital A receives and stores patient data from Lab B; later, when Clinic C requests data on that patient from both A and B, C will get two copies of the lab data. Some method of identifying and rationalizing duplicate data will need to be provided as the number of data sources and frequency of requests increases.