White Papers

Patient Portal (Teaser Article)

By November 1, 2017 No Comments

One of the most important yet challenging pieces of modern health IT is the patient portal. It is one of the main means through which patients can access their health information and engage in electronic exchange with their providers. However, it is one the most challenging processes at several levels. Most notably, it is the piece of health IT that patients use most, and their interests and needs are often different than those of clinicians.

Along those lines, though a clinician compares EHRs with other EHRs, a patient does not necessary compare the health portal with other health portals, but to the “portals” they use in other parts of their life, such as their banking portal or a social media site. Because of this comparison, health portals often fail to capture the attention and interest of the patient. Too many patient health portals have limited functionality and unintuitive design, yet, there is so much potential in a patient portal.

Drummond Academy has developed a whitepaper that explores ways to design a patient portal that expand the potential use cases while using and satisfying many of the ONC 2015 Edition criteria. Though there are certainly features that can be designed in a patient portal outside the ONC criteria, the choice to tie the applications to ONC criteria is purposeful in illustrating how the ONC requirements support and encourage a quality portal experience. Many of these elements support the CMS requirements in their new Quality Payment Program as well. These features include:

  • Foundations of Modern Patient Portal
  • Core Features – VDT and Secure Messaging
  • Patient Intake
  • Patient-Specific Education
  • API

With the move to payment for quality or payment for services, patient engagement is critical to the cost savings of providers and hospitals. Portals also can provide a way to truly differentiate an EHR developer from its competitors and create strong customer loyalty. The modern patient portal can be a major steppingstone in the evolution of healthcare in our country.

 

Modern Patient Portal (expanded whitepaper)

Introduction

One of the most important yet challenging pieces of modern health IT is the patient portal. It is one of the main means through which patients can access their health information and engage in electronic exchange with their providers. However, it is one the most challenging processes at several levels. Most notably, it is the piece of health IT that patients use most, and their interests and needs are often different than those of clinicians.

Along those lines, though a clinician compares EHRs with other EHRs, a patient does not necessary compare the health portal with other health portals, but to the “portals” they use in other parts of their life, such as their banking portal or a social media site. Because of this comparison, health portals often fail to capture the attention and interest of the patient. Too many patient health portals have limited functionality and unintuitive design, yet, there is so much potential in a patient portal.

As CMS and the healthcare industry move toward fee-for-value rather than fee-for-service, the worth of a patient portal to encourage healthier outcomes will increase, providing a great opportunity for developers.

To achieve these outcomes, the modern patient portal needs to be re-imagined in its design and workflow implementation to fully engage patients in their health care and allow clinicians more opportunities to engage their patients outside the office visit.

Scope of Document

This whitepaper explores ways to design a patient portal that expand the potential use cases while using and satisfying many of the ONC 2015 Edition criteria. Though there are certainly features that can be designed in a patient portal outside the ONC criteria, the choice to tie the applications to ONC criteria is purposeful in illustrating how the ONC requirements support and encourage a quality portal experience. Many of these elements support the CMS requirements in their new Quality Payment Program as well.

The ONC 2015 Edition has many criteria that are explicitly intended for use in a patient portal, and many others that can be used in one. This document explores creative ways in which ONC health IT criteria can be used in a patient portal.

The Drummond Group’s overview sheets provide an excellent look of the requirements of this criterion (§ 170.315(b)(6)), including references to the necessary standards and ONC background on this criterion from the preamble section of the 2015 Edition Final Rule. Those documents are available to developers who have fully enrolled for testing. Contact Drummond Group for more details.

Foundations of Modern Patient Portal

Designed as a platform

The biggest change to creating the foundation of a modern patient portal is ensuring it is designed as a platform rather than an application. Think of the patient portal as a platform with many applications that can be built on it instead of just a singular application. It is a platform for patients to see and share their health data and engage with clinicians. The portal can then have its “apps” such as viewing of health data or an email client to send and receive messages with health staff and patient-specific education.

When a portal is designed as a platform, it makes is scalable for future development and innovation. Individual applications can become outdated and obsolete, but platforms provide more flexibility. As developer see their portal as a destination for patients to engage their main healthcare applications, then they will begin to see the portal becoming an essential feature for their customers.

Bi-directional communication with EHR

Perhaps one of the biggest issues with many existing portals is limited or nonexistent bi-direction exchange and communication with the EHR. Too many portals are “dead ends” where data is only uploaded and not synchronized with the EHR.

Though a portal certainly should receive data from an EHR, data should also flow from the portal back to the EHR. This includes secure messaging and changes to data made by the patient. It is reasonable and wise to allow some controls on what can be changed in the portal by the patient and allow the treating clinician appropriate control to approve an update on the patient record. However, the portal needs to be seen as a true extension of the EHR product rather than a simple add-on application.

Adapted workflow

The final foundational piece needed for exceptional patient portals is for clinicians and hospitals to appropriately adjust their processes and workflows to introduce patient portals earlier and more often in their patient engagement.

Portals often are not promoted to patients. If patients are not encouraged to use the portal or they do not understand its benefits, then the portal will be neglected. Ideally, the patient portal is introduced when the patient first visits the clinician or hospital. A nurse or staff can explain it and show its value in finding relevant health data. Perhaps the patient uses it in the room before seeing the provider and enters intake data such as family health history and smoking status.

Clinicians need to find what works best for them and adjust their approach to best use the full value of the portal.

Modern Patient Portal using 2015 Edition criteria

Core features – VDT and Secure Messaging

When thinking about the patient portal, the two primary functions from an ONC criteria perspective are the View, Download, and Transmit (VDT) and the Secure Messaging criteria. These provide the staples of patient portal applications. Fortunately, most existing patient portals have one or both of these functions, so relatively little change is necessary, although the experience can be improved.

VDT is rather straightforward in its function by its name: It gives patients and their authorized representatives access to their health data and the ability to share it. Virtually all patient portals have this capability, and this is generally its chief application.

One thing portal developers can consider is ensuring that the layout of the patient data is presented in a way a patient can understand. Many times, the data is displayed using the style sheet rendering of the C-CDA XML listing all the patient’s health data. Though that might acceptable and useful, developers should consider using a modified design to better call out the aspects of a record most applicable to the average patient, specifically problem list, medications and laboratory results. Also, highlighting changes or updates in the record, such as new medications or lab results, will assist the patient in saying abreast of their health summary and encourage them to visit their portal account regularly.

Secure messaging is another key feature that most portals have. It involves being able to exchange messages between the patient and the provider in a secure manner. One of the greatest values in secure messaging is that it allows developers to create applications that are highly requested by both patients and providers. Using the secure message capability, developers can make customized message applications for appointment requests and medication refill notifications. Developers also might look to use some more advanced but potentially very useful means to tie secure messages or notifications from the patient portal to the mobile device of the clinician, as long as proper security features are employed.

Patient Intake Criteria

Some aspects of a patient health information cannot be determined solely by the clinician, but instead rely on the patient to reveal it. Clinicians have long used patient intake forms to collect pertinent information related to the patient. Many of the ONC criteria are elements typically captured through intake forms.

Most of this intake information is captured for new patients. Given that, allowing the patient to record this data themselves can save office time as well give the patient an opportunity be empowered and responsible for their health care. For most clinicians and hospitals, a patient portal account is not created until after the patient’s initial visit. However, if the patient engagement can be re-imagined and adapted in the workflow differently, it could be used to capture patient intake on the day of or even prior to the visit. Allowing a patient to make edits to these categories or at least see this data also can be valuable.

Family health history

Family health history is just that – recording of the health history of immediate family members (parents, siblings, and children). It is information a clinician can know only if shared by the patient, but knowing this information can greatly assist a provider in the patient’s care.

For the ONC criteria, the health IT system must capture the diagnosis or known problems and label them for the respective family member. For example, the patient indicates that the father has hypertension and brother has diabetes.

As this example above indicates, the patient might have only a general understanding of their family member’s disease and conditions. For example, they don’t know if diagnosis is type 1 diabetes or type 2 diabetes. A clinician would be able ask further questions to better identify the most accurate condition, but allowing the patient to record this is an important start. As with all intake data, it needs to be synchronized with the EHR, and often designed to allow the clinician the ability to approve or finalize the data given patients’ often limited understanding of medical details.

One option is to allow the patient portal to have several of the more common healthcare conditions preset and available for the patient to simply mark applicable conditions off in a checkbox. The provider can then refine this and add to it when the patient is seen and more questions can be asked. As new conditions are discovered or procedures done on family members, the patient has a real-time means to update this information and share with the clinician rather than waiting until the next visit.

Implantable device list

Implantable devices such as stents and pacemakers play a major role in our health care. ONC now requires health IT systems to capture implantable devices. Implantable devices are identified by a unique ID describe the device, its manufacturer, when it was made, when it expires and other important details. It is needed to get a full picture of a patient’s health.

If most people do not know even know their driver’s license number without looking at the ID, they certainly are not going to know their device IDs, which are often 50 characters long. However, they generally look them up and add them to record if given time to do so. If a provider is unable to electronically obtain the implanted device ID from hospital or surgical center records, the patient researches this after the visit ends and updates it on the patient portal. The portal can synchronize this data with the EHR so it is in the patient’s record for the doctor to view later.

Demographics

Demographics is data that has long been captured by providers for all patients and at first blush seems to be of little value in using a patient portal for its collection. However, there are two reasons this could be valuable.

The first is that demographic categories have been updated, with new codes and values. Second, some demographic categories might be more easily captured by the patient entering it directly into the health IT system.

An example of these two points are sexual orientation and gender identity, which are two new categories in demographic capture. A patient might not feel comfortable having this information recorded by the front desk or billing person, who often does capture and record demographic information on behalf of the clinician and hospital.

Smoking status

The ONC criteria (315(a)(11) requires recording of smoking status. That criterion does not have a specific set values listed, however, the patient summary C-CDA file requires smoking status to recorded as specific values such as a “never smoker” or “current every day smoker.” As with these other elements, this information is documented based on the patient revealing this to the clinician.

Another valuable means of having smoking status explicitly called out in the patient portal is to help clinicians provide smoking cessation educational materials for those patients who are smokers. Because of the great health risk of smoking, cessation activities offer a great health benefit and are easily communicated through a portal, possibly in the patient education section.

Patient-Specific Education

Providing patient-specific education within the patient portal is a natural fit for a portal. For one, CMS QPP measures speak of patient-specific education being provided electronically rather than by paper copies. Having this information stored at the patient portal where a patient is already tracking their health data reduces the number of locations or processes for a patient to track.

Second, patient specific education can be queried via the Infobutton retrieval specification, which can be accessed easily from a patient portal. Because the patient health summary contains problems and medications and other clinical information about the patient, the portal can extract this data and then use Infobutton to obtain the patient-specific information.

For those unfamiliar with Infobutton, it takes the specific SNOMED codes of a problem diagnosis or RxNorm codes of a medication prescription and uses them to find relevant education materials at a server. What also makes it a good fit for a portal is that the query to the server can be just a URL connection or web service call so the program needed to implement is minimal. An illustration of how this service can work is found here.

The final reason patient-specific education works well in the patient portal is Infobutton allows educational material to be identified based on the patient’s problem and medication lists. After the problems or medications have be recorded by the clinician, the Infobutton specification does the rest in finding the relevant material. The clinician maintains control over the relevant educational materials that are provided by ensuring the problem list and medication list are accurate.

Of course, there is also value in portal developers allowing clinicians to submit other educational materials or in providing specific educational resources themselves. Using Infobutton does not preclude providing additional educational resources but can be seen as a complement.

One design consideration is for the portal to have its own “education” tab or section. From there, the codes for medications and problems can be copied and used to make the Infobutton queries so that the relevant educational resources are immediately available. Though there are some design considerations, this task would ensure that patient education is recent and up-to-date as the patient’s record is updated.

API

A major point of interest by ONC, CMS, and the healthcare IT industry at large is the use of application programming interfaces or APIs. APIs provide interfaces for systems to connect to each other and share data and go beyond the sending of an electronic patient record to enable read and write access on specific health data. APIs are a staple in most modern computing systems, but they have been slow to take off in health care.

That is changing with the introduction of the API criteria (315.g.7-g.9) in the 2015 Edition, and CMS’ emphasis of them in their Quality Payment Program. API use holds a great deal of promise for health care.

Implementing APIs with a patient portal is a natural extension of the portal’s design for several reasons. First, the API capabilities of accessing patient data align with the core features of a patient portal. CMS recognizes this and combines the API features in the same VDT and patient access measures used for portals.

Second, the API enables a developer to access patient data on the portal using a mobile application. In a world where users often ask “is there an app for that,” providing an iOS or Android-based app for accessing patient data on a mobile device is a valuable tool. Developers able to provide an app to access patient data hosted on the portal complement their patient portal and also demonstrate how their API feature can be used.

Third, there is a real concern of patients having too many healthcare portals in terms of their health data being distributed across different portals without being synchronized. Implementing and utilizing an API provides a valid means for this synchronization or at least provides a means of showing the full breadth of the patient’s health data.

Conclusion

Making a better portal experience has some downsides, the largest of which is the cost. It is not cheap to make a quality patient portal, and alone, it is not a “billable” service for clinicians to use to re-coup costs.

To that end, applying a more iterative approach to pushing just one or two major new enhancements each year is not an unreasonable approach. It allows developers to better manage their costs, and it does not overwhelm the user with many new features at once.

However, doing nothing to enhance a patient portal puts the patient, the provider and the developer at great risk. Research shows that patients who are more engaged with their providers in their health care have significantly greater healthcare outcomes.

With the move to payment for quality or payment for services, patient engagement is critical to the cost savings of providers and hospitals. Portals can also provide a way to truly differentiate an EHR developer from its competitors and create strong customer loyalty. The modern patient portal can be a major steppingstone in the evolution of health care in our country.

Leave a Reply