Patient to Provider Issues and Implementation
As members of the NHIN Direct Individual Involvement workgroup, it is our role to advocate for the opportunities to involve the individual in direct clinical exchange. We believe
- that an engaged patient is more likely to take steps to maintain and improve her health,
- that the standardization of transport protocols developing under NHIN Direct can also apply to individuals in communication with their clinicians,
- that individuals who communicate with their clinicians asynchronously and electronically can reduce their need for face-to-face time with a doctor (depending on the nature of the communication and the procedural structure in place to support it), and
- that the reduction of clinic-time will translate into reduced healthcare costs.
The Standards & Certifications Criteria Interim Final Rule for 2011 Meaningful Use provides for an eligible professional to send a summary of the clinical chart to an individual. However, support for an individual to electronically message her clinician is not included until 2013. While we respect the need for proven incremental change, we maintain that until the individual is capable of completing the communication circle with her clinician, we have not reached our goal of actively engaging the patient in the comprehensive management of her health. Further, we believe that given the standards being established by NHIN Direct, patients may be able, technically, to send electronic messages to their providers prior to 2013; therefore, we must consider the special implications this use case will generate.
The Implementation
Using the standards and infrastructure currently being constructed, a Patient/Consumer communicating with her clinician would use the very same mechanism.
Pre-Conditions:
- as with the other use-cases, the sender (Patient/Consumer) is responsible for deciding what gets communicated
- as with the other use-cases, the sender (Patient/Consumer) is responsible for getting the Address of the target through out-of-band means
- similar to the other use-cases, the sender is responsible for determining that the transaction should happen (Given that the sender in this case is the patient, we don't anticipate a need for patient consent. If a need existed, consent would be the responsibility of the Patient/Consumer sender.)
Considerations
Although this implementation is technically possible, it raises questions and issues that must be addressed before it is practically feasible. The standards and architecture envisioned through NHIN Direct have not explicitly addressed the cases listed below.
1. Unreliable Identities
A clinician endpoint on NHIN Direct is assumed to have had his identity verified by the clinical organization that employs him, or alternatively, by the CA that issues him a certificate. A patient who signs up for a PHR via a purely web-based PHR provider undergoes no such identity proofing.
Implications: PHR service providers may need to create more convenient ways to correlate real-life and virtual identity. Alternatively, the NHIN Direct trust fabric should account for patients and clinicians in such a way that the different types of identities can be parsed by other entities in the communication chain. Alternatively, EMR providers must be able to communicate this discrepancy in trust levels to the recipients of this information. Alternatively, clinical staff must understand the dangers and likelihood of medical identity theft and treat all received data with the appropriate skepticism given its source. We should standardize these alternatives and propose the best methodology for implementation, in order to reduce confusion.
2. Indistinguishable Trust Levels
A clinical organization may choose to provision patients (through a tethered PHR) as well as clinicians as endpoints on their domain, in order to allow those patients to receive or send information to clinicians not affiliated with the tethered organization.
Implications: Patient and clinician endpoints must somehow be distinguished from each other, either through separate domains or separate certificates, so that other points in the communication chain may react accordingly (see point one). We should offer guidance to organizations establishing conventions for address provisioning for individuals who care for patients (patient proxies).
3.Clinician Refusal
An organization or clinician may choose not to receive patient-originated messages as a matter of policy, since it is not required to qualify for Meaningful Use.
Implications: At some point in the communication chain, the message from the patient must be rejected. This may happen at the Destination HSP, in the Destination system, or even through a refusal by staff to read, process, or reply to the message once received at the Destination system. NHIN Direct should examine this case and standardize the appropriate methodology to refuse such requests: Our solution may require further technical definitions of refusal messages or negative acknowledgements. Patients must be given a clear expectation of whether their messages were delivered. (While this point is also relevent for clinician-to-clinician exchange, the lack of a mandated use requirement imposed by Meaningful Use 2011 may result in a lagged implementation of patient-to-provider communication, both by organizations and systems vendors.)
4. Patient Expectations
Clinicians who communicate with each other have certain expectations about the process, based on their training. Individuals will now have access to this communication network without the accompanying experience in the medical community.
Implications: In addition to giving patients access to this powerful communication network, PHR providers must provide appropriate guidance to manage their expectations. For example, individuals must not be given the mistaken impression that messages addressed to drjones@sunnyvalleyclinic will be immediately read by Dr. Jones, even if they receive a delivery receipt. Patients who excessively message their clinicians may have their communications blocked; any such message-delivery failure must be specific enough that the PHR application is able to provide the patient with meaningful information.