User competency checklists are an essential part of the toolkit of any agency or program during every phase of adopting an Electronic Health Record (EHR) system – before, during, and after implementation. Similarly, chart audit tools are essential for use during training and at regularly scheduled intervals after “going live” (officially beginning use of your EHR software to document care of real clients). Many agencies make the mistake of forgetting that ongoing chart review is necessary on a perpetual basis in order to ensure that staff members continue to meet your agency documentation standards as program needs and your software change and evolve over the years.
A pre-training user competency checklist covering basic computer skills should be used for each staff member before they begin training in your EHR software. This includes all staff who will be participating in the initial training when EHR software is purchased as well as future staff as they come on board. This checklist should cover basic computer skills (e.g., knows how to use a dropdown menu, can use Cut, Copy, and Paste functions, knows how to switch between Windows, can Save a document, etc.). Ask your software vendor for a list of basic skills that users should know before they begin training in your EHR software. Offer supplemental training as needed.
An agency-specific post-training user competency checklist or Chart audit tool should be developed and used during the training/implementation period at and regularly scheduled intervals after going live on an ongoing basis. This tool assesses each staff member’s ability to use your EHR software correctly, effectively, and efficiently and specifically covers features of your particular EHR software rather than the universal basic skills of your pre-training checklist– consult your vendor for a suggested list of items to include. Be sure to also include your own specific program or grant documentation needs, along with items that assess competency in any standardized terminology that your EHR software is based on.
Who should conduct chart audits? There are several options – project leaders, supervisors, Super Users or peer reviewers. Peer review can be done during a dedicated portion of staff meetings or inservices. Perhaps the best approach is a combination of all of the above.
Chart audits should always be presented as learning opportunities to staff and individual follow-up needs to be offered whenever needed to ensure that the staff member understands any changes s/he needs to make in her documentation practices. Identification of common errors across a number of charts signals a need for an inservice or staff meeting discussion to reduce or eliminate the same errors from recurring in the future.
Using these valuable checklists and tools on an ongoing basis will help you and your agency now and in the future. What are you waiting for? Talk to your software vendor today!
Whether your program uses paper, electronic, or hybrid records (a combination of electronic and paper documentation), health records are legal documents and are subject to a mix of regulations governing corrections in the record that vary across states and organizations. Thankfully, there are some standard “do’s and don’ts” that apply to common changes that may need to be made in the EHR (electronic health record), such as corrections, deletions, and late entries.
EHR data entry errors can be caused by software design problems (e.g., confusing screen layouts) or more commonly, due to user error. User errors are inevitable, so a policy addressing errors should be in place before going live (i.e., generating “real” client records) with any new EHR software.
Just as using white-out or otherwise obliterating data or discarding portions of a paper record is a legal no-no, incorrect data originally entered in an electronic record must be retrievable in some way. In addition, there must be some sort of notation in an EHR that it has been amended in some way, usually by some sort of narrative entry indicating the type of change that was made.
So, generally speaking:
When researching EHR software for your agency, ask your vendor how changes are handled in the software and how the software tracks changes made after the original information has been entered.- EHR software should include the functionality to lock a record from any further editing once a final signature is applied/charting is complete. Only a very limited number of users in an agency should have the ability to unlock a record once charting/documentation has been completed.
- Your software should be able to track who made the change, what type of change was made, and when (date/time stamp) the change was made, as well as retain the original information.
- The user should make a notation in the record describing the change (such as a brief narrative note) – ask your vendor where/how this is best done.
- If a paper/hard copy record has been printed from the electronic record before the change was made, the paper record must be changed as well. No forms should ever be removed from a paper record.
- Develop a records policy before using your EHR with “real” clients. Each organization will have its own policies and procedures governing health records according to the laws of your state and other regulatory bodies.
- And most importantly, NEVER let someone else use your login and password to make a change in your client’s record!
A sound records policy in place is your best insurance policy against any legal challenges to your program’s records. Ask your vendor and your colleagues who are already using EHRs for assistance and examples.
At times the process of designing state reporting systems seems to neglect the perspective of software vendors and local health agencies. Often state requirements are promulgated via a set of forms to be filled out, even though the submission in this era is typically electronic. But the data on the forms is only as good as systems designed by the software vendors to capture and report the data, and the processes utilized by local agencies to incorporate software in everyday delivery of services. Two local agencies can each submit great-looking forms, with numbers in every box. But one agency can be using software and work flows that promote accuracy, while another agency has software that is not suited to the data being tallied, or work processes that cause data to be collected at the wrong time by the wrong person.
State public health reporting has been greatly impacted by the advent of requirements for Electronic Health Records (EHR). In 1996 Congress enacted the Health Insurance Portability and Accountability Act, commonly known as HIPAA. This led to major improvements in uniformity of data, and measures to safeguard privacy and security of data. It also laid the groundwork for EHR.
In 2007 Minnesota passed legislation requiring health providers to have an interoperable EHR by 2015. In 2009, Congress passed the Health Information Technology for Economic and Clinical Health (HITECH) Act as part of the American Recovery and Reinvestment Act. Monies are available to hospitals and clinics that make “Meaningful Use” of certified EHR software. While the focus of this legislation is hospitals and clinics, the local public health system is certainly affected by these legislative actions. In fact, some local public health agencies qualify for Meaningful Use monies, and are vitally interested in software that satisfies diverse requirements.
Twenty years ago a state health agency could convene a meeting of state and local staff, with representatives from software vendors, and talk about the specifics of state reporting. However systems for collecting and reporting data have grown much more complex in the last two decades. Even so, as a former local health director who actively participated in the design of state reporting systems, and current CEO of a software vendor that serves the public health market, I believe active dialog involving these actors would greatly assist the goal of meeting EHR requirements.
Local health agencies have been reporting 
to their state counterparts for decades. Of course state health agencies have an important role to play in the public health system, as they set policy through legislation and regulation, and dispense funds. The natural consequence of policy and funding is reporting, to ensure services are provided and funds properly spent.
The decades of the 1980s and 1990s saw widespread adoption of automation in local health agencies, as the personal computer revolution spread from the business world to the government sector. This brought an end to the era of hand-tabulating tallies of services performed, with reports submitted on paper forms. With the advent of database software, whether dBASE or Access on the personal computer, or more sophisticated software running on mini-computers or mainframes, local health agencies could collect data on a daily basis, and generate reports at will.
In this environment software companies emerged. In Minnesota, there were in the late 1980s and early 1990s at least five different software companies offering their products to local health agencies. A similar situation occurred in neighboring Wisconsin, although the differing role of local health agencies in other states may have led to a different software solution. For example, in some states the state health agency has built software for selected public health services and offered or mandated it for use in local health agencies.
There is clearly a connection between the interests of a state health agency in designing state reporting systems, and that of software vendors who sell to local health agencies the tools needed to collect data for those state reports. What should the relationship be between these parties? Here are the actors:
- The state health agency
- One or more software vendors
A variety of local health agencies, some small, with limited technical resources, and others large, with greater resources and perhaps systems they have built for themselves
Each of these actors brings unique strengths to the conversation. The state agency understands the needs for consistency and uniformity, in order to be able to report to the legislature or federal government. The software vendor understands how to design screens to collect data, a database for storing data, and reports to tally data. But the local agency understands work flow and the service delivery processes which must mesh with the collection and reporting of data.
Certainly, the need to collect and report data is secondary to the priority of delivering quality services to clients.
(Look for Part 2 of this article on 3.13.12)
You're telling me I need to take the laptop out to a home visit? Are you serious?? There is no way I can take the laptop out-- it will be ruined!
These were my thoughts when I first heard that we were going to go paperless. We have been using our laptops out in the field for the past three years and it is a slow process.
Some of our barriers are:
-
We only have two wireless cards and have six nurses in MCH that do home visiting.
-
We live in a county that does not have cellular coverage everywhere, which means we have times when we can’t chart at the point-of-care.
-
We have staff that admit that they have a hard time letting go of paper charts.
-
Not all nurses are comfortable using the computer and some don’t know how to trouble-shoot connection issues in the field.
However, we keep plugging away bits and pieces at a time. As time goes by we are all learning how to progress with change. It is not a bad thing - it is a challenging change. You start with little bits and pieces at a time and then you look back...
realizing that it was not so bad.
Today’s fiscal constraints and emphasis on accountability push us to demonstrate the outcomes of our services at all levels: individual, family, group, community, system. This is a daunting task. Agencies using the Omaha System have an advantage because the Omaha System has a built-in outcomes component that can be applied to any level of service. In brief, the KBS data we get from the Omaha System enable us to talk about the needs of a population (prevalence and severity of problems of the clients we serve).
There are several examples of applications of the Omaha System at the family, group, community, and system levels. Some of them are published on-line at omahasystemmn.org.
There is a study in progress applying a community level intervention for obesity – you are welcome to join this study! If you are interested, here is more information: http://db.tt/1VyanqJb
The precedent for use of KBS ratings at the community level was established over 10 years ago. The fundamental next step toward successful dissemination of this method is to work together as we compile examples of KBS rating guides for problems we address with families, groups, communities, and systems.
In every analysis, we find that KBS ratings are a compelling voice for public health nurses and clients – we are so fortunate to have this language!
The term electronic signature is a rapidly evolving term, used both as a generic term encompassing a variety of ways that an electronic record can be signed (attested) as well as a specific type of method. Depending on the software in use, E-signatures can be entered in many ways, such as clicking on an “I agree” button, to writing one’s actual signature on an electronic tablet (like you do in the supermarket) that is attached to an electronic document, to simply entering a secret code or PIN when entering documentation.
Standards and definitions vary across states and organizations and there is no one accepted set of regulations governing electronic signatures. Depending on individual agency requirements, policies and software may be simple or complex. However, there is a basic understanding of the three main purposes of an electronic signature as defined by the American Health Information Management Association (AHMIA). These are:
- Intent: An electronic signature signifies an approval of terms, confirmation that the signer either reviewed/approved the document or authored the document and approved the content
- Identity: An electronic signature identifies the person signing
- Integrity: A signature protects the document from repudiation (the signer later claiming that the entry was invalid) or alteration
Available at: http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_045551.hcsp?dDocName=bok1_045551
Using a unique login (username and secret password or PIN) to enter documentation in an electronic health record is the simplest form of electronic signature. Electronic health record (EHR) software using this method should allow the user to lock their entry from editing by others, as well as be able to generate a data trail of who entered or changed any data in a record (including retaining the original information in some way). This brings up an important warning to all EHR users -- never, ever share your unique login credentials (username and password) with others – if assigned your credentials by others when first using an EHR software program, it is suggested that you then change your password or PIN to one that only you know.
Other agencies may choose to utilize a more complex form of electronic signatures, including making pen tablets available to obtain a physical signature and capture it in the electronic record (a digitized signature) to complex forms of encryption that allow for sole usage by a provider. Consult with your records experts in your own agency, as well local, county, and state officials to determine what is best for you and your program.
Posted by
Ben Fyvie on Thu, Feb 16, 2012 @ 09:51 AM
Submitting a billing claim, getting a list of vaccinations for a client, faxing orders to a physician and emailing a client about their next visit; what do all of these have in common? Well, you likely wouldn’t be able to do any of them without the power of the internet. With recent technological advances you’re likely finding that more and more of your work requires a connection to the internet. Today we are going to talk about the efficiencies and money savings gained when moving to a hosted EHR solution.
The first thing you’re likely to notice when moving to a hosted EHR solution is that there is no need to install any software. This means huge time and cost savings for your information technology department. In fact, you don’t even need an IT department; you can think of it as a “geek free” solution!
The second thing you’re going to benefit from is that you are no longer tethered to your office workstation. You can get your work done from anywhere that you have an internet connection. This means you can leave work on time even if you haven’t finished your charting for the day. You can make time for dinner with your family and then later that evening you can sign in to the EHR application from home to finish your work. Think of the possibilities of being able to get your work done from anywhere…anytime!
Finally, there are numerous efficiencies gained by software vendors who offer hosted solutions. These are often passed down to users in the form of:
- Lower costs
- More frequent releases and bug fixes with no end-user intervention required
- Better stability and reliability of the application
As you can see there are many benefits to moving to a hosted EHR solution. One thing you’ll want to keep in mind is that with any hosted solution the data is not stored in your office. You’ll want to verify that the software vendor gives you full ownership rights over your data and the ability to retrieve a complete backup of your data.
The internet is already playing a major role when it comes to EHR and that role will only be expanded upon in the future. Having a hosted EHR solution will put you in a position to take advantage of the latest technology and integrations available to provide the best care possible to your clients.
Posted by
Ben Fyvie on Tue, Feb 14, 2012 @ 04:51 PM
This is the last in our series of blogs on electronic health records. The first two covered physical and digital security. The focus of this article is data confidentiality.
Client data should only be viewed on a need to know basis. There are a number of things your software can do to allow you to enforce confidentiality restrictions.
- Role assignments could be used to restrict users from certain portions of the application. For example, billers shouldn’t have any need to see charting information and so they should be assigned to a role that prevents them from viewing the charting screens.
- Program assignments could be used to group your clients into separate categories. Your employees could then be assigned to the programs for which they need access to. For example, if you have a nurse that deals strictly with maternal child health, they should have no need to view records for clients that are being seen for HIV treatment.
- Audit trails could be created for the actions your employees take in the application. With an audit trail you would be able to run a report that gives you insight into the records that a given employee has viewed,
created, modified or deleted. If a client wants to know which of your employees has viewed their record, you would have no trouble getting them this information.
There is one last thing that you can do to ensure your software application is secure. Be informed. Don’t be afraid to ask questions of your software vendor, they should be able to respond to any inquiries regarding the security measures they have in place that makes their application safe and secure.
You’re already taking an important step towards being informed when evaluating software products just by reading this blog. You can never be too safe when looking for a place to store your confidential data.
Posted by
Ben Fyvie on Fri, Feb 10, 2012 @ 04:27 PM
This is the second in a series of 3 blogs on EHR security. The first one covered physical security. Now we'll talk about digital security.
This is the type of security that gets the most attention these days. While there will never be an application that is 100% safe against hackers, there are a number of things you should look for to ensure that your application is only accessed in a secure fashion and by authorized users:
- If your application is accessed via a web browser, the web address should start with https (not http), this ensures that all data is encrypted before it is transmitted across the internet.
- Password requirements. Since
passwords are a major part of accessing any software application it is imperative that measures be taken to ensure the passwords are secure.
- Forgotten passwords should be required to be reset. The application should never remind you of your password via email.
- Passwords should be required to be ‘complex’. Typically this is considered to be at least eight characters in length with a mix of letters, numbers and symbols.
- Passwords should be required to change on a regular basis.
- An account should be locked out after a number of consecutive failed login attempts.
The last blog in this series will post next week and covers confidentiality.