An Overview of Up-and-Coming Hybrid Tablet/Laptop Technology

While working at Algonquin Studios, I’ve been well educated on the many options of operating systems and configurations such as laptops, tablets, smartphones, etc. My last post was my (mostly) unbiased review of both Android and iOS. This time around, I’d like to look at the up-and-coming “hybrid” tablets/laptops that are becoming more and more popular.

A hybrid tablet is essentially a laptop that has the availability to run both Windows and Android, or some other variation thereof, and can be detached from the keyboard to become a standalone tablet. This flexibility makes these tablets both extremely portable and extremely resourceful.

I’ve picked three variations to talk about, because I feel they cover a majority of the different options currently available and, with the ever-expanding choices, it would be impossible to discuss all the available models in any detail.

Hewlett Packard recently came out with the SlateBook x2 laptop hybrid. This hybrid only runs Android, as its marketing tagline indicates: “100% tablet, 100% notebook, 100% Android.” What puts this in the ‘hybrid’ genre is the removable keyboard, really making it, simply, a large tablet. I think the Slatebook x2 is a unique hardware option but, with the lack of Windows, people will probably just use it for surfing the web and playing with a few Android apps. The portability is still there but, with its larger screen-size I have a feeling most users will just use it as a notebook/laptop.

Samsung just revealed the Ativ Book Q, a true hybrid tablet/laptop. It runs both Android 4.2.2 (the latest version of Android) and Windows 8. The really nice feature about this particular hybrid, though, is that you won’t have to boot into either Windows or Android.  The Ativ Book Q will give you an option to simply switch from one OS to another with the touch of a button, making the transition virtually seamless. Another great feature is that Samsung gives the option to share and transfer files and folders between operating systems.With these features in mind, I expect the Q to be an extremely powerful little notebook for work and home use.

Another option is the Asus Transformer Book Trio. This is a unique hybrid in that it will ONLY run Android when not docked. This makes it a bit less dynamic than the Samsung, however, most people are already used to running Android as their mobile platform.

With all of the competition within the mobile smartphone field, I have a feeling the hybrid field will be picking up steam next. It should be fun to watch what the next couple of months brings to this new area of technology. Stay tuned!

Is Encryption Required by HIPAA? Yes.

Ok… technically that’s not 100% true.  The HIPAA Security Rule doesn’t explicitly require encryption of data at rest, or even during transmission. However, this doesn’t mean what people think it means and that misunderstanding is getting a lot of folks into trouble (literally).

The HIPAA Security Rule is a 3-tier framework broken down into Safeguards, Standards and Implementation Specifications. Within the Technical Safeguards, both the Access Control Standard (i.e. data at rest) and Transmission Security Standard (i.e. data in motion) have an Implementation Specification for Encryption. Neither of them are “Required,” but are both listed as “Addressable.” So we’re done, right? Not so fast…. From the HHS FAQ:

“In meeting standards that contain addressable implementation specifications, a covered entity will do one of the following for each addressable specification:

  1. Implement the addressable implementation specifications;
  2. Implement one or more alternative security measures to accomplish the same purpose;
  3. Not implement either an addressable implementation specification or an alternative

So… it’s not required.  But HHS goes on:

“The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative.”

The key phrase here is “reasonable and appropriate.” As in, encryption IS required if it’s reasonable and appropriate to encrypt. This is really important and we’ll come back to it later. HHS continues:

“This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing.  The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.”

Basically what they’re saying is that you don’t “have to” encrypt, but if you choose not to you’d better be prepared to demonstrate, in writing, why you believe that. Then, in the event of an audit, The Office for Civil Rights (OCR) will review your documentation and determine whether or not they agree with you.

Mobile Devices

If you check out the HHS Wall of Shame where breaches involving 500 or more patients are posted, you’ll notice a very large number of lost or stolen laptops that were not encrypted.  In a comment about the settlement with Hospice of North Idaho that involved a stolen laptop, OCR Director Leon Rodriguez said: “Encryption is an easy method for making lost information unusable, unreadable and undecipherable.”  And it really can be easy. You can purchase inexpensive encrypted hard drives for all new laptops and install 3rd party tools on old ones (see Five Best File Encryption Tools from Gizmodo).  If you have mobile devices that may contain PHI and are not encrypted, stop reading and go encrypt them right now. Seriously.

The Data Center

Many people have bought into the idea of encrypting mobile devices, but not their servers. To an extent this makes sense given that most breaches have resulted from lost or stolen devices and not so much from hacking.  However, Leon Rodriguez noted in a presentation at HIMSS13 that he anticipates hacking to be a threat that will likely grow as time goes on, and the best protection in that scenario is data encryption. This is a more complicated issue for sure, but there are lots of tools and techniques that make this very doable. I plan to elaborate on those options in an upcoming post.

Data in Motion

I’m not going to get into much detail on this one. Use SSL, VPN, or some other method of encryption when transmitting your data over public lines. Period. If you have a scenario where it is “reasonable and appropriate” to send someone’s health information in plain text over the public internet, I’d love to hear about it.


You’re required to encrypt PHI in motion and at rest whenever it is “reasonable and appropriate” to do so. I’ll bet that if you do a proper risk analysis, you’ll find very few scenarios where it’s not. Even if you think you’ve found one, and then you’re beached, you have to convince Leon Rodriguez and the OCR, who think encryption is both necessary and easy, that you’re correct. Is that an argument you want to be making in the face of hefty fines?  Not me… and that’s why I have convinced myself that encryption is required by HIPAA.

Microsoft SQL Server 2012 – AlwaysOn

Microsoft SQL Server 2012 – Always On

As technology advances, so does the need (and want) for instantaneous information. The goal is always “How can we get information as quickly as possible?” The same is the standard for disaster recovery. How quickly can we recover in the event of failure? The answer in many cases is seconds. One of the newest options for High Availability is Microsoft SQL Server’s AlwaysOn technology. The name is self-explanatory–AlwaysOn is designed to have data and information always available, even in the event of disaster. Disaster Recovery time is minimized with SQL’s AlwaysOn ability to sync multiple databases across multiple database servers.

I had the recent experience of using SQL’s AlwaysOn technology to set up a redundant application environment. The purpose of this blog post is to summarize my experience with the technology. By no means is this a start-to-finish coverage of the technology.

Overall, the perception of AlwaysOn amongst users has been very positive (simply Google “SQL Always On” and you’ll see other posts stating its benefits). I, too, was impressed with its simple setup and configuration and how well it handles failover scenarios (verified during our pre-launch testing). With all technology, there were some downsides, but I felt that the positives of AlwaysOn far out-weigh its drawbacks.

Availability Groups

  • Replication in AlwaysOn is no longer thought of as individual databases to individual servers. Complex systems can be replicated as a group, not as individual databases, minimizing setup and configuration time for replication. The one downside is that the replicas are limited to four sets, so one group can only be replicated to 4 different locations.
  • Synchronous and Asynchronous Setup
    • Synchronous Replication – Transactions are not completed until committed to all databases in the Synchronous Availability Group
      • The first thought I had when hearing this process was that it may be performance impacting since SQL will need to commit the transaction to multiple databases on multiple servers.
      • We tested this process to ensure synchronous replication to multiple databases would not cause performances degradation.
      • We used SQL’s query performance statistics to ensure that the performance of data read/writes were as efficient with the new environment as they were in the old environment.
      • As a side note, there were other factors that affected query performance times (for the better – new environment, new OS), so our test wasn’t a true comparison of SQL performance with and without AlwaysOn replication. For the purpose of our test, we needed to ensure that the AlwaysOn replication was not a detriment to application performance.
    • Asynchronous – Transactions are queued and committed to this Availability Group at a later time. Transaction completion is not dependent on committing to this database group. This is similar to Database Log Shipping in older versions of SQL Server.
      • In previous versions of SQL Server, Log Shipping would require the database to be inaccessible during restoration of the transaction logs. With AlwaysOn, the database is always online and accessible.
      • This allowed us to use the Asynchronous process for other purposes, in this case Read-Only reporting. We took long-running reporting queries and calculations and removed that processing need from the transactional database and server altogether, providing an indirect performance benefit from AlwaysOn.

Automatic Synching

  • One of the most frustrating aspects of SQL Log Shipping is when the process gets out of sync and the transactions are not being properly applied to the replicated database. This would generally result in manually copying and restoring a database to the replication server and restarting the transfer process
  • This headache is alleviated with the Asynchronous Replication of AlwaysOn. AlwaysOn polices itself for the data replication, automatically re-synching the database if a network connectivity loss or other event disrupts the replication process


  • Unfortunately, AlwaysOn is only available with the Enterprise Edition of the SQL 2012 License, so you’ll need justification to spend the extra money for the Enterprise license. This may not be the best DR solution for smaller applications.
  • However, licensing is setup to use Active vs. Passive server. This means that you don’t need an additional license for your replication servers if it is only being used in a failover scenario, which allows you to limit the number of licenses you will need.

Again, this was just an overview of my experience with Microsoft SQL Server’s Always On functionality. In the event that you are in the process of setting up a new environment using Microsoft SQL Server, I highly suggest considering AlwaysOn to handle the High Availability/Disaster Recovery requirements. See Microsoft’s overview of AlwaysOn here:

Turning Around Tough Problems for Your Customers – Part 5

OK! We’re in the home stretch of my customer service series.

We’ve followed LEAP; we’ve kept our customer informed and earned their approval for paths forward; and we’ve talked about times when “the customer is always right” benefits everyone and when “proposing a better solution” is worth the extra effort.

So, what else have I learned along the way that might help you?

Well, I’ve found that some customers will behave differently, depending on who they talk to, as they work themselves up the “authority chain.” For example, in the heat of the moment, a customer may yell at your customer service representative even though they work well together daily. But, when you call that same customer to follow up, they act as sweet as pie. What’s really behind this?

The customer may have been under pressure and, in the moment, let loose on your staff member. If so, they’ll probably apologize quickly. But there’s the chance you’re dealing with someone who’s trying to manipulate you and your team. While you’ll never be able to change your customer’s personality, you can coach your customer service team not to give historically difficult customers the privilege of spoiling their day by helping them remember to remain polite, spell out possible solutions, and escalate where necessary. If a customer personally insults a staff member or will not stop yelling, I ask my team to politely state that the conversation will continue at another time and then to hang up the phone. This trains customers that difficult behavior just slows them down.  You may want to consider teaming several people together to play different roles (e.g. good cop, bad cop; sales vs. production). I’ve found approach very effective when dealing with customers who express difficult attitudes. You may also need to offer regularly scheduled meetings for your customer service staff to vent in-house, up stream, in a safe environment.

Sometimes things get really tough and you find yourself continuously dealing with a difficult or manipulative customer. Do a little research here… Does this customer cost you too much to serve them well? While my customer service team doesn’t have the authority to fire a customer, they are empowered to make such a recommendation to the executive management team. If your company continues to work with someone who repeatedly hurls personal insults at your team, and you permit the behavior, you may lose your team’s commitment. Only you can weigh the outcomes, but you owe your employees the humility of listening to them.

Finally, rely on your Terms and Conditions as a guidepost for everyone involved. Your firm’s Terms and Conditions (T&C) are your collected wisdom that protects you and your customer. If a customer can’t see the value in both sides abiding by your T&C, they’re probably not a good fit for your company. But remember, your T&C are a living document; don’t be afraid to change them when appropriate.

What are your war stories from the trenches? It would have taken me a much longer time to develop much of this insight without the help of my two mentors; feel free to share your ideas with us to help continue to conversation!

Turning Around Tough Problems for Your Customers – Part 4

So, we’ve followed LEAP – listening without interrupting, empathizing with the customer given the facts he or she expressed, asking clarifying questions and check-downs, and  producing an immediate remedy and long-term process changes to prevent the problem moving forward. Along the way, we’ve kept our customer informed and earned their approval for paths forward. But why go to all this effort when we could just follow the wisdom of “The customer is always right?”

Let’s say that’s true – your customer knows what’s best for them, not you. Your customer has already been inconvenienced with the problem at hand. Why waste their time when you could do what they ask? They’ll come back to you in the future, confident that if things don’t go well then you’ll take care of them. Also, you’ll quickly move on to serving more customers. And, the customer will spread the word about how you took care of them.

In Buffalo, we have a fine grocery store chain that appears to follow this axiom. In practice almost everyone I know who shops there has a story about someone who brought an unsatisfactory item to the store’s customer service desk. Regardless of the problem, even if it was simply that you didn’t like the product, they’d replace the item with something you liked on the spot.

But not every problem is that simple. Does the customer really know the best way to solve the problem? You’re the expert, solving similar problems more often and in greater variety. What if the customer is missing some of the facts? What if you’ve seen their suggested remedy fail for other customers before? What if they’re asking for something that violates your Terms and Conditions? What if it’s not fair as you see it?

It’s hard to frame this in a grocery store scenario–not every business is a grocery store. What if you’re an auto mechanic and your customer suggests a solution that you know would endanger them later? You wouldn’t do it. You honor your customer when you propose a better solution and humbly make the final decision theirs. If they’re not willing to go along, honestly spell out the limits of what you can do. In grey areas, I often find myself negotiating, based on quickly grasping the principles that each side values. Humor goes a long way deflating the stress in the situation.

I think that “the customer is always right” seems to work in simple situations, where facts can quickly be assessed, the cost to get the facts is much higher than the remedy, or the customer isn’t going to hurt themselves. I believe that “propose a better idea” seems to work best when facts are hard to assess well, the cost of fact finding is much lower than the remedy, or the customer could hurt themselves unintentionally. The long term relationship is almost always worth more than the immediate issue, so choose the method that favors your relationship. And remember to go back and improve your process after.

Is there anything I’ve learned from growing my “tough conversations” method over the years? Of course! We’ll talk about that in the next post.

Turning Around Tough Problems for Your Customers – Part 3

After two posts in this series, we’ve started with a disgruntled customer escalating a disagreement to senior or executive-level management and we’ve followed a process called LEAP–listening without interrupting, empathizing with the customer given the facts he or she expressed, and asking clarifying questions and check-downs. For produce, we’ve established facts supported by evidence from both sides, proposed an immediate remedy, and proposed process changes to prevent the problem going forward. At this point, we’ve probably sent our customer a lengthy email, detailing all of the above…But do they agree with us? Do they believe our proposal was the best way to solve the problem and will do the best job of preventing similar ones in the future?

When you’ve reached your conclusions about the situation and you know what you’re fairly willing to offer, share your thoughts with your customer using the outline touched on above:

  • Facts
  • Conclusions
  • Immediate Resolution
  • Prevention
  • Approval

That last one is important. If the customer doesn’t believe in the process you’ve suggested, you’re wasting their time and yours. You’ve just accepted responsibility for the whole problem. As an example, I recently received a complaint about screen printing wearing down quickly on garments sold by our customer to a fire department. We took the few garments returned over to our screen printer and asked about the problem. Our screen printer applied an extra curing step to the logos and sent them back to the customer, who promptly complained again. Was this customer just being unreasonable? No, because we failed to discuss our experiment with the customer and get their approval to conduct it. They didn’t participate in the process, so when the garments came back distressed again, we had an even bigger problem.

The next time around we made sure to involve the customer and we discovered that the fire department had an industrial-strength laundry machine built to clean smoke and chemicals out of garments. No normal screen printing could have withstood this mighty behemoth! Now we had our facts and could recommend changes that would truly solve everyone’s problems: switch to embroidery or tackle twill (laser cut decorations that get sewn on). As in this example, it may take several loops through the process to get to the bottom of an issue.

Statistics can be your friend for gaining perspective on a problem. If you consistently make a mistake, it looks bad. If you consistently make a mistake out of thousands of correct operations, it looks different. I once had an airline complain that a logo location varied from shirt to shirt. Even after explaining that the industrial process did not guarantee exact alignment, the customer was unimpressed. But when we sampled hundreds of shirts from a 15,000 shirt order, we found that the variation was within about 3.3 standard deviations (or that around 1 in 1,000 were outliers). These hard numbers changed their perspective. Statistics can help you focus on true bottlenecks.

Another key step in ensuring customer buy-in? As I mentioned earlier, if it wasn’t written, it didn’t happen, so confirm conversations with writing and carbon-copy everyone involved in an issue. Why would you (or your customer) leave someone out? Doing so raises political questions, which almost never contribute to solving the problem or returning to a good relationship. In fact, I find that including everyone often suppresses unreasonable behavior. You may need to take a frank aside with an authority figure to handle a sensitive issue. That’s OK, as long as both parties return to the whole group with information appropriate to the group members’ roles.

For the truly deft, you can position your statements too. I find this handy when used sparingly in politically tough, long-term situations. Are there new people to the conversation? Are there casual readers who need to be kept informed? Are there some people on either side working against the shared relationship? Positioning a statement can help. I might say things like:

  • At the risk of being bold
  • As you know
  • Clearly you would agree that
  • As promised
  • From prior conversations
  • As we agreed

This helps frame the conversation for secondary readers, and forces the primary recipient to either declare their disagreement aloud or passively accept my assertions. This is hardball, and I’d generally avoid manipulating people, but the tool is there if it serves the better interests of your firm and your customer.

Having read all of this, you might ask why I’d go to these measures when I could just follow “The customer is always right” idea and move on quickly? Didn’t I just waste my time? Stay tuned…