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!
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?
Right on, he's obviously lost without a clue if all he can do is trot out these lame stereotypes about the technology (duhh, .NET is insecure, J2EE is slow) as arguments without mentioning 1 word about the friggin requirements.
.NET isn't insecure and J2EE isn't slow... they're both insecure and slow if your development methods are insecure and inelegant. That's like saying "should I use a hammer or a screwdriver? A hammer can smash your thumb, whereas a screwdriver can gouge your eye out..."
Not to mention,
you want to develop for a new vertical industry that you're not familiar with, you're not sure about your dev platform and you came to /. seeking objective analysis on a platform involving MS?? Well, you certainly deserve all the "PHP rocks!" and "11 lines of Perl are all u need" answers you'll be getting...
Any program written for the medical industry that involves capturing patient data is required to be secure. Read up on HIPPA (http://cms.gov/regulations/hipaa/cms0003-5/0049f- econ-ofr-2-12-03.pdf) before making a decision. The company I work for creates software for the medical industry and we chose J2EE for the security and relatively low barrier to entry using open source application servers and tools.
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
A webapp has the strength that all you need is a web browser to view the content. When you update the webapp, all clients are updated instantly, without having to push something out to them, or making them download something. This saves a lot of stress and headache.
There are many technologies out there for writing a database oriented project like this a lot easier. These include
Apache Tomcat, JBoss, and many of the other java based application servers are supported on many different platforms. You can run it on Windows, Linux, Mac OSX, and virtually any hardware provider you want.
I've been working now on this project for 6 months, and I have to say, I love the structure of this way of working on webapps far more than the common hodge-podge of php or perl. This isn't to say you can't program a nice, easy to maintain app in these languages, just that there is a nice framework with examples and plenty of books to do it in Java.
Don't count your messages before they ACK.
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
Last summer we developed a case management system from scratch for hospital admissions pre-qualifications and tracking. Our client serves the medical insurance industry, therefore HIPPA was a factor. We used LAMP all the way, finished the project in three weeks (no brag, just focus and swinging elbows), and they have fifteen nurses banging away 24/7, client access via https, and 100% uptime. All of their money went to us instead of software licensing, they paid less anyhow, and they are smiling ear to ear.
If the PHP is not elegant enough, for the love of sanity please use Java. If we don't feed the monster that is choking, screwing, and robbing us, it may weaken and we can get on with an unshackled future. We do the entire world a favor whenever we choose sane engineering.
"If no one tilts at windmills, the damn things will take over the world!"- Christian Simpleman
"If no one tilts at windmills, the damn things will take over the world!"- christian simpleman
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.
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.
Both .NET and J2EE are good platforms for developing and hosting business applications. Both support n-tier architectures via client- and server-side component models for assembling enterprise applications. This allows for use of either fat or thin user interfaces with both platforms. However, .NET and J2EE are far from identical, and each platform has distinct strengths.
The primary strength of .NET is its use of multiple programming languages running on a single platform. This eliminates the programming language as a barrier for adoption. Further .NET strengths include ease of use and speed of development as programmers might be transitioning from COBOL or C. (In contrast, transitioning to Java usually takes greater skill in object orientation.)
J2EE takes .NET's multiple programming-language/ single-platform paradigm and turns it around: The primary strength of J2EE is its use of a single programming language capable of running on multiple platforms. This eliminates the platform as a barrier for adoption. Further J2EE strengths include vendor neutrality and the active involvement of a large, open-source community.
Legacy applications: Can either platform make integration easier?
Healthcare providers are moving from traditional reliance on paper-based records and isolated legacy systems. Most now embraced more systematic electronic exchange of patient data, exchanged both within and across organizations such as other providers, diagnostic and laboratory test facilities, managed care organizations, etc. Creating and maintaining patient records requires the ability to extract and integrate patient data from a range of "legacy" document and system formats. legacy applications constitute an even more difficult integration category. Consider a host application that was developed in-house 20 years ago, and written in COBOL. No J2CA resource adapters are available, nor will they be available, to help integrate these applications in a J2EE environment.
From an integration standpoint, JDBC is actually more promising than J2CA. This API provides access to virtually any data source, from relational databases to spreadsheets and flat files. With a JDBC driver, all corporate data can be connected, even in a heterogeneous environment. In addition to its support for actual relational databases, JDBC can also support emulated relational models based on legacy information sources. But to do this, JDBC requires an integration product that can map the legacy-application functions to emulate a relational database model.
The .NET platform, with its dependence on Microsoft BizTalk Server, has the same drawbacks for legacy-application integration as it does for packaged-application integration. So, despite the very real integration potential of .NET and J2EE, both platforms have their associated limitations. And when it comes to legacy-application integration, neither platform can complete the job on its own.
Be aware that all vendors of application integration products do not provide equal support for .NET and J2EE. Many vendors have built their solutions exclusively around one platform or the other, heedless of the fact that both .NET and J2EE will still be the strongest presence in the years to come. Buying an integration product too hastily can tie your organization to a development platform they might not have chosen otherwise.
Therefore, you should look to application-integration vendors that are closely aligned with--and can articulate a long-term strategic relationship with--both .NET and J2EE technologies. That means checking to ensure that a solution offers interfaces such as .NET Class Libraries, COM Objects, ASP, ASP.NET, and .NET web services to support your .NET-based development efforts as well as interfaces like JavaBeans, JSP, and Java web services to support your J2EE-based development efforts.
I work for a company that just landed a large install to a large hospital system. Here are some points to consider.
.NET AND Mono deployments (or just pick one).
My experience...
1) Don't worry about the run-time in terms of a desktop requirement. Since you'll have to install your software, you'll have the opportunity to install the VM.
2) Getting security clearance to run on a hospital system will largely be dependent on your application architecture and not on your application framework. Do you depend on certain ports or services, certain databases, file shares, web services, etc.
3) A majority (overwhelming majority) of these systems do run Windows. If you find Linux in the mix, it'll usually be for very specific systems (PAX/DICOM) or back-end work (your mainframes and such). Due to the large number of small vendors in healthcare, a ton of applications are installed to the clinican's desktop. (And may have simple architectures or older frameworks like VB, Delphi, and even Terminal/Telnet). Everything from intergrated hospital wide systems to what a doctor uses on his own box to manage X, Y, and Z. [hint: look-up CCOW]
4) Integration with an EMR is important, and again, most are Windows based. If you want to feed data into "the system", be prepared to work with the system. EMRs are heavy on HL7, light on Web Services and XML.
5) Depending on your architecture, your GUI/interface and your "server" can be running on different systems, platforms, and/or frameworks. Probably not the best route but it is possible.
General knowledge and opinion...
1) Mono (.NET) for non-Windows applications is just as viable as Java for multi-platform use. You could do
2) Hospitals pay huge $$$ for integrated systems. As such, they will purchase hardware dedicated to your implementation. If your worried about running on their existing OSX servers, don't be - sell them a Dell running Windows 2003 or a black box running RH. Your software will be more expensive than the boxes. You could also just include $2-10K in hardware costs as part of the PO.
I highly recommend going to a trade-show or just talking to vendors "as a 100-300 bed hospital". You can see what others do by being a customer.
Not saying you have to do what everyone else does - but it does help to sell something that won't take a lot to get going.
FYI, here is a list of common technologies you will see floating around a typical community hospital:
.NET.
.NET, and that the question is kind of a moot point.
operating systems
digital HP Unix
AIX
VAX/VMS
Solaris
Windows 3.1, 95, 98
Windows NT, 2000, XP
programming languages
Mumps (ala the 'M' database)
CCL (fourth generation SQL-esque language)
SQL (a very little bit)
databases
oracle, oracle, oracle
some SQL
First of all, you have got to understand your (potential) client. Therefore, you need to understand FDA regulation of healthcare equipment, and of the HIPPA regulations. Because of FDA regulations regarding healthcare equipment, it often takes years (between 3 and 5, on average) for a piece of medical equipment to be designed, tested, run through trials, and (hopefully) approved. On the other hand, hospitals have a very steady stream of revenue, charge lots of money, generally have massive amounts of cash flow, and have major assets (like CT and MRI scanners, for instance). Therefore, it's common for a hospital to invest $1M for a new CT or MRI scanner at least every 10 years. However, that scanner had better be a workhorse for the hospital.
So, what this means for you as a developer is that most hospitals still have legacy systems in production that date back 10 to 20 years. As a systems administrator for the department of radiology at a local community hospital, my production environment involves:
> a Maxifile VMS/VMX terminal server running an 'M' database programmed in 'MUMPS'
> 6 oracle database servers which 100+ non-admin end-users log onto each day
> a remote-hosted oracle database which sits in Kansas (ala Cerner Corporation), which everybody at the hospital must access via a Citrix box.
> a nuclear magnetic resonance imaging scanner running VAX/VMS
etc. etc.
So, to make a long story short, if you want to develop products for the healthcare industry, you had better start thinking about how to interface with products from Oracle, Citrix, Cisco, Microsoft, and so forth.
Also, Linux is generally avoided in hospital settings. It requires too much computer knowledge (remember that hospital workers are healthcare providers, not information technology developers). More importantly, it's usually impossible to hold the developers accountable with Linux, and it's generally very difficult to obtain support contracts. All things considered, I have 1 linux machine in production, 200+ windows machines, and about 30 unix variations (AIX, VAX, HP Unix, DEC, Solaris).
So, all this being said, I think that you're barking up the wrong tree and not necessarily asking the right questions. Personally, I would suggest J2EE over
If you really want to start asking the right kind of questions, you could start with questions like 'should we start by developing an HL7 sniffer or a HIPPA auditing & compliancy application'? You would then find, either way, you will need to know Cisco (TCP/IP stacks), Oracle (SQL database connectivity), and HIPPA legal concerns (e.g. need for cryptography). In the end, you'll realize that you can do it in either J2EE or
anyhow, just my $0.02
I work for a very, very large insurance company with tens of thousands of employees, and several dozen million policy holders. At least 25% of the nation has auto insurance with us.
.NET in the enterprise for a while, until Humpty Dumpty (.NET) fell off the wall and all of Microsoft's Men and Women couldn't put it together again. For two and a half weeks customers were without quotes, or access to their policies online, and agents couldn't sell new policies or make changes to current policies. Customers were furious, agents were foaming at the mouth in anger.
.NET team flown in they couldn't get it working again for two and a half weeks. Eventually they had to rebuild the entire server room with new Windows installations on every server because they couldn't find out the problem. That might seem bad, but let me make note that the whole system was provisioned, installed, and maintained by Microsoft personnel. They broke it and they couldn't fix it for, say it with me, two and a half weeks. That should make it seem worse, but it still sounds better than it actually was.
.NET. We don't even get Visual Studio.NET installed on our development machines anymore. We have a very strong bad taste in our mouth from the whole .NET craze, which Microsoft is going very far out of their way to remove, without result.
We used
Two and a half weeks. With all of "the Shining Stars" of Microsoft's
A decision was promptly made to drop
We use J2EE and are very happy with where its going. Sun has spent a great deal of effort working with us to transition, and their support has been great. Our J2EE stuff Just Works. It works wonderfully. We are very, very happy with it. I'm using short sentences here to get the point across that we are very happy with J2EE. We've been using it for our web services and as our main development platform. We train on IBM's WebSphere Studio Application Developer, and it also is a great (but expensive!) tool.
I, as a developer, recommend J2EE. I do not represent my company in this recommendation, in case you work out who it is I work for. I am speaking totally on behalf of myself.
The company I work for is in the process of porting all of it's VB (.Net predecessor) software over to Java. The reasons are pretty interesting.
.Net, forcing a rewrite that will cost millions. Microsoft is infamous for churning its technology base, so they could easily do it again. Fool us once, we aren't going there again.
.Net (Mono is not even close to be considered - one patent infringement lawsuit from MS and it is gome). Java gives us access to just about any platform we are likely to need to deploy to.
.Net is famous for crappy performance on more than 2 cpus. Java runs great on big iron.
.Net's use cases are not.
- Microsoft essentially obsoleted our entire company's code base when they introduced
- Java has been around for 10 years, with many fewer technology upheavals.
- Java is multiplatform, much more so than
- Scalability.
- App servers - With MS there is one choice. With Java there are many vendors, with a vast range of product capabilities.
- Development tools - Just as good, wider variety and often far less expensive per seat.
- Maturity - best practices are fully understood, while
I've been with the company for about 3 years, doing both Software development and system support. During that time, most of my development has been in Java. I have yet to see any .NET development.
There may, in fact, be .NET development at Kaiser, but I haven't been able to find many references on the corporate intranet.
I would summarize Kaiser's software development as follows:
In the last few years, Kaiser has had an apiphany regarding in-house software development and now leans towards vended systems. But there is still a significant amount of in-house software development done to integrate these vended systems.
Hope that's useful.
-S
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