hello i am going to develop an EHR (Electronic Health Record System) i am new to this field and want to discuss and get the suggestion about what tool technology i have to use for this purpose:
here is my research about EHR and available tools for it
1) i am going to discuss about java as an EHR is a web based system so J2EE will be the solution for java at core level and as i am going to globalize my system so i need some standard protocol for it the most useful and appreciated one is HL7 CDA 2.0 one thing about java i like is it provides JAVA CAPS with full implementation of HL7 protocol. it make my work bit easy the second thing about java is it is very efficient for DATA CENTERED application as mine one is but the problem is with the scalability of system that is much expensive and time taking. and java is bit slower on client side that can effect downtime that should me very less approaching to zero for my system. and at last i need a attractive user interface. and the most wanted thing is privacy and security.
2) the other option is PHP for doing all as above described it is less expensive and less time taking for scalability,may contribute to achieve a good interface and a faster client side but question mark on data centric environment and security.
3) the last one is the MS's ASP.NET no doubt about security and privacy but very much expensive to develop and maintain and no platform independence and what about speed that is response and down times?
i have discussed the possibilities upto my best knowledge hope u people advise me which one will be the best to attain privacy, security, speed and scalability on best cost.
thanx in advance.
As an EHR implementor since 1983, I'd suggest you look for a language that provides a user interface that allows multiple inputs including keyboard, mouse, touch, voice and stylus, and potentially runs on multiple devices including phones and PCs. The server side if written correctly should not offer scaleability issues.
As for HL7, you're going to use that server side anyway so I don't think it's relevant to how you write your clients.
I'll start by answering your actual question. Any of those 3 languages could in principle be used for a large scale data-intensive application such as what you are considering. You may find it marginally more expensive in PHP, but it will make little difference at the scale you are describing.
If I were developing a EHR system I would start by looking at the legal aspects of it, then build the actual requirements, which I imagine would be a massive undertaking. Finally, I would just build it using whatever technology gave me access to a wide pool of skilled talent. The language will only really effect what talent you can hire in on short notice.
I hope I'm not being presumptious here, but it would appear, just from your question, that you have little experience with programming, the design of large systems, healthcare, the applicable legal framework or running an ISV. Do you have a compelling reason for entering this market?
Related
I'm going to develop an on-line IVR application using Java (without PBX).
In the software requirements there are some mathematical calculations and database communication which I prefer to implement on Java side.
As you know, different technologies are ready to integrate with Java, such as JTAPI, Zanzibar OpenIVR, Moho, VoiceXML, CCXML, Jive, Prophecy, Voicent, Voxeo etc.
Now the question is: What is the best solution? Which one is easiest to reach? Which one have the best efficiency? Do you recommend Open Source frameworks? Is there any Windows API for handling IVR systems?
If you're going to do VoiceXML with Java, you should take a look at Rivr, an open-source VoiceXML dialogue engine.
Rivr let you code your callflow naturally in the Java language. Thus you can reuse all the available Java tools (e.g. debugger, unit testing framework, coverage test tool) to develop the callflow. You also benefit from all your IDE features too (refactorings, source navigation, version control, etc).
The API is very simple. You can code a complete callflow with a single method. No need to define "states" or to manipulate templates or XML files.
Integration with server-side logic is trivial since you are only coding for the server side.
There is far too little information here to provide a direct answer, but I'll try to give you some basics.
The standards for IVR application development is VoiceXML for dialog (caller interaction) and CCXML for call control. The latter is not as commonly available. There are also numerous proprietary solutions. Your choice of an open standard versus a proprietary solution should be more about vendor/solution lock in. Even with the open standards, you'll likely use custom enhancements and have some amount of lock in, but portability will be easier. You can code directly to the telephony boards (challenging and usually poorly documented if you are someone new to telephony) or work with solutions that provide end to end capability. I find very few people porting IVR applications so I would focus on supportability of your application, features and ease of use in your decision.
Platform choices run the spectrum. You have premise (onsite) and hosted solutions. You mostly have high end enterprise solutions and low end solutions. There are very few middle ground solutions. Features (telephony and integration capabilities) vary dramatically.
From a telephony perspective, take nothing for granted. In particular, transfers. There are many ways to transfer a call. How it is done will be constrained by your connection. An analog line to the CO (phone company) can have multiple mechanisms and the one in place will typically be dictated to you. Not all telephony platforms will support what you need. Hangup detection, at least on analog lines, can also catch the novice out. Hosted solutions will typically allow you to avoid most of these problems. VoIP solutions are even more complicated due to compatibility between devices (yes there are standards, lots of them, with lots of optional parts and then there are custom flavors).
For windows specifically, you can use Lync, but it is complicated...though many of the solutions you will explore will be complicated.
In short, there is no best solution. Your knowledge of the technologies, requirements and budget are going to drive the decision. I've generally worked with enterprise IVRs in on premise and hosted configurations that are typically fronting large call centers. I have come in contact with many of the open source solutions. Anything on premise is likely to be complicated because of the system and telephony configuration. Hosted solutions have typically done most of that for you.
I know that those are "de jure standards". But you should also take Asterisk(with AGI/AMI) as a consideration for your project. If you decide to try Asterisk and Java, take a look of astivetoolkit.org it may be very helpful.
Ricky from Twilio here.
For me, picking the best tool for a particular problem is one of my favorite tasks a developer. One technique to figuring this out is blocking off a day and spending an hour or two with each potential option. A few question I'll typically explore:
Which tool is the easiest to get started with?
Which tool has the best documentation?
Which tool has an engaged community that I can learn from?
I'm sure there are a ton more questions depending on your scenario you'd want to explore (Does it fit within my budget? Can I use it with the technologies I already know and love?).
If you're looking at building an IVR, we have an API that could help. We just dropped some new tutorials including a non-trivial, production ready IVR application using Java.
I have sometimes seen that some applications that are built in php are comparatively faster than those that are developed in .net or java. I have seen some other projects also behaving same. Generally application built in .net are comparatively slower. Best example I have seen is facebook. It works well even if there is low connection or low bandwitdh but at that time other sites dont work. Does the underlying technology really matter??
Given a comparable level of skill for the people developing / operating the site, comparable infrastructure, and enough development admin time to optimize the system to the abilities of those people, then yes, it makes a lot of difference.
However, IME, the biggest differentiator between languages is not what their intrinsic perfromance, but:
the level and availability of skilled developers / admins
the amount of effort required to achieve a given end result
The lower barriers of entry to PHP programming compared with Java, means it is a lot easier to find a competent software engineer proficient in Java compared with one proficient in PHP, despite PHP skills being much more widely asserted.
OTOH, if you look at software metrics, PHP almost always trounces Java in terms of LOC/productivity. And unless you are Google or Facebook, salaries are a much greater cost than hardware - if it's slow, buy more infrastructure.
Don't get me started on .net
Hardly, its the type and quality of application that really matters.
What you could do is just create a test page, one that for example only makes one database call and display its output, in each of your languages. You'll notice they are fairly equal, the user wont notice any difference.
It all depends on the application, large complicated applications are often slower. There are many ways to optimize, in all the languages available.
Perhaps some languages and frameworks do tend to 'feel' slower, for example ASP.net is considered a bit bloated, and could feel slower. However a competent developer working on an ASP.net site will make it more performant then a less competent PHP developer.
Sure it matters. It all comes down on how fast and efficient your request can be processed.
Once the processing is done, sending back the website content will be dependent on your Internet connection.
However, the processing on the server side depends on the framework. If the framework is poorly implemented, then your website will respond slower.
Holla if you need more details.
We are designing a major webapplication for the www.
It a social community site. And I would like to know witch direction I need to take.
What works faster, flex and php or java and flex?
I've read that flex and php with amfphp is very fast (with AMFEXT).
But I have seen that 90% of the major companies here in Europe are hiring java / flex developers to develop major webapplications.
Our application needs to handle a lot of users at the same time.
Our application will be hosted in a datacenter later it will be hosted by a major cdn provider.
Our application has a video (streaming and progressive streaming) a shoppingmall and a community area.
Due to the nature of our business model we think that our application will attract a lot of users a day.
So we must have a webapplication that works very fast. With a strong technology on the backend. Java or PHP (amf support)
for the Database:
We will start with mySql and make the switch to oracle and then to sas.
What is the right direction for our application?
flex and java or flex and php?
I have no idea which provides "faster" execution - however, I do know that "faster" isn't the only reason to choose a language. Here's a general comparison of Java and PHP and here's another that compares Java, PHP and Ruby on Rails - neither one focuses on the language executing "faster".
Especially with Flex - you will most likely spend more time executing in Flex rather than in the backing server side language. Also, since the application is Flex - it should be possible to provide similar test implementations in PHP and Java and compare the results for your specific application.
The biggest part of the choice would be whatever language and platform your developers are familiar with.
This is a pretty subjective question. I believe that PHP tends to be a little bit faster but it really sort of depends on your applications requirements. From personal experience, I have been able to get more done with less code with PHP. Java has a much more strictly enforced object oriented approach which is actually quite nice whereas PHP is still lacking a bit in this area. For the most part, you will be able to accomplish the same things with both languages. I also feel that PHP has much better community driven support then Java which could be a factor. It really all depends on what you guys are most comfortable with. Both languages play well with Flash/Flex.
Java is faster than PHP in terms of pure execution time. Here is an interesting algorithm performance comparison that ranks a number of languages, showing Java to be approximately 300 times faster than PHP:
http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
With that said, this is NOT a good approximation of the speed differences for real-world applications. A major bottleneck will typically be your database. However if your application requires a lot of processing that doesn't occur in the database, you may see performance improvement with Java.
One advantage in terms of remoting is that Adobe offers Blaze DS which is a standard implementation of AMF for Flex. They also include some messaging capabilities ("data push") which I don't believe are implemented in AMFPHP.
Language choice is largely (though not entirely) irrelevant in terms of speed. Very large deployments have been built on both, and the speed factor comes from good architecture and code. So whether you go with php or java, hopefully there are good architects/designers/developers versed in the ways of writing for performance involved.
Java is always going to be faster than PHP, unless you have done something very wrong!
BUT...
The speed of the server side script won't really be noticed by the user, because so many other things add to the time it takes to get a response from the server (network delay, propagation delay, etc). To the user PHP and Java will seem equally fast.
To the server, however, there is a difference. According to your post you plan to have many concurrent users. If each user takes 20% longer to complete a request with PHP, then PHP can handle 20% fewer concurrent users. So if you worry that the server will fill up and run at maximum capacity, then I would pick Java. If you don't expect that to happen for quite a while, then I would pick PHP, based solely on performance.
Of course there are other things to take into account, like what you can do with each language, libraries available, developers available to/how well you know each one.
I would also strongly advice against changing anything backend once the system is up and running. If you start out with MySQL, don't change to Oracle half way. Either stick to MySQL, unless it becomes impossible, or start using Oracle from the beginning.
I would say, try both by doing a prototype ( e.g 3-4 pages ) for each language, and run a few performance test , overall should not take more than one week to do these.
Each language has its own pros / cons.
My organization has a lot of legacy ASP software on its hands.
Since our perception is that Microsoft has shown a distinct lack of support for its older products, we need to figure out what to migrate to next.
If we migrate to ASP.NET from Classic ASP, It feels like that'd be a 'complete rewrite' "migration". Since that is probably the case, we're thinking about turning to a free (as in beer and as in speech) platform. I particularly think our investment (in programming effort, I mean) would be better spent with a platform that will let us evolve, rather than forcing us to dump very single line of code every 4 / 5 years. This is the main argument we've been using to advocate moving towards a 'free' platform.
Currently we're thinking about using a mixture of Java with a dynamic language like JRuby or Groovy.
My questions are: What would be a good migration choice? Are our fears unfounded? Would we (conceivably) need to rewrite a large portion of the codebase after 4 or 5 years anyway? What arguments do you have for moving to either .NET or to a free platform?
We recently migrated a substantial ASP project to ASP.NET and it's definitely possible to do a migration that doesn't become a complete rewrite, preserving a susbstantial proportion of the original code (although we benefited from some fairly well architected code with good separation between the business logic and the presentation layers from the outset).
We looked at two possible routes to the migration:
A ground-up rewrite as a 'proper' ASP.NET application making the most of the built-in controls and shifting all of the business and data access layers into classes etc - ie the way we approach a new ASP.NET project.
A more basic syntactic migration, taking the ASP pages and changing them over to ASP.NET without making too many up-front changes to the structure or logic. Then building on that as we continue to develop the site by making better use of ASP.NET controls, separate classes etc for new and revised functionality.
Due to schedule pressures, we adopted the second route, allowing us to make the switch sooner rather than later and then take a longer-term view on more fundamental changes as part of future developments.
On that basis, for the initial migration we were able to re-use the majority of the existing code, although this is gradually being replaced as we go forward. With an 'average' page having, say, 50-200 lines of HTML and 50-500 lines of VBScript code (as separate functions, not mixed into the HTML spaghetti-style), we found it took about an hour per page to migrate them, including changing all of the ADO data access to a new ADO.NET data access layer. Some simple pages took just a few minutes - some of the more complex pages took a whole day - but about an hour a page was the overall figure across hundreds of pages, with the time to change the data access representing a significant part of the effort.
If we were to redo the migration today, we'd use ASP.NET MVC rather than web forms as it maps better to the way that the original pages were written - although I couldn't comment on whether or not a migration to MVC would take more or less time.
This doesn't necessarily have any bearing on whether or not you want to move to a free platform or change languages - you might have other reasons for wanting to do this. (Our client was Windows based so moving to ASP.NET, development time aside, carried no additional costs.) However, I can say that it's possible to migrate a substantial ASP site to ASP.NET without a complete rewrite - and it's equally possible to migrate from earlier versions of ASP.NET to more recent versions with minimal work. Obviously the route that we chose, preserving some of the ASP feel to the code rather than opting for a complete redevelopment, might not suit everyone - but it does give you a low impact entry point into ASP.NET that then allows you to build on that groundwork while making the most of your existing codebase and skills.
You know mono exists right?
I think you'll find that the longevity of a language is not as important as you think it is, since the lifetime of the major versions of an app is really quite likely to be less than that of most languages. And to be fair to .NET 2.0 -> 3.0 is a pretty small shift up, not a "dumping every single line of code" exercise. If you even wanted to shift up, which isn't really required yet.
I think a strong case could be made for any given platform you might consider, I'd look at other factors like your programmers comfort/skills/familiarity, community support, extensions, and fitness for purpose.
The choice lies in your company's ability to support whatever you choose.
Are you going to support the code yourselves? If so, what is your skill set base right now?
If you are currently enjoying ASP, ASP.NET (code rewrite or no) seems like the first idea to try, even if you don't realise it, by having used ASP thus far, you have probably acquired a great deal of knowledge in maintaining IIS, as well as the plethora of Microsoft based Services and Servers that you can reuse or at least easily adapt to, in ASP.NET development, deployment and support.
JAVA, RUBY, Whatever you choose, the beauty/usefulness/power/usability/durability of any technology lies on the people behind its maintenance.
The questions you should be making are:
best directed at your team
who will be developing, planning managing the resulting app/service?
Are you Ruby people? If not, do you want to be?
Are you JAVA people? same as above
are you....?
..and so on..
Don't distract yourselves with costs here and there or free versus non free.
when the technology is unknown/new to the people behind a project, man hours in support can be much more expensive than most packaged software solutions out there, which will then provide you with support.
This is also true for development environments where you have to pay more for the IDE/Server/etc, but on the bottom line you have less of a learning curve to go through and support at your level of expertise.
Besides: just like #annakata said, you have plenty of opportunities/projects to implement "free as in beer" ASP.NET functionality.. mono or not..
Example: you can set up ASP.NET service with Apache if you like that sort of thing..
Choose what technology you want to adopt by what you know and what you want to know, not what you think is the latest and greatest in buzz, specially if the whole reason why you even started thinking about rebuilding your code set is due to the lack of support for ASP from Microsoft.
I don't think you can escape the pain of migrating every 4-5 years given that the industry is in a continuous flux and tools, platforms and languages evolve to maximize efficiency. There's no guarantee that Groovy/Ruby/C# won't change to adopt the next big thing.
Personally I wouldn't lose sleep trying to 100% future proof myself. If that is the goal then you might as well use assembly and even then there's no guarantee that'll stay constant either.
Just consider the following
1) What do your guys know? If they are vb guys it makes sense to move to VB.NET
2) What budget do you have for tools?
3) Does the platform you want to move to have the stuff that you need? I remember some time back discovering with amazement Powerbuilder's support (or lack thereof) for regular expressions
4) Is there a community around the platform?
For a product in long run (may be 0.5-1 million users) is it good to use java instead of .net from the cost/profitability perspective. To elaborate more..consider web farm scenario in which one will have to purchase windows + Sql server + some antivirus licenses for .net applications. But for java it's almost free. What points should I consider?
PS: I am a .net person by heart
I would expect bandwidth to cost more than software licences is you're reasonably successful - although obviously that will depend somewhat on the kind of app, and I haven't run any figures.
Are you just starting this up yourself, with little firm idea that it will take off? If so, I suggest you go with whatever makes your life easier to start with. If things take off, you'll either have enough money to pay for the licences easily, or you'll quite possibly need to rewrite the app anyway. Writing an app which provably scales to a million users is likely to cause you a lot more grief than writing one which scales to 10,000. Get the app out there early, get feedback ASAP, and you can do what it takes if it ever becomes truly successful.
Go with what you know. With that many users price may not be important.
The first thing you should consider is the fact that you are a .net person. Java syntax is very similar, but it will take you time to learn (more importantly, become good enough to write an app this large) in a language you don't know as well. You should consider whether the savings are worth that time to you.
Also, keep in mind that there are many (legal) ways to get cheap (sometimes free) copies of the Microsoft software that you need, or the "lite" versions of the software that you need... which may be enough to get you going until your venture starts making money. So explore those before making a decision too.
License fee's cost less than a weeks pay for a development team.
Go with what you will be most productive in, and you'll save money.
Btw, WebSphere costs $1600 per CPU...Java isn't always free.
If you're a .net person, then stay with c#.net.
Whenever this topic comes up, I'm reminded of the part of yahoo that used to be written in lisp, and used lisp very effectively in its design.
http://www.algo.be/cl/TEE-lisp/3212824097309629/index.htm
Like others have said, it doesn't matter much what platform you choose, as long as you can use that platform well.
If you're talking about purely buying hardware it depends. You could run a Java web app for simply the cost of the machines if you decide to use open source software. However you could go with Oracle as your database and Weblogic as your App Server and then pay for it.
But most importantly, you say yourself you're a .net guy - so you'd have to have the intangible cost of however long it would take you to get to the point where you actually know what you are doing with Java. The syntax is very close, sure, but you have to learn which Java frameworks you want to use, which APIs you want to use, how to deploy to whatever App Server you choose, etc.
Joel wrote about this in Language Wars
How do you decide between C#, Java, PHP, and Python? The only real difference is which one you know better. If you have a serious Java guru on your team who has build several large systems successfully with Java, you're going to be a hell of a lot more successful with Java than with C#, not because Java is a better language (it's not, but the differences are too minor to matter) but because he knows it better. Etc.