T1

Notes

1. Another common acronym for this type of organization is RHIO, which stands for Regional Health Care Information Organization. Though a SNO is conceptually similar to a RHIO, we use SNO because there are a number of national or supra-regional institutions such as the VHA, the CDC, health plans, pharmacy chains, and State regulatory agencies that are not defined by regional boundaries and that need to connect with entities in more than one geographic region. Unlike the regional focus of RHIO, a SNO is any group of data-sharing entities that agree to be bound contractually by technical and policy standards, regardless of actual geographic proximity.
2. Though we chose the word entity for its obvious parallel to the definition of 'covered entities' under HIPAA, there may be entities in a SNO that are not covered under HIPAA, such as data centers. These entities nevertheless need to comply with the Common Framework, or the entities that employ them need to agree to take on the responsibility of ensuring that compliance.
3. This is sometimes called the 'thin NHIN' model; it assumes a high degree of autonomy and control remains with today's health care information providers, and that no significant new national technical organization is required to 'operate' the NHIN as a whole. Instead, the existence of policies, standards, and connectivity allows the secure sharing of data with authorized persons nationwide without staffing new sites of central management or control.
4. The application that does the querying could be as simple as a secure web browser, or as complex as an integrated medical record system.
5. The decision about which of the records to request can be done either with human intervention or by an automated process.
6. It is critical, in fact, that any such aggregation service not cache the clinical data it is handling, so that it doesn’t become a significantly attractive hacking target.
7. Uniform response to intra-SNO requests for records are not required, nor are they forbidden. An individual SNO can, as a matter of policy, mandate such uniform access if it decides to do so. This requirement would override the ability of individual institutions to differ in data access policies.
8. This design pattern is known as the End to End principle (http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf).
9. There is nothing to prevent a group of SNOs, for example all SNOs in a given region or state, to develop independently their own inter-SNO index of patients.
10. It is possible to imagine an entity in a SNO requesting data from an outside entity unaffiliated with a SNO, the reverse of this transaction, but such a transaction would be completely ad hoc, as it involves a data-holding entity ungoverned by the Common Framework.
11. http://www.cancerdiagnosis.nci.nih.gov/.
12. Note that patients may in some cases be considered 'members' of a SNO, if they access their data from interfaces supported by the SNO. These patients are not covered by Common Framework requirements, as they enjoy a different degree of control over their data than incorporated entities do.
13. During the proof-of-concept testing in 2005, interoperating systems used a mix of platforms and tools, including the .Net framework (1.1) running on Windows XP servers and Java application and Web Services servers (Tomcat and Axis) running on Linux.
14. Note that these requirements don't foreclose optional support of additional data types or interaction patterns. They are simply minimum requirements, so that new entities joining a SNO have an obvious and small set of required standards to support, and so that an entity that wants to belong to more than one SNO is not caught by requirements to support multiple standards.
15. Because identity, authentication, and authorization services are already required by HIPAA, we treat them separately below
16. Note that there may be records held by institutions within the SNO that exist but are not listed in the RLS, because of some institutional or patient preference for keeping them unlisted. This is an option for entities in the SNO unless SNO-wide policy overrules such a thing, and is not itself overruled by another regulation such as a state-wide requirement.
17. This second format assumes that the querier has some method of obtaining such a record number, either because the patient has provided it or because the querier has used it in the past for the same patient.
18. One caveat is SSN; if a system uses SSN for matches, the RLS should never return the SSN, even if the requestor supplied it, because of the sensitivity of that particular field.
19. New York State Identification and Intelligence System (http://www.nist.gov/dads/HTML/nysiis.html).
20. For a fuller accounting of Markle Connecting for Health's view of national health identifiers, see the Markle Connecting for Health 2005 report “Linking Health Care Information: Proposed Methods For Improving Care And Protecting Privacy,” pp. 11-15 (http://www.markle.org/publications/863-linking-health-care-information-proposed-methods-improving-care-and-protecting-priv).
21. In the case of automatic queries, the individual identity should be that of the person most directly responsible for dispatching the query, e.g., the clerk who oversees the system doing the querying. This is because the goal of the identity reporting is to aid subsequent audits.
22. We do envision the possibility of third party providers offering network access to their services, but these services exist at the same conceptual layer as the SNOs themselves.
23. Uniform Resource Identifier, which is effectively a location-insensitive version of a URL. For more on URIs and URLs, see http://www.w3.org/TR/uri-clarification/.
24. Though guaranteed uniqueness presents interesting theoretical problems in large systems, it does not in small systems. Therefore, while we hope that someday the NHIN has enough participants to merit inclusion of one or more health care-specific schemes for mandated uniqueness, along the lines of the Internet's Domain Name System (DNS), we do not envision a system that large for 3 years at the earliest.
25. Because the NPI suffers from the same drawbacks as the SSN—it is a public identifier with no accompanying authentication method—the presentation of a HIPAA number must never be regarded as authenticating the requesting institution.
26. It is possible to imagine an entity in a SNO making an outbound request to an unaffiliated entity, but as the recipient would not have implemented the Common Framework, the question of standards and policies for such a transaction would be ad hoc.
27. The Internet's Domain Name System (DNS), which we have studied as an example of a distributed system, grew out of the failure of such addressing schemes as the number of Internet nodes approached 1,000.
28. Another reason for caution in this domain is that while generic federated identity systems have been under development for much of the last decade, no such systems have achieved widespread use, and most current multi-party identity systems are industry- or institution-specific. Because of the unique responsibilities of health care providers as stewards of data whose misuse can be both catastrophic and irremediable for the patient, we have generally erred on the side of accepting less efficiency in return for more safety.
29. We also examined the use of one-way hashes as ways of allowing the RLS to use SSN-like accuracy in matching records, without ever holding any patient's actual SSN. While the work on this method is impressive, the implementation overhead is large both in terms of original cost and in negative effect on speed of individual queries. Like mandated on-disk encryption, we believe this is an area that merits further study.
30. There may be only two such cases because we have intentionally restricted our work to a well-defined set of problems. As the work continues, we expect to encounter more of the issues that arise when a standard is required, and there are one or more unfinished or impractical candidates to choose from.
31. http://www.w3.org/Submission/ws-addressing/.
32. http://www.oasis-open.org/committees/security/.
33. Note that this does not presuppose the involvement of formal standards development organizations (SDOs) in all cases; there are many examples of proposed standards that failed to get any adoption in the field, as well as examples of de facto standards that were only blessed by standards bodies after the fact, if at all. Given Markle Connecting for Health's focus on practical implementation and incremental development, we have tended to prefer de facto but unannointed standards to proposed but unadopted ones.
34. Uniqueness in this case is contextual. A URL only needs to be disambiguated from another URL, and email address from another email address, and so on.
35. Permanence is the characteristic of an identifier being unique in time. A permanent identifier, once issued, is never re-used to refer to anything else. A permanent identifier may stop being valid, when the thing it points to may disappear, but it will never point to anything else.
36. http://www.atomenabled.org/developers/syndication/.

Markle Connecting for Health thanks Clay Shirky, Chair, Technical Subcommittee, and Adjunct Professor, New York University Graduate Interactive Telecommunications Program, for drafting this paper.