View, Download, and Transmit Data from EHR

Feedback on Adoption Level of Direct

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

Direct adoption level for VDT

Since transmit via Direct is required functionality under the 2014 Edition Certification criteria, then the adoption level should be at least that of 2014 Edition certified EHRs (4 or 5).

Julie Maas

CEO, EMR Direct

Remove "trust" barriers to patient-directed interoperability

As Chief Technology Officer of Patient Privacy Rights Foundation, I urge the removal of trust barriers to patient-directed interoperability via Direct or FHIR API. This will enable information to flow without special effort and help patients assemble a longitudinal health record accessible to all of his / her real-world caregivers.

The work of the 2016 API Task Force should also be recognized for its contribution to patient-directed exchange. In particular, that Task Force elucidated the patient’s absolute right to designate a destination for transmission via a FHIR API without any blocking on the basis of “trust” by the API operator. Per the Task Force, the FHIR API operator can warn the patient directing exchange that a destination is “untrusted” but it cannot cannot block the patient from using it if they insist. Per the API Task Force, information blocking on the FHIR API would only be allowed for destinations that would endanger the institution’s security or other patients such as through a denial-of-service attack.

I strongly endorse the addition of Kantara Initiative User Managed Access (UMA) to the API standards for patient directed exchange. UMA should apply equally to both research and clinical APIs so I suggest we remove the “for Research” and make the title “Remote Patient Authorization and Submission of EHR Data”.

The healthcare application of the UMA standard has been profiled by the HEAlth Relationship Trust (HEART) workgroup http://openid.net/wg/heart/ and this work should be recognized in the ISA.

The 21st Century Cures Act provision for API access “without special effort” should be referenced and discussed in the ISA. One way to enable patients to provide access to the FHIR API “without special effort” is to allow the patient to specify their UMA Authorization Server via the institution’s Patient Portal. This would be equivalent to a patient using the portal to opt-in to a health information exchange (HIE) of their choice. Once the patient has done this, their choice should be honored for the next year or until the patient signs into the portal and revokes the HIE designation. There’s no need for the patient to sign-in to the portal for every data access by the designated HIE. There are major benefits of portal control of the HIE to the patient and to interoperability. The patient can point various service providers to the same HIE regardless of whether a particular provider “trusts” a particular HIE. An HIE can then serve a patient’s providers wherever or whoever they are including mental health services, long-term care, research, patient communities, or international facilities. For their part, the HIEs will have to compete on the basis of their privacy policies for the patient’s trust and will not need to worry that their access would be blocked by some FHIR API operators.

Another patient benefit would be a more uniform user experience across different service providers. Patients already need to get credentials to the provider’s patient portal for View, Download, and Transmit. Adding the ability to designate their HIE to the VDT patient portal would avoid introducing a new set of credentials and a new user experience. This would promote health information exchange and help to create longitudinal health records.

Patient identity matching is also enabled by allowing the patient to designate their HIE via the patient portal. That HIE designation would be verified by the HIE the same familiar way a service provider verifies an email address today. This voluntary association between the patient identity and the patient’s HIE preserves the privacy of the patient and allows matching across a full range of services including mental health because the patient’s consent is conveniently factored in.

How about just simple e-mail…

How about just simple e-mail?  SMPT, POP3, et cetera.  I'm NOT a covered entity, and would like this to remain simple.

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 View, Download, and Transmit Data from EHR. 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.

Remove process burdens on…

Remove process burdens on patients under HIPAA that may limit patient access to their health information based upon patient choice of levels of privacy.

Patients should have instantaneous population of care into their medical record

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.

Allow patients to view the complete patient record, including pricing, tests, films, lab results, and health care provider notes. Enable patients to comment on their review of such services. Provide affiliated charges and pricing. Price and cost transparency should occur before patients get care and should be presented electronically. As patients access the EHR, they should access the range of pricing from the institution.

The health care provider should be able to view their patient’s aggregated/comprehensive patient electronic health record. Health care providers should have the ability to email notes and orders to each other to communicate regarding patient care.

Technology can support automatic data transfer to patients and better security protection. This will allow patients to be sure their health care providers have the information they need to provide high quality treatment while allowing patients and caregivers to manage their acute and chronic conditions at home.

View, Download, and Transmit Data from EHR

Much like the financial community, patients should be able to download their medical data. If any provider or the patient himself wants to view the integrated lab tests and look at a five or ten year horizon, he/she should be able to readily download the data and compare and contrast changes. They should stored in machine-readable form to allow for data analytics by care providers, caregivers, patients, and for research (where the patient has chosen to opt in).

HHS should seek to remove blockage and process burdens on patients under HIPAA that may limit patient access to their health information based upon patient choice of levels of privacy. See our comments above regarding instantaneous population to the digital record and eliminating signing a form for access and waiting 30 days.

Patients should be able to view their complete patient record, including pricing, tests, films, lab results, and health care provider notes. The EHR should provide affiliated charges and pricing. Price and cost transparency, outside of emergency situations, should be provided upfront to the patient prior to rendering services. As patients access the EHR, they should access the range of pricing from the institution compared to other comparable price ranges for a similar procedure elsewhere.

Health care providers should be able to view their patient’s aggregated/comprehensive patient electronic health record. Health care providers should have a two-way ability to communicate via email, phone, and text with each other regarding patient care.

We support the OpenNotes movement for physician notes to be provided attached to the patient EHR and two-way communication to be allowed for patient engagement.