Direct Citizen Community
Table of Contents
Introduction
Members of this community include entities providing Direct addresses for citizens and providers/organizations that choose to exchange messages with them. The unique needs of citizen addresses requires a different approach to identity proofing and in many cases an asymmetric trust model: For example, not all providers that send information to their patients want to receive messages from them.
In provider communities, identity proofing of accounts is important primarily because trust is achieved through broad affiliation. That is, one provider is comfortable sending to another because they know they are a licensed physician, or an employee of an IDN, or so on --- not necessarily because they know the provider personally. They trust that possession of an address means the owner of that address is "in the club" as it were.
This trust level breaks down for citizens, because we are all citizens --- there is no "club". In the provider-citizen exchange case, what is important is that a specific provider has a relationship with a specific citizen --- e.g., the patient is a registered patient at the provider's clinic. Supporting this trust level requires an additional level of identity proofing that can only happen between that citizen and their providing organizations. The "HISP Policies: Provider HISPs" section below establishes more detail on this.
Note that this community is not intended to limit voluntary exchange between citizens and providers operating under other policies or terms. The purpose of this community is to incent broad exchange through a one shared set of policies that can reduce the administrative burden and number of individual relationships required of participants, but participation is completely voluntary and we do not claim any exclusivity around the ability to enable this type of exchange.
Acceptable Exchange
Messages exchanged under the umbrella of this community are intended to support treatment and care relationships. In order for the channel to remain useful, it is important that it does not become choked with "spam" as our traditional email boxes have become. Unsolicited marketing messages are not appropriate for this channel. While the definition of "unsolicited" and "marketing" are perhaps fuzzy, we believe the spirit is clear.
Individual reports of abuse should be handled between the individual parties involved, and escalated to HIDPs and HISPs as necessary. If an HIDP demonstrates a pattern of failing to act according to the standards of this community, the Board (see "Governance") may vote to remove its certificates from its bundles. Because membership in this community is voluntary, the Board is authorized to use this option at its discretion.
Anchor Bundles
Because of the asymmetric nature of this community, it includes three "anchor bundles" defined for different purposes:
- The Citizen Bundle is installed by HISPs serving providers and organizations that want to exchange messages with citizens. The organization installing this bundle can configure it for sending to citizens, receiving from them, or both at their preference.
- The Provider2Citizen (P2C) Bundle is installed by HISPs providing Direct addresses to citizens. These HISPs must configure these anchors only for receiving messages from providers.
- The Citizen2Provider (C2P) Bundle is also installed by HISPs providing Direct addresses to citizens. These HISPs must configure these anchors only for sending messages to providers.
Certificates may appear in both the P2C and C2P bundles, for those HIDPs that wish to enable two-way exchange with citizens.
Note that at some point in the future, the number of anchors in the bundles may become burdensome. If and when this occurs, the community, through the Board, may choose to reduce the burden by creating a Citizen Community Certificate Authority to represent participants. In the near term, however, this level of bureaucracy does not seem necessary.
Management of the bundles is the responsibility of the Direct Citizen Community Board. See the "Governance" section below for details.
HIDP Policy
Citizen HIDPs
Citizen certificates must be issued at the individual address level. Organization-level certificates are not appropriate for citizens, as they enable an (albeit difficult to implement) scenario in which addresses may be hijacked and personal information stolen. Note this risk does not apply to provider certificates.
As discussed in the introduction, identity proofing at the certificate level does not serve a meaningful role for citizen participation in Direct. Therefore, there is no specific identity proofing requirement for issuing a Direct certificate to individuals. However, it is required that Citizen HIDPs provide sufficient information to responsibly act upon abuse complaints and revoke individual certificates if appropriate.
Citizen HIDPs must ensure that their certificates are valid only at HISPs that meet the policy --- that is, they are issued only to email domains known to be hosted by HISPs compliant with the standards of this community.
Because identity proofing is not a high-burden exercise for citizens, it is our expectation that most citizen HIDPs will be bundled with HISPs --- for example, Microsoft HealthVault acts as both HIDP and HISP for its users. However, this is in no way a requirement, and we have kept the policy sections separate to reinforce the two roles still exist.
Provider HIDPs
In general, certificates in the the P2C and C2P bundles should satisfy the HIDP requirements of the Direct Ecosystem and/or Federal Communities (see "References" section below for important notes here). However, because citizens may wish to exchange with "non-traditional" providers that may not otherwise be present in the Direct ecosystem (e.g., personal trainers or coaches), this is not a hard requirement.
Provider HIDPs in this community must ensure that certificates are granted only to organizations or individuals that act as providers of care, generally defined as personal interactions that support health or wellbeing. The community does not pass judgment on types of treatments and may also include participants such as payers that engage in support of personal care.
HISP Policy
Citizen HISPs
A citizen HISP must agree to abide by the Markle Common Framework for Networked Personal Health Information.
Citizen HISPs must also provide a clear mechanism to respond to abuse complaints from providers.
Provider HISPs
Provider HISPs must operate following the HISP requirements of the Direct Ecosystem and/or Federal Communities (see "References" section below for important notes here).
Provider HISPs must also provide a clear mechanism to respond to abuse complaints from citizens.
Most importantly --- provider HISPs must ensure that their users have the capability to "whitelist" and/or "blacklist" (at their discretion) specific citizen addresses for send and receive, rather than blindly trusting any message signed by a certificate rooted to the Citizen anchor bundle. In the EMR case, this will typically be implemented by an in-office process for associating a Direct address with a particular patient record. In a traditional email case, the email software must have "rules" capability that enables a provider to configure which addresses should be accepted and which should be rejected.
The capability may be provided by the HISP itself or by software run "behind" the HISP --- but the HISP is responsible for ensuring that the capability exists. This is important in order to avoid the channel being overtaken by spam that undermines provider confidence and willingness to participate in Direct exchange.
This approach implements a two-tier approach to trust for providers exchanging messages with citizens:
1. (HIDP Level) The Direct infrastructure will ensure I exchange only with citizen systems that support responsible handling of consumer-controlled health information.
2. (Whitelist/Blacklist Level) I can further configure my system to exchange only with citizens I have a specific relationship with.
Governance
Ownership and maintenance of the community anchor bundles will be managed by the Direct Citizen Community Board. As yet we have no idea who will be on it, how often it will meet, what procedures it will use, or where anchor bundles will be made available. Working on it! TBD TBD TBD.
As we are very early in the establishment of this community, it is expected that the Board will change and improve these policies over time. Interested parties can receive updates whenever they are updated by registering for email updates on this wiki page.
References
IMPORTANT: This community refers in a number of areas to the policies of the Direct Ecosystem and Federal Communities. Currently these communities are in parallel forming their own requirements. In this interim period of development, the Board will be given discretion to permit provider participation by validation of loosely defined "reasonable requirements." That is --- if the provider HIDP or HISP demonstrates that they are operating in a commercially-reasonable manner to provide exchange capability to providers, we will likely include them in bundles at this time.
History
The wiki maintains the authoritative history of this page. This section is intended only to provide key context around major changes.
- Initial draft 6-11-2011 (Sean Nolan)
- Updated for clarity only 6-17-2011 (Sean Nolan)