Which Parts of an EHR Implementation Should Be Their Own Project?

A really great discussion has been started on this post about staged patient portal implementations. Here’s one comment that really struck a chord with me:

I think that on a lot of strategic roadmaps “patient portal” is listed as a goal…a one time deadline without understanding how the patient portal works; what information flows into a fully functioning portal and to the patient; and what the system, risk, and security requirements are to consider.

This will require C level suite and decision makers to ask questions that might be getting them “into the weeds” a bit or questions that they may not know to ask. This is why a several strong consultants that are specialists in individual subject matter might be needed – instead of one project manager expected to move the project plan forward on the road map and to know everything.

This comment is right that the patient portal is often seen as a line item on a project plan that just needs to be completed. That couldn’t be farther from the truth. As one person said, sometimes you can get a grand slam, but most of the time you have to do a bunch of little things along the way. A patient portal is a great example of this. You don’t just implement a patient portal one time and then it will run forever. There’s more you can do to leverage a patient portal for your institution.

Are there other parts of an EHR implementation that exhibit similar characteristics? Maybe you implement them, but there’s always more that could be done to improve its use in your organization? Templates and workflow are one that come to mind. There should be an ongoing evaluation of your templates and workflow in order to ensure that it’s as optimized as possible.

What other pieces of your EHR project could benefit from a separate staged project plan? Of course, this assumes you’re starting to think more strategically than just trying to check off the MU check boxes.

About the author

John Lynn

John Lynn

John Lynn is the Founder of the HealthcareScene.com, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference, EXPO.health, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.

3 Comments

  • Positively – Implementation of PHR is not only about technology but also about educating the consumer to access PHR and creating the need to use it till such time it becomes part of life – similar to online banking. Getting the consumers to login in PHR and explore the information and functions available, by itself, is a project – leaving the technology part alone; deciding what is going to be shared with the Consumer is another and if Encounter/Clinical notes are to be shared, educating the Physician to document in a manner that the notes can be shared is another project by itself. What tangible benefits that the consumer gets by logging on to patient portal affects the adoption rate; can online scheduling, request for refills, online bill payment of patient responsibility, remote monitoring and access to Providers online – which ones to implement so that there is value for Consumers and a need to login to PHR…………….

    Other than this Direct/Connect/HISP is a project by itself and educating the Providers on the value is another Project………….

    John – you are right; there are no home runs; all these are smaller projects and taken together achieves the goals.

  • For the Meaningful Use stage 2 having a patient portal is one of the core requirements and the doctors are required to show their interaction with the patients through the patient portal. for this reason physicians should understand how the patient portal works and how they can engage the patients with the patient portal.

  • Pretty good timing. We are about to roll out a new version of our Patient Portal.

    The essence of this is portal users do not need to be “users” of the backend EHR. They don’t take up a “slot” (i.e requiring extra seats).

    The portal users log into the portal, they see a menu of services that they can request, they click, they fill in the form that pops up and they press submit.

    Adding new services to the menu can be done at any time without taking down the system etc.

    The messages that go from the portal log-in go to a single or mulit-thread engine that has an extensive rule set such that a routine request results in a response whereas anything “special” appears in the Intray of either a clinical or admin system user who then phones or schedules a face-to-face or does the required research to push back a response.

    No portal user gets close to the backend system. The engine is the only log-in at the backend system.

    It pays to go easy with portals, you don’t have much control over who is actually at the portal – not all patients have or can master the setup for dual factor authentication.

    But, for routine requests such as “Is my next appointment on Wednesday or Thursday?”, portals can greatly reduce the number of phone calls where patient phones, has to be on hold for 5 minutes or longer etc.

    On security – we know that short passwords where the patient uses the name of their dog/cat are easy to guess.

    It turns out long passwords actually are less secure for the simple reason that the patient has to write them down (very few have LastPass) so the passwords usually end up stuck to the side of the computer or in a wallet, making things really easy for hackers.

Click here to post a comment
   

Categories