CanadianEMR: EMR Comparisons, Ratings, Directory Services and Expert Discussions

Updated BC College Guidelines on EMR Use

The British Columbia College of Physicians and Surgeons has reminded physicians about the change to the retention of medical records as defined under section 3-6(2) of the Bylaws under the Health Professions Act. The Act has been amended to reflect the change to the Limitation Act. College registrants are now expected to retain medical records for a minimum period of 16 years from the date of last entry or from the age of majority, whichever is later, except as otherwise required by law as of June 1, 2013.

Highlights from an updated College Guideline on EMRs:

• Physicians may choose either to scan paper records electronically in a “read only” format, e.g. pdf, or to start entering data from day one of their new EMR. Either way, the College recommends that paper records be kept in close proximity for at least six months. Unless they are completely scanned into the EMR, paper records must be kept indefinitely if the patient continues to attend. If the patient has left or moved, paper records must be kept for at least 16 years from the date of last patient contact (or until the patient reaches age 35 for patients under 19).
• Physicians must ensure that complete medical records (paper, electronic, or a combination of both) are accessible at all clinical decision points and for the duration of the retention period prescribed under section 3–6 of the Bylaws under the Health Professions Act.

Click here to download a full copy of the updated guideline.

What Is the Next Phase for EMRs in Canada?

One of the questions that I am frequently asked about EMR systems is to describe what I see as the future of EMRs in Canada. With many provinces now achieving a critical mass of EMR users, we will now be able to do things with EMRs that in the past were very difficult to achieve. There are some key EMR features that I would like to highlight.

• Usability: EMRs will get easier to use. This will take place at variable rates depending on which EMR system you are using. Those with active user groups who can provide constructive feedback to vendors will benefit the most. As the focus shifts from getting physicians to adopt their first EMR system, to EMR optimization, it will become more important for vendors to focus on the usability of their systems and they will dedicate a greater proportion of their resources to improving their products.
• Mobility: EMRs are traditionally accessed using a laptop or desktop computer. The laptop is sometimes carried by the physician from room to room or can be attached to a wall mount or mobile cart. Because it is best to access one’s EMR using a large monitor due to the large amounts of information that need to be accessed, it is not practical in many settings to use tablets or even smartphones on a consistent basis in the examination room. However, outside of the medical office, the needs are completely different. When accessing one’s EMR remotely, the ability to view specific information using a mobile app, or even a browser with secure access, are extremely valuable to clinicians who may need to look up a lab result or write a prescription. The next phase of EMR use will see a much wider range of mobile apps for both look-up purposes and the management of medications and clinical notes.
• Security: Some clinicians are likely to use regular email for communication with colleagues and patients. This is not ideal from a security perspective, but often practicality trumps security, particularly if the process is time-consuming and makes the messaging more difficult. The next phase of EMRs will incorporate easier-to-use and more streamlined secure communications to transmit information to colleagues (secure referral or consultation) or to communicate with patients through integrated patient portals.
• Analytics: As physicians move through the early challenges of EMR implementation and achieve a level of optimization of their internal office setting, they will become far more focused on the ability of EMRs to improve patient care. This will dovetail with pay-for-performance programs in which provincial programs will expect to see measurable benefit for the dollars invested in healthcare. In a paper-based practice, this would be extremely difficult to accomplish; however, using an EMR that incorporates analytic capabilities, it will be possible to generate status reports for populations or individual patients with a click of button.

What other features do you think will be prominent in EMRs in the next 5–10 years? Add your thoughts or comments below.

EMR in Canada Part II — A Developer’s Perspective

Part 2 of a three-part series of articles written by a veteran software developer who has worked extensively in the EMR industry. The article series is published on his behalf. His comments are directed broadly at the industry. Read Part 1 Read Part 3

Where We Are

There are three key areas that I see as the most problematic:

• Poor User Interface (UI) Design
• Lack of Quality Assurance
• New Technologies

Poor User Interface (UI) Design

The development of our current EMR systems usually started with selection of an SQL database, creation of the tables and links between the tables, then development of the client system. This resulted in clients with user interfaces that were heavily influenced by the database schema, not by how the user would want to see the data. (Define the Client)

One can see the result of this development approach in the most vital part of an EMR — the patient chart. In clinics that are still paper based, a patient’s chart is a collection of documents, lab reports, clinical notes, etc. that are usually sorted chronologically. The doctor can quickly flip through the pages to gain an understanding the patient’s history and current conditions. In EMR systems the client chart is often a jumble of data grids in separate tabs or windows. This results in lab results on one page, procedures on another, consults on a third, etc. Even in EMR systems with a Cumulative Patient Profile (CPP) the CPP tends to look like a bunch of grids cut and pasted together. The data is organized the way a programmer would organize it, not the way a doctor would.

In designing user interfaces I use a technique call Task Analysis. With this method you break down each task a user would perform into individual steps, and then mock-up the steps one window at time. For this I like to use old fashioned pen and paper. I draw each window on a page of paper and walk through a task one page at a time. Drawing the windows by hand is a good way to judge the complexity of the information the user is looking at. If it takes more than a few seconds to draw the window, then it is too complex and you probably have items in the window that are irrelevant to the task being performed. If you find there are too many windows, they may need to be combined into one so they can be executed in a single step. I repeat this for each task that has been identified. Once completed, I take the stack of pages to a user and have them walk through each of the tasks one page at a time. This technique is also a good way to analyze an existing user interface, drawing the pages and walking through the steps. Simplicity is key. However, most EMR systems I have looked at fail in this regard.
 
Years ago, when designing software for Win 95 and XP and 640×480 screens, data density was a big deal. We used to calculate data density by measuring the area taken up by data compared to the entire screen. Having multiple windows open at the same time was a problem with Win 95 and XP, so you tried to fit as much data as possible into small screens. These days the opposite is true. With Windows 7 and large wide monitors, good UI design means an uncluttered display and sparse data. This makes it easy for a user to comprehend at a glance what is on the screen. There are many ways to display more information; most current EMRs still have densely populated windows. This is the result of designing around database tables.

Lack of Quality Assurance

Over 10 years ago the term “Test Driven Development” was coined. This referred to the concept of writing tests to check the functionality of each section of code as you developed it. This forced developers to separate code into small, testable chunks or Units and the tests were called Unit tests. Frameworks were developed to create and run Unit Tests for almost every programming language. It was a huge leap forward in improving both the quality of code and the pace of development. Test Driven development and Unit testing quickly became standard practice, or so I thought until I started working for EMR companies. The companies I worked for did some Unit testing; however, it was not standard practice and the amount of code tested was limited.

Unit testing has its limits, programmers only write tests to make sure their code does what it is supposed to do. By inserting X, one tests in order to produce Y. This is called Positive testing. An equally useful form is Negative testing. If one inserts Z, or anything other than X, what is produced? Programmers regularly perform Positive Unit tests, but rarely Negative tests.

Another way of testing applications is running automated test scripts on the actual application as a whole. This is called QA testing. It predates Unit testing and requires special tools. It also requires a different type of programmer. QA testing needs to include both Positive and Negative testing. In the latter case the QA person creates tests to see what happens if the user does something unexpected or that they should not be allowed to do. QA tests also make sure that the application meets design specifications. More importantly for EMR systems the QA tests check that data entered in one part of the system appears correctly in another. This is important to ensure that updated patient health data appears correctly in other areas of the EMR.

A robust system cannot be developed without strong quality assurance and good QA is as intensive as programing the system being tested. Mature software companies have requirements for the size of the QA team. Microsoft has a ratio of 1:1 in that there is one QA position for every programer in the development team. Other companies have different ratios, but the important thing is that these ratios are maintained. As the development team grows, the QA team should also grow.

None of the EMR companies I worked for had set requirements for the size of the QA team. The QA teams were small and with each release, they found themselves scrambling to adjust their test suite for all the changes the developers had made. This left gaps in the test coverage and releases often went out without the QA process completed. The quality of the product is directly related to the amount of QA that is performed prior to release. This is important in critical healthcare applications such as EMRs.

New Technologies

Some will argue that EMR systems should stick with established technologies and that the risk of using new technologies is too high. The difference between “New” and “Established” in the high tech industry has been shrinking for years and now is almost nonexistent. As one well regarded development manager told his team designing a new system: “Use things that are going to work great in two years.” Canadian EMR companies tend to use older technologies.
 
NoSQL Databases

About 12 years ago, the industry started to realize that SQL databases had their limitations and alternate database systems were re-introduced and new database systems developed. This was dubbed the NoSQL movement and today NoSQL databases are behind many of the websites you use every day. It is not unusual for a site to use more than one type of database.
 
NoSQL databases store data in a number of different formats, each suited to a different type of data. One category of NoSQL database is the document database. These databases do not have a fixed schema like an SQL database, but are dynamic with the schema being generated as documents are added to the database.
 
The SQL database model is well developed and understood, but EMR systems deal with a number of different types of data. Managing client lists, scheduling appointments and billing operations are things that SQL database are well suited for, but this is just a small component of an EMR system. The client chart is made up of completely different types of data. Most of this data comes in via EDT interfaces as HL7 files. EMR companies often have teams working on just the EDT code in order to shoehorn this data into a SQL database. Document databases are well suited to EMR chart data as most digital data is in HL7 format, which at its heart is a document format. However, I don’t know of a single EMR system that uses anything other than a SQL database.

Tablets

There is almost a daily growth in the number of tablets computers. The next generation of doctors will have gone through training with tablets in their lab coats and will be expecting to use them in clinical practice settings. While some EMR vendors do have “tablet” applications, I was unable to get much information about them and I am skeptical of how useful they really are. The tasks you would want to manage on a tablet are not the same tasks you would on a desktop. Even when completing the same task on a tablet, the user interface for a tablet needs to be completely different. Tablets come with built in cameras for still images, video and audio recording, which opens up many new ways of capturing data during an encounter. A good EMR client on a tablet should be designed and developed separately from the desktop or web app version. There are also security considerations that need to be considered with tablet applications. Tablets are easily lost or stolen. Can you remotely wipe all data from your tablet that has gone missing? There are security systems that provide this function as well as other security functions needed on tablets with access to sensitive data, but I am unaware of EMR vendors that have made use of them and I would not use one that was not secured by one of these systems.

The next article will focus on the evolution of the EMR market in Canada and a vision of the path forward for EMRs from a developer’s perspective.

Should I Access My EMR Using a Mobile Phone?

A 2012 Manhattan Research study on technology adoption by physicians (Taking the Pulse® U.S.) reported that 85% of U.S. physicians now own or use a smartphone professionally. Moreover, 62% of U.S. physicians own a tablet and half of the tablet-owning physicians have used their device at point of care. While the numbers may vary slightly between Canada and the U.S., I think it is safe to assume that adoption of smartphones by Canadian physicians is comparable to American colleagues. This creates opportunities and challenges in terms of how physicians use mobile devices to access patient information.

Smartphones have evolved rapidly in the last five years with Apple and Samsung battling for worldwide supremacy in this lucrative market. What this intense competition has done is increase the speed, readability, and functionality of phones to a point that they have become the ultimate “converged” device offering voice, email, messaging, Internet access, and a wide range of apps (many of which are customized for healthcare). The high resolution 4.8" screens of the Samsung Galaxy SIII or the 4" Apple iPhone 5 are sufficiently large and crisp that the barrier of screen size is no longer a limitation when viewing information. The ability to pinch and zoom in on certain information or increase the size of text makes it possible to view not only data, but images. So, why would physicians not want to access their EMR using their mobile phone? It is unlikely that any physician would want to use their mobile phone as their device of choice when seeing patients in a hospital or clinic; however, there are many times that the ability to view critical data is extremely useful and convenient when away from the clinic or a regular computer.

Consider the following if accessing your EMR via your mobile phone:

• How do you plan to use your mobile phone to access your EMR?
• Do you have a mobile app that allows you to view information in your patient’s records or, will you use your phone’s browser to login to your EMR as if you were accessing from a regular laptop or desktop computer? Is the data passed between your EMR and your mobile app encrypted? Similarly, does your EMR require secure browser access (https vs. http)?
• Will you only be viewing clinical data or interacting with it to transmit orders or medications?
• Is any sensitive clinical data stored locally on your device or is all data purged after you close your mobile phone session?
• These are important questions to consider as you will be held accountable should there be a data breach that is linked back to access via your phone. A December 2011 article in American Medical News titled, Smartphones blamed for increasing risk of health data breaches suggests a correlation between the rise in smartphone use and the increase in security data breaches. While many of these breaches have occurred in larger healthcare organizations, there are a number of ways that mobile phones can create a mechanism to gain access to patient data.

Could you be creating a security risk by accessing patient data via your mobile phone and what can you do to mitigate the risk?

• Do you use good security practices? These include:
  
  • Using a passcode to access the phone. Takes a bit longer, but prevents (or at least delays) inappropriate access.
  • Not storing all of your usernames and passwords on your phone in a folder called passwords.
  • Careful use of bookmarks and auto-login features. For example, not saving your username and password in your mobile app or browser. Entering a password takes longer, but is more secure.
  • Not storing sensitive clinical patient information on your phone. You may be tempted to run reports or save reports on your phone in unprotected folders. If your phone gets lost or stolen, these are the first places that a thief will look.
• If your phone gets lost or stolen, do you have the ability to remotely wipe all of the data on the device? You can also set up tracking applications that allow you to find your phone using mapping software.

With the prevalence of smartphones amongst physicians, the likelihood that you will access some sensitive clinical data is high. If you are going to do so, consider how you should protect your device and your patients’ information. The above guidelines are not comprehensive but can be used as a starting point to ensure you do not become the weak link in the process.

Privacy and Security in an EMR Based Practice

Anyone who has implemented and used an EMR is aware of the terms Privacy and Security. However, what do they mean and how does one apply the concepts to the protection of personal patient data in the EMR-based practice? Privacy experts will describe privacy principles as enablers in the development of the right technology processes and software. While this is true if understood and applied in advance, privacy can also be a barrier to adoption, particularly if software was never designed with today’s privacy requirements in mind.

In 2005/2006, I was a member of a team of primary care physicians and specialists working on a primary care strategy for Vancouver Coastal Health. One of the strategies was the development of a Privacy Toolkit for the medical practice. Nigel Brown, Managing Consultant of the Security, Identity and Privacy Practice, IBM Global Technology Services, led the development of the toolkit and described privacy in the following ways:

Historical Definition — Physical Privacy: “the right to be left alone”
Modern Context — Information Privacy: “the right to have knowledge and control over information about you”

Information Privacy — Identifiable Information about an individual, including the following:

• Factual information such as contact, health, financial, affiliations, etc.
• Biological information: biometrics, blood type, DNA
• Derived information: credit scores, etc.
• Opinions: performance evaluations, etc.
• Observations: shopping habits, etc.

Security is the ability to protect the confidentiality and integrity of information and computer resources using the acronym CIA:

• Confidentiality: Allowing access only by authorized individuals.
• Integrity: Ensuring that information is not altered or tampered with by unauthorized individuals.
• Availability: Ensuring that information is available when needed.

Confidentiality is the process of ensuring that information is accessible only to authorized individuals.

A failure in either security or confidentiality can compromise privacy. However, privacy can also be compromised through the use or misuse of information by authorized individuals.

What can you do within your office to protect privacy? The following are a number of suggestions that apply to both paper-based and EHR-based practices:

• Position computers in administrative areas so that staff conversations cannot be overheard from public areas.
• Place computers, printers, and other devices in non-public areas and rooms that can be locked.
• Limit the display of personal information in areas where patients wait or walk to examination rooms.
• Establish policies that encourage discretion when discussing patient information, particularly if there is a possibility of being overheard by other patients, for example in check-in areas.

The issues of Privacy and Security are complex and require a common sense approach to correctly apply the right principles to specific situations. To assist you further, the BC Medical Association provides a very useful resource on privacy issues.

How Safe is Your Patient Data? The Password Conundrum

When using computers in healthcare, there is not much that seems more mundane (and irritating) than having to change your password on a regular basis. Government organizations and hospitals excel at requiring users to change their password every 42 days. Not sure why this particular number of days was selected — perhaps there is evidence that this is the safest timeframe. However, when one has to access multiple systems (EMR, Hospital system, Provincial EHR, Diagnostic systems) each with their own password renewal cycle, it can become a full-time job managing passwords. Add to that the need to never use the same password twice, plus the requirement for passwords to be of differing lengths and contain specific characters, and you have a formula for password perdition. Click here to read a very amusing (and unfortunately accurate) summary of the challenges of password management.

A number of years ago, I had the opportunity to work in a regional health authority as a member of the IMIT team. I met and spent time with a number of security and identity management specialists and was astounded at the complexity of identity management and how many different options exist to identify and authenticate users of computer systems. As a general rule of thumb, the more stringent the control, the more complex to use. The ideal option is to have high security with maximum ease of use. Unfortunately identity management often gets in the way of easy access to clinical data, particularly when there are multiple individuals using the same computer terminal.

In a medical practice, it is not uncommon to find a list of passwords on a sticky note attached to a computer for easy access by staff, particularly if needed to access clinical applications on the physician's behalf. The medical office is designed for maximum efficiency using whatever workarounds necessary to focus on the job at hand — namely, caring for patients.

Implementing a robust identity management program is a challenging change management exercise and one that is likely to be resisted for all the reasons provided above.

So, are there viable alternative options to passwords that are just as secure and do not require the dreaded 42-day password renewal? One option is to use a proximity card. This is an electronic wireless card that automatically athenticates a user when you are within a certain distance of a computer terminal. To read an earlier blog post on proximity cards, click here. However, proximity cards are not a perfect solution. They are costly and also are difficult to use if there are multiple proximity cards used within a practice. For a new user to login to a computer, the existing user has to move out of the critical proximity of the terminal to “log out” and the new user then can move into that zone to login. Efficiency is degraded because of the time lags in logging in and out. Another option is to use a thin client (such as an Oracle Sun Ray terminal). If the EMR is run on a remote server, the software can be accessed using a process called virtualization on these terminals. This probably does not mean much to readers, but how it works is that each user has a unique card. Upon entering the exam room, the card is plugged into the terminal and the same software session is immediately displayed as when removing the card from the previous terminal. This is fast and does not require multiple passwords or other factors to login or out. Not all EMRs can operate using Sun Rays; however, it is certainly a viable option. If you have an opportunity to see a Sun Ray based practice in action, I highly recommend you do so.

What are your experiences with passwords? Do you suffer from password fatigue. Do you have any suggestions for readers of this blog to help them with their identity and password management strategies? Add your thoughts by clicking on the “Comments” link below.

What are the Common Causes of Security Breach?

(Click here for the Improving Care with Mobile Phones and Mobile Health Technology podcast)

From time to time, one reads about security breaches as a result of a computer being stolen containing patients’ personal health information or breaches as a result of a network being hacked (as occurred recently to Sony’s online gaming community). However, as more information is stored in “the Cloud”, how secure is that data and how worried should we be about breaches?

Michael Koploy recently posted the following on his blog, “Software Advice”. HHS Data Tells the True Story of HIPAA Violations in the Cloud. In the posting, Michael states:

“At Software Advice, we speak on the phone every day with physicians who are researching electronic health records (EHR) software. We commonly hear that they’re afraid to switch to a system that puts their health records “in the cloud.” Their fear is that patient records will be out there on the Interweb, just waiting to be hacked. We’ve written about this misconception plenty and even touched on the double-standard of using web banking while eschewing cloud-based EHRs. Just a hunch, but I bet more hackers want my credit card information than my HDL/LDL ratio.

Now, the US Department of Health and Human Services (HHS) is disclosing on its website all health record security breaches that affect more than 500 people. This provides a trove of data to back up our assertions that cloud-computing is safe. Of course, it’s all relative.”

Michael has published some interesting graphs and tables summarizing the top causes of security breaches. Although Canada is somewhat different in structure, I believe the breakdown would be quite similar.

Have you or someone you know experienced a security breach? Provide your thoughts and feedback by clicking on the “Comments” link below.

Protecting the Security of Patient Data

Security and Privacy are often treated as one and the same, however they are very different. Whereas privacy refers to policies, user identification, access controls and systems design, security refers to firewalls, password management, physical protection of the data etc.

Recently, the health records of 83,000 individuals were lost in Ontario as a result of the loss of a USB key. A micro-SD card smaller than one's thumbnail can store 4GB of information and as solid state hard drives become more popular, we are sure to see the storage capacity of these devices surge. Huge amounts of personal information can be stored on tiny media that are easy to lose or misplace.

Bottom line - make sure that you are extremely careful where and how you store personal patient information. Thinking this through beforehand can avoid dangerous and costly errors at a later date. This is a good lesson for anyone who works with digital patient information.

Health records of 83,000 lost in Ontario OSHAWA, Ont. – Ontario’s privacy commissioner has launched an investigation after a USB drive containing the personal health information of more than 83,000 people, who went to flu clinics in Durham Region just northeast of Toronto, went missing. The USB key contained the personal information of persons who attended a Durham Region Health Department flu vaccination clinic for either an H1N1 or seasonal flu shot between Oct. 23 and Dec. 15. Commission spokesman Bob Spence said the probe will try to determine what happened and what steps might be taken to prevent a similar incident from occurring. A health department nurse was taking a USB key containing the records to her car in Whitby, Ont., for use at a remote clinic site on Dec. 15 when the device was lost. A search failed to turn it up. “We believe it was lost on regional property. We have some video surveillance tape to indicate that was the case,” said Dr. Robert Kyle, chief medical officer of health for Durham Region. Read full article: Canadian Healthcare Technology

Add your thoughts or comments by clicking on the 'Comments' link below

The High Cost of Security/Privacy Breaches

The high cost of security and privacy breaches was made amply evident in a recent article from the California Healthcare Foundation regarding the loss of hard drive from a Veterens Affairs medical facility. A storage device (probably costing less than $200) has resulted in a potential $20 million response.

"The Department of Veterans Affairs has reserved more than $20 million to respond to a recent data breach that could affect nearly one million VA physicians and patients, according to Bob Howard, the department's CIO, Government Executive reports. The breach occurred in January when a hard drive was lost from a VA medical facility in Birmingham, Ala., and was not recovered. The hard drive included sensitive information on any U.S. physician who billed Medicaid or Medicare through 2004 and on more than 500,000 VA patients. "We have no evidence that [information is at risk]...but we don't take the chance," Howard said. A group of about 650,000 physicians and 254,000 veterans in May were notified by mail of the breach and provided with credit monitoring services through a General Services Administration blanket purchase.

The credit monitoring funds will be pulled from the VA's fiscal year 2007 cybersecurity budget, Government Executive reports. Howard said the VA's health information system, called VistA, has weaknesses because it was built when the VA did not worry as much about security. He added that department officials are looking to expedite the modernization process of VistA, which is scheduled to last until at least 2015. The modernization update aims to protect the electronic health records and make them available on the system worldwide via the Internet. The VA's joint project with the Department of Defense on an EHR system has improved the prospects of obtaining more resources from Congress for a VistA upgrade, Howard added. Investigators still are attempting to locate the hard drive and the FBI has offered a $25,000 reward for information leading to its location (Pulliam, Government Executive, 6/14)."

Protecting patient privacy should be a critical objective for all eHealth projects. In this case, it may have been pure negligence that resulted in the loss of the hard drive, but without effective education programs and an educated administrative and provider group, how will data be effectively protected in the future? How do we avoid these types of incidents from happening or reduce the risk of their ocurrence to the barest minimum?

To add your thoughts, click on the 'Comments' link

Are Security Requirements and Care Delivery Naturally at Odds with One Another?

An NHS trust has adjusted policy in order to allow physicians to more efficiently utilize electronic health record systems by 'sharing smartcards'. This is the reality of a natural tension that exists between the need to deliver care efficiently and the need to protect data and make individuals accountable for their access to systems.

"An NHS trust board has approved the sharing of smartcards, in breach of security policy under the £12.4bn NHS National Programme for IT (NPfIT), because slow log-in times would restrict the time of doctors treating emergency patients.

Paul Cundy, spokesman for the British Medical Association's GP IT subcommittee, said the actions of the trust "drive a coach and horses through the so-called privacy in the new systems". He said, "This is precisely what we have long predicted and shows that security systems, although highly specified on paper, need to be tested against live environments before they can be said to be secure." But Duncan Robinson, director of IT at the trust, said it had decided specifically in Accident and Emergency to slightly depart from what he called security "guidelines" to allow the sharing of smartcards on certain PCs. He said the trust was concerned that logging on could take up to 90 seconds. Without smartcard sharing, if doctors using a secure PC are called away when accessing a file, they may have to log off and on again when they return to it."

Link: NHS security dilemma as smartcards shared - 30/Jan/2007 - ComputerWeekly.com.

Is it possible to have the best of both worlds or do we need to accept a reduced level of security - e.g. shared IDs in a controlled environment, in order to make sure that the systems can operated in a clinical setting?

To add your thoughts or comments, click on the 'Comments' link below.