Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Direct Project Security Overview

Direct Project Security Overview

Ratings: (0)|Views: 20 |Likes:
Published by Rich Elmore

More info:

Published by: Rich Elmore on Dec 10, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





Direct Project Security OverviewIntroduction:
The Direct Project is a set of specifications and service descriptions that, when implemented within astrong policy framework, enables simple,
point-to-point electronic messages between health careparticipants. The Direct Project security specifications provide a set of functional requirements that needto be implemented by the various Direct Project technologies and protocols in order to satisfy themessage handling policy recommendations of the HIT Policy Committee. In simple terms Direct Projectsecurity specifications are intended to say “
messages go where they are meant to, are not altered during transmission, and are not seen by anyone for whom they are not intended 
."In the same way that clinicians currently do not assume that it is safe to fax protected health informationto anyone with a fax number, or mail PHI to anyone with a post office address, Direct Project users shouldnot assume that it is safe to send messages to any Direct Project address. Direct Project users will needto establish real-world trust relationships with other Direct Project users on their own terms, but once theyhave established this real-world trust, they can be sure that a Direct Project network will securely deliver Direct Project messages to the trusted Direct Project user.As much as possible, the design of the Direct Project secure network will not force Direct Project users toadopt trust policies they might otherwise have rejected, or reject trust policies they might otherwise haveadopted. However, in order to build a secure platform for the transmission of PHI, Direct Project mustspecify acceptable protocols and technologies that Direct Project Implementers will use to communicatesecure network PHI messages over multiple possibly insecure, temporary inter-network interfaces for Direct Project users. For example, an insecure and compromised network node along the transmissionpath should not allow an attacker to modify information en route and alter the contents of the message,pretending to each legitimate participant to be the beginning and endpoint of the message. (Man in theMiddle attack).In some cases, these protocols and technologies will come with specific configuration options that willhave policy implications and may also present constraints that the Direct Project will force on the trustpolicies of its users.The Direct Project security protocols and technologies are an established reference point for currentlydefined and accepted "levels of assurance" within the trust framework that protect participants againstwell known existing network security threats regarding confidentiality, message integrity and interceptionas defined by NIST.The decision to use the ITU-T X.509v3 standards for public key infrastructure (PKI) based on IETFInternet certificate profiles (PKIX) will enable Direct Project users to create trust policies that enablenetwork encryption by the use of digital certificates, public and private keys and certificate authorities. Thecontent encapsulated in the messaging protocol is secured using the Secure/Multipurpose Internet MailExtensions (S/MIME) protocols.
If two Direct Project users trust each other in the real world, and can mutually agree on standards and  policies for handling PHI, they will be able to configure a Direct Project implementation to securely send messages containing PHI to each other.
The following is a set of assumptions that provide “context” for the Direct Project security specifications
Policy guidance
for the Direct Project will be provided by the NHIN Workgroup of the HIT Policy
Committee and will not be decided within the Direct Project itself. Organizations must choose thepolicies and practices that support their specific environments.
The Direct Project will be conformant with applicable federal and state laws, including but notlimited to security and privacy laws.
has made the determination that it is clinically and legally appropriate to send
to the
outside of the Direct Project Specifications.
The sender has fulfilled all legal, regulatory and policy requirements such as consent,authorization, accounting of disclosure, privacy notices, data use restrictions incumbenton the receiver, and the like prior to initiating transport.
The receiver of the information agrees to use the information for the purpose it was sent,not for other purposes.
The Sender has verified that the Reciever's address is correct. The Sender may obtain theReceiver's address via any number of appropriate means that are currently not specified by theDirect Project.
The Sender knows that the patient’s privacy preferences are being honored, because the patienthas consented to the sending of information to the Receiver for the specific purpose.
The Sender and Receiver have ensured that their HISP, if one is used, is authorized to act assuch and is authorized to handle PHI according to law and policy.
The Sender and Receiver 
do not require common or pre-negotiated patient identifiers
.Similar to the exchange of fax or paper documents, there is no expectation that a receivedmessage will be automatically matched to a patient or automatically filed in an EHR.
Goals of Direct Project Security specifications
The goals of the Direct Project security specifications are to achieve the following:
Enabling Message Handling Trust between Participants:
Verify the identity of a sender when information is received
Allow a Direct Project participant to specify other participants they trust to exchangeinformation
Provide non-repudiation service that assures the origin of information
Protecting the Information Exchanged:
Ensure information including PHI that is exchanged between Direct Project participants iskept confidential during transit.
Verify that information exchanged between Direct Project participants was not altered intransit.
Ensure that the technology choices enable different policy frameworks that might existacross various organizations.
Enabling Trust between Participants
In general terms an entity A (e.g., provider, hospital, patient) is said to trust another entity B only whenentity A believes that entity B behaves correctly. In other words Trust is an indication of confidence inanother to fulfill their promises and conform to some basic policies, ethical codes and adherence to thelaw.In the context of the Direct Project Security specifications, the parameters of trust are constrained to theGoals and Assumptions noted above. That is to say, given that the sender intends to send to the receiver (that is, trusts the receiver with respect to the trust issues in the Assumptions), the Direct Project Securityspecifications must ensure that the transaction conforms to the listed Goals.
Options For Enabling Trust
The Direct Project considered the following models for establishing messaging handling trust:1.Requiring individual or organization by organization determinations of messaging handing trust2.Requiring a single national floor set of messaging handling trust policies and a single nationalcertificate trust anchor 3.Allowing multiple overlapping circles of trust that are expected to converge over timeThe determination of the project was that the first option inherently does not scale, and the second optionwas not achievable in the timeframe of interest. We therefore chose a "Circles of Trust" model.
Background on Trust and X509 Certificates
This short primer of terms and concepts is important to understand the material that follows.A Certificate, in the context of this document, is a standard X509 Certificate. The Certificate has certainproperties that allow software to verify that the certificate was issued to the person or organization itpurports to, that it is in current standing, etc. Certificates are generally signed by a second certificate heldby a Certificate Authority, which establishes policies by which it will issue signed certificates. Byinspecting certificates, it is possible to prove that the Certificate was issued by the trusted CertificateAuthority, by inspecting a chain of certificates that root to a known Trust Anchor.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->