Discussion on:

10 ways to sell corporate on Linux

12)Tell them that that truck parked out there has a shark in it.
13)Quote the Bible.

Critical applications we utilize (and that thousands of other healthcare enterprises utilize) are Windows-based, do not have a native Linux version, and the Wine kludge is NOT an option.

It really doesn't matter how many thousands of applications are available for Linux, the fact of the matter is, it's still not enough.

You use databases. The data are stored on Linux [or Unix] servers, it's only the front-end interface that's on Windows client computers.

Why is that even necessary? Doctors and nurses cannot always be assumed to know a couple dozen SQL commands despite their command of Latin & chemical nomenclature? Of course, some of them will say "it's too difficult, I can't become a computer programmer on top of my real job," and the complaint will seem legitimate. But, it isn't as hard as that to learn Create/Read/Update/Delete syntax [CRUD] as those arguments suggest; it isn't tantamount to "becoming a programmer," I promise. It is, however, a valuable skill, with a longer shelf-life than in-depth knowledge of Windows v. Most Recent, or v. One Previous. The nurses and doctors will deal much more easily than they have with the slow but relentless increase in paperwork for insurance & financial purposes, and what's really foolish is to claim that "critical apps" should be running on an operating system with such unreliable uptime.

Looks like CPA's, insurance agents & used car salesmen [in clown suits, with sharks in the van, thumping their Bibles] have set the "standards" in that industry. That is not Shineola.

I've worked for 10 years as an IT consultant in Healthcare for 2 of the 3 largest healthcare companies in the world. I know for a fact that not one clinician (of hundreds) I've ever worked with would have even the slightest interest in learning any new computer 'programming'. 90% refuse to even use the Windows GUI's until they are forced into it - they try to dictate and get their secretaries to drive the computers.

Seriously, your suggestion has no chance whatsoever.

Since I've not worked in the health care industry I can only make my comments to you reflect similar "mulishness" faced in other professions. In the early days of Windows, I worked with a bevy of different lawyers and let me tell you that in those early days they absolutely REFUSED to even touch a PC. However, 25 years later they'll be the first to admit they couldn't do without.

I imagine the health care professionals are in the same denial and are much slower to change. I recently had the opportunity to observe a very large health network's operation and I can tell you that any of their professionals that did NOT use the technology were not there for very long. I believe your statistics of 90% are more like 60% and lessening with each year.

Just as paper and ink of old were the domain of the scholarly or rich, technology is the tool of the masses today and will not be denied.

I have worked in hospitals (in HR) with clinicians. I agree most MD's have ZERO interest in learning tech stuff lying outside their medical field. Doctors are pretty conservative overall, with good reason - unproven treatments can kill people. HOWEVER, if a computer system is simple enough to use it will thrive. My argument with MS is their product sucks, not just the OS, I could care less as long as it works, but word/excel, etc are a real pain to use, with quirky, hard (for me) to memorize rules, and no simple drop down menus to drive functionality, but instead seriously aggravating crap like macros, formulas, loss of formatting when merging info, etc., etc., etc., etc.. Linux and other open source products should be truly scaring the crap outta MS with good reason, they have the potential to drive MS out of business, and I truly hope that happens. ASAP.

I am not a programmer. I hate SQL, I HATE macros, I hate Excel requiring me to do complicated, error prone "formulas" to do simple things, when drop-down menus should serve that function. If I have a choice between an MD knowing SQL or getting my meds or diagnosis right, guess which one I choose? Your argumant is problematic and IMO reflects the techie bias, that "we should all do it, it's so simple" . I have neither the time nor interest to be a programmer, and there are millions like me, with many more like me than like programmers.

In my preferred career, science, refusing to learn computer programming was truly not an option, so here I am.

I don't advocate medical professionals all becoming fluent in SQL, just conversant in the basics of it. My reasoning is probably more familiar in automotive maintenance: a small increase in knowledge can drastically decrease the probability of getting ripped off, at the service station or at the dealership. In other words, if you don't need the GUI offered by MS Access to perform routine Insert, Update, Delete and Select queries, then your options expand to MySQL and PostgreSQL, without need to hire an expensive "web developer" for every incremental change in your tables & relationships.

You'd still hire a database developer to create the tables & relationships, and keep a database admin on staff, but your needs for an "IT dept" would at least be less, and the more hospitals that do this, the more pressure Microsoft feels to deliver better quality at better prices. Or, more likely, fail.

I spend most of my time in Excel at work too the point where I break Excel/IE's memory management at least once a week due to the size and forula in workbooks I have open.

First, Excel is a calculator and templating system.

The simple idea is to have a value in one cell, a value in another cell and what you want to do with them in a third. Cell A shows value "1", Cell B shows value "1" and Cell C shows "2" based on it's forumal "=A+B".

The more complex idea is to have a set of calculations that can easily be updated by providing updated source data.

It is also a basic form of database when using functions like "vlookup()" but the basics is that all spreadsheets are function based calculators.

The other thing to remember is that, in Excel especially, each cell is really three layers:

Layer 1 - The value, what you see displayed in the cell

Layer 2 - The formatting, how you see what is displayed in the cell

Layer 3 - The formula, what functions are actually in that cell to calculate the value displayed

Excel is pretty easy to use the basic abilities of the program and the menus do try to help for those who don't want to write there own cell functions.

Mind you, I've met people that think Word text tables are far superior to Excel worksheets for storing data in table formats. It may be a case of using the wrong tool for what your trying to achieve. I know here, I do all my calculations in Excel and most of the formatting but the final summary usually goes out as a PDF or imaged object (past special is your friend) in a powerpoint presentation.

Nice root review of what Excel is. Thanks. Unfortunately Excel is a raging pain in the ass to use most of the time. No simple drop down menus, doing some fairly complicated things requires formulas that MS never explains (ok - does not explain 85% of the time - and a typo is death, and their popup is dumb: "to fix common problems, click Help - and Help doesn't give you any help!) and writing a macro is an exercise in frustrating agony (for me and most other non-programmers) AND Excel simply will NOT do some things. Not to rant at you, but MS clearly doesn't give a fig about improving their product. If Calc or other open source programs were easier to use, MS Excel would be toast. I pray for that day.

Until that day, I'm limited to Excel. Luckily, with a programing background, I'm very comfortable writing complicated cell formula and such. Remember, it's the equivalent of a TI graphing calculator not a toaster so it's going to require the user do some things for themselves. You can, of course, choose to consider or ignore any tips which may make working with Excel easier.

I do agree about MS, they are a business who generates the program code as the product so buget limitations mean it will only ever be good enough to make the sale. If it's all you got to work with though, you'll find more hapiness looking for ways to make it a less painfull tool.

For me, the limitations of Excel are not user related; I break it's memory management almost daily. I can always learn Excel's deeper functions in detail but I can't fix a programing issue like a memory leak. Open enough heavy XLS and you'll find your print format settings get lost. Each cell will get it's own page and you'll recieve a "can't fit margins" message box. Close all your Excel windows and reopen them; tada, it works again for a while. You can even save the "broken" XLS and get correct formating rather than the broken layout you're seeing. I suspect it's due to IE6 as it presents the same issue; use enough memory (webapps.. ick) and the browser will start loading pages really slow if it doesn't time out all together. Close all browsers and start over; lightning fast.

MS is definately better at business than then are at product quality but there focus was always profit margins before end user benefits.

Here's too hoping I can soon open any of my complicated XLS in OOo and get full VB, cell formula and graphing support. Cell formula seem to be good now but graphing is still rough.

I don't think it's any more necessary for medical practitioners to know SQL than it is for me to know how to correctly take blood sample or what to listen for through a stethoscope. While they may be able to acquire rudimentary SQL skills, their expensive time would be better spent diagnosing and treating patients. If they're having to use SQL commands on a regular basis, someone needs to write a better front-end to the database.

I respectfully think knowing one's own blood type, a good idea, is a closer analogy to knowing CRUD in SQL than knowing how to take a blood sample, which is useless except for medical practitioners and certain drug addicts.

I'm with you on the idea that this is easy stuff:

SELECT * FROM table WHERE something = something

For a someone who's only interest is getting the information so they can move on with what they are actualy doing the better choice would still be a simple front end:

first name: [_______________]
( ) critical patient details
( ) current medicatoins
( ) current allergies
( ) full medical history

[Submit]

You could use the same interface on PDA, tablet, notebook or desktop. Entering a name and selecting the detail level is still more intuitive and less typing than running your own SQL under Toad or a similar query front end.

It would be nice if everyone wanted to understand there tools intimately but it's hard enough finding people who want to know there own car beyond gas here, go pedal there, stop pedal there and steer with this. Sadly, computers are even more of a despirate sell when IT is not your area of interest or profession.

Now, to really dare to dream I'd work towards something like this:

- the medic walks into the examining area or room. Proximity identifies the patient too be visited and no username is intered.
- the medic check the first screen automatically displayed for current treatment and all relevant details.
- the medic spots something causing them question and hits a button to review the patient's full history
- the medic presses one of the events in the list and it filters down to just that chain of events and related entries up to the present point
- treatments are adjusted after the patient is examined as needed by the medic
- the adjustment is forwarded too the server through the medic's tablet. The pharmacy get's it's perscrition notices, the OR or other facilities get requests and respond with apointment times.

The issue of patient data security is, of course, managed seamlessly by the technology so confidentiality is maintained.

Yeah, I would have liked too see the Newton 2100 get more of a foothold when it was the new toy. If I remember correctly, it actualy did see continued use in the medical industry for a few years after it went dead in other industries.

You're already too far ahead of the market. Back up, and give the more of the same, only better, at least for a while.

Now, to really dare to dream I'd work towards something like this:

- the medic walks into the examining area or room. Proximity identifies the patient too be visited and no username is intered.
- the medic check the first screen automatically displayed for current treatment and all relevant details.
- the medic spots something causing them question and hits a button to review the patient's full history
- the medic presses one of the events in the list and it filters down to just that chain of events and related entries up to the present point
- treatments are adjusted after the patient is examined as needed by the medic
- the adjustment is forwarded too the server through the medic's tablet. The pharmacy get's it's perscrition notices, the OR or other facilities get requests and respond with apointment times.

The issue of patient data security is, of course, managed seamlessly by the technology so confidentiality is maintained.

How would the data get so well-organized without the medics having any understanding of the OLAP cubes or whatever you're using to define all those relationships?

edit: skipped a word

"How would the data get so well-organized without the medics having any understanding of the OLAP cubes or whatever you're using to define all those relationships?"

Isn't that what programmer-analysts get paid for? I don't know how a transmission operates but I can effectively operate a car because someone designed a stick on the floor to act as my interface.

And, I knew I didn't say this well enough the first time around.

Neon outlined a solution that would retrieve "all relevant details" -- only the relevant ones. I submit that what is "relevant" is something no self-respecting doctor would nor should ever turn over to any programmer-analyst, even one with a pile of Ph.D's & M.D.'s. The doctors who write the wrong prescriptions based on faulty decision trees governing what data are retrieved from the multi-dimensional medical data monster are the ones who will be the first defendants. Only after the errors become obvious to a sufficiently-knowledgeable patient who survives the wrong prescription or wrong treatment would the programmer-analyst be held legally accountable for writing that software wrong.

Second, in the best-case scenario, decent algorithms and structures for such an OLAP solution would require far more labor-months than instructing health care workers in rudimentary, ISO or ANSI SQL. Plus, they have the specialized background knowledge to know which tables to query, and direct access to observe their patients, which the programmer-analyst of such a project can never have.

In conclusion, I think OLAP just puts too much of the responsibility for thinking onto the programmer to be a good choice for relationships more complicated than year/quarter/month/day, debit/credit, principal/interest and similar, which fall basically within the realm of "common knowledge," or just barely outside it, in the realm of "common business knowledge." The computer can be a convenience and improve efficiency in many ways, but using it well might require even end users to acquire some programming knowledge, especially in professional trades requiring advanced, specialized education. Such is life.

Learning how to operate a manual transmission is a small price to pay for transportation on a vehicle that doesn't poop.

First, text based interfaces should be used much more frequently.

In the late 90's the bank where I worked upgraded from an AS400 terminal based system to a Windows solution. It then took tellers and new accounts people much longer to complete a simple transaction using point and click instead of the keyboard.

Also, as Neon mentioned, text interfaces are extremely portable. They work much better with interactive voice controlled systems too.

Second, if apps are designed to use a web browser as the front end then the presentation layer is almost done for you the minute you begin development. Especially if the code being pushed to the browser is clean - perhaps (hyper)text is sufficient?

The unfortunate reality is that users have come to judge an application's merits based on "window" dressing.

Whatever. I better go. I need to get to the dealership and take delivery of my cardboard Ferrari. It's slow and awkward to go anywhere but you should see its shiny paint job!

Nothing about Linux prevents writing of front-ends that are just as good as those that can be written for Windows. Sure, marketing budgets have made Windows known to the business people in health care, so now a lot of existent software works more smoothly, or only on Windows. But, the original choice to purchase software developed for the less-stable platform was the error, not some shortcoming in Linux.

As I noted below, "Windows is unstable" is the equivalent of the outdated "Linux is hard" fallacy. Both show a lack of recent experience with the relevant OS.

If the original choice was to select the only existing software option, how can it be an error? The buyer could have contracted to have an application written, with all the attendant delays, consultations, developing and writing application specs. Or they could buy something off the shelf quickly, with the possibility that new hires in the same field may already be familiar with it.

This last point is a big reason corporations buy many apps instead of developing them in house. It's impossible to advertise for a new employee an require they be familiar with a "home grown" app.

But it isn't solved. If I accepted an improvement over the instability of Windows 9x as "good enough," I might as well capitulate to the fallacy that there is no global warming, because there is no increase or a minor decrease in temperature since 1998, the hottest year on record. Windows is still not as stable as Debian GNU/Linux, which never automatically downloads & installs anything causing an unstoppable reboot, as just one example. Every time that happens, it is exactly equivalent to being "taken down by malware" -- for just a short time. If you're in urgent need of a transfusion and the doctor can't retrieve your blood type because of a Windows Update, a short interruption in the operation of the computer is as acceptable as a complete wipe of the hard drive.

I do have to agree that the hospitals and medical offices that bought software developed for Windows can't be faulted for not writing their own, "home grown" programs. I should have been more specific, that it was the corporate dufi who had their development team(s) write software only for Windows that made a crappy choice. I also don't suppose they should be responsible to advocate for Linux throughout the medical community, and hold their own profits hostage to their ability to convince all to undertake the costs of switching away from Microsoft, immediately. But, not even porting the same apps to Linux and not making any mention of the greater reliability of that platform are ethically questionable choices, if you ask me. Assuming that the programmers are knowledgeable enough to write mission-critical software, and assuming that these apps really are "critical" at all, helping an inferior operating system maintain market dominance and continue to endanger patients is not justifiable. Of course, if this so-called "critical" software is only about records for insurance companies and have no bearing whatsoever on patient care, then the entire conversation is moot, and all I've said about it applies only to a non-existent situation fabricated by the poster above.

I worked in Healthcare IT for almost 8 years and it was almost like pulling teeth just to get them to do CPOE. Good luck on SQL. Physicians have enough to worry about without trying to be database wizzards, thats why they pay US the big $$

And, I did already point out that a GUI can be developed in Linux just as well as it can be for Windows.

I have to agree with Palmetto. The medical staff need not to have any SQL knowledge to do their jobs. The front-end is all that they need to be concerned with since that is where they perceive that all of the "work" is being done. In my office I'm impressed if the medical staff can figure out how to change their passwords or read their email.

I do know of one doctor who uses a Linux-based medical software but unfortunately the name of the program escapes me. It's PHP and MySQL based running on a a SUSE box.

So it has a GUI. Whatever. It doesn't need Windows.

It doesn't have to be a GUI, but it's got to at least be menu driven. Whether that's a GUI, at text menu (as clhansen points out above), voice driven, whatever.

It's unrealistic to expect medical professionals (or any other non-IT worker) to learn SQL commands in order to extract routinely needed data. We get paid to design interfaces to ease that data retrieval for them.

Just as there are thousands of companies who use some proprietary software that only runs on Windows for tracking timber tracts for logging companies, room assignments for hotels, who has what checked out at the video store and so on.

The fact is, these applications can be redeveloped to run on Linux, often for a fraction of the cost of a single year license for the application it's replacing - and they can be developed to talk to the same backends that everything else uses. Usually, when we create software like this, the client sees the benefits almost immediately and pushes to have more of their business process pushed to the more resource friendly, far more stable and more user friendly solutions that we provide.

The hard part is getting past the whole mentality that everything must run on Windows. More than once we've been flat out laughed at when we suggested making the move. Then too, more then once we've seen that attitude completely turn around once we give them a little taste of what's really possible.

I agree with the previous post that said doctors and nurses don't want to learn a new OS. However, the handful of commands that must be learned for Linux are probably easier than figuring out Windows... they are just used to Windows.

I believe that one of the key issues is support. The institution would have to invest in training and support for the ramp-up. If that issue is addressed, I think that Linux would be more widely accepted in healthcare.

As a non-tech (HR) person, and with some experience in Hospitals, I agree that most clinical staff do not want to learn tech info, commands, and the like. They have lives to save and patients to tend to. I have looked at Linux a bit, found Gnumeric a bitch to figure out and basically dropped it. Until Linux truly suprasses Windows in intuitive use, with simple drop-down menus that allow functionality, it will be an also-ran for nerds and IT people (with sincere apologoes to nerds, and IT people).

I worked with EMS systems before. I went to great lengths at that job not to make anything different for the user. They didn't care about tne os, they just used applications, which in that field are industry standard type apps. Users that transfer from other parts of the countries in entirely different organizations would come in and know immediately what to do. These people saved lives for a living (dispatchers, call takers and EMS response people) so I wouldn't dare have thought to switch over to Linux and try some new app out to save a buck or two when seconds are what really counted. Not only that but operating between different private (hospitals),state, local and federal agaencies demanded alot of interoperability and data sharing. It kind of smooths the process if everyone runs the same software and no data translation is needed. People can instantly look at reports, statistics, ems info or dispatch info generated from the same data in different agencies, kinda helpful when seconds matter.

And I'm not a nerd, I'm a geek...get it right.

Feeling that Windows is more or less intuitive than Linux greatly depends on what you are used to.

Linux is my main desktop and server OS. I have used it extensively for many year. I also have used Windows for many year and have lots of experience with many versions of it and have done lots of programming in windows. Even so, every single time I want to copy and past text in windows, I select the text using the mouse (to copy it) and then click the middle mouse button (to paste it)...

What I'm trying to say is that, "user-friendly" and "intuitive" are very dependent on your experience and habits.

I'd love to find and work for such a company. There's got to be one in Toronto here someplace but the mystic list of IT businesses continues to elude me.

I deal with it in the Accounting Arena.

All of the accounting specific applications are written for the Windows OS. When approaching these vendors to port their apps to Linux, they respond there is no demand. Yet when speaking to other firms they state there is no software on Linux so they cannot move.

Additionally, many of these vendors will NOT support their apps installed on Linux with Wine.

For the industry specific applications port to linux you will need a large number of customers to demand the change.

In addition to that, Medical just like Accounting, have professionals that use windows at home and do not want anything diffrent in the office. Now in a corporate environment, it is easier to say get over it. However, in these professional firms that are usually LLC or partnerships, it is really difficult to tell them to suck it up.

I know of at least one large hospital that uses Linux for many of their applications.

Generally the admin staff is too tied in to windows to move, although they have equivalent software available.

So on this subject, please tell me what makes Linux not ready for healthcare? I would really like to know the technical reasons.

Regards,
Les H

I would like to make two points, one is I worked for two large health care systems and I can tell you that both organization has a lot of applications (Over 250 in one and 375 in the other) and most of them are Windows based application so they will need to be ported to Linux. Looking at the application today 95 plus are not.

The other point I would like to make is that one the organizations worked for had to rolled back there Windows 4 implementation mainly because they didn?t like logging into the OS. Change is not accepted well within the health care industry based on my observation anyway.

The real-time hardware and other equipment like sonographs are probably using a Linux kernel if not some other Unix like OS. I knwo GE's sonograph isn't running on top of a Windows install. Your also using it in most of your mobile equipment unless it's all winCE based.

The business decision to develop on Windows using code that can't be ported to other platforms does not mean those other platforms are not "ready" or not already being used.

I was like you and thought it would be running some UNIX derivative but no, OS2. I was told by the GE tech installing that a lot of their medical machines run OS2.

I've only seen the sonographs used for 3d/2d baby imaging so a Unix of some sort was my guess with GE being industry and weapons technology company. The UI hides the underlying platform well as it should though.

Good on them for keeping OS2 alive though. I wish it was still a viable OS for day to day desktop but using it embedded in a product means no hardware driver issues.

The original article is based on using Linux as a computer operating system. I don't think there's any debate about the viability of Linux to support a single dedicated application.

As an embedded, the Linux kernel has long since proven it's abilities. It seems most of us in this thread got stuck on the comment claiming that the Linux kernel had no place anywhere in medical practice.

I worked in the OR, for a few different hospitals, for 7 yrs. The OR is where the money is made. Part of the reason for not making too many changes is time is money. In the OR everything is time driven. If its going to take someone 2 extra minutes to set up a machine, that is money. It pushes everything back.
Linux in hospitals is defiantly something that can (and will) happen. It would need to be tested extensively before deploying. Of course time would have to be set aside for training and money would need to be spent to have an experienced person available for a crisis situation.
It will happen. Someone will mention it and research will be done on how much money it will save over x amount of yrs.
money = slow process.

Using Linux in Large Organisations Does not mean that you can't use Windows on Clients or Small Health Offices,
There are a enough tools for using Linux and Windows.

and possibly the best argument for Linux they could get:

http://showmedo.com/videos/video?name=1950000;fromSeriesID=195

The flash video of installing a desktop linux, all of about half an hour.

how's that page view count?

17 - 456: Installing PCLinuxOS by Jaqui

which is always available, even without a login:

http://showmedo.com/mostPopular

The Windows installation tools available at the corporate level reduce install the OS to a couple of scriptable command lines. Corporate IT shops usually install the OS only once per hardware model, make a Ghost image of it, and copy that image to other systems of the same hardware configuration.

Great video, but not an advantage worth mentioning in a corporate IT shop.

One might deploy Linux to a few carefully-chosen Power Users, for example, on older/spare hardware, to test the waters before implementing a corp-wide switch. At least, that would be the smart way to change.

If we were to implement this where I work, I'd start the users who have minimal application requirements. This would mean the factory floor, where they only need access a couple of web-based applications and our ERP software. I also get the biggest bang for my support dollar since these are the machines users are screwing up all the time because Windows can't prevent them.

Unfortunately, the web based data they need is in MS Sharepoint, and I don't know if a non-IE browser can access them. Assuming Sharepoint is accessible through some other browser, there's the ERP issue. Is there a Linux client for SAP, and a utility to add bar codes to output printed from SAP? How about drivers for Intermec and Symbol USB and PS2 bar code reader (3 of 9, PDF 417) and Zebra thermal printers?

It's not going to happen anyway; we purchase MS software under an enterprise agreement based on the number of systems we have. We'd have to change more than just my 65 factory floor systems to make renegotiating worth the trouble. If we're paying for it anyway, why not use it?