Slashdot Mirror
Developing for Healthcare - .NET vs J2EE?
An anonymous reader asks: "Our small southern shop (an eleven man team) is about to commence development on some medical software geared for physician's offices and hospitals. Since we have never developed in this area before (our primary source of income comes from developing software for regional transportation offices of the government) we are at loss for the reigning technologies. The two technologies we are considering are J2EE and .NET. What are the opinions of the Slashdot crowd? Surely others have developed for the monstrous healthcare industry. Thanks!"
"My senior manager recommended using .NET. His argument is that most desktops he has seen in hospitals already run Windows, the development time will be cut down for this small to mid-size project, rich desktop clients are possible and there will be no application server costs involved. He also contends that .NET has more templates and abilities than J2EE (which is simply 'web targeted' in his opinion.
Half of my coworkers are with him and the other half have suggested using J2EE due to portability--we do not want to cut off any potential sources of income with an already dwindling future. Has GNU/Linux become widespread in the healthcare industry that we should consider developing for it too? What about Mac OS X server?
The last problem we have is winning over the IT staff hearts. They are the ones who ultimately give the go ahead to purchase the software. Java gets a bad rap for being slow, while Microsoft (and by extension) .NET has the shadow of being insecure. How can you possibly win?"
Half of my coworkers are with him and the other half have suggested using J2EE due to portability--we do not want to cut off any potential sources of income with an already dwindling future. Has GNU/Linux become widespread in the healthcare industry that we should consider developing for it too? What about Mac OS X server?
The last problem we have is winning over the IT staff hearts. They are the ones who ultimately give the go ahead to purchase the software. Java gets a bad rap for being slow, while Microsoft (and by extension) .NET has the shadow of being insecure. How can you possibly win?"
Because it simply doesn't matter.
Either your client dictates the technology or he doesn't. The "Healthcare Industry" is a vast array of mixed technologies, so it doesn't matter that way. And if they're buying your solution, they're buying your SOLUTION (which typically involves hardware), so THAT'S not important.
Go with what you know, go with what you're comfortable with. The success or failure of your project will have nothing to do with this decision, just in how you pull it off.
You can find all sorts of excuses to fail in either platform, and you can find just as many reasons to succeed. Pick one, don't second guess yourself, and stick to it.
Good Luck!
Don't ask us. You know the client better than us, and should be able to determine what the best tool for the job is based on the application you are writing, as well as the environment which you are installing it in. Don't make the decision based on what everyone else is using, base it on what will work the best.
Feed the need: Digitaladdiction.net
Your project, assuming there really is one, is doomed already.
You're asking an Internet message board for advice on a development platform? For software you're going to develop for an industry you have no experience with?
Sounds like you're asking the wrong question. What sorts of applications are you expecting to develop? Is it primarily database stuff? Are you developing for a small or large organization? (given that you have an IT staff, I'd expect large).
The only thing I can tell you for sure is that it's much easier to prove to an IT staff that something's not slow than that something's not insecure -- just show them Eclipse or anything else that...doesn't use Swing...which is the one really slow part of Java.
Really, though, these technologies are so similar that you should probably just pick one and go with it.
-Amalcon
For the past four years, I have been working for a company that develops healthcare software. We chose .NET for our applications, but I have also done a fair amount of development in J2EE environments. In my opinion, both J2EE and .NET are fine platforms and either one will work. It will be the user interface and features of your application that will ultimately determine its acceptance. People who use healthcare applications are not computer people and don't want to be. They just want to enter their billing, schedule their appointments, retrieve their lab results, etc. If your application allows users to do that quickly and easily, nobody will care what the platform is.
.NET.
Now, having said all that, I will fall back on the usual logic and say that if your application needs to be platform independent, J2EE is the obvious choice. If you want the easiest and most productive development environment, stick with
MS has pretty much bet the bank on .Net, so even if windows loses market share I can't see it going anywhere anytime soon.
.Net at work (not out of choice) and I must say that I've been pleasently surprised. Ethical grandstanding aside, VS.Net is a very good IDE and C# is a particularly nice language. IMHO, easier to use than Java.
I use
I still agree with your cocclusion though - depending on the current skill level of the deveopers of course, I think Java is the better option. Both platforms are pretty similar, but with Java you get (better, complete) portability.
Ben
Yeah, like I want my medical records stored in a database that is touted for its supposed speed, not for meeting the requirements of ACID transactions.
I work for a small company that does almost exactly what you're talking about, but so far only for hospitals. We have been in business for twenty years now and are having some of the same discussions. We currently run on win32, SCO Unix and AIX. In the past we have supported DOS, HP-UX, Solaris, Linux, AIX, UNIX and WIN32. Most of our customers are running our software (which is character mode btw) on Windows, but our largest, highest paying, and most stable customers are on AIX. If you want large customers you may want to consider something portable. They will usually have a RS6000 running Oracle in the hospital and have many Windows machines connected to it. You can get away with ignoring the RS6000, but that's the most stable machine in the building and IS would love to put it to use. From a support point of view, our customers on AIX and UNIX have the fewest problems and call us the least. There is nothing like trying to diagnose a label printing problem on a Windows network while working remotely over a modem or vpn connection.
Our debate is focused on whether we should support only one OS, probably Windows, or continue to support three. We'll be switching from UNIX to BSD at some point. (Personally I'd rather use Linux, but as a company we are familiar with UNIX and I'm told BSD is very similar.) The Unix variant side likes the security and reliability, the Windows side likes the graphical interface and the fact that Windows machines are everywhere. Plus we have both Windows and AIX customers that insist on their OS of choice. One thing that scares me about Windows is HIPAA, which makes the hospital liable if a patient's information is leaked. No court cases have been brought yet, but the thought of all that patient information on a Windows machine that could get hijacked is scary. A lot of these hospitals allow remote vpn connections and some of these networks get infected with a worm now and then. I wonder how long before someone decides to steal a patient database and bribe the hospital?
Most hospital systems, and even some Physician software will communicate with other systems using HL7 protocol over TCP/IP. This is the thing keeping us busiest now and a lot of times it's what the hospitals find most useful.
Just my two cents, but get used to having the customer tell you what they want and be prepared to do it, if at all possible. Flexibility is key, even more than taking advantage of the latest software trends. Support wise, they will need hand-holding, but they will be loyal customers if you respond to their problems quickly and kindly.
From the sound of it I would have to say that their first step is to just decide whether it they want to create a webapp, standalone, or client/server program. My choice would be a webapp for the very reasons stated in the above post.
.Net. In reality, if you go with a webapp then the backend is not as important as if you were trying to create a standalone or client/server program. This is because as long as the program runs it is more a matter of the hardware than the software that you need to think about. For instance, when the industry at large went from using 200Mhz systems to using 1Ghz systems people were raving about just how fast even basic scripts were executing. Since most systems are now over 2Ghz in speed; scripts execute (to the layman's eye) as quickly as compiled programs. And in truth, unless you are dealing with thousands of hits per minute - to all intents and purposes scripts do execute as quickly as a compiled program. But that's only because most of the work is being done to simply set up the process to run and to take the process back down. The actual execution time of a script or a compiled program is quite small. So to be honest about everything (at least as honest as I can get about this and still keep everything on a general basis) I'd be in just as much of a favor in using Perl/PHP as I would anything else.
.Net you create classes.
.Net all have built-in encryption. But there are libraries for C++ to do encryption. So (again) it is all about the same.
.Net - this process is the same as well. Edit, compile, and execute. So there isn't any difference here either. So the whole thing really just boils down to what you feel comfortable working with. Just remember though that in order to use .Net on any other system besides Windows XP you will have to install Mono first. Since Microsoft doesn't do Macs, Linux boxes, Minicomputers, Mainframes, or anything else that doesn't look, sound, and act like a Windows box.)
For languages, although some differ, I would suggest Perl or PHP first (not only because they are fast but both languages run on a large number of systems in the same manner. So if your boss comes to you one morning and says you are moving from a Windows box to a Linux box you can rest assurd that your programs will still execute properly), Java next, C++ after that, and then I might consider
With Perl you create packages.
With PHP you create classes.
With Java you create classes.
With C++ you create classes.
With
So it is all (basically) the same - no matter which language you go with. Once you have your classes (or packages) set up all you are doing is reading to include them into your program and then running the program. Further, Perl, PHP, Java, and
(At work I have VI set up so I can just hit two keys and my work automatically compiles and another two keys and it will execute. I know I could combine these commands but in this way, if the compile dies I can go back to editing without having to kill the sub process. What this is leading to is that whether it is Perl, PHP, Java, C++, or
Someone put a black hole in my pocket and now I'm broke.
I have worked in a hospital IT department for 10+ years and we support approximately 1000 workstations. Here are a few suggestions:
1. Make it easy to deploy/update. Preferably web based, or your app can update itself. If not, make sure it can be installed silently via MS SMS, group policies, etc.
2. If using a database, you better make sure it enforces integrity and does not try to guess what you mean and do it's own thing. MySQL for example will "help" you by truncating strings and accepting crappy data. You don't want to be screwing with patient data. Lawsuits are common and your data will need to stand up in court. Yes, your app should be able to stop this - but you never know! If open source is your thing, try Firebird.
3. Hospitals shutdown for evenings, weekends, holidays. There is never a "good" time to have downtime. Minimize the need for it and try to build redundancy in your app.
Hint: There are fairly few recent PCs in many hospitals. So unless you are targeting only wealthy private hospitals, assume the worst.
I use to work on a Unix based custom information system that over a decade old, and on a dozen Unix platforms, and they were developing a new Windows based system. It took multiple years to develop with the new product that was not good enough to replace their existing Unix solution, so hadn't sold a single copy of the new system.
Of course, to your secondary question, I don't know, but I think it is a classic case of horse before the cart though.
Very true. Our healthcare application is C and various 4GL database languages running on a Linux server with a Java front-end. Java 1.5 running XP look-and-feel looks great on Windows and performs just fine, plus we can develop on Linux and run it on Linux for the (few) clients who choose to use Linux desktops. I'd go with GDI or Java hands down. GTK is too ugly on Windows and QT just doesn't feel quite right either. Java is good because it's portable and very quick to develop, only downside is start-up time, but for client apps 1.5 is definitely the way to go.
.NET just because it's hip, go with it if you really really need that kind of enterprise/middleware format. If your app is simple client/server it'll probably be easier to just do it in established languages like plain C, Java, Perl etc. Don't over-engineer your product, especially not for just a couple of clients. Maybe if it gets more popular you can afford to spend the cash on developing some superduper amazing system, but it's really easy to piss away money spending months (years!) designing something that you only ever deliver to one client.
Don't go with J2EE or
A lot of healthcare work is about fitting into other systems' products. HL7 is a really important standard for transferring data between medical products, but be aware that even some of the biggest names in the industry don't support it fully or may not even support it at all. Be prepared to make lots of Perl and shell script "glue" to share your data with other systems. You might need to contact Medicare and large health insurance companies to see if they need data transferred electronically and what format they want.
Good luck!
Speaking from expierience, I worked several years as an IT Manager in the healthcare industry in Connecticut, the most important thing I was forced to consider was ease of use and speed. While security is always a concern, it sometimes had to take a backburner to speed and just plain old usability.
.Net as that is what, from my expierience, is going to get you the most market share. Make it run quick, and by all means make it simple to use.
I cannot speak for other healthcare industries in other areas, but we were a 100% Microsoft shop with the exception of our Web Server. Almost every application that I looked at in my time as IT Manager was a windows based application. I have no problem with Linux, and I personally prefer it, but not many crossed my desk. I would say about 95% of the applications I saw were Windows based Apps.
Perhaps the best thing for you to do would be to try and do some research on your target audience (Hospitals, VNA's, Single MD Practicioners, Multiple MD Practicioners, Walk-in Clinics etc.) and if possible find out what type of servers / software / brands they are currently using. You are going to get some people that will not give out that information but some will, and it is all in how you approach it that will get you that information.
In the end I think you are going to find that it would be better to go with the
Brian
No offense to the Mono folks, but I just don't see them ever having 100% cross-platform capability. It will never be possible to seamlessly change your development and deployment environments from Microsoft.NET to GNU Linux/Mono. And if it ever does become that easy, Microsoft will be ready with some kind of nastiness (patent lawsuits, forced upgrades, etc).
The group I work in writes custom engineering (design and anlaysis) applications for our company (Fortune 100). Some of these applications have been ported several times over the years as the flavor-of-the-week OSes/platforms changed. And today we're still porting applications to Windows using MFC! What happens when Microsoft obsoletes MFC, or Linux becomes the standard for engineering desktops, or even Apple starts supplying top-of-the-line technical workstations? We'll port again! But now is the time to take advantage of open source, cross-platform development environments.
Spend your time working on a solution for your customer, rather than worrying about future portability issues. I just feel that if you go Microsoft now, you'll regret it in the future; I just don't see how anyone can make a reasonable justification for going with Microsoft and claim to have a solid long-term vision.
Even Microsoft's lame slogan, "Where do you want to go today?" supports their obvious short-term approach. Today just isn't as important as tomorrow: I know where I need to be tomorrow; once I figure out how to get there, what I do today will naturally be right.
I find myself wondering exactly how much experience this chap really has in this market, as opposed to listening to a bunch of people with real experience talking, since "PAX" is actually spelled "PACS" (stands for Picture Archive and Communication System) and HL7 is an XML-based protocol.
.Net, despite the great strides mono has made, you're going to be a microsoft bitch^H^H^H^H^Hshop for the foreseeable future. if you go java, get ready to deal with the fact that there are a lot of areas of it that are overengineered for your purposes. There are downsides to both, but there are just as many upsides to each as well. If it were me starting from scratch, i'd go with java, if only because i like eclipse as an IDE better. (and for the record, i agree with anyone who says that's a bad reason to choose a toolkit--but i'd make the same decision six days a week and twice on sunday :) )
That being said, if your target market is small physicians offices, don't worry about the runtime; the overhead of installing it to the workstations is indeed negligible. BUT, if you plan on targeting hospitals at all, the lack of a runtime can indeed be a great selling point. While writing a web-based PACS/RIS/scheduling (RIS=Radiology Information System) my company found that in the vast majority of installs, the clincher to the sale was the lack of a required executable install (except for the radiologists who were doing diagnostic reads) and/or the end-to-end integration of our system, which meant they didn't have to cobble together four or five different vendors' software using obscure export/import procedures that usually ended up as a post-it note on the monitor of the technician doing the job.
on the choices of software: if you go with
honestly, if you're intent on going into this area, go for the little shops first. hospitals are attractive targets for the big boys like GE Medical Systems, and they will eat your friggin lunch, right after they kick you in the balls just for fun. There's a huge market for smaller offices who can't afford an entry-level price of half a million for a HIS system but still need practice management. This is what the ASP business model was born to cover. Tell a doc you'll install for less than 5k, charge him 5 bucks a patient/study/unit of work/whatever but in doing so allow him to better track his expenses, increase his payments from medicare/insurance, see more patients in less time, employ fewer people, or whatever promise your software makes, and he'll be foaming at the mouth to buy whatever it is you're selling.
I agree totally. I used .NET at my previous Hedge Fund, and I use J2EE at the current one. It is night an day. Do you ever want to see a full stack trace (not just the couple of methods that the exception crossed before it was caught?), do you want to avoid .dll hell, do you want software that is efficient and has a collections API that wasn't designed by a 12 year old? If you answered "YES" to any of those questions, avoid .NET like plague.
.NET and C# is the best way to go if you want to use the Microsoft solution, but it has SEVERE CRIPPLING deficiencies. No coplete stack traces, nothing even approaching the scale or efficiency of something like JBoss, operator overloading that everyone loves to use (Ever see == throw a NullReferenceException?), the glories of COM (learn love Single Threaded Apartments), and half the examples are written in VB. I could just go on for days.
Since it's for a hospital, I assume that...
1) It's server like, pushing around data and integrating with other systems.
2) It really shouldn't crash.
3) You'll probably have lots of home computers, terminals, etc.. as users. It might be hard to track them all down to get stuff upgraded, especially considering that doctors may not always have the time for you to screw with their computers.
Seriously though, you just can't go wrong with J2EE. It'll run on anything, you can get pretty much any sort of appserver you want. You can get free appservers (JBoss), expensive ones (Websphere), or just embed your stuff in the database (Oracle) if that's what you think is appropriate. Java Web Start is a godsend for managing applications, and EJB will easily handle all your communications needs.
I just can't stress this enough,
This is, in fact the reason I quit my previous job. After trying to pound nails with a screwdriver for about a year (and getting roughly the progress you would expect from such an attempt), I threw in the towel and moved somewhere more sane. My life is much better now.
First of all don't use EJB's unless you have to. If you don't need distributed transactions then stay away. You don't want heavy weight frameworks to drag you down. Read: Better, Faster, Lighter Java. http://www.oreilly.com/catalog/bfljava/ For a free introduction read: http://www.onjava.com/lpt/a/4744
My personal advice is a stack made of:
- JSF for the webfront. Struts if you are a bit more conservative. http://struts.apache.org/
- Spring for the business logic. http://www.springframework.org/
- Hibernate for persistence. http://www.hibernate.org/
If your need a thick client then use Swing instead of JSF. Then you can stick RMI in between two of the layers.Don't forget to have fun.
TCAP-Abort
I stopped reading your post when the website you refereneced made the point, "I do not take any guarantee about the quality of software referenced here. Use at your own risk."
The Java platform supports ONE language, Java. There are hacks that provide support to more languages, but NONE are supported by the platform.
Oh, and Java's language support is typically much more obscure. Ever heard of Jython for example?
Bill
It's my Sig and you can't have it. Mine! All Mine!
I started reading the whole thread of replies, and I couldn't find a better comment than the one made by the first poster: "Java isn't slow, .NET is not insecure".
.NET, C or C++, try to think wether you have solid facts and a really large experience to support it, or just your idea of how things are, read elsewhere from someone you don't really know.
.NET for the way it's architectured, but the freedom it gives you in development it takes away in vendor lockin. I initially saw Mono with lots of suspicion, mostly regarding its legal status and possible future implications. Then I spent some time reading about it and ended up dismissing those fears.
A programmer worth its weight knows that each language has its niche, and for specific tasks there are enviroments that work best. Then there are those who believe the hype and form a concept of things without actually ever having a 1st hand impression. It's a bit like racism, applied to programming languages, and it has a common origin: ignorance. I hope this doesn't sound ecletic, but it probably could inspire flames, since people usually have a hard time admitting their ignorance. But the next time you feel like writing something about Java,
Also, the belief that a programmer can only be good in one language is ridiculous. Give a good programmer a month and he'll excel in whatever you throw at him in a given language. And what he doesn't know, he'll learn. Give him a project and a couple months and he'll know things inside out. Maybe he'll have a preferred language, but who's to say that won't change over time? Evolving oneself as a programmer sometimes involves changing paradigms.
That said, I consider myself mainly a C programmer, then converted to C++. Nowadays I use C/C++ very little, for very specific things or for my private projects (involving OpenGL & C++). I've worked extensively with Java, Perl, PHP, Prolog and bit in a dozen others. I'm in the process of learning everything possible about Mono/C#, and I'm enjoying it.
I don't really enjoy Java mainly because I find developing in it to be a real pain. When you have learned over 20 different languages, you value freedom of expression, and Java doesn't give you that - it locks you into a syntax that is archaic and not very flexible. I don't like the Sun Java team making choices for me, like not allowing operator overloading and not having propper syntactic support for modern OO concepts like properties. Maybe one day they'll understand the language syntax itself isn't important - just convenient - and will follow the road of Parrot or MSIDL (argh).
I like
I have recently gone through a process I consider similar to yours, and I don't envy you. It's a though choice. I recently spent almost two weeks studying the whole issue, experimenting with RAD systems for Java, Delphi, C++ and C#. In the end, I ended up adopting a solution based on LAMP2 (Linux, Apache2, PostgreSQL, Mono) - which should not be confused with LAMP (Linux, Apache, Mysql, PHP). Here's the reasons and thoughts:
- We find C# to be quite more expressive as a language. Mono is in a state good enough for us to use it, which satisfies our needs for platform independance.
- Java is not modern enough syntactically. It wasn't designed for some of the things it's used for nowadays, namedly GUIs, and that shows. Nowadays, having to write 'a.setLabel( a.getLabel() + "..." )' instead of 'a.label += "..."' looks stupid, and just shows what happens when people make decisions on your behalf based on their beliefs: on this I agree with Anders Hejlsberg.
- We prefer open source solutions whenever possible. We have many people with skills on PostgreSQL and its internals (we've had to extend it before).
- Apache is rock solid.
- Global input from the rest of the team.
There were, of course, lots of small decisions related t
"I don't mind God, it's his fan club I can't stand!" E8
There's a *huge* difference.
Sun has worked for the last decade trying to ensure above anything else that Java works on as many platforms as possible.
Microsoft have worked for their entire life as a business to ensure that software only runs on their system.
The track record of these companies should be all the argument that people need.