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?"
Don't ask us. You know the client better than us
.Net to be quicker for developing business applications. The Microsoft CLR also seems to have better performance than most JVMs I've seen.
I couldn't agree more!!
IMO, I've found
I'm sure there are plenty of Java developers with the opposite opinion... this is just my $0.02.
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.
And the answer to your question is J2EE. Simply because you can run tomcat, struts and jstl alongwith a local copy of mysql on any old machine. If plans called for scaling (like heavy weight centralized database using oracle) you can do that, if plans call for scaling the app and port to heavy weight app servers you can do that. With MS, your entry point is your max scalable point and there is no scalability.
.NET is easier than J2EE/Struts/Swing at the moment. However this is rapidly changing with new toolkits from IBM and BEA (for websphere and weblogic).
I WILL grant you that developing UI under
Have fun,
Another one of them H1Bs taking american jobs.
Faraz
Java is not that slow. In ye olde days it had a pretty high memory overhead--it still does--but who cares anymore? Memory is cheap and expansive, and (rightly so) people would rather have security and dependability.
.NET simply because of maturity and to stay away from a dangerous MS. We all know that MS has the balls and the market share to squash an enemy by any means necessary, even if that means doing something nasty with .NET. Sun doesn't even has this option. I'm not sure if they have the balls, but they sure don't have the market share. It is in their interest to make Java a viable competitor, not a tool for entrenchment. Their biggest conflict of interest is probably in offering Java for Linux which competes with Solaris. Obviously they are not in a position to withhold support.
I would choose Java over
While I don't have extensive experience with it, you could compile your Java into native binaries...see GCJ and JET.
That having been said, I would definitely consider some of the options presented that do not fall in the binary choice you have presented us.
Finally, while I have not done so personally, my cousin's husband works for a company that develops their product in Java, but apparently can, with not too much trouble, use some automated tools to generate C# for the occasional dead-set MS customer than they come upon now and then. I don't know if tools to perform the inverse exist. He made C# translation sound like fairly trivial an issue for them.
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.
1. It is possible to build faster applications using a language that compiles to native/is not interpreted. Though Java is not much slower (if slower) than other languages when implemented with this in mind. For a really slow technology try microsoft distributed queries.
.NET applications. And all technologies are only secure as the code that was developed and the architecture that they are run on. You don't have to run .NET on windows, try it with mono.net with a LAMP(ish) server build.
2. It is possible to build very slow
Upfront statement: .NET on campus, and am currently not paid for this position. So, in a nutshell, I basically promote the technology because I really like it. However, I think Java's pretty cool too.
.NET - I've seen even some grad students putting together a pretty awesome application in C# .NET for a programming competition that was aimed at the health care industry and had great acceptance with the hospital. The development time is quicker (especially in VS.NET), there are definitely security/cryptographic libraries implemented, and there is a huge open-source community built around .NET programming.
.NET framework has been ported in a large part to *nix with the Mono project and has been used quite successfully in Munich which has recently ported to Linux by a company called Volcker.
.NET and .NET was much faster and much cleaner as well. Plus, you can inherit from old C++ classes and leverage existing code/libraries in your new application.
I'm a Student Ambassador to Microsoft, I've been promoting
My thoughts are that yes, it will definitely work in
Also, the
I've developed GUI applications in both Java and
This sig donated to Pater. Long live
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
Instead of re-inventing the wheel, get involved in open-sourced solutions. You can find a good list here.
From this list, I have personally only seen VistA which has been used by the Veteran's Affairs Department for a very long time. Certainly long enough to mature. It's scalable and will work with groups of hospitals. It's designed by Doctor's to fit the way they work and it's easy to use (so Doctor's have told me). It's open source, and there's a community web site.
There are cons though: It uses a little-known programming language called M, and although otherwise complete, does not have a module for paediatrics (it's very hard to find child veterans!). The people I have met have been extremely helpful, however, and will help you with any customization or new capabilities.
Again, that would be HIPAA - http://www.cms.hhs.gov/hipaa/. I love the fact that we have all these programmer/engineers/designers who can throw around a host of programming metaphors and every buzzword in the Buzzword Bingo game card and yet can't remember that it's HIPAA (Health Insurance Portability and Accountability Act) not HIPPA. I guess it doesn't surprise me since a good 3/4 of the healthcare providers and health organizations out there have pages on the internet that mispell it.
What cracks me up even more is the people who refer to it as the Health Insurance Portability and Privacy Act (OR Health Insurance Privacy and Portability) and the use the abbreviation HIPAA.
It's only been around since 1996 - you'd think sometime soon some consistent use of terms would emerge. But what the fuck, it is the healthcare industry after all.
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
If Java is not slow, then how come every Java app I use at work just frickin' CRAWLS compared to similar software written in native code, and generally takes up at least twice as much RAM to boot?
My real world example for showing why I don't like Java at work:
Step 1: Start up Excel. Load about 20 massive spreadsheets. Also start up Safari and Firefox. And get some MP3s playing on iTunes. And start XCode and tell it to start compiling the app I've been working on. Go back to Excel, and start futzing with the spreadsheets. Did I mention that those spreadsheets have multiple worksheets and cascades of formulas all over the place? Anyway, notice how the computer is slowing down, but it's not ready to die or anything.
Step 2: Quit EVERYTHING. Load up the Java PDF viewer whose name escapes me because I got rid of it a couple months ago. Watch the program take about 40 seconds to load. Open a 20-page PDF file, watch it take even longer to display. Listen to the hard drive make a bunch of unholy noise the whole time. When it comes up, scroll the PDF. While it's struggling to draw the next page, try clicking on the Finder and see if a Finder window comes up anytime soon.
Yeah, I've heard that the OS X JVM is slow. I think that it's still a hit against Java, because the only strong reason I can think of to use Java for things other than applets is its platform-independence. For that to be a good argument, Java has to be viable on a whole host of platforms, not just Windows and (I assume), Solaris. So if you want multiple platforms, Java is slow because it sucks on most platforms, and if you only want one platform, Java is slow because you might as well be writing native code.
The McKesson Horizon suit of products (clinical) all have a J2EE future. Right now availability is a top concern for those of us deploying clinical systems and evaluating vendors. A portable solution is important here because it allows the IS shop to determine which scalability/availability solution best fits their budget.
If you are creating fat clients, .NET is the way to go, most likely. If you want web based, J2EE has a lot of open-source compenents you can use to get your application networked via HL7 .NET nor J2EE, rather it is PHP/MySQL
HAPI is a java-based open source HL7 library:
http://hl7api.sourceforge.net/
JEngine can quickly route HL7 messages to & from your application:
http://jengine.org/
If your software is open source, or you can use open source components, OpenEMR can give you a leg up for clinical demographic and medical data management. It's neither
http://www.openemr.net/index.php
If you will be interfacing to large hospitals or medical centers, you will most likely bump into Cerner http://www.cerner.com/ or McKesson HBOC http://www.mckesson.com/homeflash.html. While these companies are a bit out of scope for your question, you might want to reserach them as they are the biggest players in the field. Good luck, it is an interesting time in the health care IT field.
I am currently working on a project for a software company that sells to the health insurance industry.
In developing this project I've had contact with a lot of the largest health insurance companies in our region.
What I have found most of them have in common is a mixture of J2EE and ColdFusion, almost exclusively. It appears that dotNet hasn't made the inroads with the health care industry that they have with other corporate clients.
Holmes
Both .NET and J2EE can be made to work. In the UK (where I live) the National Health Service has launched a programme to provide nationwide healthcare record integration. It's going to be expensive (around $6bn so far and some projections estimate a total cost around 10 times that). However, it'll be the first such system in the world and will have useful patient benefits (e.g. get admitted to A+E - the ER for US folk - and the doctors there will be able to access your medical notes even if you've never been to that hospital before). More detais of the programme here and here.
.NET, and the national facilities (which provide services for all 60 million patients [approx]) are mostly built using J2EE on Oracle on Solaris. At the moment, the middleware is SeeBeyond e*Gate.
.NET 1.0 with other things using SOAP - it doesn't seem to interoperate well. Maybe that's fixed now though.
As for what technologies are in use, the local service providers (of which there are 5 with about 12 million patients each) are mostly using Microsoft-based solutions, mainly written in
Speaking personally, I have had difficulty integrating
All you need for running .NET apps is an implementation of the .NET Framework (be it the MS one or Mono).
Yeah, that's extra crap but not more than you would have with a Java solution.
When developing code we often forget the longer-term impacts that often hinder us later.
Take Java versus .NET. If I develop in Java then I don't have to worry about doctors who might want to use it on a Apple OS/X. If the world goes Linux it runs on Linux. Or perhaps some new tablet PC is running BSD or Linux. It may not even seem important now but going .NET limits you.
Very few programming projects are truly unique, as they often borrow source or copy the logic of existing systems. Would it not be nice if you could share the source code between Windows, Linux, OS/X, AIX, Linux, BSD, HP-UX and Solaris? If your shop only runs Windows now can you say this will be true for 2, 5 10 years down the road?
Even if you are a Microsoft only shop, you can borrow source code from Open Source Java Linux projects to help with the coding. .NET does not allow you this.
Having such a broad range of platforms it runs on generally means the programmers are more skilled and more source code is available. More skilled programmers often produce programs that crash less lowering maintenance and increases user service. .NET does not offer any of this.
Why .NET then? It's best redeeming value is that it takes lower skilled programmers and locks in that you must use Windows to run it. Although the product is OS bound and perhaps even less reliable you may have the skill sets to do it faster. If Microsoft jumps the price of their products you're stuck with it as you would not want to pay the price of re-coding all your projects. Techno-lock in if you will.
In a hospital, information security must be an issue. If you go just by the numbers on CERT or other vendor independent source .NET and Windows itself are relatively insecure when compared to other options. Java is by no means 100% secure, but at least it began its life with security as part of its design. In Java, security was not an afterthought or refit.
Historically languages like Java will last a lot longer than .NET. This lends longevity to code and effort. From your career point of view, would you rather hedge your skills on something that is OS independent or sink your precious learning time into a vendor slotted technology where if they fail you have to re-learn something else. We often forget it takes years of effort to become really good at a programming language.
Java offers a lot. If your manager does not use Java over .NET then he should have to back it up with some good reasons beyond his knowledge that one of his mutual funds just happens to own some MSFT stock.
We develop applications for health insurance (HIPAA compliant) at zeomega. These applications involve patients payors and providers alike so lots of PHI. we use FOSS platforms zope python ingres postgres mysql on linux runs like a champ , cuts down development time in half as python is easy to learn and program in. we used to do development on websphere before. not anymore. as far as .net goes ugghhh we dont want to wait for support on an 800 number helping some idiot thousands of miles away to fix his own bugs and dont even get me started on the security nightmare
I work in the SouthEast now. I'm not directly envolved in software development for the medical industry but I do keep my eyes open. Most medical systems that are doing modern development have chosen J2EE over .Net and I have no clue as to why.