Security architecture design process for health information exchanges (HIEs)
Matthew Scholl, Kevin Stine, Kenneth Weicong Lin, Daniel Steinberg · 2010
Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. Executive SummaryProtecting electronic patient health information is crucial to developing systems and structures that support the exchange of that information among healthcare providers, payers, and consumers using Health Information Exchanges (HIEs). 1 As noted in the Summary of the Nationwide Health Information Network (NHIN) report from the Office of the National Coordinator, "An important core competency of the HIE is to maintain a trusting and supportive relationship with the organizations that provide data to, and retrieve data from, one another through the HIE.The trust requirement is met through a combination of legal agreements, advocacy, and technology for ensuring meaningful information interchange in a way that has appropriate protections." 2The purpose of this publication is to provide a systematic approach to designing a technical security architecture for the exchange of health information that leverages common government and commercial practices and that demonstrates how these practices can be applied to the development of HIEs.This publication assists organizations in ensuring that data protection is adequately addressed throughout the system development life cycle, and that these data protection mechanisms are applied when the organization develops technologies that enable the exchange of health information.This operating model will help organizations that are implementing HIEs to:• Understand major regulations and business drivers;• Identify cross-organizational enabling services;• Define supporting business processes (for each service);• Develop notional architectures (as a blueprint to support services, processes, and the selection of technical solutions); and• Select technical solutions.2.0 8 The HIPAA Security Rule, 68 Fed.Reg.34, 8355.9 Standards for Privacy of Individually Identifiable Health Information, Final Rule ("The HIPAA Privacy Rule"), 65 Fed.Reg.250, 82462 (incorporated at 45 CFR Parts 160, 162, and 164).10 68 Fed.Reg.34, 8334 (incorporated at 45 CFR Parts 160, 162, and 164).