Patient Exchanging Secure Messages with Care Providers

Printer Friendly, PDF & Email
Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 2
Yes
Free
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • To learn more about Patient Portals and their usage, see the Patient Engagement Playbook
  • See FHIRDirectPatient PortalAPI, and Open API projects in the Interoperability Proving Ground.  
  • “Direct” standard is based upon the underlying standard: Simple Mail Transfer Protocol (SMTP) RFC 5321 and for security uses Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751.
  • For Direct, interoperability may be dependent on the establishment of “trust” between two parties and may vary based on the trust community(ies) to which parties belong. The leading trust communities to enable communication amongst the most users include DirectTrust (for provider messaging and consumer-mediated exchange) and NATE (for consumer-mediated exchange).
  • Direct is not currently supported by a formal SDO but is actively maintained and updated by the Direct Community.
  • Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers.
  • When using the SMART on FHIR model, the authentication model uses OAuth2. Except for “Secure Communication”, the security patterns listed do not apply.
  • System Authentication – The information and process necessary to authenticate the systems involved             
  • User Details – identifies the end user who is accessing the data                
  • User Role – identifies the role asserted by the individual initiating the transaction                
  • Purpose of Use – Identifies the purpose for the transaction                
  • Security Labeling – the health information is labeled with security metadata necessary for access control by the end user  
  • Secure Communication – create a secure channel for client-to-server and server-to-server communication            
  • Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery                
     

Comment

Feedback on use of Direct Standard

As President and CEO of DirectTrust and speaking on behalf of our large membership and community interested in patient participation in Direct exchange with their Providers and others of their choice, my feedback would be that the adoption level is growing rapidly, as patients and consumers obtain Direct addresses for personal applications, such as PHRs, and also as third parties work with patients to obtain their permission to receive and use their health information via Direct exchange.  Patients' HIPAA rights enable them to designate an electronic end point via Direct to which their health information in electronic format, for example the C-CDA formatted CCD, must be sent by the health care provider or their organization.  Patient portals are becoming capable of asking patients to designate a Direct address for such transmission, which does not require any additional permissions or filling out of forms by the patient with the portal account.  This methodology is attracting a wide stakeholder audience, as researchers, referral specialists, application providers, and many others recognize the ease and ubiquity of Direct exchange for secure and interoperable health information exchange initiated by patients and consumers.  I would suggest at least 2 dots in the Adoption Level column of this ISA table.  Thank you, David C. Kibbe

Empower patients with secure, portable, usable transport of PHI

     As a consumer and sometime patient interested in electronic exchange since discussion of the first RHIO in my state, I am pleased to find this new section of the ISA out for public comment. The efficiency of such exchange with my providers is beyond question. What's needed, though, is: a) authoritative assurance that privacy and security of my personal health information are designed into software protocols that are readily and easily usable by me *and* my providers; b) portability of my identity so multiple providers will accept my information and/or requests for information without a different process, log-ins with different passwords, etc. with each provider; and c) protection against miss-use or sale of my personal health information by any party in the chain of technology that links me to my providers.

     As a volunteer member of DirectTrust, Co-Chair for several years of its Patient and Consumer Participation in Direct Work Group, and consumer member of its Board of Directors, I am persuaded that the Direct Protocol for health information exchange, as elaborated in DirectTrust's policies and expectations, serves these needs.

     If I had a Direct address that I could use for all my providers, this would be a huge leap for consumer/patient empowerment for access to and use of their personal health information. While some allege that FHIR accomplishes this, the fact is that FHIR is not a health information exchange standard; it is a patient access standard applicable for limited use cases. So, for example, I cannot use FHIR to transmit my records directly from an existing patient portal to a new physician. Let me urge that the final draft of the ISA incorporate standards that the entire HIT community AND consumer/patients can use TODAY. These include the Direct Standard for transport and CCDA and FHIR for content.

Advancing Patient Communication

Given the prevalence of Direct among providers today, and the fact that many Health IT vendors certified for 2014 Edition e.3 (Secure Messaging) using Direct, I would recommend at least two dots for the adoption level of patient message exchange via Direct. To improve the efficiency of providing care through the use of this secure electronic communication method, I encourage the following: 1) patients should be able to register/link their patient Direct address in EMRs during in-person visits so that providers can have confidence in the identity of an address during correspondence, 2) encouraging providers to make a suitable Direct address, at least that of their office as a fax replacement, available to patients in a public Direct Directory and via other public sources such as their website rather than being "unlisted", and 3) usability and other enhancements to the user interfaces within EMRs so that secure messages from patients and other providers can be answered and managed, just like email is used today for efficient correspondence in all other business sectors of the US economy, without requiring a specific attachment type or other attachment type such as a CCDA. 

AMA comments on the 2018 ISA

On behalf of American Medical Association (AMA) I appreciate the ability to comment on the 2018 Interoperability Standards Advisory (ISA).

Comment:

The AMA requests the Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) be added to the standards listed for Patient Exchanging Secure Messages with Care Providers. The CFD code set was developed in 2010 in response to industry demand for a patient-focused version of CPT that is comprehensive and useful. The CFDs take the complex terminology of medical procedures and services within CPT and translates it into a language that patients and caregivers can better understand and use. An example is CPT code “Arthrodesis, great toe; metatarsophalangeal joint,” which translates to the CFD “Fusion of great toe.” The CFDs have been included in the Centers for Medicare & Medicaid Services’ (CMS) guidance to Medicare Administrative Contractors (MACs) for adding new CPT codes. One specific example is CMS Transmittal 3670 on the addition of CPT codes to report physical and occupational therapy evaluations.

Patients should have a “key”…

Patients should have a “key” to be able to share ‘read-only’ access to an entire record for another provider and include a time out option.

Patients should be able to choose the levels of privacy AND choose the levels of security.

Patients should be able to communicate in a non-secured way and include a confidentiality disclaimer at the bottom of emails. This can be either a confidentiality disclaimer, or one that states the patient understands that privacy cannot be guaranteed; this goes on every email chain. The patient agrees that they will not hold the institution/provider accountable for it.

If the patient chooses and asks for a non-secure, readily available text or email with the provider, the patient should be free to email and text and choose their own level of privacy. The patient will be responsible for it.

The patient could also choose to use a secure, portal email as well.

Provider notes and/or synthesis of care should include a two-way update with the ability to go back and forth on comments/edits to patient notes.

Patient Exchanging Secure Messages

Patients and providers should be able to have two-way communication through email, Facetime or Skype, texting, photos, videos, and phone calls. New communication technology conduits should be readily adopted for such two-way communication, rather than requiring a regulation or legislation to allow people to communicate.

The patient should be able to choose to communicate through a text or email with his or her provider and FaceTime where appropriate. Like in the legal world, providers may have a disclaimer regarding confidentiality and security.

The patient’s own choice of privacy and security should supersede any institutional requirements. The patient should be able to opt in for deeper levels of security but should automatically be able to choose to share their fully integrated electronic file where they deem fit. The integrated file should be automatically available for emergency care.

The current software allows for physician notes to be viewable to the patients themselves. Patients should have readily available access to these physician notes. In addition, patients’ ability to edit and provide comments to the physician notes would be an important link to their longitudinal care. Better yet, patient edited and co-produced notes with their providers may be optimal. Most importantly, the collective needs to allow for patient participation and communication two-way with the patient’s integrated EHR.

Engage Patients with a Copy of Their Complete Health Data

Direct addresses at the NIST Level of Assurance 3 level, used by DirectTrust participants, provide security and assurance to providers that the person on the other end of the exchange is who they say they are. The use of Direct addresses allows the consumer to effectively communicate with all their providers and payers, without any party being worried about inappropriate release of data or reputational harm. Provider EHRs are beginning to ask consumers to enter the consumer’s personal health record (PHR) address and indicate that the consumer wants any updates to their EHR record to be sent automatically to their PHR. Essentially all the PHRs on the market now accept C-CDAs from provider EHRs and many of them do so using Direct addresses. Because there are currently more than 1.5M Direct addresses including 50,000 consumer addresses, and more than 200M messages have already been exchanged, I would suggest at least two dots for Adoption. 

FHIR could be used in the future to send data to PHRs but FHIR is not ready for this task now for the following reasons:
1) there is too much optionality in current resource definitions (DirectTrust fully specifies the acceptable Direct message options)
2) there is no provider or organization directory (there is with DirectTrust)
3) there is no OAuth-based trust network (there is with DirectTrust)
4) FHIR doesn't cover organizations without EHRs like skilled nursing facilities, longterm care, home health, public health (DirectTrust works for them)