Direct Transport SWG – ONC Data Access Framework
Statement of Principles Document for MU2 Transitions of Care
First Draft, Comments Solicited from Workgroup
Version 1.0.1
DRAFT DOCUMENT, COMMENTS WELCOME
This Statement of Principles document describes key aspects of a Transition of Care (ToC) implementation proposed by Dr.
Stephen Beller, Peter Bachman, and Sabatini Monatesti who are fully responsible for its content. In this document, we explore a
DAF/Direct implementation that enables secure queries via the Direct Applicability Statement to meet MU2 ToC requirements.
There would be an Implementation Guide corresponding to this document for purposes of design.
Statements herein represent the opinions, beliefs, and best judgments of the authors and may be adopted by the DAF Direct SWG
as a specific use case using different implementations. As such, they are not necessarily subjected to the same level of formal
scientific review as Standards or Guidelines. Each institution or practice should decide individually whether to implement some,
none, or all of the principles in the statement based on the sound medical judgment of medical personnel participating in that
institution or practice.
I.
Introduction:
a.
b.
c.
d.
e.
The described implementation conforms with the Direct Applicability Statement, STA to STA methodology (Direct
Applicability Statement secure transport agent1) for sending and receiving medical Protected Health Information
(PHI) securely over the Internet. It also combines the element of “known verifiable endpoints” under the control
of a private key holder using multiple layers of verification that is widely recognized by Certificate Authority
industry groups for different industry verticals and does not require the unusual use of DNS to validate PHI
exchange.
There are defined endpoint security requirements2 between and among partners mutually authenticated to NIST
800-63-1 LOA 3 3 in what we describe generally as a “social/clinical network.” This network leverages
authentication, authorization and encryption to protect PHI based on HIPAA requirements, as well as computer
security and network best practices recognized by security frameworks.
We recognize that there are known and unknown risks. Known risks include: DDOS, DNS spoofing, X.509v3
Certificate falsification, MITM, cyberspace military attacks from a foreign power, or insider threats, alteration of
patient data records (data integrity). Unknown risks include: CVE software flaws or zero day vulnerabilities which
are dynamic, even though they may have wide spread application such as the recent coding error in the OpenSSL
software libraries. If there is a CVE assigned it is assumed that use case actors will update their software to
mitigate risk exposure.
There is no trade group, community of interest, or trust framework with a “get out of jail free card” that prevents
it members from being sued for negligence. There are, however, legal limitations imposed by the Certificate Policy
Statement as defined by the American Bar Association.
The digital signatures used to support our implementation’s ToC use case, which is described below, have
advanced ETSI non-repudiation qualities that are currently outside the scope of Direct dual use encryption
certificates. The use of additional verification technology3 is defined by the S&I Framework esMD work groups in
terms of time stamps and verification which are assumed to be valid in court for 20 years. This anticipates risk of
cryptographic protocol failure, expiration of a specific individual digital certificate, and the business failure of a
1
2
3
http://www.directproject.org
http://www.commoncriteriaportal.org/files/epfiles/st_vid10390-vr.pdf
RFC 3161
S.J. Monatesti, S. Beller, P. Bachman
May 9, 2014
1
Direct Transport SWG – ONC Data Access Framework
f.
g.
h.
certificate authority that may have received the “Internet Death Sentence”4 or have been removed from usage
from a trust bundle.
We assume that HISPs using these advanced digital signatures have or will adopt appropriate X.509v3 certificates.
These certificates allow for interoperability based on anti-fraud legal trust framework requirements as described
by the ongoing effort of the American Bar Association Working Group on Trust Frameworks (including Direct
Trust). Refer to idmanagement.gov for details on other trust frameworks.
The PKI private keys in our use case are managed directly by the sender who possesses the private key using local
secure storage, instead of through a third party agent or proxy (such as a HISP in non-pass-through mode). This
results in higher security against network and HISP insider attacks according to the Direct Project security analysis.
5
The entire taxonomy of potential risks and mitigations is not covered in this document, but has been
documented elsewhere.
Our implementation is a secure, interoperable, MU2 compliant nationwide health information (NwHIN)
architecture. It includes novel features such as the “Computerized Health Agent (CHA).” The CHA is a separate
software element that is distinguished from the Direct Applicability Statement’s Security/Trust Agent (STA)
technical messaging endpoint located within a HISP or at a provider’s desktop or email gateway. While we use a
COTS e-mail client as an appropriate STA, it differs from the normative definition of “Direct Transport.”
i.
We do not define the usage of edge protocols because it is not part of Direct Transport. For example, the typical
use of TLS certifies the name of a computer endpoint (server) in the DNS, and not a recipient STA., This creates a
security gap as PHI is transferred (however briefly) from the server memory unencrypted to the HISP mail queue
to be sent via the HISP STA. As such, the HISP must handle PHI in the clear. This is similar to the situation that
occurred at Target when they were recently hit with a memory scraping software program at their point of sale
terminals.
j.
Any provider’s identity can be uniquely validated in the X.500/LDAP Directory. The provider is listed in the
Directory” (i) according to his/her assigned alpha-numeric Object Identifier (OID), (ii) under both the HL7 realm6
k.
l.
and the X.500 Administrative Domain, c=US7, or (iii) under a subentry of a nationally validated entity using ANSI, a
federation, or a state Directory as described in relevant ISO and IETF documents under the c=US naming scheme.
Sole trust in DNS entries is misplaced because accurate replies to queries depend on multiple factors such as DNS
Security (DNSSEC) and digitally signing root server entries for TLD, (top level domains) as described in the
documentation and implementation guide for S&I Framework Provider Directory. Direct does not specify DNSSEC
or encrypted DNS replies. In fact, incorrect DNS replies are acceptable to Direct because the sender identity is
independently verifiable by the individual certificate. However, DNS vulnerabilities can result in spoofing of
certificate entries since they cannot be tied back to the individual in a meaningful way.
In terms of Direct, only the “subject alternative name” field in the certificate is defined as having either a “Direct
Address” or an “Organizational DNS Name,” which are both valid fields under RFC-5280 and extends X.509v3 for
various Internet profiles.
m. The provider Directory tightly binds a certificate’s subject field with a Directory’s subject entry; this differs from
DNS, which binds the certificate’s subject field with the Directory’s alternative subject field. Since the Directory
validates the subject and not the alternative subject field, use of DNS requires an additional level of security that is
4
5
6
7
http://en.wikipedia.org/wiki/DigiNotar
http://wiki.directproject.org/Threat+Models
http://wiki.hl7.org/index.php?title=Realm
RFC1218, http://tools.ietf.org/html/rfc1218
S.J. Monatesti, S. Beller, P. Bachman
May 9, 2014
2
Direct Transport SWG – ONC Data Access Framework
not provided by any “trust organization.” As such, the solution we will demonstrate conforms with the Federal
Bridge in that subjects are defined in the Directory under c = US, which enables the secure exchange between all
certificate subjects without unnecessary barriers. For example, a similar “namespace” occurs between zip code
n.
and home address, with name, uniquely identifies the occupant and binds it to the endpoint.
A provider Directory (TS 21091)8 will be provisioned in X500/LDAP or DSML connected to databases linked through
web services using HPD+ as the shared schema from IHE9 (and already are provisioned in multiple places) the
linkage between the provider’s specialty (say Cardiology) is then available for routing, which obviously would not
be part of the typical Direct certificate specifications to provide a medical context for healthcare information. It
should be noted that the X500/LDAP implementation is one singular directory made up of individual LDAP servers
that are run by ANSI registered organizations. For example, say CERNER wanted to run a national HPD+ LDAP
server it could do so with access through the X500 Directory, or through a DSML enabled database. That would
require that CERNER have a corresponding validated entry in the X500 namespace. Other organizations could
locate themselves underneath CERNER in the Directory information tree (DIT). This allows for navigation to the
distributed directories. An example why DNS is bad in this regards, would have been the classic case of the
domain name “WHITEHOUSE.COM” (the porn site) as opposed to “WHITEHOUSE.GOV.”
o.
p.
q.
The overall technology is voluntarily deployed by participants (and follows NSTIC Fair Information Practice
Principles)10 deployed as an Internet application layer using SMTP to support a Publish Subscribe logical layer
relationship11 between and among a community of authenticated users, and distributed over the Internet with
encryption protocols as was tasked to the ONC by the Executive Branch as a requirement from the public in
(Executive Order 13335, 2004), thus forming an ethically12 enabled social network (EESH) as part of the agile
evolving NwHIN architecture that conforms to the published Executive Branch Cybersecurity Policy.
The EESH is a larger overall concept than any specific data exchange envisioned for healthcare. This specific
implementation leverages common off-the-shelf (COTS) components (that have already met stringent security
analysis testing)13 already in wide use within enterprises and by the public and can provisioned using current open
source and commercial offerings along with Internet and ISO standard services as described by S&I Framework
workgroups such as Provider Directory.
This COTS implementation with custom software as an EHR module and architecture offers rapid compliance
uptake potential among organizations that may not have participated in MU2 incentives and are less likely to be
integrated within current EHR offerings as would be typical in a Hospital setting after MU1. Thus it goes beyond
8
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=51432
http://wiki.siframework.org/IHE+HPD+Standard+Analysis
10
http://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf
11
An internet application layer is logically independent of transport layers underneath in the OSI stack. Interactions only occur at
known transition points to preserve logical separation. Thus this is more resilient to degradation of normal services in disaster
scenarios and still is capable of carrying current situational knowledge between participants which is required for effective patient
routing. This is a design characteristic carried forward from message routing in nuclear war military planning which formed the
design of the early Arpanet, in which dedicated “telephone circuits” would be disrupted, and messages would be routed as
necessary between surviving nodes such as ICBM silos and civilian infrastructure for command and control functionality. Thus the
Internet design was “disaster ready” by allowing for different layers.
This contrasts with other transports that are also acceptable in this use case for MU2 compliance, such as SOAP which have a tighter
logical binding of transport to data elements but can also use the Internet.
http://en.wikipedia.org/wiki/OSI_model#Layer_7:_application_layer/ For a simple phrase to describe this to non-technical users it
is “Connect pub-sub using Direct” by using the pub-sub design pattern
http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern implemented by the CHA which is bound to the Direct STA, and
understands the semantics used by the EHR as output in a HL7 C-CDA to the CHA.
12
http://princetonacm.acm.org/tcfpro/presentations/Introduction_of_ethics.pdf
13
http://www.commoncriteriaportal.org/files/epfiles/st_vid10390-vr.pdf
9
S.J. Monatesti, S. Beller, P. Bachman
May 9, 2014
3
Direct Transport SWG – ONC Data Access Framework
II.
MU1 integration to sharing data under MU2, and sets the stage of further integration and patient engagement
under MU3.
r. Network components include LDAP and DNS, Federal Bridge LOA 3 ACES14 Certificates for signing and encryption
for each individual user, CMS/NPI directory data elements as captured in S&I , IHE, ISO TS-21091 X.500 Provider
Directory model, and cleared IP usage of the top level X.500 Administrative Domain Name (C=US) as applied in the
existing FICAM trust framework, to distribute this information over the Internet as described in OID 1.3.6.1.115
along with existing certificate policies and certificate practice statements. It is expected that any NSTIC relying
parties should accept these X.509v3 certificates as a valid proof of identity based on polling of the NSTIC medical
working group during a recent Plenary.16
s. Our specific ethical implementation requires minimizing of potential risk of loss, misuse, or destruction of PHI
leading to reduced patient safety risk, while still providing a national framework enabling comprehensive access to
patient data.
Goals of our ToC implementation
a.
Demonstrate a Direct, HIPAA-compliant, “conduit” implementation.17 The details will be described in an
implementation guide that documents the extensibility, quality assurance18 and applicability of our
implementation for sharing ToC PHI in a disparate HIT industry in a machine to machine, machine to human,
human to human environment.
b.
Deploy a node-to-node (point-to-point, desktop-to-desktop, STA to STA) network model of “Basic Direct” that uses
the SMTP + S/MIME over the internet instead of web services.
Impose no requirements for a BAA or any prior authorizations and authentication other than that provided by the
FICAM trust framework plus c=us X500 Directory integration. This is consistent with the Administrative
Simplification Rule of HIPAA regarding communication between covered entities (as detailed in the Omnibus Final
Rule), which forbids barriers to the exchange of health data between covered entities.
d. Require no additional steps be added to trust the credentials on a business layer as they are presented and
subsequently automatically validated by the software and cryptographic libraries which validate the CA signature
validation path. If the FICAM approved Federal Bridge CA is included in the trust bundle (which is not typically the
case for the Direct Trust), then the FICAM trust network specifically states that the approved credential is valid for
any use as defined in the Certificate Policy Statement, which enables the citizen to drive the process and make
patient centricity a reality in the virtual world.
e. This uses Federal Bridge CAs to enable cross certification and cross Certificates at the Bridge thus creating an
Identity Assurance Hub between certified Certificate Authorities and related participants.
Our specific Use Case for meeting ToC MU2 requirements:
c.
III.
a. Assumptions
i. Using the ethical framework one implement efficient and effective care between acute and long term
care facilities. This is MU2 criteria 15 – 17. The best way to accomplish this goal is by fully communicating
14
https://www.idmanagement.gov/entities-cross-certified-federal-bridge
http://www.alvestrand.no/objectid/1.3.6.1.1.html
16
http://www.idecosystem.org/content/8th-plenary-recap
17
http://www.gpo.gov/fdsys/pkg/FR-2013-01-25/html/2013-01073.htm, “This is consistent with our prior interpretation of the
definition of ``business associate,'' through which we have stated that entities that act as mere conduits for the transport of
protected health information but do not access the information other than on a random or infrequent basis are not business
associates.”
18
http://wiki.siframework.org/Desktop+to+Desktop+Implementation+-+Specification,+Standards+and+Testing
15
S.J. Monatesti, S. Beller, P. Bachman
May 9, 2014
4
Direct Transport SWG – ONC Data Access Framework
all of the data requirements in the federal regulations. The ground truth is that patient’s data is
distributed in different systems and may exist on an attending physician’s EHR at their office, at the Long
Term Care Facility, medical record on paper, etc. This data needs to be gathered up and transmitted to all
the authenticated and authorized members of the care team, so that the patients ToC data to avoid
having the patient ping-pong through the system.
ii. During an care coordination process where patient is ping-ponging between acute and long term care
facility patient information is exchanged based on an N by M array of authorized care givers, i.e., Provider
(1 – N) requesting PHI from Provider (1 – M)19
iii. ToC demands a satisfactory response to the needs of patients by effectively sharing PHI between facilities
in a secure manner.
iv. PHI receivers are facilities that exist physically in the same physical locale and may also have actors that
are not yet electronically enabled, do not yet have EHRs, use artifacts such as Personal Identity
Verification (PIV) cards during the patient incident (episode of care). There may also be a social
relationship that is not electronically verifiable. To properly document interactions when electronic
systems are used for patient transfer to another facility we must make sure the correct data elements are
also included in that transfer, or sent ahead to potential recipients.
v. Once a secured connection is established and verifiable, the PHI receiving party must be able to exchange
relevant PHI with the sending node without requiring additional communication channels for
authorization. In the case of an ambulance crossing various jurisdictions for routing during a disaster, the
use case actors would be able to present adequate electronic credentials that could be verified by the
relying party, such as a FEMA incident commander, to coordinate resources in terms of evacuation of
facilities. There are documented failures during Katrina that this use case would have addressed.
vi. The recipient of patient data (defined use case actor who is authorized by that facility) may have minimal
historical HL7 data within their EHR system. The patient is assumed to be injured or in distress and
requires assessment at the ER prior to admittance, establishing a plan-of-care, administering treatment, ,
transfer, discharge, or release of PHI .
vii. PHI documentation is maintained in a certified EHR for each facility, or the attending physician for that
facility may have the information, which could be accessed to effectuate the ToC.
viii.
Requesting party (Requester) sends a Direct query request to the replying party (Responder) for
information defined in the CDA ToC template and the Responder(s) return those data in a CDA ToC
template encapsulated as an attachment to transport mechanism (e.g., Direct query response with
attachment).
ix. At each endpoint there may be an OASIS environment20 communicating to an EHR or a provider without
an EHR.
b. Use case particulars
i.
We expect that the results of compliance to quality measures will be documented and available to quality
reporting organizations such as CAQH through S&I Framework SDC. Individual implementations may
deviate from this condition.
ii. The implementation will be one step above paper/fax as the medium for transferring documents between
facilities that are electronically verified by the transferring provider using COTS-based applications. If
patient is transferred from point A to B in the physical world, the patient-transfer must be accompanied
with electronically integrated CCDA.
19
20
Universal modeling language
http://www.carevoyantindia.com/HomeHealth.aspx
S.J. Monatesti, S. Beller, P. Bachman
May 9, 2014
5
Direct Transport SWG – ONC Data Access Framework
iii. In the event the patient is not cognizant at the receipt point of care, the implementation will support
effective routing information to an applicable facility to provide stabilization.
iv. Based on the patient’s pre-negotiated preferences, electronically stored mortality or advanced directives
that are not strictly clinical—such as a faith component, or to reconcile patient wishes (ethical
consideration) with owner of legal health power of attorney documentation—will also be made available.
IV.
v. Questions to resolve: who is this patient, does the PHI I have corrected and does it come from a trusted
source21, has the sending party abridged the rights of the patient22, and can recipient system or
authorized person resolve the content23 (OIG reference regarding oversight)?
vi. This implementation would enable relevant access to PHI ensuring that a dialogue between the endpoints
is secured.
Supported Standards
a.
V.
HIPAA, HITECH, IEEE/ACM ethical constraints, X500, X509V3, 360X Closed Loop Referral, SMTP/SMME, HL7V2, S&I
Framework24 applicable guidelines25, Federal Bridge ACES Cert for each participant
b. Required Infrastructure
i. Validated encryption standard
ii. Zip – compression standard
iii. SMTP – mail transport standard
iv. XML – import and export functionality
v. TCP/IP ISO – seven layer stack (Application, Presentation, Security, Transport, Network, Data Link,
Physical)
vi. Spreadsheet, Formulas, Functions and Macro Code – data manipulation standards
vii. File Naming, Format and Storage – data management standards
viii. LOINC/ICD/SNOMED/etc. – data terminology standards
Justification
a.
VI.
Low cost, minimal risk, ethically designed, minimal development and maintenance, meets all HITECH, HIPAA MU2
requirements, promotes real time access to CMS NPI and automatic resolution of provider ID and credentials, i.e.,
authenticated and authorized to process, use PHI, available today for pilot testing.
Conclusion
a. Given the ethical, financial, bio-surveillance, and clinical issues facing HIT interoperability and the poor
performance of EHR to meet clinical practitioner needs the authors believe that the implementation presented
above should be pilot tested ASAP
21
https://oig.hhs.gov/reports-and-publications/archives/workplan/2013/Work-Plan-2013.pdf
http://www.databreachtoday.com/oig-to-review-medical-device-security-a-6490
23
http://blog.himss.org/2013/11/07/how-might-healthcare-organizations-engage-end-users-to-mitigate-risks-to-patient-safety
22
24
25
http://wiki.siframework.org/Desktop+to+Desktop+Implementation+-+Specification,+Standards+and+Testing
http://wiki.siframework.org/Query+Health+DIRECT+and+FlatFile+based+POC
S.J. Monatesti, S. Beller, P. Bachman
May 9, 2014
6
Direct Transport SWG – ONC Data Access Framework
5/9/2014
X
IX. Attachment 1 – EESH N-by-M Array
X.
Sabatini J. Monatesti
Sabatini Monatesti
President
Attachment 2 – Reference of Terms (Acronym Definitions)
a. ACES - FBCA stands for Federal Bridge Certification Authority. ... Authority (FBCA) and Access Certificates for
Electronic Services (ACES) pro
b. AES256 – Advanced Encryption Standard is a symmetric encryption algorithm
c. ANSI – American National Standards Institute
d. BAA – Business Associates Agreement
e. CA – Certificate Authority
f. CAQH – Council for Affordable Quality Healthcare (Washington, DC)
S.J. Monatesti, S. Beller, P. Bachman
May 9, 2014
7
Direct Transport SWG – ONC Data Access Framework
g. CCDA – Consolidated Clinical Document Architecture
h. CHA – Computer Health Agent
i.
CMS/NPI – Centers for Medicare and Medicaid Services/National Provider Identifier
j.
COTS – Common-of-the-Shelf Technology
k. CVE – Common Vulnerability Encounter
l.
DNS – Domain Name Service
m. EESH – Ethically Enabled Social Network
n. EHR – Electronic Health Record
o. ETSI – European Telecommunications Standards Institute 2009
p. FEMA – Federal Emergency Management Agency (USA)
q. FICAM – Federal Identity, Credential, and Access Management
r. FIPP – Fair Information Practice Principles (FIPPs)
s. FISMA –Federal Information Security Management Act of 2002
t. HIPAA – Health Information Portability Accountability Act
u. HISP – Health Information Service Provider
v. HITECH – Health Information Technology for Economic and Clinical Health Act
w. HL7 V2 –Health Level 7 Version 2, standard defines a syntax (grammar)
x. ICD - International Classification of Diseases
y. IEEE/ACM – Institute of Electrical and Electronic Engineers/Association for Computing Machinery
z. IETF – Internet Engineering Task Force
aa. IHE – Information Health Exchange
bb. IP – Internet Protocol
cc. ISO – International Standards Organization
dd. LDAP – Lightweight Directory Access Protocol
ee. LOA 3 –– NIST Level of Assurance @ Level 3, digital signature is a digest of the message being signed and
encrypted by the digital signing algorithm using the private key. Private keys stored on a local computer
S.J. Monatesti, S. Beller, P. Bachman
May 9, 2014
8
Direct Transport SWG – ONC Data Access Framework
should, at a minimum, be protected by a password or Personal Identification Number (PIN). The PIN would
not prevent other covert hacking methods such as keystroke logging. Thus, it is strongly suggested that
signers consider using authentication protocols that meet NIST LOA 3
ff. LOINC – Logical Observation Identifier Name Codes
gg. MITM ––Man-in-the-Middle attack
hh. MU1, MU2, MU3 – Meaningful Use, ONC Measures
ii. NIST– National Institute of Standards and Technology, http://www.nist.gov
jj. NSTIC –The National Strategy for Trusted Identities in Cyberspace
kk. NwHIN – Nationwide Health Information Network
ll. OID – Object Identifier
mm.
ONC – Office of National Coordinator of Health Information Technology
nn. PHI – Personal Health Information
oo. PIV – Personal Identify Verification
pp. PKI – Public Key Infrastructure
qq. RFC - The IETF adopts some of the proposals published as RFCs as Internet standards. Request for Comments
documents
rr. S&I Framework - The Standards and Interoperability (S&I) Framework within the Office of the National
Coordinator for Health
ss. SMIME – Secure/Multipurpose Internet Mail Extensions is a standard for public key encryption and signing of
MIME data
tt. SMTP – Simple Mail Transfer Protocol
uu. SNOMED - Systematized Nomenclature of Human Medicine (a multiaxial nomenclature for indexing medical
records)
vv. STA– As a data holder, you will need to send patient health information (payload) from your system to a
Direct address. In order to do that, your system needs to be able to send that payload through a
Security/Trust Agent (STA).
ww.
SWG – Office of National Coordinator Sub-Workgroup
xx. TCP/IP – Transmission Control Protocol/Internet Protocol
S.J. Monatesti, S. Beller, P. Bachman
May 9, 2014
9
Direct Transport SWG – ONC Data Access Framework
yy. TLS – Transport Layer Security
zz. ToC – Transition of Care
aaa.
XML – eXtensible Markup Language
bbb.
ZIP – Compressed File (PKzip file name extension)
S.J. Monatesti, S. Beller, P. Bachman
May 9, 2014
10