DRAFT pending workgroup approval

Our primary action in the Individual Involvement workgroup has been to ensure that the patient-specific MU requirements are aligned properly with the NHIN-D user stories. Specifically we have asked (and received agreement that):
  1. The MU 2011 requirements, which effectively amount to sending messages from PROVIDERS TO PATIENTS, be considered a “MUST” requirement for NHIN-D v1.
  2. The MU 2013 requirements, which add the capability of sending messages from PATIENTS TO PROVIDERS, be considered a “SHOULD” requirement for NHIN-D v1. While we believe this is not a strict v1 requirement, it is important that the protocols be defined in such a way that addition of this use case should be evolutionary, not disruptive, to v1 implementations.

As we’ve discussed these requirements in detail, three specific considerations that relate to patients as “first class actors” in NHIN-D have emerged. We are asking that the Security & Trust workgroup ensure that their proposals take these into account:
  1. The organization/member relationship for patients is fundamentally different than for providers. The scalability of NHIN-D address provisioning as proposed depends on the fact that organizations will “self-provision” addresses for their members – e.g., a hospital will allocate addresses for its providers and staff, and a SAAS HISP will allocate addresses for small practices. These organizations have relationships that will allow them to ensure that only its legitimate providers are granted accounts. While patients will receive addresses from organizations such as Google Health or HealthVault --- these organizations cannot reasonably offer the same level of proofing to anybody who “shows up” on the Internet. Therefore, NHIN-D will have to support the case where membership in an organization does not necessarily imply a fully-identity-proofed relationship.
  2. Trust relationships may need to be more granular for provider/patient messaging than for provider/provider messaging. Generally, we believe that once there is a trust relationship between health organizations, providers will be comfortable exchanging messages with any provider in those organizations. However, this will not always be true of patient/provider relationships. Many providers may want to exchange messages only with patients that they have established, existing relationships with. Therefore, NHIN-D must support the ability to trust only some members of an organization.
  3. Patient/provider trust may not always be mutual --- so we will need to support the concept of asynchronous trust policies. There is a wide range of attitudes in the provider community about electronic messaging with patients. It is clear that some providers that are willing to send messages TO patients are not yet ready to receive FROM them (and possibly the reverse as well). Therefore, in order to maximize adoption, NHIN-D must not require fully-symmetric trust between two endpoints in the system.

We’ve tried here to specify the “what” of the need without making assumptions about the “how” that the Security and Trust workgroup will arrive at. Please let us know if further clarification on any of the above is required.