Pennsylvania eHealth Collaborative
HISP Certification Requirements
VERSION LOG
Version Number
Description of Change
Name of Author
Date Published
1.00
Initial Draft
PA eHC Team
March 22, 2012
1.10
Editorial Review
Jenna Barnaby
April 3, 2012
1.20
Failed Password Changes
Jenna Barnaby
April 6, 2012
1.30
Integrated Reporting Information
Jenna Barnaby
April 20, 2012
1.40
Integrated Exit Strategy Information
Jenna Barnaby
April 23, 2012
2.0
Revision from participant feedback to
Jenna Barnaby
May 3, 2012
Jenna Barnaby
May 7, 2012
Jenna Barnaby
May 11, 2012
Jenna Barnaby
July 23, 2012
produce initial final version
2.1
Adding language regarding timelines
for PA eHC root certificates and
formatting cleanup
2.2
Changed DIRECT Trust Certificate
Policy Attestation Form to reflect that
PA eHC has not stood up a CA yet
2.3
Added language calling out the need
to MDN
Please note that this is a living document that will change as the DIRECT project
and health information exchange changes. PA eHC retains the right to alter this
document at any time. Steps will be taken to communicate changes to certified
HISPs.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 1 of 69
May 2012
TABLE OF CONTENTS
1.
Introduction .............................................................................................................................. 5
2.
Description of the Functions and Services ................................................................... 6
2.1.
HIPAA Compliance Attestation ...................................................................................... 6
2.1.1.
The HIPAA Security Rule ............................................................................................. 6
2.1.2.
Precertification preparation ........................................................................................ 7
2.1.3.
The NIST HSR Toolkit ................................................................................................... 7
2.1.4.
Context for Use ............................................................................................................... 8
2.1.5.
Certification Requirements ......................................................................................... 8
2.1.6.
Post-conditions .............................................................................................................. 10
2.1.7.
Flowchart Overview ..................................................................................................... 10
2.2.
DIRECT Trust Certificate Policy Attestation............................................................ 11
2.2.1.
PA eHCO Issued Certificates .................................................................................... 12
2.2.2.
DIRECT Trust Community ......................................................................................... 12
2.2.3.
Precertification preparation ...................................................................................... 13
2.2.4.
Federal Bridge and DirectTrust.org Certificate Policies ................................. 13
2.2.5.
Context for Use ............................................................................................................. 14
2.2.6.
Certification Requirements ....................................................................................... 14
2.2.7.
Post-conditions .............................................................................................................. 15
2.2.8.
Flowchart Overview ..................................................................................................... 15
2.3.
Digital Certificates ............................................................................................................ 15
2.4.
HISP to HISP Communication...................................................................................... 17
2.5.
Provisioning of DIRECT Email ...................................................................................... 18
2.5.1.
New User Registration ................................................................................................ 19
2.5.2.
User Logon ...................................................................................................................... 20
2.5.3.
Change Password Notification ................................................................................. 22
2.5.4.
Password Change ......................................................................................................... 23
2.5.5.
Forgot UID....................................................................................................................... 23
2.5.6.
Forgot Password ........................................................................................................... 23
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 2 of 69
May 2012
2.5.7.
Request Answers Reset.............................................................................................. 23
2.5.8.
User Request Unlock ................................................................................................... 24
2.5.9.
Validate Healthcare Provider.................................................................................... 24
2.5.10.
Additional security functions .................................................................................... 25
2.6.
Support for DIRECT ......................................................................................................... 26
2.6.1.1.
Email clients with and without native S/MIME .............................................. 28
2.6.1.1.1.
Email without native S/MIME............................................................................... 28
2.6.1.1.2.
Email client using native S/MIME ....................................................................... 29
2.6.1.2.
Web portal or RESTful API .................................................................................... 29
2.6.1.2.1.
Additional Support Requirements for Web Mail ............................................ 30
2.6.1.3.
EHR with integrated S/MIME functionality...................................................... 30
2.6.2.
DIRECT Project to/from XDR (e.g., Nationwide Health Information
Network Exchange) ......................................................................................................................... 30
2.6.3.
2.7.
White Pages Lookup .................................................................................................... 31
DIRECT mail and white space...................................................................................... 32
2.8.
C32 and C62 – Send, Receive, Attach & Download – Structured and
Unstructured Documents .............................................................................................................. 34
2.8.1.
The Structured C32 Document ............................................................................... 35
2.8.2.
The Unstructured C62 Document........................................................................... 35
2.8.3.
HISP Requirements...................................................................................................... 36
2.9.
Sending & Receiving DIRECT Emails ........................................................................ 36
2.9.1.
Sending and Receiving DIRECT Emails – Requirements ............................... 36
2.9.2.
Additional Support Requirements .......................................................................... 37
2.10.
Provide Access to Shared White Pages .................................................................... 39
2.11.
Translation and Transformation.................................................................................. 40
2.12.
HISP Business Continuity and Exit Strategy Requirements............................. 41
2.13.
Audit Logging ..................................................................................................................... 42
2.13.1.
Audit Logging ................................................................................................................. 42
2.13.2.
Logging and Audit Controls under HIPAA ........................................................... 43
2.13.3.
Audit and Accountability Checklist......................................................................... 43
2.13.4.
Categories of Logging and Audit Controls .......................................................... 44
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 3 of 69
May 2012
2.13.5.
Violations and Enforcement...................................................................................... 45
2.13.6.
Sanctions ......................................................................................................................... 46
2.13.7.
Definitions ....................................................................................................................... 46
3.
HISP Certification Program Reporting .......................................................................... 47
3.1
HISP Service Categories .................................................................................................... 47
3.2
Certification Process Feedback and Reporting .......................................................... 47
3.2.
Operations Reporting ...................................................................................................... 49
3.3.
HISP Reporting Oversight Committee ...................................................................... 51
4.
Assumptions / Dependencies / Constraints / Exclusions ...................................... 51
4.1.
Assumptions ....................................................................................................................... 51
4.2.
Dependencies ..................................................................................................................... 52
4.3.
Constraints .......................................................................................................................... 53
4.4.
Exclusions ............................................................................................................................ 53
5.
Standards and/or Reference Documents .................................................................... 54
6.
Approvals ................................................................................................................................. 54
APPENDIX A – HIPAA COMPLIANCE ATTESTATION SHEET .......................................... 55
APPENDIX B – MEASURES TO ENSURE DATA PRIVACY AND CONFIDENTIALITY ............ 56
APPENDIX C – HIPAA COMPLIANCE ATTESTATION .................................................... 64
APPENDIX D – DIRECT TRUST CERTIFICATE POLICY ATTESTATION ............................ 65
APPENDIX E – DIRECTTRUST.ORG CERTIFICATE POLICY ATTESTATION FORM ............. 66
APPENDIX F – FBCA AND DIRECTTRUST.ORG REFERENCES ....................................... 68
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 4 of 69
May 2012
1.
Introduction
(NOTE: Particular attention should be paid to any sections regarding digital X.509
certificates.)
The national DIRECT Project was launched in March 2010 in response to the growing need
for a single push standard for exchanging health information electronically across
organizational boundaries. The Office of the National Coordinator (ONC) set the stage for
collaboration within the private sector to create a secure, simple, cost-effective mechanism
to send health information directly to known, trusted recipients using the Internet. DIRECT
messaging was born.
DIRECT messaging is the sending or receiving of secure email with or without attachments
that is compliant with the protocols, standards and industry best practices associated with
the DIRECT Project.
Essentially, DIRECT messaging is secure email for the exchange of protected health
information (PHI). Regular email is not appropriate for the exchange of PHI because it has
the inherent risk of information being compromised or accessed by unauthorized users
during transmission.
The PA eHC is the custodian and guardian of the Community Shared Services (CSS) that
provide a gateway to the Pennsylvania health information exchange-network (HIE-Network)
and all its participants. In order for health information service provider (HISP) and HIE
organizations to obtain access to the CSS, they need to fulfill a number of requirements,
including complying with the respective HISP or HIE certification programs.
Note: HIE organizations without HISP services shall only apply for HIE certification.
However, if the organization is an HIE with HISP services, it will need HISP and HIE
certification. This document applies only to certification of HISP services.
One of the subsets of requirements within the certification program is that HISP
organizations need to be in compliance with certain security and privacy rules as mandated
by the federal government.
The Health Information Technology for Economic and Clinical Health Act (HITECH Act)
mandates audits of healthcare providers to investigate and determine if they are in
compliance with the Health Insurance Portability and Accountability Act (HIPAA) Privacy
Rule (effective in 2003) and Security Rule (effective in 2005). These audits are performed
by the Department of Health and Human Services (HHS) Office of Civil Rights (OCR).
Under certain situations, the HITECH Act extends the imposition of both civil and criminal
penalties under HIPAA to business associates, not just covered entities. As a general
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 5 of 69
May 2012
message of caution, this component of the healthcare industry should also take on the selfevaluation of existing policies, procedures and safeguards.
To get started with DIRECT, a user needs access to the Internet and a Web browser. Most
early DIRECT messaging services will be accessible through email-like Web portals, although
electronic health records (EHRs) and personal health records (PHRs) are starting to
integrate DIRECT messaging modules into their products to make it even easier and more
convenient for their customers to do DIRECT messaging. In many aspects, this integration
of DIRECT messaging into EHRs is similar to the integration of e-prescribing into EHRs,
which has been ongoing for several years.
Once a new user has registered and established their identity, a HISP can provide the user
with a DIRECT address, which will be used to send and receive all DIRECT messages, just as
easily as regular email. If DIRECT messaging is integrated into an EHR, then the EHR may
serve as the HISP, or the EHR may contract with a third party for HISP services.
The HISP not only provides a DIRECT account with a unique email address and digital
certificate, but also ensures that the DIRECT messages, plus any attachments, are routed
securely to the intended recipient, including DIRECT message recipients who are subscribers
to other HISPs.
Because HISPs fulfill such an important role in the exchange of secure DIRECT messages,
the PA eHC has put together a HISP Certification Program to provide HISP organizations
with an opportunity to participate in the Pennsylvania HIE-Network.
2.
Description of the Functions and Services
The following set of functions and services lists the requirements a fully certified HISP will
comply with, unless those functions are listed as optional. The PA eHC reserves the right to
change the requirements for certification and to revise this document at any time.
2.1. HIPAA Compliance Attestation
[Mandatory]
The purpose of this section is to provide guidelines and policy directives on how HISP
organizations that want to obtain certification status in the Pennsylvania HIE-Network
certification program should provide HIPAA Compliance Attestations.
2.1.1.
The HIPAA Security Rule
The HIPAA Security Rule (45 CFR 160, 162, and 164) establishes national standards
to protect individuals’ electronic PHI that is created, received, used or maintained by
a covered entity. The Security Rule requires appropriate administrative, physical and
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 6 of 69
May 2012
technical safeguards to ensure the confidentiality, integrity and security of electronic
PHI.
2.1.2.
Precertification preparation
In order to have the necessary information available to provide a HIPAA Compliance
Attestation (see Appendix A), HISP organizations may consider using a resource
toolkit provided by the National Institute of Standards and Technology (NIST) to help
with the attestation information gathering.
NIST has been involved in health information technology (HIT) research since 1994
and, through the American Recovery and Reinvestment Act (ARRA) of 2009, is
playing a major role in accelerating the development and harmonization of standards
and developing conformance test tools for HIT. One such tool is the HIPAA Security
Rule Toolkit (HSR Toolkit). See the following website: http://scap.nist.gov/hipaa/
2.1.3.
The NIST HSR Toolkit
The purpose of the NIST HIPAA Security Rule (HSR) Toolkit project is to help
organizations better understand the requirements of the HIPAA Security Rule,
implement those requirements and assess those implementations in their operational
environments.
The NIST HSR Toolkit application targets users who include, but are not limited to,
HIPAA-covered entities and business associates, and other organizations, such as
those providing HIPAA Security Rule implementation, assessment and compliance
services. Target user organizations can range in size from a large nationwide health
plan with vast information technology (IT) resources to a small healthcare provider
with limited access to IT expertise.
The HSR Toolkit is intended to be one of many useful resources that users can
leverage. Although the toolkit application has been developed by NIST, NIST is not a
regulatory or enforcement authority for the HIPAA Security Rule. The HSR Toolkit is
not intended to make any statement of an organization's compliance with the
requirements of the HIPAA Security Rule. Statements of compliance are the
responsibility of the covered entity and the regulatory and enforcement authority,
which, in the case of the HIPAA Security Rule, is the Health and Human Services
Office of Civil Rights (OCR).
Large organizations can use the HSR Toolkit to supplement their risk assessment
processes conducted by their security offices. The toolkit may also be used to assist
in alignment across multiple operating units. Small organizations can utilize the
toolkit to gain a better understanding of the current status of their HSR
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 7 of 69
May 2012
implementation and to serve as input into an action plan for implementation
improvements.
The HSR Toolkit is a desktop-based application that is intended to be a useful
resource among a set of tools and processes that an organization can use to assist in
reviewing its implementation of the HSR. It is a self-contained, operating system
(OS) independent application that can be run on various environments, including
Windows, Red Hat Linux and Apple OS X platforms. The security content that makes
up the question set will provide support that organizations can reuse over and over
again.
The HSR Toolkit addresses the 45 implementation specifications identified in the
HIPAA Security Rule and covers basic security practices, security failures, risk
management and personnel issues. See Appendix B for the “Measures to Ensure
Data Privacy and Confidentiality” that lists some of the important sections of the
applicable HIPAA rules. Basic security practice questions raised by the tool include
defining and managing access, backups, recoveries and physical security. Questions
addressing security failures deal with legal items to attend to after an incident, such
as breach notifications. Risk management questions address periodic reviews and
evaluations and can include regular functions, such as continuous monitoring. Lastly,
personnel issue questions address access to information as well as the on-boarding
and release of staff.
2.1.4.
Context for Use
Use of the HSR Toolkit can support an organization’s risk assessment process. The
purpose of a risk assessment is to identify conditions where electronic PHI could be
disclosed without proper authorization, improperly modified or made unavailable
when needed. Responses to the questions in the HSR Toolkit can help organizations
identify areas where security controls designed to protect PHI may need to be
implemented or where existing implementations may need to be improved.
The purpose of the HIPAA Compliance Attestation is to help the PA eHC with the
screening of HISP organizations to establish to what extent they comply with the
HIPAA Security Rule. If an organization has used the NIST HSR Toolkit or any
similar type of toolkit, they should be able to provide the PA eHC with a HIPAA
Compliance Attestation based on the information gathered and acted upon from
using the toolkit.
2.1.5.
Certification Requirements
In order to pass the HIPAA Compliance Attestation, HISP organizations (applicants)
must have appropriate administrative, technical and physical policies and procedures
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 8 of 69
May 2012
to ensure the integrity and confidentiality of protected healthcare information. These
policies and procedures must protect against any anticipated threats or hazards to
the security or integrity of such information. As a practical matter, the required level
of security is intended to be commensurate with the attendant risks.
In the event that the Electronic Healthcare Network Accreditation Commission
(EHNAC) develops a HISP accreditation program and an applicant is appropriately
accredited by EHNAC, the applicant may submit proof of such accreditation and
indicate such on the attestation sheet.
If an applicant is not appropriately accredited by EHNAC, then the applicant has to
provide other proof of compliance with the HIPAA Security Rule. At a high,
summarized level, the following requirements are in play:

Applicant has policies to protect against disclosure of PHI.

Applicant utilizes strong encryption, user authentication, message integrity
and support for non-repudiation as security measures in compliance with any
legislation requiring it.

Applicant must maintain a list of all individuals, contractors and business
associates with access to electronic PHI.

Applicant must have policies in place that prohibit individuals from storing
unencrypted PHI on personal computers, consumer devices and removable
storage media.

Applicant must implement policies and procedures to ensure compliance with
applicable requirements of the HIPAA Privacy and Security Rules.

Applicant has policies and procedures in place to ensure continuing
compliance with data security policies, including secure methods of access to
and transmission of data.

Applicant limits the use, disclosure or request of PHI, to the extent
practicable, to a limited data set or, if needed, to the minimum necessary to
accomplish the intended purpose of such use, disclosure or request.

Applicant refrains from selling or otherwise using PHI in such a way as to
violate privacy or confidentiality.

Applicant must use effective controls and implement procedures for guarding
against, detecting and reporting malicious software.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 9 of 69
May 2012

Applicant must demonstrate that appropriate security is in place for wireless
networks to protect the privacy of data during transmission and in storage.

Applicant must demonstrate that configuration standards are in place that
includes patch management for systems that store, transmit or access
electronic PHI, including workstations.

Applicant must implement a security measure to ensure that electronically
transmitted PHI is not improperly modified without detection.
The above high-level requirements are more fully covered in the HITECH Act and the
HIPAA Privacy and Security Rules. Applicant shall attest, by means of the HIPAA
Compliance Attestation (see Appendix A), to be fully compliant with applicable HIPAA
requirements.
2.1.6.
Post-conditions
If a HISP provides an attestation indicating that they are fully compliant with all the
requirements of the HIPAA Security Rule when electronically transmitting actual
patient information, then they have complied with the HIPAA Compliance Attestation
requirement of our certification program. As part of the certification program, HISP
organizations shall also agree to comply with annual audit and review policies that
may investigate HIPAA compliance.
2.1.7.
Flowchart Overview
The flowchart in Appendix C, the HIPAA Compliance Attestation, represents the
certification process, from a PA eHC perspective, at a very high level.
The HIPAA Compliance Attestation, highlighted in yellow, is part of the overall
certification screening process. The HIPAA Compliance Attestation is only one of a
number of screening tests. All the applicable screening tests will be performed in an
iterative process loop. At the end of the screening process, the PA eHC will
determine whether a certification application will be approved or rejected and the
applicant will be notified of the outcome. If an application is not approved, an appeal
process will be available to manage the non-compliance issues.
Although most steps in the overall certification process are common to both new as
well as existing (renewal) certification applications, some steps, such as “revoke
certification,” apply only to existing certifications.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 10 of 69
May 2012
2.2. DIRECT Trust Certificate Policy Attestation
[Mandatory]
The Pennsylvania eHealth Collaborative (PA eHC) DIRECT Project is a multi-phase
project. Among the goals of the initial Direct Project activities involves the definition and
establishment of a DIRECT Trust Community and associated X.509 Certificate Policies.
For DIRECT purposes, a Trust Community is a network of healthcare providers that have
been authorized to exchange (send and receive) healthcare information using the ONC
DIRECT messaging protocols. In order to accurately identify and validate the senders
and receivers of DIRECT protocol secure messages, a Trust Community must be
implemented to provide a reasonable guarantee that DIRECT messages cannot be sent
or received by unauthorized (non-healthcare provider) entities. The DIRECT Project
specification mandates that all organizations and individuals wanting to securely
communicate via the DIRECT Project messaging protocols enforce message privacy,
authentication, integrity and non-repudiation. DIRECT mandates the use of the ITU-T
X.509v3 standards for Public Key Infrastructure (PKI) based on IETF Internet certificate
profiles (PKIX). These principles form the backbone of the trust on which the Trust
Community and associated DIRECT PKI must be built. The Trust Community must
contain a set of policies and procedures that:

Align authenticated organization and/or individual identity(s) to one or more
DirectTrust.org aligned X.509 digital certificates

Enable management of associated X.509 digital certificate private keys

Ensure PHI is handled in manners compliant with HIPAA requirements regardless
of whether or not an entity that is handling PHI is considered a HIPAA covered
entity
PA eHC is the custodian and guardian of the DIRECT Trust Community that provides the
security assurance necessary to conduct DIRECT protocol message exchange, within and
between health information service providers (HISPs), in Pennsylvania. In order for HISP
organizations to obtain PA eHC certification, they need to fulfill the PA eHC certification
program requirements.
One of the requirements within the PA eHC certification program is that HISP
organizations need to align their certificate policies with the DirectTrust.org certificate
requirements.
ONC has mandated that digital certificates must be published and maintained as a
means of identifying and authenticating entities (individuals and organizations)
conducting DIRECT message exchange. Certificates are published, housed and validated
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 11 of 69
May 2012
by Certificate Authorities (CA). Entities receiving certificates are identified and
authenticated by Registration Authorities (RA).
HISPs must be able to discover and request validation for digital certificates associated
with DIRECT message sending and receiving end-point entities. The digital certificate
must be used to encrypt PHI when the data is at rest or in transit. PHI within a DIRECT
message may only be viewed by authorized entities that have been identified and
authenticated by a RA and that hold valid, current, CA-issued, DirectTrust.org aligned
X.509 digital certificates.
The HITECH Act mandates audits of healthcare providers to investigate and determine if
they are in compliance with the HIPAA Privacy and Security Rules. These audits are
performed by the OCR.
Under certain situations, the HITECH Act extends the imposition of both civil and
criminal penalties under HIPAA to business associates, not just covered entities. As a
general message of caution, this component of the healthcare industry should also take
on the self-evaluation of existing policies, procedures and safeguards.
The purpose of this section is to provide guidelines and policy directives on how HISP
organizations that want to obtain certification status in the PA HIE-Network HISP
Certification Program should provide DIRECT Trust Certificate Policy Attestation.
2.2.1.
PA eHCO Issued Certificates
A PKI assessment for PA eHC began in late May 2012. It is possible the assessment
will contain the recommendation that PA eHC stand up its own CA in order to issue
DirectTrust.org aligned, X.509 digital certificates. If PA eHC issues its own
certificates, it will hold the public keys of those certificates to facilitate ease of
discoverability. Until these possible actions take place, HISPs certified by PA eHC will
use X.509 certificates that meet the criteria of the DIRECT Trust Certificate Policy
Attestation required by the PA eHC HISP Certification Program.
If PA eHC stands up a CA, all certified HISPs shall purchase and exclusively use PA
eHC DirectTrust.org aligned certificates for all DIRECT communications within the
Commonwealth of Pennsylvania. It is anticipated that all the HISPs certified by PA
eHC will purchase and use the certificates no later than January 2014.
2.2.2.
DIRECT Trust Community
The HIPAA Security Rule (45 CFR 160, 162, and 164) establishes national standards
to protect individuals’ electronic PHI that is created, received, used or maintained by
a covered entity. The Security Rule requires appropriate administrative, physical and
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 12 of 69
May 2012
technical safeguards to ensure the confidentiality, integrity and security of electronic
PHI.
A Trust Community will be established for the purpose of facilitating DIRECT
message exchange within Pennsylvania. A Trust Community exists when:

The sender has a strong certainty that only someone controlling the receiver’s
private key (presumably the receiver) can view the message

The receiver has a strong certainty that only someone controlling the sender’s
private key (presumably the sender) sent the message

Both sender and receiver have confidence that nothing happened to the
message in transit (e.g., tampering, disclosure, etc.)
HISPs that have complied with all PA eHC HISP certification requirements, including
providing a completed DIRECT Trust Certificate Policy Attestation, will be admitted to
the Pennsylvania HIE-Network trust community.
2.2.3.
Precertification preparation
In order to have the necessary information available to provide a DIRECT Trust
Certificate Policy Attestation, HISP organizations will need to gather, compile and
document their digital certificate policies. All policies related to the identification and
authentication of entities and the issuance and maintenance of digital certificates will
be required to measure compliance with attestation requirements. As part of the
HISP certification process, the PA eHC will review the HISP’s DIRECT Trust Certificate
Policy Attestation and compare all of the HISP organization’s digital certificate
policies with the DirectTrust.org certificate policies.
2.2.4.
Federal Bridge and DirectTrust.org Certificate Policies
The purpose of the Federal Bridge Certificate Authority (FBCA) is to provide guidance
related to the digital certificates issued to entities who wish to engage in secure
communication with U.S. Government federal agencies. To facilitate the missions of
the organizations, interoperability is offered to non-federal entities. There are 12
policies specified at six different levels of assurance in this certificate policy, which
are defined in X.509 Certificate Policy for the Federal Bridge Certification
Authority (FBCA) at
http://www.idmanagement.gov/fpkipa/documents/FBCA_CP_RFC3647.pdf.
DirectTrust.org is an organization being formed as an independent nonprofit entity
by and for participants in the DIRECT exchange community in order to establish and
maintain that high level of trust needed by all. Members include representatives from
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 13 of 69
May 2012
HISPs, health information exchanges (HIEs), CAs, as well as healthcare providers
who are their purchasers and subscribers. DirectTrust.org members working together
will foster stability and interoperability of DIRECT exchange implementations across
the country. By offering education and guidance for security and trust best practices,
a national trust framework will be formed and maintained that supports secure
health data exchange over the Internet. DirectTrust.org’s recommended DIRECT
related certificate policies are contained within the DirectTrust Ecosystem
Community x.509 Certificate Policy – Draft For Trial Use at
http://directtrust.wikispaces.com/Direct+Ecosystem+Certificate+Policy.
2.2.5.
Context for Use
Use of the DirectTrust.org certificate policy as a comparison tool can support an
organization’s certificate policy self-assessment process. The purpose of a certificate
policy self assessment is to identify areas where certificate policies may need to be
modified or improved prior to seeking PA eHC HISP certification.
The purpose of the DIRECT Trust Certificate Policy Attestation is to help the PA eHC
with the screening of HISP organizations in order to establish to what extent they
align with the FBCA and DirectTrust.org certificate policies.
If an organization has used the FBCA or DirectTrust.org certificate policies to do a
self assessment, they should be able to provide the PA eHC with a DIRECT Trust
Certificate Policy Attestation based on the information produced as a result of those
comparisons.
2.2.6.
Certification Requirements
In order to pass the DIRECT Trust Certificate Policy Attestation, HISP organizations
(applicants) must have appropriate administrative, technical and physical policies
and procedures to ensure the integrity and confidentiality of digital certificates issued
to entities engaging in the exchange of PHI via DIRECT messaging protocols. These
policies and procedures must protect against any anticipated threats or hazards to
the security or integrity of digital certificates in alignment with FBCA or
DirectTrust.org certificate policy guidelines.
In addition to enabling and promoting the security functions of the statewide HIENetwork, the PA eHC requires HISPs to:

Exchange certificates amongst themselves, in order to establish trust

Associate X.509 certificates with full DIRECT email addresses or health
domain names
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 14 of 69
May 2012

Secure the confidentiality and integrity of the content by handling it through
S/MIME encryption and digital signatures
2.2.7.
Post-conditions
If a HISP provides an attestation indicating that they are fully aligned with all the
requirements for digital certificate policies as specified by DirectTrust.org, then they
have complied with the DIRECT Trust Certificate Policy Attestation requirement of
our HISP certification program. As part of the certification program, HISP
organizations shall also agree to comply with annual audit and review policies that
form part of the certification renewal process.
2.2.8.
Flowchart Overview
The flowchart in Appendix D represents the certification process, from a high level,
PA eHC perspective.
The DIRECT Trust Certificate Policy Attestation, highlighted in yellow, is part of the
overall certification screening process. The DIRECT Trust Certificate Policy Attestation
is only one of a number of screening tests. All the applicable screening tests will be
performed in an iterative process loop. At the end of the screening process, the PA
eHC will determine whether a certification application will be approved or rejected
and the applicant will be notified of the outcome. If an application is not approved,
an appeal process will be available to manage the non-compliance issues.
Although most steps in the overall certification process are common to both new as
well as existing (renewal) certification applications, some steps, such as “revoke
certification,” apply only to existing certifications.
2.3. Digital Certificates
[Mandatory]
Healthcare providers, engaging in DIRECT message exchange, will be required to
possess an X.509 digital certificate with policies aligned to guidance provided by
DirectTrust.org.
Note: If the PA eHC stands up its own CA, it will establish a single root certificate with
policies aligned to DirectTrust.org. All X.509 certificates issued to certified DIRECT
participating entities in Pennsylvania will have certificate policies chained, directly or
indirectly, to PA eHC’s established root certificate.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 15 of 69
May 2012
In order for a new certificate to be issued to an entity wishing to engage in DIRECT
exchange, a Registration Authority (RA), authorized to perform RA functions by the PA
eHC, will confirm the identity of that entity and authenticate the entity’s professional and
legal credentials, giving the entity the right to perform DIRECT exchange. After the RA
has identified and authenticated an entity it will send, on behalf of the applying entity, a
Certificate Signing Request (CSR) to a Certificate Authority (CA), authorized to perform
CA functions. The CA will issue and enable the X.509 digital certificate for use by
registering and publishing the certificate related information, public/private keys, to
appropriate registries (DNS, LDAP, Active Directory, etc.).
The CA must be able to disable a digital certificate in the event of policy violation or
certificate expiration. Once the certificate is disabled, the CA must also update/correct
all registry entries and disable/retire the public/private keys. When an RA issues a CSR
for a certificate renewal, after re-validating the certificate holder’s identity, the CA must
be able to re-enable the associated digital certificate, re-enabling/issuing public/private
keys, and publishing/updating all associated registry entries.
The requirements detailed in this functional specification do not apply to digital
certificates issued to healthcare consumers or patients. These specifications are only
applicable to entities directly providing healthcare services.
The functional process to create and publish a new X.509 digital certificate, in
accordance with DirectTrust.org, would flow as follows:

An entity (individual or organization) wishing to become a DIRECT participant will
apply for a digital certificate with an authorized RA.

An authorized RA will confirm the entity’s identity and verify the entity’s
professional and legal credentials as a healthcare provider.

The RA will issue a CSR to the requesting entity, which will indicate to an
authorized CA that the entity has been verified in accordance with DirectTrust.org
requirements.
The following certificate creation related functional services should be provided by HISP
organizations as a part of their provider on-boarding process:

The applying entity will submit the CSR to an authorized CA as a formal request
for an X.509 digital certificate to be issued to that entity.

The CA will verify the validity of the CSR and issue a digital certificate associated
directly with the applying entity, containing a unique and individually identifiable
public key. The CA shall also securely encapsulate entity attributes in the digital
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 16 of 69
May 2012
certificate, if authorized by the Certificate Policy (CP) and based on the request
issued by the RA.
The following certificate install/enable related functional services should be provided by
HISP organizations as part of their certificate management and administration process:

The CA will publish the newly issued digital certificate and notify the requesting
entity that the certificate has been issued.
The following certificate disable/expire/retire related functional services should be
provided by HISP organizations as part of their certificate management and
administration process:

The CA will cease publishing and/or suspend validity of a previously issued digital
certificate and notify the requesting entity that the certificate has been disabled,
expired or retired.
2.4. HISP to HISP Communication
[Mandatory]
For DIRECT services, the PA eHC has chosen to create a HISP market where multiple
HISPs offer DIRECT services within the state. As members of the established trust
community, HISPs will be able to conduct inter-HISP (HISP to HISP) DIRECT message
exchange among healthcare providers subscribing to unaffiliated HISPs that are also
members of the established trust community.
The functional requirements for any HISP within the PA eHC trust community conducting
inter-HISP DIRECT message exchange with any other HISP in the trust community are
as follows:

A trust community member HISP must agree to assume that a trust relationship
exists between that HISP and all other trust community member HISPs.

A trust community member HISP must agree to comply with and abide by all
state and federal mandates, regulations and specifications, including but not
limited to HIPAA and the DIRECT Project Specification, regarding healthcare data
exchange privacy and security, when conducting inter-HISP DIRECT message
exchange with other trust community member HISPs.

A trust community member HISP must agree to comply with and abide by all
DirectTrust.org certificate policies when conducting inter-HISP DIRECT message
exchange with other trust community member HISPs.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 17 of 69
May 2012
2.5. Provisioning of DIRECT Email
[Mandatory]
Note: As part of the HISP Certification Program, a HISP that provides self-serve,
online provisioning functions shall provide concrete proof that it is operational and
complies with the DIRECT provisioning requirements.
A fully certified HISP shall allow an Internet connected healthcare professional the ability
to apply for a fully functional DIRECT email account/address.
As part of the overall provisioning process, a HISP shall also take responsibility for
managing stakeholder identities. See the New User section for more details. An identity
could be either a person or entity (e.g. group, facility, etc.) such as one of the following
stakeholders:

Physicians

Registered Nurses

Licensed Practical Nurses

Pharmacies

Optometrists

Dentists
Before a user can send or receive DIRECT email messages, both sending and receiving
users need to obtain DIRECT email addresses. A DIRECT user can apply for an email
account for a healthcare organization (clinic, etc.) or an individual. Hence, the provision
function for an email account shall cater to both.
This functionality expects the cooperation of a number of parties. Summarized, the
provisioning process (using an online, self-service application) for establishing email
accounts for DIRECT users consists of the following steps:


A user goes online via a web portal provided by a HISP organization:
o
Provides certain identification information
o
Requests a DIRECT email address/account
If the HISP organization does not have an appropriate security certificate in place
for the user, then the creation of a security certificate needs to take place first.

If a security certificate is in place for the DIRECT user, then the provisioning
process of the HISP shall continue and confirm that the user is who they claim to
be. If the user is who they claim to be, then the provision function for an email
account shall:
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 18 of 69
May 2012
o
Create a unique DIRECT email account and address for the user.
o
Link the user’s certificate to that unique DIRECT email account.
o
Make the necessary email account information, including public keys,
available for discovery by other authorized users.
o
Notify the user that the new DIRECT email account is now active.
Upon successfully acquiring a DIRECT email address, the user is ready to send and/or
receive DIRECT email messages and attachments.
Joining a HISP allows users to utilize the above mentioned functions so they can actively
exchange secure PHI messages with other users of the same or other healthcare
organizations. The following list contains the provisioning functions the HISP will need to
perform. Please note that PA eHC does not dictate how these functions will be
performed, but instead indicates which must be present in the HISPs provisioning
process.
2.5.1.
New User Registration
This function allows an internet-connected healthcare professional to apply for a
DIRECT User ID (UID).

At the appropriate point in the registration process, the applicant(s) shall
agree to any applicable legal terms and conditions required by the governance
process.

Depending upon the security assurance level required for the applicant, it may
be necessary that identity be established by in-person proofing. This would be
conducted before a Registration Authority (RA) trusted agent (e.g., notary
public).

Once identity is validated, the applicant’s details shall be captured in a
registration application in order to open a new DIRECT account for that user.

If a new user already has a valid DIRECT digital certificate(s), the registration
application shall allow the user to upload that certificate(s), if so desired.

If a new user wants to obtain a new DIRECT digital certificate, the registration
application shall enable the certificate request process. See the section
“Validate Healthcare Provider,” for more detail.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 19 of 69
May 2012
2.5.2.
User Logon
User logon to a HISP for DIRECT email gives full access to any PHI contained in that
account. Therefore, the logon function must combine ease of use with the latest
industry standards for security.
HISP logon shall consist of identification and authentication. Users will identify
themselves with a DIRECT User ID (UID), most likely a username. Then users will
authenticate themselves to establish confidence in the presented identifier, the UID.
Authentication will take the form of a password.

UID or Username – PA eHC recommends that usernames consist of the
user’s DIRECT email address or that part of the email address before the “@”
symbol. However, a HISP may want to implement a more advanced UID
policy.

Passwords – Under PA eHC policy, the password for a DIRECT email account
represents the second factor of two-factor authentication. Using more than
one authentication factor increases security. A DIRECT email account
connected to an X.509 certificate means one layer of authentication already
exists. The certificate, something the user “has,” combined with the
password, something the user “knows,” creates two-factor authentication.
Because the password must be remembered, may be seen and represents the
easiest target for security attacks, it requires password management that exceeds
the guidance provided for the UID. Password management is the process of
defining, implementing and maintaining password policies throughout an enterprise.
If the HISP has password policies more secure than the following suggestions from
PA eHC, then the HISP should adhere to its policies. The following is a list of
suggested password management policies that a HISP may use or compare to their
own for security level setting.
1) Case Sensitive – Use case sensitive password policies. Additionally, prior to
any hashing of the passwords, do not convert all the letters to the same case.
2) Password Makeup – These two policies represent the latest recommendations
from NIST for password strength.
a. Passwords may be longer rather than more complex
i. 10 to 15 characters
ii. At least one number
iii. At least one uppercase letter
iv. At least one lowercase letter
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 20 of 69
May 2012
b. Passwords may be shorter and more complex
i. 8 to 10 characters
ii. At least one uppercase letter
iii. At least one lowercase letter
iv. At least one digit
v. At least one non-alphanumeric character
The HISP shall clearly communicate its password policy to the user.
3) Policy Changes – If the HISP makes changes to any policies, procedures or
agreements which affect the user, such as changing security standards
mandated by the DIRECT Project, the user shall be presented with the new
procedures or agreements. After being given the opportunity to read the new
terms and conditions required by the governance process, the user must
agree to them before being given the opportunity to logon.
4) HISP/User Interaction – The HISP will inform users that no HISP
representative will ever ask for the user’s password.
5) Failed Password Attempts – The HISP must have a policy for when the user
enters the incorrect password more than once. If the HISP already has a
policy in place for failed password attempts, they do not need to adopt the
suggested policy of PA eHC, which appears below, unless the HISP’s policy is
less secure. If they do not have a policy, they may use PA eHC’s suggestions
or institute one that aligns with industry security standards.
Repeated entries of an incorrect password may be a legitimate user who has
forgotten the correct one. However, the repeated entries may also be an
invalid user attempting to access the account.
PA eHC offers the following suggestions for failed password attempt policies:
a. If the user makes five consecutive failed attempts at entering the
correct password, then the HISP system will lock the account.
i. The use of fewer allotted attempts may frustrate users causing
them to create an easier, and thus weaker, password or to
store the password insecurely.
b. Unlocking the account shall be self-service using a series of security
questions unless the HISP provides a 24-hour, seven-days-a-week
help desk for assistance with unlocking.
6) Storage policies – The manner in which a HISP stores the passwords of its
users may make them vulnerable to attack. To mitigate attacks on
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 21 of 69
May 2012
passwords while they’re stored, a HISP may want to consider one of the
following:
a. Encrypting files that contain passwords
b. Using operating system access control features to restrict access to
files that contain passwords
c. Storing one-way cryptographic hashes for passwords instead of storing
the actual passwords
7) Preventing Password Guessing – Some of the simplest password attacks occur
from “shoulder surfing,” the act of looking over the user’s shoulder. To
prevent password guessing, PA eHC recommends HISPs consider one or more
of the following:
a. Password field should not have a maximum allowable length equal to
the minimum length of the user’s password. For example, if a user’s
password must be eight-characters long, the password field should not
have a maximum length of eight characters.
b. The “Submit” button clicked by the user once the username and
password were entered should not be grayed out at any time during
the process. In other words, it shouldn’t become operational the
moment the password reaches the minimum required length.
c. If the user enters an incorrect password or username, no information
should be given about what is incorrect.
8) One-Time Passwords (OTP) – If the HISP chooses to use OTPs for any reason,
they shall be randomly generated. Additionally, as the name indicates, once
the OTP is used to log into the account, the user must enter a new password
and the OTP shall become inactive.
2.5.3.
Change Password Notification
The change password notification function alerts a DIRECT user to the password’s
impending expiration. The alerts would appear at defined intervals prior to the
expiration.

This notification will provide the user with sufficient time and instructions to
successfully change the password before expiration.

If the user ignores the notifications, this function shall cause the password to
expire in accordance with DIRECT and all other health security policies and
specifications.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 22 of 69
May 2012
2.5.4.
Password Change
This function provides a DIRECT user with the ability to change the password.

This will be accomplished by requiring the user to login using the current or
expired password and then enter a new password. The user will be required
to enter the new password a second time to ensure correctness.

The password change function shall ensure that password lengths, characters,
numeric and special character combination protocols are met in accordance
with DIRECT and all other health security policies and specifications.

A separate section titled Forgot Password will assist users with forgotten
passwords.
2.5.5.
Forgot UID
This function will provide a DIRECT user with the ability to retrieve their UID using
their administrative email account.

The user must furnish their administrative email account to act as an
intermediary account until a new UID is established.

Whenever necessary, the user may request their forgotten UID and the
answer will be sent to their administrative email account.

2.5.6.
The user may or may not need to answer a pre-established security
question(s) before receiving the UID to get back in the system.
Forgot Password
The forgotten password function goes hand-in-hand with the Request Answers
Reset function. It will allow the user to verify that they are a legitimate DIRECT
user who forgot their password and needs reset instructions sent to their
administrative email address. After the user correctly answers the security questions,
proper reset instructions will be emailed to their administrative email address. Once
the proper instructions are received, the user shall be given the opportunity to reset
their password to one that meets the HISP sign-on validation rules required for
certification and all other applicable health security policies and rules.
2.5.7.
Request Answers Reset
In order to promote self-service and reduce administrative costs, users requesting a
password reset will be required to answer a number of security questions. Only after
correctly answering the questions will the user receive the reset instructions from the
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 23 of 69
May 2012
system – see the Forgot Password function. The system will provide a selection of
possible security questions that a user chooses when registering for an account. The
answers to the questions should only be known by the registered user and should
help prevent potential security breaches. The user may request to update the
answers at any time.
2.5.8.
User Request Unlock
The user request unlock function will allow a DIRECT user to request an
administrator or help desk to unlock their account.

The administrator or help desk shall require that the user provide applicable
information to ascertain that the unlock request is legitimate.

Once the user has been verified and authenticated, the administrator or help
desk shall unlock that user’s account. Then the user may attempt to login
again. If the user continues to forget their password, the user shall be given
the opportunity to use the Forgot Password functionality.
2.5.9.
Validate Healthcare Provider
The healthcare provider validation function will be used to validate/authenticate that
an individual is a healthcare provider within the Commonwealth of Pennsylvania.
The process to validate a healthcare provider consists of a number of steps with a
number of potential players involved. Two of the important roles are the Registration
Authority (RA) and the Certificate Authority (CA).
From the perspective of a HISP, they can relate to RAs and CAs in a number of ways.
A HISP may:

Act as RA and CA. A HISP proves the applicant’s identity during enrollment
and issues certificates as appropriate.

Act as RA only. A HISP proves the applicant’s identity during enrollment and
then passes the necessary information to an independent CA. The CA
provides the certificate to the HISP.

Act as CA only. An independent RA proves the applicant’s identity during
enrollment and then passes the necessary information to the HISP, which
issues certificates as appropriate.

Act as neither CA nor RA. An independent RA proves the applicant’s
identity during enrollment and then passes the necessary information to an
independent CA, which provides the certificate to the HISP.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 24 of 69
May 2012
From a healthcare provider’s perspective, by the time they receive a X.509
certificate, they will have completed a number of provisioning steps such as
registering as a new user, obtaining a DIRECT email address, etc. These provisioning
steps can be done by the individual provider, or on behalf of an individual, by a
representative of an organization (e.g. @healthypracticeoffices.org) to which the
provider belongs.
Regardless of whether an individual provider applies or a representative applies on
behalf of the individual, a number of items are required to verify the identity of the
individual requesting a certificate:

Identity shall be established by in-person proofing by the RA, a trusted agent
or an entity certified by a state or federal entity to confirm identities (e.g.,
notary public).

Information provided shall be verified to ensure legitimacy. A trust
relationship between the trusted agent and the applicant, which is based on
an in-person antecedent, may suffice as meeting the in-person identity
proofing requirement.

Credentials required are one federal government-issued picture I.D., one
REAL ID Act compliant picture ID or two non-federal government IDs, one of
which is a photo ID (e.g., non-REAL ID Act compliant driver’s license).

Any credentials presented must be unexpired.
Once the provider is validated by the RA, the RA will provide a Certificate Signing
Request (CSR) to the entity acting as the CA. The CA will provide a X.509
certificate.
2.5.10.
Additional security functions
A HISP must enable the following functions to ensure security of DIRECT email.

Expiration of the validity of previously issued unique DIRECT email
addresses.

Revocation of the validity of previously issued unique DIRECT email
addresses.

Renewal/re-instatement of previously issued unique DIRECT email
addresses.

Issuance of X.509 digital certificates to fully verified healthcare providers.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 25 of 69
May 2012

Expiration of the validity of previously issued X.509 digital certificates.

Revocation of the validity of previously issued X.509 digital certificates.

Renewal/re-instatement of previously issued X.509 digital certificates.
2.6. Support for DIRECT
[Mandatory]
Because DIRECT users participating in the trust community are allowed to use different
deployment models, certain fundamental rules apply. See the Deployment Models
document for at http://wiki.directproject.org/Deployment+Models.
Any participant using the specifications included in the Applicability Statement for
Secure Health Transport (ASSHT) at
http://wiki.directproject.org/Applicability+Statement+for+Secure+Health+Transport will
likely be using the same deployment model for sending and receiving DIRECT emails.
However, it is possible, and allowed, that they could be using different deployment
models.
For example, a healthcare provider might use their electronic health record (EHR) to
send documents because the EHR might be a very natural place to package the
documents of interest and, with a very simple user interface, send the documents using
the specifications included in the ASSHT. This same healthcare provider then might use
an email client to receive documents that are pushed using the specifications included in
the ASSHT so that they can use the filtering and sorting functionality inherent in
common email clients today.
It is important to recognize that any deployment model can be used to send and any
deployment model can be used to receive DIRECT emails. This implies that HISPs need
to be able to provide a variety of functions and services to support these different
deployment models that their DIRECT users may choose.
As a basic support requirement for HISPs, it should be noted that any deployment
model on the sending side shall be able to communicate with any deployment
model on the receiving side. Thus, the deployment model that the sender uses is
totally independent of the deployment model that the receiver uses.
In general, HISPs applying for certification should be able to accomplish the following
tasks:
Sending
1. Packaging content or implementing XDM
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 26 of 69
May 2012
2. Locating the destination's address
3. Locating destination’s certificate
4. S/MIME-signing the content using Source Private Key
5. S/MIME-encrypting the content using Destination Public Key
6. Sending the S/MIME message with SMTP and Secure Socket Layer (SSL) or
Transport Layer Security (TLS)
Receiving
1. Receiving S/MIME message with SMTP and SSL or TLS
2. Optional storage of the S/MIME (encrypted) message
3. S/MIME signature verification using Source Public Key
4. S/MIME decryption using Destination Private Key
5. Send an encrypted MDN when the message is received
6. Optional POP/IMAP
7. Optional storage of decrypted content
Certain HISP tasks are regarded as mandatory, while others are optional.
Mandatory Tasks:
Besides routing (sending/receiving) DIRECT messages, HISPs must also manage trust
relationships (who can send to/receive from), and publish digital certificates to enable
encrypted, secure communication.
Optional Tasks:
HISPs often may provide DIRECT addresses; store DIRECT messages (either temporarily
or long-term); serve as a registration authority (RA) and/or a certificate authority (CA)
(verify provider identity and/or issue digital certificates); and offer other
services/enhancements (webmail client, APIs / edge protocols, directories, etc.).
There may be additional tasks and support functions, such as translation and
transformation, depending on the deployment architecture and business agreements in
place.
In the world of DIRECT emails, PA eHC will expect that a HISP can and shall provide a
number of the functions and services to support the deployment models presented
below. It should be noted that the specifications included in the ASSHT do not mandate
all those functions and services for a HISP. However, PA eHC starts from a certification
position that will distinguish between HISPs that can provide all those functions and
services and those that cannot. For information on what functions PA eHC considers
mandatory and which optional, please refer to the test plans provided in the packet
presented during the application phase of the PA eHC HISP Certification Program.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 27 of 69
May 2012
2.6.1.
Deployment Models
In order for a HISP to provide any DIRECT email capability, it must support one or
more of the deployment models. As stated previously, details concerning the
deployment models may be found at
http://wiki.directproject.org/Deployment+Models. What follows is a brief description
of each of the three deployment models. A HISP may provide one or more of the
models.
2.6.1.1.
Email clients with and without native S/MIME
The Deployment Model document lists email clients that natively use S/MIME and
those that don’t as two separate models. For the purposes of the PA eHC HISP
Certification Program, the email client is one deployment model. However, we
have listed the differences between the two email clients as detailed in the
Deployment Model document to cover all contingencies.
2.6.1.1.1.
Email without native S/MIME
An email client that does not use S/MIME uses common email functionality
with a HISP service that intercepts all outbound/inbound email messages. The
email client shall be configured to connect to the email server hosted by the
full-service HISP in a manner that is secure. All other security is handled by
the HISP. The HISP shall support:

Security functionality to encrypt and sign outbound e-mail

Decrypt and validate signatures on inbound e-mail

To assure confidentiality of information transmitted between client and
HISP, TLS is mandated for this deployment model
To configure the email client, the HISP may provide APIs/edge protocols and
additional support to the DIRECT user. The DIRECT user may be required to
do one or more of the following:

Obtain the SMTP and POP3 or IMAP domains for the HISP, and
configure the email client to use these domains for sending and
receiving email.

Configure these domains to use SSL, for both incoming and outgoing
messages. This will secure the information transmitted between the
email client and the HISP. This step is required to protect health
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 28 of 69
May 2012
information passed in messages from the point it leaves a computer to
the point it reaches the HISP's email servers.

Configure the internal and external port numbers to the value supplied
by the HISP.
2.6.1.1.2.
Email client using native S/MIME
An email client using native S/MIME could be a fully functional email client, or
a common enterprise class e-mail system that supports the proper security
requirements. The HISP shall support:

True end-to-end security with no third-party access to PHI
Additional support items for the user to consider:

TLS is not mandated between client and HISP, although it could be
used to provide additional protection.

The sender or receiver must also manage an address book.

The human or organization that is sending the messages is
responsible for verifying the address of the recipient and obtaining
the destination's security keys. This is often done with a simple test
message that contains no sensitive data but its receipt is confirmed
through, for example, a telephone call.
2.6.1.2.
Web portal or RESTful API
A Web portal or RESTful API is representative of a thin client using an internet
browser for user interface and uses an external service to provide all of the
requirements of the DIRECT Project.
In this model the user interacts using only their internet browser or, where the
client is an application (e.g., EHR or Personal Health Record (PHR)), using an
application programming interface (e.g., RESTful API or SOAP API, etc.) in a way
that is defined by the service they have. The HISP shall support:

The management of certificates and private keys

User authentication between the client and their HISP

Content packaging
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 29 of 69
May 2012

Addressing, including access to the White Pages (see the White Pages
Lookup section), locating and validating user endpoints

Security – TLS is mandated for this deployment model

Delivery of DIRECT messages
2.6.1.2.1.
Additional Support Requirements for Web Mail
In addition to the above requirements, HISPs that provide DIRECT email
services via a Web portal deployment model shall also support:

Attaching to and downloading from DIRECT emails any structured and
unstructured documents, provided those documents comply with all
applicable healthcare federal and state laws. See section C32 & C62
Send, Receive, Attach, Download for more details.
2.6.1.3.
EHR with integrated S/MIME functionality
An EHR with integrated S/MIME functionality integrates all of the requirements
needed to be DIRECT compliant into the EHR application. In this model, the user
is likely to be given a very simplified interface to select the documents to send as
well as the destination address. The EHR shall manage content packaging,
addressing and security. The trusted HISP service shall support:

Delivery of the message package
Additional support items for the user to consider:

TLS is not mandated between client and HISP, although it could be used
to provide additional protection.

The EHR must integrate the DIRECT Project functionality into the native
code.

The EHR must manage addresses and digital certificates or integrate with
a directory that does.
2.6.2.
DIRECT Project to/from XDR (e.g., Nationwide Health Information
Network Exchange)
There is the potential for an HIE with a HISP scenario that is using XDR for push
workflows. These HIEs would like to send to and receive DIRECT emails from
participants that are using the specifications included in the ASSHT.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 30 of 69
May 2012
There is the need to treat the XDR environment as a fully trusted party. While the
XDR environment may be a Nationwide Health Information Network (NwHIN)
Exchange participant, it could also be another entity that is not in the NwHIN
Exchange, such as a health information organization (HIO) (local, regional, state) or
an EHR that communicates via XDR.
This model requires the conversion of XDR to and from the DIRECT Project
specifications. See the XDR and XDM for Direct Messaging specification at
http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging for more details.
A system in an XDR environment can always choose to also be a DIRECT Project
participant to get end-to-end security. The choice should be based on the sender and
receiver relationship and their risk management strategy. A solution supporting both
XDR and the specifications included in the ASSHT would be an application that can
decide which transport to use to get to the desired destination.
The "DIRECT Project to XDR" Destination HISP shall be a trusted service provider by
the PA eHC and shall:

Advertise via DNS "MX" records that it is the endpoint for all of the addresses
for which it can translate in the XDR space

Allow any DIRECT Project sender to send to any XDR endpoint as long as
there is a trusted "DIRECT Project to XDR" destination HISP service available
to do the translation

Ensure that there is no need for the XDR receivers to have independent digital
certificates

Handle errors due to missing metadata, based on policy
In the scenario where the XDR sender is utilizing a "DIRECT Project from XDR"
source HISP as a trusted service provider that HISP shall:

Sign the content

Discover the recipient's certificate for encryption
2.6.3.
White Pages Lookup
The CSS provided by PA eHC includes “white pages” lookup functionality that makes
it easier for CSS participants to locate and validate destination email addresses. See
the section Provide Access to Shared White Pages for more details.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 31 of 69
May 2012
Certified HISPs will have access to the “white pages” and shall support a subset of
the following user and system functions:

The Global Address List function, only mandatory for Web mail, provides
DIRECT email users with the basic search function to be able to locate and
validate other DIRECT users via first name, last name, organization or email
based lookup

Locate/Validate User Endpoint - This system function will interoperate with
the different mail solutions (DIRECT, Web mail and EHR) to enable the CSS
global address list function to locate a user’s valid DIRECT email address
using a number of different user search fields

Problem or Failure Notification and Resolution – Addressing a multitude of
problem permutations, ex. invalid DIRECT user, invalid DIRECT domain,
mailbox full, etc.
2.7. DIRECT mail and white space
[Mandatory]
As part of the HISP Certification Program, a HISP shall attest to abide by the “Rules of
the Road” of the DIRECT Project. See the Direct Trusted Exchange Rules of the Road at
http://wiki.directproject.org/Direct+Rules+of+the+Road.
In order to cater for “white space” (underserved/unserved community) users, DIRECT
stakeholders shall not be required to belong to any given HIE. As long as they have
access to the internet, use a valid DIRECT email address and a trusted HISP, then those
stakeholders shall be allowed to participate in the DIRECT community and exchange
DIRECT email messages, with attachments. It should be noted that DIRECT users who
have signed up with non-certified HISPs may not be able to get access to the CSS, as
access to the CSS is reserved for certified HISPs and HIEs only.
Using DIRECT email/messaging is simple. The text and figure below explain what a
provider-to-provider workflow for DIRECT messaging looks like, including some of the
behind-the-scenes activity performed by a HISP. This functionality assumes the
cooperation of a number of parties.
The DIRECT user/subscriber:

Logs into the DIRECT messaging account (or opens up the desktop DIRECT email
client or accesses the DIRECT module in the EHR) and composes a DIRECT
message
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 32 of 69
May 2012

Attaches all the information relevant to the communication, such as a PDF file or
Continuity of Care Record or Document (CCR/CCD) exported from the EHR,
progress notes, diagnostic images, etc.

Clicks send.
After the user clicks send:

The DIRECT message travels to the sender’s HISP, which ensures that the
message is routed securely to the authorized recipient.

The HISP encrypts the message, authenticates the identity of the sender, and
routes the message to the recipient’s HISP (see diagram below).

The recipient’s HISP routes the message to the recipient’s DIRECT inbox.

The recipient logs into the DIRECT account, opens the message, and views all of
the information (including the attachments) needed for consultation with the
patient.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 33 of 69
May 2012
How DIRECT Email Works
HISP = “Health Information Service Provider”
White Pages Application
www.whitepages.direct.pa.gov
Import/
Export
Basic Participant Directory
TLS/
SSL
HISP - A
HISP - B
Security Agent
EHR
(Inbox)
Security Agent
SMTP/SMIME
(Public Internet)
E-Mail Server
TLS/
SSL
E-Mail Server
TLS/
SSL
HTTPS
E-mail
Desktop
Import/
Export
TLS/
SSL
E-mail
Web
EHR
(Inbox)
HTTPS
E-mail
Desktop
E-mail
Web
As seen in the image above, this functionality must provide for the scenario where one
or more of the participating certificate keys are not readily discoverable, because the
email address is not present in a participant directory. For that purpose, HISPs may
need to provide a “white pages” capability to allow stakeholders to build their own
contact list.
Alternatively, the CSS may enable a workable solution to help white space users
overcome certificate discovery problems.
2.8. C32 and C62 – Send, Receive, Attach & Download –
Structured and Unstructured Documents
[Mandatory]
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 34 of 69
May 2012
In the world of DIRECT emails, two types of documents are the most frequently used
attachments. They are:

The structured continuity of care document (C32)

The unstructured document (C62)
In general, senders of DIRECT emails shall be allowed to attach structured (C32) and
unstructured (C62) documents to their DIRECT emails, provided they comply with all
applicable healthcare federal and state laws. Recipients of DIRECT emails that have C32
and/or C62 attachments shall be allowed to download those attachments into their local
storage areas or, if applicable, consume them into their electronic health record (EHR)
systems.
2.8.1.
The Structured C32 Document
The structured C32 document, also known as the continuity of care document (CCD),
summarizes a patient's medical status for the purpose of information exchange.
The content may include administrative (registration, demographics, insurance, etc.)
and clinical (problem list, medication list, allergies, test results, etc.) information. By
offering data in a predefined and structured format, a native HL7 CCD promotes
interoperability between participating systems such as EHRs, personal health record
systems (PHRs), practice management applications and others. The expectation is
that consuming systems will be able to use the CCD information to input and/or
update information in their instantiation of the patient’s healthcare record.
However, as is often the case when a variety of information technology systems are
being used, CCD documents may be compiled using different protocols. In situations
where CCDs are not transmitted in a native format and recipients do not have the
proper system in place to consume the CCD, HISPs shall avail themselves of
software engines to make the CCD natively consumable before downloading the
CCD. The applicable policies on the import of a CCD into an EHR are not covered
here.
See the Health Information Technology Standards Panel (HITSP) Summary
Documents Using HL7 Continuity of Care Document (CCD) Component at
http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=4&PrefixNumeric=32,
for more detail.
2.8.2.
The Unstructured C62 Document
A C62 document contains “information blocks” which are not limited by format, with
the exception that it must be possible to generate an image. Sufficient metadata
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 35 of 69
May 2012
must be present to describe that information. The body of a C62 could include an
unstructured (e.g. UTF8 Text) presentation preserved format, such as PDF, which is
readily usable by end users, including consumers and providers. See the following
link for details on how to validate attached PDF documents:
http://www.pdflib.com/fileadmin/pdflib/pdf/pdfa/2009-05-04-Bavaria-report-onPDFA-validation-accuracy.pdf.
The C62 document may be used to capture and store patient identifiable,
unstructured document content, including unstructured lab test results.
2.8.3.
HISP Requirements
In addition to other requirements of the HISP Certification Program, a HISP shall
attest to allowing any internet connected DIRECT stakeholder with a valid DIRECT
email address the ability to send or receive DIRECT email messages with attached
documents, such as C32 and C62, to/from other valid DIRECT email addresses. In
addition to providing the ability to attach documents to DIRECT emails, HISPs shall
also allow their DIRECT email recipients to download any attached documents. If a
part of their provided services, they may perform translation and/or transformation
services to allow users to consume C32 documents.
The above requirements assume that all the sending and receiving stakeholders are
signed up with a trusted HISP. More detailed information on the various scenarios
and implications of HISP communication can be found in the HISP to HISP
Communication section.
2.9. Sending & Receiving DIRECT Emails
[Mandatory]
Because any deployment model can be used to send and any deployment model can be
used to receive DIRECT emails, HISPs need to be able to support different deployment
models.
2.9.1.
Sending and Receiving DIRECT Emails – Requirements
As part of the HISP Certification Program, a HISP shall attest to having the capability
and shall be willing to provide support to:

Send native/client (DIRECT) emails to DIRECT email users. This function
enables native/client (DIRECT) email users with the basic ability to send
secure messages to other DIRECT email users (client, Web Mail, EHR) in the
DIRECT community.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 36 of 69
May 2012

Support the combinations to/from Web mail, client email and EHR. This
function will enable the exchange of emails between native (client), Web mail
and EHR mail systems.

Support message content from unstructured data to structured data and vice
versa (including but not limited to PDF, text files, images, XML files and
others). This function will enable the data payload within emails to be
converted to and from structured and unstructured data formats.

Provide a DIRECT mail system for white space users. This function will enable
all interested white space users with a secured DIRECT enabled email system
that allows the users to be located in a global address book. It also provides
the basic functions (send, receive, reply, reply all, forward etc.) of a DIRECT
enabled mail system.

Receive DIRECT emails natively (client). This function provides native
(DIRECT) email users with the basic ability to receive email from other native
email users in the DIRECT community.

Send an encrypted Message Disposition Notification (MDN) when a message is
received by a DIRECT user.

Do text formatting. This function enables a DIRECT email user with the ability
to customize the text within an email (font choices, point size, underlining,
bold, italics etc.).

Save or export attachments out of the DIRECT mail system. This function
enables DIRECT email users to save received email attachments out to a local
storage format or directly import into an EHR. These attachments can be
structured as well as unstructured documents.

Locate and attach documents found in local storage to a DIRECT email and
send the whole package to other DIRECT email users. This function enables
DIRECT email users to attach documents from local storage and send those
documents to other DIRECT email users. These attachments can be
structured as well as unstructured documents.
2.9.2.
Additional Support Requirements
In addition to the above requirements, under certain scenarios correlated to HISP
services, HISPs shall also:
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 37 of 69
May 2012

Issue certificates as a Certificate Authority (CA) or obtain the certificates from
a trusted third-party CA

Ensure the authenticity of the sender and receiver via X.509 certificates

Assign unique DIRECT addresses to individuals or organizations

Associate X.509 certificates with full DIRECT address or Health Domain
Names

Provide an “edge” or “on-ramp” protocol or application/protocol combination
to the end user for sending and receiving messages and attachments

Access the White Pages of the CSS

Locate the destination's address

Locate the destination’s certificate

Package message content using MIME and, optionally, XDM

Secure the confidentiality and integrity of the content by handling it through
S/MIME encryption (using the destination’s public key) and signatures (using
the source’s private key)

Send the S/MIME message via SMTP

Receive S/MIME message via SMTP

Store (optionally) the S/MIME (encrypted) message

Do S/MIME decryption using the destination’s private key

Do S/MIME signature verification using the source’s public key

Do optional POP/IMAP

Do optional storage of decrypted content
The various deployment models will have different support needs as detailed in the
section Support for DIRECT.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 38 of 69
May 2012
2.10. Provide Access to Shared White Pages
In this HISP market, it is anticipated that some HISPs may desire to offer their
customers the address information located outside their own HISP community. This
could occur in a HISP to HISP communication scenario or a HISP to HIE communication
scenario. Because the HISPs will not have access to this information directly, PA eHC
will provide this data as a service offering. In order to meet this need, PA eHC chose to
enable a shared White Pages Directory containing healthcare provider information for all
healthcare providers associated with participating HISPs as part of the planned CSS
offering.
PA eHC certified HISPs will be able to access the CSS shared White Pages, for a fee, for
the purpose of providing their DIRECT participants with healthcare provider contact
information – see the section Support for DIRECT for more details. Certified HISPs are
expected to contribute DIRECT address contact details/updates for all of their HISP
participating Pennsylvania healthcare providers to the CSS White Pages. It is expected
that the CSS White Pages will be a comprehensive single source contact list for all HIE
and HISP participating healthcare providers in Pennsylvania.
The functional requirements for any PA eHC certified HISP wishing to access the CSS
shared White Pages are as follows:

CSS shared White Pages will provide healthcare provider contact information,
including the DIRECT address, for all providers associated with certified HISPs
and HIEs within the PA eHC affiliated community.

PA eHC certified HISP participants will be granted access to the CSS shared White
Pages in return for a mutually agreed upon periodic fee.

HISPs will access the CSS shared White Pages via a standards based defined
method (API, web service, etc.) for the purpose of acquiring individual provider
contact information or bulk updates (downloads) to their local provider contact
information.

HISPs will access the CSS shared White Pages via a standards based defined
method (API, web service, etc.) for the purpose of adding/updating individual
provider contact information or bulk additions/updates (uploads) to the CSS
shared White Pages from their local provider contact information.
HISPs will provide feedback to CSS on errors encountered during bulk updates and work
with CSS to resolve those errors.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 39 of 69
May 2012
2.11. Translation and Transformation
As part of the overall data exchange capability to be provided in the state, PA eHC
intends to foster the capability to transform data to/from structured or unstructured
formats and translate data content values based on accepted data vocabulary sets for all
participants. HISPs have the option to provide data transformation and translation
services as part of their service offering. If a HISP chooses to offer data transformation
and translation services, those services can be enabled directly by the HISP within their
own infrastructure or indirectly through a third-party organization. PA eHC will make it
clear through communication to the marketplace which HISPs offer
transformation/translation services.
Transformation, in the simplest terms, is the modification of the format of data that is
being transmitted between information systems. This data can include, but is not
limited to, patient clinical summaries, patient laboratory test orders/results, electronic
pharmacy prescriptions, patient administrative transactions, etc. As related to HISP
services, transformation services can include, but are not limited to, all of the following
message content transformation scenarios:

Standard HITSP C32 (Continuity of Care Document), to/from unstructured data
formats such as document, text, or PDF formats or other standard or nonstandard structured data formats

Standard HITSP C62 (Unstructured Document) used to transmit patient
identifiable documents or images, to/from unstructured data formats such as
document, text, or PDF formats or other standard or non-standard structured
data formats

Non-standard proprietary structured data formats, to/from unstructured data
formats such as document, text, or PDF formats or other standard or nonstandard structured data formats

Non-standard proprietary structured data formats, to/from structured data
formats such as C32, C62, XDS transactions or other standard or non-standard
structured data formats
Translation is the modification of data content values between sending and receiving
information systems. In most cases translation involves replacing non-standard data
content values with equivalent standardized content values based on published content
standards. As related to HISP services, translation services can include, but are not
limited to, all of the following message content translation scenarios:
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 40 of 69
May 2012

Standard logical observation identifiers names and codes (LOINC) data content
vocabulary values translated to/from proprietary or non-standard laboratory
ordering/test results data content vocabulary values

Standard CDC OIDS data content vocabulary values, translated to/from
proprietary or non-standard data content vocabulary values

Standard systematized nomenclature of medicine (SNOMED) data content
vocabulary values, translated to/from proprietary or non-standard data content
vocabulary values

Standard ICD–9 or ICD-10 data content vocabulary values, translated to/from
proprietary or non-standard data content vocabulary values
The requirements detailed in this functional specification do not apply to all HISPs.
These specifications are only applicable to HISPs that choose to directly or indirectly
enable data transformation and/or translation services.
The optional functions necessary to meet HISP certification transformation and
translation service capability requirements are as follows:

Enable the ability to provide the capability to transform source data content
structure (structured and unstructured) to a specified target data format
structure (structured and unstructured)

Enable the ability to provide the capability to translate source data content values
(standard and non-standard) to specified target data content values (standard
and non-standard)
2.12. HISP Business Continuity and Exit Strategy Requirements
[Mandatory]
Exit strategy requirements for HISPs fall into two categories. HISPs must have a
reasonable, executable business continuity plan that ensures there will be a
minimal disruption to the availability of DIRECT services as a result of adverse
events. HISPs must also have a business exit strategy that includes the
capability to, and agreement to, facilitate the transition of their DIRECT client
base to another provider, at no cost to their clients, in the event that the HISP
cannot continue as a viable provider of DIRECT services.
2.12.1.
Business Continuity Planning
A HISP certified by PA eHC to provide DIRECT messaging services must make
every reasonable effort to offer uninterrupted DIRECT services to their client
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 41 of 69
May 2012
base. In the event that internal or external factors impact the HISP’s operations,
the HISP must have a published business continuity plan in place containing all
actions, activities and tasks necessary to minimize DIRECT service disruption. In
the case of a service disruption, every effort must be made to return to full
operating capability within an acceptable time period with no degradation in
service delivery, systems integrity or data security.
2.12.2.
Business Exit Strategy
In the event that a HISP can no longer provide DIRECT messaging services to
their client base, due to internal or external factors, voluntary or involuntary, the
HISP must have the capability to transition its client base to another PA eHC
certified HISP. DIRECT service transfer must be orderly, timely, provide for
minimal service disruption and be at no cost to the DIRECT client base.
2.13. Audit Logging
[Mandatory]
This section defines logging and auditing functions that form part of the certification
program requirements for the Pennsylvania HIE-Network. Effective logging and auditing
practices are essential safeguards for PHI shared at any level and can assure
participants that there is compliance with legal requirements for technical, physical and
administrative safeguards. At least as importantly, publicly announced auditing and
logging practices can foster trust among individual patients and the general public that
data is being used only in appropriate ways.
2.13.1.

Audit Logging
All organizations participating in the Pennsylvania HIE-Network shall maintain an
audit log of all logins, logouts and failed logins that occur as part of an
authentication process that potentially provides user access to the CSS or other
access to PHI.

All HISPs shall maintain audit logs that documents individuals accessing PHI. The
audit logs shall minimally identify:
o
The user accessing the health information
o
User Location/Department
o
Date/Time (when accessed)
o
Device identifier (i.e. subsystem or system of origin of the event [access
request])
o
Content (type of data being accessed)
o
Type of action (e.g. read, write, update, delete, or copy) or access for
diagnostic purposes.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 42 of 69
May 2012

All HISPs shall develop and adopt minimum standards for routine auditing on
individuals’ access of PHI.

All HISPs shall develop and adopt:
o
The data elements to be maintained and exchanged for auditing
individuals’ access of PHI
o
The frequency and by whom the auditing will be accomplished within their
organization

o
The minimum retention time of audit logs maintained
o
Procedures for reporting audit results
All HISPs shall develop and adopt procedures for:
o
Informing the patient(s), the person(s) or organization(s) committing the
breach, and other participating HISPs, concerning situations where PHI
may have been inappropriately accessed
o
Informing the patient(s), the person(s) or organization(s) affected by a
breach. The owners of the breached PHI must be notified in accordance
with HIPAA.
o
Conduct investigations of such situations
o
Notify PA eHC and provide a corrective action plan
2.13.2.
Logging and Audit Controls under HIPAA
The HIPAA Privacy Rule provides that “a covered entity must have in place
appropriate administrative, technical, and physical safeguards to protect the privacy
of protected health information”, re 45 CFR § 164.530 (c)(1). An effective audit and
logging system will often be part of the overall set of safeguards expected under the
Privacy Rule. The HIPAA Security Rule is more specific, in that Section 164.312(b)
requires audit controls as a standard: “Implementing hardware, software, and/or
procedural mechanisms that record and examine activity in information systems that
contain or use electronic protected health information”; and, “Implementing
procedures to regularly review records of information system activity, such as audit
logs, access reports, and security incident tracking reports” are necessary.
2.13.3.
Audit and Accountability Checklist
The following is the minimally required audit and accountability checklist for systems
and solutions that may potentially expose PHI. This checklist is intended to apply to
HISPs that apply for certification and it represents good practice for a broader range
of covered entities.

The system is required to log users’ system login and logoff with date and
time.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 43 of 69
May 2012

The system capability shall include logging, reading, creating, updating,
deleting, forwarding, and printing access initiated by individuals and
processes for systems containing confidential and restricted data. For data
warehouses, data marts, and operational data stores, the system must have
the ability to log queries, or alternatively the tables read must be logged. Row
level logging must be available on demand.

All audit records must be identified by a unique record key or number and
include:
o
The user (user identifier/name of user) accessing the health
information
o
User location/department
o
Date/Time (when accessed)
o
Device identifier (i.e. subsystem or system of origin of the event
[access request])
o
Content (type of data being accessed or activity being performed)
o
Type of action (e.g. read, write, update, delete, or copy) or access for
diagnostic purposes

Unsuccessful login attempts and access violations within the system must be
logged.

Security administrative functions must be logged.

System administrative functions must be logged.

Audit records must be protected against unauthorized access, modifications,
and deletion.

Audit records must be readily available for 90 days and archived for a
minimum of seven years.

Security administrators and auditors can request or generate reports which
may consist of any or all of the audit record elements for any or all types of
actions.
2.13.4.
Categories of Logging and Audit Controls
In addition to the checklist, there are additional logging and auditing control
functions that shall be required of the HISPs.

Audit of access to high profile/VIP records
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 44 of 69
May 2012

Procedures for follow-up on suspicious activity, such as indications of possible
privacy or security breaches

Review of network intrusion detection system activity logs

Review of system administrator authorizations and activity

Review of physical access to data centers

Other reviews of technical, physical, and administrative safeguards as
established by the policies of the organization.

Beyond these sorts of compliance efforts, it is recommended that HISPs have
random audits of demographic and clinical records (only if these records have
been decrypted and re-encrypted in their system prior to resending). These
random audits are based on the level of risk for that portion of the system.
HISPs shall also provide for some level of random audits (sampling) for the
participants in the HISP.
o
The HISP logs and monitors all system activity and any expanded
query access. See Audit and Accountability Checklist section.
o
Access to the HISP for users determined to be a risk to security will be
suspended, terminated and/or flagged for enhanced security review
commensurate with the potential risk.
o
Patients/consumers are provided the means and opportunity to
request an audit report of who has accessed their health information
through the HISP, including utilization of expanded query. Audit
reports do not contain personal health information. The HISP
establishes specific procedures to respond to patient requests for audit
reports in a timely manner.
o
As part of the HISP user security audit, the staff identifies users that
potentially “misused” the HISP by accessing individually identifiable
health information without meeting the need-to-know standard.
o
Follow-up/Legal Action – Upon a determination that an authorized user
has not complied with this privacy policy, the user's access may be
suspended, limited or revoked if doing so is necessary for the privacy
of individuals or the security of the HISP.
2.13.5.
Violations and Enforcement
HISPs are required to notify PA eHC of any breach in security.

A “breach” is defined as the unauthorized acquisition, access, use or
disclosure of PHI in a manner not permitted by the Privacy Rule or Security
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 45 of 69
May 2012
Regulation (45 CFR 164.402) which compromises the security or privacy of
such PHI such that the use or disclosure poses a significant risk of financial,
reputational or other harm to the individual.

Reporting of any breach, detected by the HISP, requires notifying the
patient(s), the person(s) or the organization(s) committing the breach, and
other participating HISPs that were part of the violation. Additionally, the
owner(s) of the breached PHI, including patient(s), provider(s) and
organization(s) must be notified. A copy of that report shall also be sent to
PA eHC.

A corrective action request is completed and appropriate actions shall be
taken.
2.13.6.
Sanctions
Sanctions shall be applied where necessary.

Appropriate sanctions are applied by the HISP as required, up to and
including full suspension from the HISP for a specified period.

Processes for carrying out sanctions (e.g. dispute resolution procedures,
termination procedures, etc.) shall be covered in the HISP’s Standard
Operating Procedures (SOP).
2.13.7.

Definitions
Audit Log: The term audit log shall mean a record of actions performed on
data. Examples are creation, queries, views, additions, deletions and changes.

Audit Trail: The term audit trail shall mean a record that shows who has
accessed a computer system, when it was accessed and what operations were
performed for users at any level.

Protected Health Information (PHI): The term Protected Health
Information shall have the meaning ascribed to it by 45 CFR 160.103, and
shall include, but not be limited to, written or electronic information relating
to the diagnosis, treatment, test, prognosis, admission, discharge, transfer,
prescription, claims and/or other data or information implicitly or explicitly
identifying a patient to whom items or services are provided by a participant.

Unsecured Protected Health Information:
The term Unsecured Protected Health Information shall mean protected
health information that has not been secured through the use of technology
or methodology standards as provided by federal law.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 46 of 69
May 2012
3.
HISP Certification Program Reporting
PA eHC, along with participating HISPs, shall provide reports on the application process, the
certification process and afterwards during operations. The qualitative reports will utilize a
memo format, whereas quantitative reports will have a format specified by PA eHC.
A reporting matrix will be provided by PA eHC at the beginning of the certification process to
summarize the written content. Reporting shall start at the beginning of the application
process and continue until certification is complete.
3.1
HISP Service Categories
HISPs are certified according to the range of services they support and provide to their
users and PA eHC will need reporting of certain measures (see below) broken down by
these service categories. Full details of the categories may be found elsewhere in the
FSDs, but for reporting purposes the following categories will be used.

HISP acts as CA/RA

HISP has access to unencrypted data, i.e. manages the private keys of the
address holder

HISP uses SMTP, S/MIME protocols to communicate with other HISPs

HISP supports desktop-email client(s) (such as Outlook) that supports POP-S
and IMPA-S interfaces using SSL connections

HISP supports desktop-email client(s) (such as Outlook) that supports POP-S
and IMPA-S interfaces using HTTPS connections

HISP supports DIRECT email via natively coded EHR or API provided by the HISP
using SSL connections

HISP supports DIRECT email via natively coded EHR or API provided by the HISP
using HTTPS connections
Please note that HISPs will most likely have multiple categories it should be able to
report on.
3.2
Certification Process Feedback and Reporting
The following reporting requirements apply during the certification process:
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 47 of 69
May 2012
a. Prior to the certification process, the following information is required from the
HISP to establish a baseline: The number of users signed up with the HISP in
total and broken down by service categories.
b. During the certification process, a daily report shall be provided by the HISP to
PA eHC in the form of a memo. This memo shall include progress to date,
issues that have been encountered, and constructive feedback about the
certification process. This report must also include the number of test plan items
completed so that PA eHC can track the HISP’s certification progress. (Please
see the HISP Certification Program flowchart.)
Note: If the HISP has a problem and is unable to complete a test plan item, the
HISP shall notify PA eHC via the daily report memo and the HISP and PA eHC
shall work together to resolve the issue.
c. Once testing is underway, the HISP shall provide proof/attestation documents
for the Portal Delivery, Email Client and/or EHR DIRECT Email Integration
test plans as attachments to the daily report memo.
The test plan attestation sheets shall be used to provide daily inputs to PA eHC
regarding progress achieved. Additionally, the following information shall be
logged:

The number of failed message attempts the HISP encountered during
testing:
o The number of times the test message had to be retried before
success
o Cause and corrective action for the failures
d. At the conclusion of the certification process, constructive observations about
the overall process would be appreciated so that PA eHC can continually improve
the process.
e. If the HISP uses a subcontractor or vendors to help provide their services, PA
eHC may require performance reports on the subcontractor/vendor.
f.
PA eHC shall require the HISPs to monitor the reporting requirements as
detailed in any SLA, BAA, or DURSA in effect with their clients and provide that
information to PA eHC on a monthly basis. This information will not be used to
make public comparisons between the HISPs. Such requirements can include
but not be limited to:
1) System:
 Availability percentage
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 48 of 69
May 2012
2)
3)
4)
5)
 Average response time
Support and maintenance:
 System availability
 Service restoration downtime
 Status of the hosting site
Verification of annual disaster recovery testing
 Date of test
 Results
 Cause and corrective action of any issues
 Verification of corrective action
Support and maintenance functions for a customer support center (if
applicable) including:
 Number of calls
 Time to answer
 The number of abandoned calls
Issue and issue resolution
 Unauthorized access, use, release, or disclosure of data
 Other contract compliance issues
g. HISPs are expected to fully comply with all Pennsylvania and federal laws and
other regulations including but not limited to HIPAA privacy and security, CMS
regulations/requirements, etc. Those requirements are expected to be flowed
through to their vendors, and will be attested to in the FSD PS 1.3.2.3 DIRECT
Trust Certificate Policy Attestation v2.1, FSD PS 1.3.2.1 HIPAA
Compliance Attestation v2, FSD PS 1.3.1.61 DIRECT Pilot Participant
Attestation v2.1, TS 1.3.2.50 email Client Test Plan, TP 1.3.2.41 Portal
Delivery Test Plan or TP 1.3.3.7 EHR DIRECT Message Integration Test
Plan documents.
h. Any other reports as required by the PA eHC HISP Participation Agreement.
3.2.
Operations Reporting
3.2.1 General
Upon certification, HISPs shall be required to provide reports that will permit
PA eHC to effectively oversee HISP/DIRECT activity within the commonwealth.
The following reporting requirements apply:

Participating HISPs shall provide monthly functional reports, as
described below, not to arrive later than the 6th of each month.

PA eHC will aggregate information at a statewide level, de-identifying
results from individual HISPs. All aggregated information will be
public record.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 49 of 69
May 2012

Participating HISPs may choose to allow PA eHC to include their
functional reporting in public record reporting.

Specific formats for reports from participating HISPs to PA eHC and
for aggregated reports published by PA eHC will be created in
cooperation with the HISP Reporting Oversight Committee.

Where possible, measures will include baselines and change over
time.
3.2.2 Monthly Reportable Items
All of the below shall be reported both in total and broken down by service
categories unless otherwise noted:
1) New registrations

The number of new users registered during the reporting
month

Aggregate number of messages sent from those new accounts
during their first 30 days
2)
The number of accounts the HISP services at the end of each month
3)
Number of HISP to HISP messages sent
4)
Number of HISP to HISP messages received
5)
Number of secure electronic communications sent by providers
6)
Number of secure electronic communications received by providers
7)
Number of messages with attachments
8)
Number of unique DIRECT addresses that were used to send a
message
9)
Number of unique DIRECT addresses that were used to send a
message with an attachment.
10) Number of unique DIRECT addresses receiving a message
11) Number of unique DIRECT addresses receiving a message with an
attachment.
12) Number of failed message transports

The cause

The corrective action

Verification that the corrective action was effective
13) Number of accounts disabled and reason(s) for disabling
14) Number of accounts reactivated
15) Number of certificates revoked and reason(s) for revocation
16) Number of certificates reactivated (from a revocation)
17) Number of X.509 Certificates issued (if performing RA/CA functions)
18) Number of user X.509 Certificate renewals
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 50 of 69
May 2012

Any changes to certificate information shall be reported by the
HISP

Any changes to the certificate policy
19) Number of new users who already have an X.509 Certificate

Who issued the certificate?

Who holds the root?

What type of certificate is it?
3.2.3 Changes to Certificates
The monthly report shall include an additional narrative describing any
changes to certificate information, status, or policy statement, with detailed
explanation.
3.2.4 Special Reports
Upon request, the HISP shall provide PA eHC with a listing of names and
addresses of their participants so that PA eHC may conduct a “Satisfaction
and Value” survey. The survey is anticipated to be conducted annually.
3.3.
HISP Reporting Oversight Committee
PA eHC will constitute a HISP Reporting Oversight Committee (HISPROC), to advise and
collaborate with PA eHC regarding ongoing HISP reporting activities. Certified HISPs
are required to provide at least one representative each to participate in the HISPROC.
Any changes to functional reporting requirements, timing or methodology must be
reviewed and accepted by a majority of HISPROC members prior to adoption.
It is assumed that all HISPs currently have the infrastructure capability to gather the
aforementioned data. If this is not the case, the HISPROC may consider changing
requirements that the HISPs mutually agree are not reasonable, unless the change
would interfere with PA eHC’s capabilities to meet federal grant compliance
requirements.
4. Assumptions / Dependencies / Constraints / Exclusions
4.1.
Assumptions
It is assumed that:

A trust environment with underlying public key infrastructure (PKI) is in place for
the DIRECT community to exchange secure DIRECT email messages, with or
without attachments.

Security certificates compliant with the PKI rules and regulations prescribed by
the governing entity are available for the DIRECT community.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 51 of 69
May 2012

PA eHC may issue, directly or through a third party, a single root X.509 digital
certificate aligned with DirectTrust.org.

Certificate policies for digital certificates issued to participating PA eHC certified
entities within Pennsylvania may be directly or indirectly chained to the PA eHC’s
root certificate if PA eHC stand up its own CA.

Participating RAs, identifying and authenticating entities to receive digital
certificates chained to the PA eHC root certificate, will be certified to do so by PA
eHC.

Participating CAs, issuing digital certificates directly or indirectly chained to the
PA eHC root certificate, will be certified by PA eHC to do so.

During the new user registration process, the HISP shall require the user(s) to
agree with the legal terms and conditions required by the governance process.

The HISP will provide ongoing support functions for end users. Ongoing support
functions may include, but are not limited to: help desk services, application
support, technical support, systems analysis, and other end user support
services.

That the applicable rules as specified by the DIRECT Project, the HIPAA Privacy
Standards, and any other applicable health security policies and specifications,
are followed.

Access to PA eHC’s CSS will only be available to PA eHC certified HISPs that are
members of the PA eHC trust community.

HISPs within the PA eHC trust community can conduct inter-HISP DIRECT
message exchange with HISPs which are not members of the trust community
by exchanging X.509 digital certificates, and thus establishing a trusted
relationship.

A HISP must have met all defined PA eHC HISP certification criteria and
currently be certified/in good standing in order to be granted access to the CSS
shared White Pages.

Access to the PA eHC’s CSS shared White Pages will only be available to PA eHC
certified HISPs that are members of the PA eHC trust community.

An individual HISP will only be allowed to update CSS shared White Pages
information for participating providers that were added to the CSS shared White
Pages by that HISP.

Transformation and Translation are optional services which may be, but do not
have to be, offered by a HISP seeking certification to provide HISP services.

HISPs are proper business ventures in good standing and have proof at hand for
PA eHC to inspect.

Business Continuity Plans and Exit Strategies are available for review by PA eHC

PA eHC reserves the right to revise the HISP Certification requirements. A policy
will be developed for collaborating with the HISPs about such changes.
4.2.
Dependencies
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 52 of 69
May 2012

HISP(s) shall be fully operational and willing to provide online provisioning
services to the DIRECT community.

Standards must be adopted for the identification and authentication of entities to
be issued digital certificates for DIRECT message exchange.

Standards must be adopted for the certification of CAs issuing digital certificates
directly or indirectly chained to the PA eHC root certificate.

Standards must be adopted for the certification of RAs identifying and
authenticating entities to receive digital certificates chained to the PA eHC root
certificate.

Parties engaging in Transformation / Translation integration functions must
agree to source / target data content format and value(s).

Standards must be adopted for transactions related to accessing and utilizing
data from the CSS shared White Pages.
4.3.

4.4.

o
Addition
o
Access
o
Update
o
Deactivation
Constraints
DirectTrust.org Certificate Policies are still in draft, and could change in the
future.
Exclusions
Access to the CSS, including DIRECT message address information, will not be
available to non-certified HISPs offering HISP services within Pennsylvania.

Access to the CSS, including shared White Pages information, will not be
available to non-certified HISPs offering HISP services within Pennsylvania.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 53 of 69
May 2012
5. Standards and/or Reference Documents
A list of key reference documents and background material is provided in the table below.
These documents can be retrieved from the links provided.
Table 4-1 Reference Documents
Document ID – Title
Link
National Institute of Standards and
Technology – Special Publication
800-118 Guide to Enterprise
Password Management
http://csrc.nist.gov/publications/drafts/800-
X.509 Certificate Policy for the
Federal Bridge Certification Authority
(FBCA)
http://www.idmanagement.gov/fpkipa/docume
DirectTrust Ecosystem Community
x.509 Certificate Policy – Draft For
Trial Use
http://directtrust.wikispaces.com/Direct+Ecosy
Deployment Models
http://wiki.directproject.org/Deployment+Mode
118/draft-sp800-118.pdf
nts/FBCA_CP_RFC3647.pdf
stem+Certificate+Policy
ls
Applicability Statement for Secure
Health Transport (ASSHT)
http://wiki.directproject.org/Applicability+State
XDR and XDM for Direct Messaging
Specification
http://wiki.directproject.org/XDR+and+XDM+f
Direct Trusted Exchange Rules of the
Road
http://wiki.directproject.org/Direct+Rules+of+t
HITSP Summary Documents Using
HL7 Continuity of Care Document
Component
http://www.hitsp.org/ConstructSet_Details.asp
Bavaria Report on PDF/A Validation
Accuracy
http://www.pdflib.com/fileadmin/pdflib/pdf/pdf
ment+for+Secure+Health+Transport
or+Direct+Messaging
he+Road
x?&PrefixAlpha=4&PrefixNumeric=32
a/2009-05-04-Bavaria-report-on-PDFAvalidation-accuracy.pdf
6. Approvals
Approved By: __________________________________
Date: _____________
Approved By: __________________________________
Date: _____________
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 54 of 69
May 2012
Appendix A – HIPAA compliance Attestation sheet
1. Org. Name:
2. Address:
3. Telephone:
4. Applicant:
5. Title/Role:
Applicant attests to the following:
1. Applicant is fully accredited by the Electronic Healthcare Network Accreditation
Commission (EHNAC) through their Health Information Exchange Accreditation
Program (HIEAP);
Yes☐
No☐
AND the accreditation is current and in proper standing.
Yes☐
No☐
Note: If applicant attests “Yes” to both questions in this question set, then applicant
may skip questions 2 and 3 below.
2. Applicant has used the NIST HSR Toolkit and, upon request, can provide proof to be
fully compliant with the HITECH Act and HIPAA Privacy and Security Rules.
Yes☐
No☐
Note: If applicant attests “Yes” to this question, then applicant may skip question 3
below.
3. Applicant has sufficient policies and procedures in place to ensure continuing
compliance with all applicable federal laws that apply to health information
exchange, including the HITECH Act and the HIPAA Privacy and Security Rules, and,
upon request, can provide concrete proof to be fully compliant with the HITECH Act
and HIPAA Privacy and Security Rules.
Yes☐
No☐
Signature of Authorized Representative/Applicant:
_____________________________________
Printed Name of Authorized Representative:
_____________________________________
Date:
_________________
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 55 of 69
May 2012
APPENDIX B – Measures to Ensure Data Privacy and
Confidentiality
The NIST HSR Toolkit focuses on the following to help organizations ascertain HIPAA
compliance:
164.308 ADMINISTRATIVE SAFEGUARDS
164.308(a)(1)(i) Standard: Security management process. Implement policies and
procedures to prevent, detect, contain and correct security violations.
164.308(a)(1)(ii) Implementation specifications:
164.308(a)(1)(ii)(B) Risk management (Required). Implement security measures sufficient
to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with
164.306(a).
164.308(a)(1)(ii)(C) Sanction policy (Required). Apply appropriate sanctions against
workforce members who fail to comply with the security policies and procedures of the
covered entity.
164.308(a)(1)(ii)(D) Information system activity review (Required). Implement procedures
to regularly review records of information system activity, such as audit logs, access reports
and security incident tracking reports.
164.308(a)(2) Standard: Assigned security responsibility. Identify the security official who is
responsible for the development and implementation of the policies and procedures required
by this subpart for the entity.
164.308(a)(3)(i) Standard: Workforce security. Implement policies and procedures to
ensure that all members of its workforce have appropriate access to electronic protected
health information, as provided under paragraph (a)(4) of this section, and to prevent those
workforce members who do not have access under paragraph (a)(4) of this section from
obtaining access to electronic protected health information.
164.308(a)(3)(ii) Implementation specifications:
164.308(a)(3)(A) Authorization and/or supervision (ADDRESSABLE). Implement procedures
for the authorization and/or supervision of workforce members who work with electronic
protected health information or in locations where it might be accessed.
164.308(a)(3)(B) Workforce clearance procedure (ADDRESSABLE). Implement procedures
to determine that the access of a workforce member to electronic protected health
information is appropriate.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 56 of 69
May 2012
164.308(a)(3)(C) Termination procedures (ADDRESSABLE). Implement procedures for
terminating access to electronic protected health information when the employment of a
workforce member ends or as required by determinations made as specified in paragraph
(a)(3)(ii)(B) of this section.
164.308(a)(4)(i) Standard: Information access management. Implement policies and
procedures for authorizing access to electronic protected health information that are
consistent with the applicable requirements of subpart E of this part.
164.308(a)(4)(ii) Implementation specifications:
164.308(a)(4)(ii)(A) Isolating health care clearinghouse functions (Required). If a health
care clearinghouse is part of a larger organization, the clearinghouse must implement
policies and procedures that protect the electronic protected health information of the
clearinghouse from unauthorized access by the larger organization.
164.308(a)(4)(ii)(B) Access authorization (ADDRESSABLE). Implement policies and
procedures for granting access to electronic protected health information, for example,
through access to a workstation, transaction, program, process, or other mechanism.
164.308(a)(4)(ii)(C) Access establishment and modification (ADDRESSABLE). Implement
policies and procedures that, based upon the entity's access authorization policies,
establish, document, review, and modify a user's right of access to a workstation,
transaction, program, or process.
164.308(a)(5)(i) Standard: Security awareness and training. Implement a security
awareness and training program for all members of its workforce (including management).
164.308(a)(5)(ii) Implementation specifications:
164.308(a)(5)(ii)(A) Security reminders (ADDRESSABLE). Periodic security updates.
164.308(a)(5)(ii)(B) Protection from malicious software (ADDRESSABLE). Procedures for
guarding against, detecting, and reporting malicious software.
164.308(a)(6)(i) Standard: Security incident procedures. Implement policies and
procedures to address security incidents.
164.308(a)(6)(ii) Implementation specification: Response and Reporting (Required).
Identify and respond to suspected or known security incidents; mitigate, to the extent
practicable, harmful effects of security incidents that are known to the covered entity; and
document security incidents and their outcomes.
164.308(a)(7)(i) Standard: Contingency plan. Establish (and implement as needed) policies
and procedures for responding to an emergency or other occurrence (for example, fire,
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 57 of 69
May 2012
vandalism, system failure, and natural disaster) that damages systems that contain
electronic protected health information.
164.308(a)(7)(ii) Implementation specifications:
164.308(a)(7)(ii)(A) Data backup plan (Required). Establish and implement procedures to
create and maintain retrievable exact copies of electronic protected health information.
164.308(a)(7)(ii)(C) Emergency mode operation plan (Required). Establish (and implement
as needed) procedures to enable continuation of critical business processes for protection of
the security of electronic protected health information while operating in emergency mode.
164.308(a)(7)(ii)(D) Testing and revision procedures (ADDRESSABLE). Implement
procedures for periodic testing and revision of contingency plans.
164.308(a)(7)(ii)(E) Applications and data criticality analysis (ADDRESSABLE). Assess the
relative criticality of specific applications and data in support of other contingency plan
components.
164.308(a)(8) Standard: Evaluation. Perform a periodic technical and nontechnical
evaluation, based initially upon the standards implemented under this rule and
subsequently, in response to environmental or operational changes affecting the security of
electronic protected health information, that establishes the extent to which an entity's
security policies and procedures meet the requirements of this subpart.
164.308(b)(1) Standard: Business associate contracts and other arrangements. A covered
entity, in accordance with164.306, may permit a business associate to create, receive,
maintain, or transmit electronic protected health information on the covered entity's behalf
only if the covered entity obtains satisfactory assurances, in accordance with 164.314(a)
that the business associate will appropriately safeguard the information.
164.310 PHYSICAL SAFEGUARDS
164.310(a)(1) Standard: Facility access controls. Implement policies and procedures to limit
physical access to its electronic information systems and the facility or facilities in which
they are housed, while ensuring that properly authorized access is allowed.
164.310(a)(2) Implementation specifications:
163.310(a)(2)(i) Contingency operations (ADDRESSABLE). Establish (and implement as
needed) procedures that allow facility access in support of restoration of lost data under the
disaster recovery plan and emergency mode operations plan in the event of an emergency.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 58 of 69
May 2012
164.310(a)(2)(ii) Facility security plan (ADDRESSABLE). Implement policies and procedures
to safeguard the facility and the equipment therein from unauthorized physical access,
tampering, and theft.
163.310(a)(2)(iii) Access control and validation procedures (ADDRESSABLE). Implement
procedures to control and validate a person's access to facilities based on their role or
function, including visitor control, and control of access to software programs for testing and
revision.
163.310(a)(2)(iv) Maintenance records (ADDRESSABLE). Implement policies and
procedures to document repairs and modifications to the physical components of a facility
which are related to security (for example, hardware, walls, doors, and locks).
164.310(b) Standard: Workstation use. Implement policies and procedures that specify the
proper functions to be performed, the manner in which those functions are to be performed,
and the physical attributes of the surroundings of a specific workstation or class of
workstation that can access electronic protected health information.
164.310(c) Standard: Workstation security. Implement physical safeguards for all
workstations that access electronic protected health information, to restrict access to
authorized users.
164.310(d)(1) Standard: Device and media controls. Implement policies and procedures
that govern the receipt and removal of hardware and electronic media that contain
electronic protected health information into and out of a facility, and the movement of these
items within the facility.
164.310(d)(2) Implementation specifications:
164.310(d)(2)(i) Disposal (Required). Implement policies and procedures to address the
final disposition of electronic protected health information, and/or the hardware or electronic
media on which it is stored.
164.310(d)(2)(ii) Media re-use (Required). Implement procedures for removal of electronic
protected health information from electronic media before the media are made available for
re-use.
164.310(d)(2)(iii) Accountability (ADDRESSABLE). Maintain a record of the movements of
hardware and electronic media and any person responsible therefore.
164.310(d)(2)(iv) Data backup and storage (ADDRESSABLE). Create a retrievable, exact
copy of electronic protected health information, when needed, before movement of
equipment.
164.312 TECHNICAL SAFEGUARDS
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 59 of 69
May 2012
164.312(a)(1) Standard: Access control. Implement technical policies and procedures for
electronic information systems that maintain electronic protected health information to allow
access only to those persons or software programs that have been granted access rights as
specified in 164.308(a)(4).
164.312(a)(2)(i) Unique user identification (Required). Assign a unique name and/or
number for identifying and tracking user identity.
164.312(a)(2)(ii) Emergency access procedure (Required). Establish (and implement as
needed) procedures for obtaining necessary electronic protected health information during
an emergency.
164.312(a)(2)(iii) Automatic logoff (ADDRESSABLE). Implement electronic procedures that
terminate an electronic session after a predetermined time of inactivity.
164.312(a)(2)(iv) Encryption and decryption (ADDRESSABLE). Implement a mechanism to
encrypt and decrypt electronic protected health information.
164.312(b) Standard: Audit controls. Implement hardware, software, and/or procedural
mechanisms that record and examine activity in information systems that contain or use
electronic protected health information.
164.312(c)(1) Standard: Integrity. Implement policies and procedures to protect electronic
protected health information from improper alteration or destruction.
164.312(c)(2) Implementation specification: Mechanism to authenticate electronic protected
health information (ADDRESSABLE). Implement electronic mechanisms to corroborate that
electronic protected health information has not been altered or destroyed in an
unauthorized manner.
164.312(d) Standard: Person or entity authentication. Implement procedures to verify that
a person or entity seeking access to electronic protected health information is the one
claimed.
164.312(e)(1) Standard: Transmission security. Implement technical security measures to
guard against unauthorized access to electronic protected health information that is being
transmitted over an electronic communications network.
164.312(e)(2) Implementation specifications:
164.312(e)(2)(i) Integrity controls (ADDRESSABLE). Implement security measures to
ensure that electronically transmitted electronic protected health information is not
improperly modified without detection until disposed of.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 60 of 69
May 2012
164.312(e)(2)(ii) Encryption (ADDRESSABLE). Implement a mechanism to encrypt
electronic protected health information whenever deemed appropriate.
164.314 ORGANIZATIONAL REQUIREMENTS
164.314(a)(1) Standard: Business associate contracts or other arrangements.
164.314(a)(1)(i) The contract or other arrangement between the covered entity and its
business associate required by 164.308(b) must meet the requirements of paragraph
(a)(2)(i) or (a)(2)(ii) of this section, as applicable.
164.314(a)(1)(ii) A covered entity is not in compliance with the standards in 164.502(e)
and paragraph (a) of this section if the covered entity knew of a pattern of an activity or
practice of the business associate that constituted a material breach or violation of the
business associate's obligation under the contract or other arrangement, unless the covered
entity took reasonable steps to cure the breach or end the violation, as applicable, and, if
such steps were unsuccessful.
164.314(a)(1)(ii)(A) Terminated the contract or arrangement, if feasible; or
164.314(a)(1)(ii)(B) If termination is not feasible, reported the problem to the Secretary.
164.314(a)(2)(i)(A) Implement administrative, physical, and technical safeguards that
reasonably and appropriately protect the confidentiality, integrity, and availability of the
electronic protected health information that it creates, receives, maintains, or transmits on
behalf of the covered entity as required by this subpart;
164.314(a)(2)(i)(B) Ensure that any agent, including a subcontractor, to whom it provides
such information agrees to implement reasonable and appropriate safeguards to protect it.
164.314(a)(2)(i)(C) Report to the covered entity any security incident of which it becomes
aware.
164.314(a)(2)(i)(D) Authorize termination of the contract by the covered entity, if the
covered entity determines that the business associate has violated a material term of the
contract.
164.314(a)(2)((ii) Other arrangements. (A) When a covered entity and its business
associate are both governmental entities, the covered entity is in compliance with paragraph
(a)(1) of this section,
164.314(a)(2)((ii)(1) It enters into a memorandum of understanding with the business
associate that contains terms that accomplish the objectives of paragraph (a)(2)(i) of this
section; or
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 61 of 69
May 2012
164.314(a)(2)((ii)(2) Other law (including regulations adopted by the covered entity or its
business associate) contains requirements applicable to the business associate that
accomplish the objectives of paragraph (a)(2)(i) of this section.
164.314(a)(2)((ii)(B) If a business associate is required by law to perform a function or
activity on behalf of a covered entity or to provide a service described in the definition of
business associate as specified in160.103 of this subchapter to a covered entity, the
covered entity may permit the business associate to create, receive, maintain, or transmit
electronic protected health information on its behalf to the extent necessary to comply with
the legal mandate without meeting the requirements of paragraph (a)(2)(i) of this section,
provided that the covered entity attempts in good faith to obtain satisfactory assurances as
required by paragraph (a)(2)(ii)(A) of this section, and documents the attempt and the
reasons that these assurances cannot be obtained.
164.314(a)(2)((ii)(C) The covered entity may omit from its other arrangements
authorization of the termination of the contract by the covered entity, as required by
paragraph (a)(2)(i) (D) of this section if such authorization is inconsistent with the statutory
obligations of the covered entity or its business associate.
164.314(b)(1) Standard: Requirements for group health plans. Except when the only
electronic protected health information disclosed to a plan sponsor is disclosed pursuant to
164.504(f)(1)(ii) or (iii), or as authorized under 164.508, a group health plan must ensure
that its plan documents provide that the plan sponsor will reasonably and appropriately
safeguard electronic protected health information created, received, maintained, or
transmitted to or by the plan sponsor on behalf of the group health plan.
164.314(b)(2) Implementation specifications (Required). The plan documents of the group
health plan must be amended to incorporate provisions to require the plan sponsor to
implement safeguards.
164.316 POLICES AND PROCEDURES AND DOCUMENTATION REQUIREMENTS
164.316(a) Standard: Policies and procedures. Implement reasonable and appropriate
policies and procedures to comply with the standards, implementation specifications, or
other requirements of this subpart, taking into account those factors specified in subsection
164.306(b)(2)(i), (ii), (iii), and (iv). This standard is not to be construed to permit or
excuse an action that violates any other standard, implementation specification, or other
requirements of this subpart. A covered entity may change its policies and procedures at
any time, provided that the changes are documented and are implemented in accordance
with this subpart.
164.316(b)(1) Standard: Documentation.
164.316(b)(2) Implementation specifications:
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 62 of 69
May 2012
164.316(b)(2)(i) Time limit (Required). Retain the documentation required by paragraph
(b)(1) of this section for 6 years from the date of its creation or the date when it last was in
effect, whichever is later.
164.316(b)(2)(ii) Availability (Required). Make documentation available to those persons
responsible for implementing the procedures to which the documentation pertains.
164.316(b)(2)(iii) Updates (Required). Review documentation periodically, and update as
needed, in response to environmental or operational changes affecting the security of the
electronic protected health information.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 63 of 69
May 2012
APPENDIX C – HIPAA Compliance Attestation
HIPAA Compliance Attestation
New Certification
needed?
Start
Receive new
certification
Apps
Yes
No
Time to Renew
Certification?
Yes
Renewal
Notification
process
Receive
Renewal
Apps
prepare for
screening
process
No
Exit
Notify applicant
Log
Yes
Monitoring
process
Yes
All critical Info
provided?
No
Yes
Certification
Program
Compliant?
Start
Screening
process
All Screening
Tests OK?
No
HIPAA
Attestation
screening
No
No
NonCompliance
process
Flag test OK –
Yes/No
More Screening
tests?
Yes
Yes
HIPAA
Attestation
Compliant?
No
Appeal?
Yes
Revoke existing
Certification
No
Reject
Certification
Apps
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Existing
Certification?
Page 64 of 69
No
Exit
May 2012
Yes
APPENDIX D – DIRECT Trust Certificate Policy Attestation
DIRECT Trust Certificate Policy Attestation
New Certification
needed?
Start
Receive new
certification
Apps
Yes
No
Time to Renew
Certification?
Yes
Renewal
Notification
process
Receive
Renewal
Apps
prepare for
screening
process
No
Exit
Notify applicant
Log
Yes
Monitoring
process
Yes
All critical Info
provided?
No
Yes
Certification
Program
Compliant?
Start
Screening
process
All Screening
Tests OK?
No
DIRECT
Trust CP
Attestation
screening
No
No
NonCompliance
process
Flag test OK –
Yes/No
More Screening
tests?
Yes
Yes
DIRECT Trust
CP Attestation
Compliant?
Yes
No
Appeal?
Yes
Revoke existing
Certification
No
Reject
Certification
Apps
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Existing
Certification?
No
Page 65 of 69
Exit
May 2012
Appendix E – DirectTrust.org Certificate Policy Attestation Form
1.
Org. Name:
2.
Address
3.
Telephone
4.
Applicant
5.
Title/Role
Applicant attests to the following:
1. Applicant has established formal published policies and procedures regarding the
issuance and use of digital certificates.
Yes☐
No☐
2. Applicant has performed a self assessment comparing applicant’s digital certificate
policies and the digital certificate policies as defined by the Federal Bridge Certificate
Authority or DirectTrust.org.
Yes☐
No☐
A. Were discrepancies discovered between applicant’s digital certificate policies and
the digital certificate policies as defined by the Federal Bridge Certificate
Authority or DirectTrust.org?
Yes☐
No☐
B. If the answer to A is YES, please provide detail on the discovered discrepancies.
3. Applicant possesses an X.509v3 digital certificate(s), and the willingness and ability to
participate in a trust community to provide DIRECT services in Pennsylvania.
Yes☐
No☐
If NO, does applicant agree to acquire an X.509v3 digital certificate(s)?
Yes☐
No☐
4. Applicant intends to act as an RA for the purpose of identifying and authenticating
entities to be issued X.509v3 digital certificate(s).
Yes☐
No☐
If NO, does applicant agree to acquire the services of an RA authorized to perform
these services as related to the issuance of an X.509v3 digital certificate(s)?
Yes☐
No☐
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 66 of 69
May 2012
5. Applicant intends to act as a CA for the purpose of issuing X.509v3 digital certificate(s).
Yes☐
No☐
If NO, does applicant agree to acquire the services of a CA authorized to perform
these services?
Yes☐
No☐
6. Applicant has policies and procedures in place to ensure continuing compliance with data
security policies, including secure methods of access to and transmission of data.
Yes☐
No☐
7. Applicant refrains from selling or otherwise using identifying data related to identified
and authenticated entities that have been issued X.509v3 digital certificate(s) in such a
way as to violate privacy or confidentiality.
Yes☐
No☐
8. Applicant utilizes strong encryption, user authentication, message integrity and support
for non-repudiation as security measures in compliance with any legislation requiring it.
HITECH § 13402(h); 45 C.F.R. §§ 164.312(a)(2)(iv), 164.312 (e)(2)(ii)
Yes☐
No☐
9. Applicant uses effective controls and has implemented procedures for guarding against,
detecting and reporting malicious software. 45 C.F.R. § 164.308(a)(5)(ii)(B)
Yes☐
No☐
10. Applicant, upon request, can demonstrate that appropriate security is in place for
wireless networks to protect the privacy of data during transmission and in storage.
Yes☐
No☐
11. Applicant, upon request, can demonstrate that configuration standards are in place that
includes patch management for systems which store, transmit or access to information
related to X.509v3 digital certificate(s), including workstations.
Yes☐
No☐
12. Applicant has implemented policies and procedures to ensure compliance with applicable
requirements of the HIPAA Privacy and Security Rules. 45 CFR 160, 162, and 164
Yes☐
No☐
Signature of Authorized Representative/Applicant:
_____________________________________
Printed Name of Authorized Representative:
_____________________________________
Date:
_________________
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 67 of 69
May 2012
Appendix F – FBCA and Directtrust.org references
The FBCA and DirectTrust.org Certificate Policies focus on the following to ascertain
compliance:
X.509 Certificate Policy for the Federal Bridge Certification Authority (FBCA)
1.1.1
Certificate Policy (CP)
1.1.2
Relationship between the FBCA CP and the Entity CP
1.1.3
Relationship between the FBCA CP and the Entity CP
1.1.5
Interaction with PKIs External to the Federal Government
1.3.1.6
Federal Bridge Certification Authority (FBCA)
1.3.2
Registration Authority (RA)
1.3.5
Affiliated Organizations
1.3.6
Relying Parties
1.3.7
Other Participants
1.4.1
Appropriate Certificate uses (High)
2.2.1
Publication of Certificates and Certificate Status
2.2.3
Interoperability
3.2
Initial Identity Validation (High)
3.3
Identification and Authentication For Re-Key Requests (High)
4
Certification Life-cycle (All sections, High)
5
Facility Management and Operations Control (All sections. High)
6
Technical Security Controls (All sections, High)
7
Certificate, CARL/CRL, and OCSP Profiles Format
8
Compliance Audit and Other Assessments (All sections)
9
Other Business and Legal Matters (All sections)
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 68 of 69
May 2012
DirectTrust.org Certificate Policies
1.1.1
Certificate Policy (CP)
1.1.2
Relationship between this Direct Trust CP and a Corresponding CP
1.1.3
Relationship between the FBCA CP and the CA CP
1.3
PKI Participants (All sections)
1.4.1
Appropriate Certificate Uses
1.5.4
Certification Practices Statement Approval Procedures
2
Publication and Repository Responsibilities (All sections)
3
Identification and Authentication (All sections)
4
Certificate Life-cycle (All sections)
5
Facility Management and Operations Control (All sections)
6
Technical Security Controls (All sections)
7
Certificate CRL and OCSP Profiles Format (All sections)
8
Compliance Audit and Other Assessments (All sections)
9
Other Business and Legal Matters (All sections)
* Where inconsistency, incongruence or lack of detail exists between the two referenced
sources, DirectTrust.org Certificate Policies shall take precedence.
Pennsylvania eHealth Collaborative
HISP Certification Requirements
Page 69 of 69
May 2012