Useful IT. Bringing Health Record Transfer into the 21st Century.
I read the Life as a Healthcare CIO blog on occasion, mostly because as a former radiographer, health care records integration and other non-diagnostic IT use in healthcare is a passing interest of mine. Within the last hospital I worked at the systems didn’t communicate – not even close, as in there was no effort to make them do so. This intrigues me, as since I’ve entered IT I have watched technology uptake in healthcare slowly ramp up at a great curve behind the rest of the business world. Oh make no mistake, technology has been in overdrive on the equipment used, but things like systems interoperability and utilizing technology to make doctors, nurses, and tech’s lives easier is just slower in the medical world. A huge chunk of the resistance is grounded in a very common sense philosophy. “When people’s lives are on the line you do not rush willy-nilly to the newest gadget.” No one in healthcare says it that way – at least not to my knowledge – but that’s the essence of what they think. I can think of a few businesses that could use that same mentality applied occasionally with a slightly different twist: “When the company’s viability is on the line…” but that’s a different blog. Even with this very common-sense resistance, there has been a steady acceleration of uptake in technology use for things like patient records and prescriptions. It has been interesting to watch, as someone on the outside with plenty of experience with the way hospitals worked and their systems were all silos. Healthcare IT is to be commended for things like electronic prescription pads and instant transfer of (now nearly all electronic) X-Rays to those who need them to care for the patient. Applying the “this can help with little impact on critical care” or even “this can help with positive impact on critical care and little risk of negative impact” viewpoint as a counter to the above-noted resistance has produced some astounding results. A friend of mine from my radiographer days is manager of a Cardiac Cath Lab, and talking with him is just fun. “Dude, ninety percent of the pups coming out of Radiology schools can’t set an exposure!” is evidence that diagnostic tools are continuing to take advantage of technology – in this case auto-detecting XRay exposure limits. He has more glowing things to say about the non-diagnostic growth of technology within any given organization. But outside the organization? Well that’s a completely different story. The healthcare organization wants to keep your records safe and intact, and rarely even want to let you touch them. That’s just a case of the “intact” bit. Some people might want their records to not contain some portion – like their blood alcohol level when brought to the ER – and some people might inadvertently lose some portion of the record. While they’re more than happy to send them on a referral, and willing to give you a copy if you’re seeking a second opinion, these records all have one archaic quality. Paper. If I want to buy a movie, I can go to netflix, sign up, and stream it (at least many of them) to watch. If I want my medical records transferred to a specialist so I can get treatment before my left eye oozes out of its socket, they have to be copied, verified, and mailed. If they’re short or my eye is on the verge of falling out right this instant, then they might be faxed. But the bulk of records are mailed. Even overnight is another day lost in the treatment cycle. Recently – the last couple of years – there has been a movement to replicate the records delivery process electronically. As time goes on, more and more of your medical records are being stored digitally. It saves room, time, and makes it easier for a doctor to “request” your record should he need it in a hurry. It also makes it easier to track accidental or even intentional changes in records. While it didn’t happen as often as fear-mongers and ambulance chasers want you to believe, of course there are deletions and misplacements in the medical records of the 300 million US citizens. An electronic system never forgets, so while something as simple as a piece of paper falling out of a record could forever change it, in electronic form that can’t happen. Even an intentional deletion can be “deleted” as in not show up, but still there, stored with your other information so that changes can be checked should the need ever arise. The inevitable off-shoot of electronic records is the ability to communicate them between hospitals. If you’re in the ER in Tulsa, and your normal doctor is in Manhattan, getting your records quickly and accurately could save your life. So it made sense that as the percentage of new records that were electronic grew, someone would start to put together a way to communicate them. No doubt you’re familiar with the debate about national health information databases, a centralized location for records is a big screaming target from many people’s perspectives, while it is a potentially life-saving technological advancement to others (they’re both right, but I think the infosec crowd has the stronger argument). But a smart group of people put together a project to facilitate doing electronically exactly what is being done today physically. The process is that the patient (or another doctor) requests the records be sent, they are pulled out, copied, mailed or faxed, and then a follow-up or “record received” communication occurs to insure that the source doctor got your records where they belong. Electronically this equates to the same thing, but instead of “selected” you get “looked up”, and instead of “mailed or faxed” you get “sent electronically”. There’s a lot more to it, but that’s the gist of The Direct Project. There are several reasons I got sucked into reading about this project. From a former healthcare worker’s perspective, it’s very cool to see non-diagnostic technology making a positive difference in healthcare, from a patient perspective, I would like the transfer of records to be as streamlined as possible, from the InfoSec perspective (I did a couple of brief stints in InfoSec), I like that it is not a massive database, but rather a “faster transit” mechanism, and from an F5 perspective, the possibilities for our gear to help make this viable were in my mind while reading. While Dr. Halamka has a lot of interesting stuff on his blog, this is one I followed the links and read the information about. It’s a pretty cool initiative, and what may seem very limiting in their scope assumptions holds true to the Direct Project’s idea of replacing the transfer mechanism and not creating a centralized database. While they’re not specifying formats to use during said transfer, they do list some recommended reading on that topic. What they do have is a registry of people who can receive records, and a system for transferring data over the wire. They worry about DNS-style health-care provider lookups, transfer protocols, and encryption, which is certainly a large enough chunk for them to bite off, and then they show how they fit into the larger nation-wide healthcare electronic records efforts going on. I hope they get it right, and the system they’re helping to build results in near-instantaneous secure records transfers, but many inventions are a product of the time and society in which they live, and even if The Direct Project fails, something like it will eventually succeed. If you’re in Healthcare IT, this is certainly a way to add value to the organization, and worth checking out. Meanwhile, I’m going to continue to delve into their work and the work of other organizations they’ve linked to and see if there isn’t a way F5 can help. After all, we can compress, dedupe, and encrypt communications on-the-wire, and the entire system is about on-the-wire communications, so it seems like a perfectly logical route to explore. Though the patient care guy in me will be reading up as much as the IT guy, because healthcare was a very rewarding field that seriously needed a bit more non-diagnostic technology when I was doing it.
UAE IT Decision-Makers Highlight Growing Scale and Impact of DDoS Attacks
Ahead of tomorrow's IDC CIO summit in Dubai, F5 Networks has released new survey findings highlighting UAE IT decision-makers' views on DDoS attacks. Out of 102 respondents from companies with at least 500 employees, 55%said they had endured a DDoS attack. 13% put the estimated cost of recovery as high as US $ 30 million, 31% put the figure at US$ 20-30 million, and 34% US$10 to 20 million. When asked what the “most disastrous” impact of a DDoS attack would be, 47% of respondents cited the impact on customers. 19% said it would be reputation damage and 14% believed it would be revenue loss. The survey also highlighted the need for greater industry-wide awareness. Only 6% said they could “very accurately” describe the difference between a Layer 3 (network protocol) and Layer 7 (application layer) attacks. 57% said they could do so “somewhat accurately”. F5 Networks is a Gold Sponsor and will take part in a panel discussion focusing on IT security priorities at the IDC CIO Summit 2015, which is held from 25-26 February at Atlantis The Palm, Dubai. The event is held under the patronage of H.E. Sheikh Nahayan Mabarak Al Nahayan Minister of Culture, Youth & Community Development.
Damned if you do, damned if you don't
There has been much fervor around the outages of cloud computing providers of late, which seems to be leading to an increased and perhaps unwarranted emphasis on SLAs the likes of which we haven't seen since...well, the last time the IT saw outsourced anything reach the hype-level of cloud computing. Consider this snippet of goodness for a moment, and pay careful attention to the last paragraph. From Five Key Challenges of Enterprise Cloud Computing I won’t beat the dead “Gmail down, EC2 down, etc down” horse here. But the truth of the matter is enterprises today cannot reasonably rely on the cloud infrastructures/platforms to run their business. There’s almost no SLAs provided by the cloud providers today. Even Jeff Barr from Amazon said that AWS only provides SLA for their S3 service. [...] Can you imagine enterprises signing up cloud computing contracts without SLAs clearly defined? It’s like going to host their business critical infrastructure in a data center that doesn’t have clearly defined SLA. We all know that SLAs really doesn’t buy you much. In most cases, enterprises get refunded for the amount of time that the network was down. No SLA will cover business loss. However, as one of the CSOs I met said, it’s about risk transfer. As long as there’s a defined SLA on paper, when the network/site goes down, they can go after somebody. If there’s no SLA, it will be the CIO/CSO’s head that’s on the chopping block. Let's look at this rationally for a moment. SLAs really don't buy you much. True. True of cloud computing providers, true of the enterprise. No SLA covers business loss. True. True of cloud computing providers, true of the enterprise. What I find amusing about this article is that the author asks if we can imagine "signing up cloud computing contracts without SLAs clearly defined?" Well, why not? Businesses do it every day when IT deploys the latest "Business App v4.5.3.2a". Microsoft Office 2007 relies heavily on on-line components, but we don't demand an SLA from Microsoft for it. Likewise, the anti-phishing capabilities of IE7 don't necessarily come with an SLA and businesses don't shy away from making it their corporate standard anyway. In fact, I'd argue that most cloudware today comes with an anti-SLA: use at your own risk, we don't guarantee anything. The CIO/CSO's head is on the chopping block if he does have an SLA, because there's no guarantee that IT can meet it. Oh, usually they do, because the SLA is broadly defined for all of IT in terms of "we'll have 5 9's of availability for the network" and "applications will have less than an X second response time" and so on. But it isn't as if IT and the business sit down and negotiate SLAs for every single application they deploy into the enterprise data center. If they do, then they're the exception, not the rule. And the applications this is true of are so time-sensitive and mission critical that it's unlikely the responsibility for them will ever be outsourced. Financial services and brokerages are a good example of this. Outsourced? Unlikely. The IT folks responsible for the applications and networks in those industries are probably laughing uproariously at the idea. The argument that an SLA is simply to place a target on someone's head regarding responsibility for uptime and performance of applications is largely true. But that would seem to indicate that if you're a CIO/CSO and can wrangle any SLA out of a cloud computing provider that you should immediately use them for everything, because you can pass the mantle of responsibility for failing to meet SLAs to them instead of shouldering it yourself. This isn't a cloud computing problem, this is a problem of responsibility and managing expectations. It's a problem with expecting that a million moving parts, hundreds of connections, routers, switches, intermediaries, servers, operating systems, libraries, and applications will somehow always manage to be available. Unpossible, I say, and unrealistic regardless of whether we're talking cloud computing or enterprise infrastructure. Basically, the CIO/CSO is damned if he has an SLA because chances are IT is going to fail to meet them at some point, and he's damned if he doesn't have an SLA because that means he's solely responsible for the reliability and performance of all of IT. And people wonder why C-level execs command the compensation levels they do. It's to make sure they can afford the steady stream of antacids they need just to get through the day.CIOs Should Know that IT is Infrastructure as a Service.
InformationWeek has been out and about talking up their most recent CIO survey and keeps calling attention to the fact that one in three CIOs see creating a new business or business model as a driver in 2011. This is not a new phenomenon, but one in three is more CIOs than I would have intuitively thought, so I started to think about it. There has always been a drive, at least in every company I’ve worked for, that if you want to grow your ivory tower you need to generate revenue. Because IT is a support function – it was infrastructure as a service long before cloud computing came along, if you look at it in the right light – this mentality didn’t generally drive CIOs. Serving the business in the best manner possible was huge on CIO’s list of things to do, but generating revenue just didn’t drive them. Which leads to the question “why now?” The answer to that question is likely manifold. First, there are those businesses where IT is the business. An online trading house, for example, doesn’t exist without IT. The same is true of Amazon, eBay, and a host of other companies. For those companies, being in IT is 100% being on the business side of the house. Your innovations and modifications are to the lifeblood of the company. Then there’s the advent of cloud, which has people buzzing (right or wrong) about business value and IT as a Service. That has to be playing in these CIO’s minds. And finally, it seems that every year the mantra “do more with less” has been echoing about the halls of IT, and CIOs might just be reaching out for ways to do more and add staff. But in the end, no matter whether you’re in insurance, utilities, telecom, manufacturing, whatever, IT does add value to the business, and becoming the business is not required to show that fact. Everywhere I have had the opportunity to work, either as a consultant or full-time employee, the company could not function at the level it does without IT. We all know that, the business knows that, the thing is that IT is horrible about communicating that fact. And always has been. So if you’re in a business whose product is not software, focus on enabling the business, not in creating new business. Lori and I were just chatting this survey up, and she brought up one of the cloud-o-nomics points that makes normal IT folks shudder. No, you’re not generally going to lease out extra capacity to random people. Unless you are in the cloud business, selling cloud services is a distraction from your purpose – to support the business. You’ve got virtualization to worry about, many of you are starting to look at virtual desktop infrastructure (VDI), cloud is on your radar, security concerns continue to leave a dark cloud over IT (yeah I used that allegory), and that’s before you even touch the specific needs of your market and organization. Do not invent work. I’m not saying ignore a good idea – much of the great software out there was created by people who had an internal need and once they solved it they shared it with the world – but don’t say “create new lines of business” as a directive unless your organization is moving that direction. The point is that IT grew to the behemoth that it is because the business needed support. That investment is reaping rewards, but unless it was specifically made with the aim of getting into new businesses or business models, there is a risk associated with bleeding off some of those resources on speculative productization efforts. Make sure you’re doing what you’re there for, and make certain the business knows it. IT runs large swaths of the business in a fashion so highly automated that without it, the business would implode. I’m not over-exaggerating here, stop and think what order volume would be with no PCs. Now talk with the business about that. Let them know how much growth is directly the result of IT. I remember an insurance company I worked at doing disaster planning – if HQ was wiped out, likely there would be people needing the services of their insurer – and the plan was to shift to doing everything by hand. Eventually the conclusion was reached that it was not feasible to do that, and a secondary, geographically remote, datacenter was built. That was a golden opportunity to point out that the business wouldn’t be what it was without IT, but from what I could tell, no one was sending that message other than myself, and I was an IT architect, so I was sending that message mostly to IT in the hopes that managers would pick up on it. So if you’re not an IT business, stay focused on supporting those on the business side. Make every decision based upon “does this help the business”, and make it clear that’s why you’re making it. It’s not as cool as creating new products, but if you want to create new products in IT, then go to work for a business in the IT space. They’re a lot of fun, in my experience, and then your energy will be directed in the right way. But for those in non-IT businesses, show how your initiatives will improve things for the business, and if you can’t, then consider very carefully whether that item should be an IT initiative. Again, the problem is nothing new, since the first network cable was run, something as simple as “we have to upgrade this network segment or bad things will happen in the future” has been a hard sell. Those who will be most successful at IT management will not be those looking to do businesses job for them, but those who can communicate why IT initiatives will help the business grow. Related Articles and Blogs IT Must Create Products, Not Just Cut Costs CIO Conversation – John Matthews On Intelligent File Management (Security) Thunder from Down Under The Real Meaning of Cloud Security Revealed Is Your Glass of Cloud Half-Empty or Half-Full? Is Vendor Lock-In Really a Bad Thing? Damned if you do, damned if you don't Control, choice, and cost: The Conflict in the Cloud Knowing is Half the Battle No soup for you! Multi-Tenant Security Is More About the Neighbors Than the Model Application Delivery Virtualization - data center Is Your Cloud Opaque or Transparent?It’s about customers and CIOs, not vendors and campaigns.
Lately there has been a whole lot of breast-beating and article writing attributing this trend to that vendor and this other trend to this other vendor. You may have noticed that we at F5 benefit from some of this noise. It is pretty well accepted that we are the ADC leader and most pundits include us as one of the few “cloud enabling” vendors. But all of this misses the point. The point is that you, and your contemporaries around the world decide what The Next Big Thing will be, not some marketing person writing a campaign plan. The needs of the average IT department determine what is going to be successful and what is not. When a vendor enables something that you couldn’t do in the past, then marketing certainly makes you aware that it’s out there, but no vendor is responsible for any trend in high-tech. Smart technology companies acknowledge this in a couple of ways. First by offering products that solve your problems – be they problems we’ve known about since the 80s or something new that other technology changes have brought about. Second by telling you how their products/solutions solve your problems. Note that SaaS as presented in the 90s never really materialized, but Salesforce certainly did. Salesforce offered a product that solved a problem many – nearly all - of us had at the time, and used the SaaS model to make paying for it less painful than the big-systems alternatives. That worked well for Salesforce, but other names, some of them big names, had mediocre success or downright failure at doing the same thing. Every once in a while I think it is critical that someone who writes in the space regularly reminds you of something the hype-cycle typically fails at: That it is about you, not a vendor or a vision or an architecture. That you need to make the architectural decisions that best suit your organization’s needs and not worry about what the flavor of the week is. There are a growing number of success stories with cloud in international businesses that want to have uniform global access to data, that doesn’t guarantee that your organization is best served by this model, it only means that early results show this model has promise for some organizations. Of course we’ll sell you gear if you go this route. We’ll also sell you gear if you don’t, call up your local sales rep and they’ll tell you all about it. The point is that there is no race. Do what makes sense to you at the rate it makes sense to you in the interests of best serving your employer. The days of the “cool new doodad” in IT are gone, but increasingly the business people are muttering about the “cool new doodad” – tablets and cloud both spring to mind – make it your job to help them understand where these things can help, and where they’re a threat or unnecessary overhead. The head of IT is increasingly under pressure to speak in plain language about strengths and weaknesses. And if you’re not conversant with talking in your native tongue about high-tech, make it a point to get that way. Business users want to understand why something is a good or bad idea, they don’t generally want to understand the gory details. You may need them to back up your stance, but certainly sitting in a meeting with a group of business owners is not the time to start using throughput numbers and latencies. Simply a “we improved performance by X percent” is more in line with the needs of the business – unless you want the accounting and legal teams to start diving down into the details whenever you meet with them. Didn’t think so. So go out there and solve your company’s IT problems. Have some fun doing it. Pay attention to the latest fad so you know when it is ripe with potential… But don’t obsess about it, because until you and your peers decide it is time to act, the latest fad is just so much ink and venture capital. And like I’ve said before, smart companies like F5 will be there to serve you when the time is right.
