Direct Ecosystem Community

From Direct Project
Jump to navigation Jump to search
Version 0.1

Introduction

To put this page in context and for definitions of the terminology used below, please reference the parent Direct Communities page.
 
  The Direct Ecosystem Community was formed to define a baseline set of policies and rules that can facilitate broad exchange among a diverse set of health care participants the majority of whom are covered entities or members/employees of a covered (CE), or a business associate (BA) of a covered entity under HIPAA. The community is working to achieve responsible consensus quickly in support of imminent real-world deployments of Direct that are in the service of this group of participants. This group was originally formed as the "Direct Rules of the Road" workgroup, which subsequently created three separate communities of interest for Direct exchange: a federal community; a citizens community; and this ecosystem community.

HIDP Policy

The Ecosystem Community has expressed its policy consensus for Health Identity Providers (HIDPs) in the form of an RFC 3647-compliant X.509 Certificate Policy document found here:
 
 [1]
 
  All aspects of HIDP policy (identity proofing, certificate management, certificate profile, etc...) are found in the Ecosystem Certificate Policy. A HIDP that wants to conform to this Certificate Policy should write a Certification Practices Statement (ideally in an identical format to the Ecosystem Certificate Policy) and submit it for approval through the governance processes defined below.
 
  Some background on Direct identities:
 
  Direct identities associated with X.509 certificates can take two forms: organizational or individual.
 
  As defined on the Direct Communities page, an organizational certificate is associated with the domain name common to all Direct addresses of a healthcare organization. For example, if the domain name of "direct.goodhealth.com" is present in a Direct organizational certificate, all associated Direct addresses for Good Health are bound to that same identity. In other words, all of the following Direct addresses would map to the same "direct.goodhealth.com" certificate or identity:
  • DrRalphJohnson@direct.goodhealth.com
  • Labs@direct.goodhealth.com
  • BarryDeckerRN@direct.goodhealth.com


An individual identity or certificate, on the other hand, is associated with exactly one Direct address. For example, each of the direct.goodhealth.com Direct addresses listed above would be tied to a separate X.509 certificate.

HISP Policy

HISPs Serving Healthcare Entities, Organization, and Individuals (non-patients)

It is the responsibility of the HISP to provide intuitive tools and knowledge to a healthcare organization/individual that allows it to implement a trust policy consistent with security policies and within the capabilities of the Direct Project PKI architecture. To reap the benefits of secure but ubiquitous communication, healthcare organizations/individuals should codify trust by, as much as possible, adding trusted root certificates to its users’ Direct Project truststores (coarse-grained trust). Healthcare organizations should not use the Direct Project PKI truststore to enforce business policies above and beyond those dealing with privacy and authentication of Direct Project messages.
 
  A healthcare organization/individual that is a HIPAA covered entity will either provide HISP services within its network or execute a HIPAA BAA with a third-party HISP. Either way, all PHI retention, use, disclosure, security, and access will follow HIPAA guidelines for a covered entity.
 
  A healthcare organization/individual that is not a HIPAA covered entity will either provide HISP services within its network or execute a BAA with a third-party HISP that is materially equivalent to a HIPAA BAA. Either way all PHI retention, use, disclosure, security, and access will follow guidelines equivalent to those required of a HIPAA covered entity.
 
  A Direct address contains a domain component that may be rooted at the HISP (e.g., DrJoe@GoodHealth.MyHISP.com) or may be independent of the HISP (e.g., DrJoe@direct.GoodHealth.com). Should the user decide to switch to a different HISP, choosing the latter option allows him to do so without changing his Direct domain/address(es). HISPs should allow a provider to use his own domain (and certificate) if desired.
 
  When a healthcare organization is issued an organizational Direct certificate, then HIPAA best practices should be followed by the healthcare organization in determining the appropriateness of assigning Direct addresses to its members (all of which will use the same Direct organizational certificate for S/MIME signature verification and encryption).
 
  A HISP should not use an organizational certificate to represent more than one distinct organization. A HISP should not use an individual certificate to represent more than one distinct healthcare individual. For example, if a third-party HISP provides service to 20 distinct hospitals (legal entities), each hospital should be associated with a different organizational certificate.
 
  HISPs must use secure edge protocols to deliver/send Direct messages to/from its users. Using a username/password authentication mechanism that serves to give access to the Direct private key (organizational or individual) for S/MIME signature creation and message decryption is a valid form of authentication per this policy.

HISPs Serving Patients

Identity proofing patients in a manner similar to a healthcare organization or individual is not practical or desired. Rather, healthcare organizations must be responsible for obtaining a patient's Direct address from them in a trustworthy manner (e.g., in person).
 
  A HISP serving patients (e.g., a PHR) should not use one organizational cert to represent all patients. It should issue one individual certificate per patient.
 
  See the Direct Citizen Community.

Certificate Discovery/Directory

To ensure interoperability, a HISP and/or HIDP must publish Direct X.509 certificates as CERT resource records within the Domain Name System (DNS) as specified in section 5 of the Applicability Statement for Secure Health Transport. DNS is a scalable, federated directory with a format standard for holding and accessing X.509 certificates. This does not preclude the formation of additional directory mechanisms in the future, but rather addresses the immediate need for certificate discovery in the context of HISP interoperability.

Granularity of Trust

The truststore of a Direct user is a collection of certificates (trust anchors). Every certificate used to verify a signature on a Direct message or to encrypt a Direct message must chain back to a trust anchor in the truststore. See section 4.2 of the Applicability Statement for Secure Health Transport.
 
  To encourage as much interoperability as possible, Direct users in conjunction with their HISP should, whenever feasible, place root certificates in the users' truststore. There is no technological or operational reason to not place specific organizational or individual certificates in a truststore. However, organizations should strive to populate truststores with certificates that allow the broadest interoperability possible within the confines of organizational security policy and practice.

Governance

To enable Direct users and HISPs to quickly assess the policies and practices of HISPs and HIDPs, a governance mechanism and a governance body should be put in place. For purposes of this document the name of DirectTrust.org shall be used to refer to this body. This consensus statement should form the basis for agreed upon policies and practices for such a governance structure.
 
  The creation of DirectTrust.org and its governance mechanisms, including this consensus statement, should not have the effect of creating competitive disadvantage through mandates that, in the initial Direct rollout period, are prohibitively difficult for many HISPs and HIDPs to accommodate. There must be room for innovation in the market. It must also be clear that any conformance of HISPs and HIDPs to this consensus statement and to the rules and best practices adopted by DirectTrust.org is completely voluntary. If a HISP or HIDP chooses to offer Direct services without agreeing to this consensus statement or to the conditions for membership in DirectTrust.org, they may do so.
 
  The DirectTrust.org governing body should have, at minimum, the following responsibilities:
  • Review and approve/disapprove the Certification Practices Statements (CPSs) that HIDPs submit for review/certification.
  • Maintain a public list of approved HIDPs.
  • Review and approve/disapprove HISPs that attest to operating in compliance with the Ecosystem HISP policy set out in this document.
  • Regularly review and update the Ecosystem Certificate Policy based on feedback and experience.
  • Work with all Federal Government entities defining the Direct Federal Community to harmonize the policies of this document with those of the Federal Community with an overarching goal of merging the communities into one.


DirectTrust.org should have the authority to revoke a HISP and HIDP from approved status if clear evidence is presented that the entity is not practicing according to the policies set forth in this document.

References

Applicability Statement for Secure Health Transport
Direct Ecosystem Community X.509 Certificate Policy
Evaluation Criteria for Trust Anchors and Certification Authorities
Best Practices for HISPs
Direct Boot Camp Privacy and Security Presentation
RFC 3647
Direct Federal Community
Direct Citizen Community
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=Direct_Ecosystem_Community&oldid=221"