The Brazilian National Healthcare System, called the largest enterprise Java application ever built, has brought a valuable level of automation to the public healthcare system as well as the people of Brazil.

Brazil is one of the few nations in the world with a completely free public healthcare system. Like any public service of that magnitude, many operational problems exist. Parts of the system were largely paper based and very little integration was available between existing IT systems between the government and local health care providers. With these problems in mind, the building of a health care automation system called Siga Saude was commissioned. The system is designed to handle all aspects one could imagine in a public healthcare information system including scheduling and inventory management of doctors and equipment, billing, disease tracking, reporting/auditing, regulatory compliance, and security access control.

This case study takes a look at the architecture, solutions, lessons learned and future directions for the project.

The application is based on EJB 2.1 + Struts and utilizes a well defined layered architecture using established EJB design patterns including data transfer objects, session facade, service locator, and business delegates. Development was done in Eclipse, testing and deployment done on the JBoss application server. A rules engine (Drools) was used in certain areas, and the application is currently deployed non-clustered on a Dual Xeon 3.1 server with 4 gigs RAM, on Linux, running JBoss 3.2.7.

One significant lesson learned was that code generation is essential to a system like this.

Code generation was a key success factor on this project. It gave more productivity to the developers and made the code homogenous. Having an homogeneous code is very important when you have 50 developers working in independent teams, all of them sharing the same basic components. Using XDoclet, however, after a while, had an unwanted side effect, since the generation time took too long. Moving to annotations allowed to decrease generation time and still keep the benefits of code generation.

Other topics covered include:

• The implementation process of certain important use cases like scheduling appointments
• Using annotations to solve XDoclet drawbacks
• How a rules engine simplified business logic
• Future testing outside of the container
• Moving to a POJO-based architecture
• How AJAX simplified UI workflows

What do you take away from this case study? Have you implemented any of these processes yourselves? How would you have done what the Brazilian team have done?

FYI - You can also view the JavaPolis talk (Login required) from Fabiane on this project. Or you could listen to the podcast (Login not required :)

I beg to defer about the "simplicity" of the Rules Engine. Its syntax is quite confusing to be read. As usual, misused XML. I'm also not sure about the usefulness of this kind of Rules Engine. For me, it's just runtime-compiled Java code. It's like scripting. It's has not been used as a declarative rules-based engine, but simply as a XML repository of very procedural IF-THEN's.

yes it is... which is why we are replacing it with the new version (still can use XML, its just a little more helpful).

yes it is... which is why we are replacing it with the new version (still can use XML, its just a little more helpful).

Can you share how? I need to do the same thing.

Hi Mark. See Peter lins comment. Peter lin has been helping out - mostly complaining about maven and bad jokes (joke !) The difference between rules (declarative) and script is a fine line when your rules operate directly on objects - at tne end of the day it is up to the folks writing the rules and the object model as to how declarative it is (and it takes practice). It also means sometimes flattening your object model for the rules, which not everyone wants to do (hence things shift towards a scripting engine). Peter can explain it better then most. Cheers. Michael. project page: http://labs.jboss.com/portal/index.html?ctrl:id=page.default.info&project=jbossrules

Hi Mark. See Peter lins comment.

Peter lin has been helping out - mostly complaining about maven and bad jokes (joke !)

The difference between rules (declarative) and script is a fine line when your rules operate directly on objects - at tne end of the day it is up to the folks writing the rules and the object model as to how declarative it is (and it takes practice). It also means sometimes flattening your object model for the rules, which not everyone wants to do (hence things shift towards a scripting engine). Peter can explain it better then most.

Cheers.
Michael.
project page: http://labs.jboss.com/portal/index.html?ctrl:id=page.default.info&project=jbossrules

yeah, I bitch and moan about maven all day long. It's a nasty habit. But on the less silly side, the new drools3 has a completely new core based on some code I donated. Once drools3 is released, performance should be 20x better than drools2. in terms of rules degenerating to scripts. I've seen that happen first hand. the primary problem with rules is the steap learning curve. many people try to stick to OO structure with a deep object graph. that often works against rule chaining and produces inefficient rules. models that aren't too deep tend to work better because it is easier to take advantage of node sharing and rule chaining. although some products on the market today claim, a rule consultant isn't needed and that only a fancy spreadsheet is sufficient, that's far from reality. part of the job of a rule consultant is figuring what parts of the business process is inefficient or poorly thought out. it's the job of the consultant to help figure out how to improve the business process and produce good rules. only way that happens is close collaboration. tools help make it easier, but that's a small part of the equation. my bias 2 cents. peter

Hi Mark. ...

Well, I have a bunch of rules in XML files. Unfortanately it is somewhat difficult to see the bigger picture. My plan is to take the "lessons learned" and persist the structure so it can be designed and visualized by a non-Java developer. Sure, they will still need to understand some coding. I will probably use JGraph. I have a basic set of functionality that needs to be wired together with domain objects. It will be very specific to my domain. I don't see how it could be done in a spreedsheet, but it isn't rocket science either.

I beg to defer about the "simplicity" of the Rules Engine. Its syntax is quite confusing to be read. As usual, misused XML.

I'm also not sure about the usefulness of this kind of Rules Engine. For me, it's just runtime-compiled Java code. It's like scripting. It's has not been used as a declarative rules-based engine, but simply as a XML repository of very procedural IF-THEN's.

I totally agree that using a Rule engine isn't necessarily easy or simpler. The benefit of using a rule engine is that some of the logic can be written as rules and take advantage of rule compilation. Procedural if/then/else logic written by hand might be efficient or horribly slow depending on the developer. Using a rule engine, a rule gets compiled to the optimal form, so execution speed is not a significant risk. Of course, if the person writing the rule can't think clearly, then it really makes no difference if the business logic is in Java or rules. there are a lot of new features in drools3 that should help reduce the learning curve. drools3 also has a completely rewritten core, that should be comparable to commercial products. I sometimes contribute to drools, so I'm far from being objective. peter

Hi Joao, that's exactly what I thought when I first read about how Drools works: imperative Java code embedded in an XML file... Yes, "misused XML", again. I just can't imagine a worse debugging scenario. Regards, Cristina

Joseph, Having a houseful of Brasilians and traveling there often, I have seen this system firsthand. Its interesting that while most doctor offices don't have a computer, and use index cards to track patients, they have a smart card reader and keypad. It allows them to enter a billing code and track it to the patients smartcard. Very quick, efficient, and cost effective. The thing I find most disturbing, is that Brasil has implemented this system in such an effective manner, and the United States has NO CLUE. Billing transactions are immediate. No need for third parties pumping up the costs or even insurance companies! Everyone in Brasil has access to free care. You might want to get in line at the free clinic at 12AM if you want to be one of the few to get in. You are also limited as to what level of care is provided. Most folks subscribe to an optional ala carte plan, such as transplant option, surgery option, etc. All of these charges then are just a keycode to be entered when the patients card is swiped. This system works!

The application is based on EJB 2.1 + Struts

I'm not surprised they need that amount of hardware

non-clustered on a Dual Xeon 3.1 server with 4 gigs RAM, on Linux, running JBoss 3.2.7.

Spring/Hibernate rules :)

The application is based on EJB 2.1 + Struts

I'm not surprised they need that amount of hardware

non-clustered on a Dual Xeon 3.1 server with 4 gigs RAM, on Linux, running JBoss 3.2.7.

Spring/Hibernate rules :)

You are such a big fan of EJB's that you are not surprised that such a huge app can run on what in J2EE context is a very small hardware config ? :-)

Everyone in Brasil has access to free care.

Yippee, hooray, it's all FREEEEEEE...nobody pays. All the equipment, medicine, doctors, hospital, and nursing resources just come out of thin air.

Thanks for posting this article Joseph. Very well written with to the point information on all aspects of the project... Drools was definitely a good choice. I've used it on two projects and personally liked it as compared to other rules engines. Also, the side effects of XDoclets are good to know. I haven't had a chance to work on such huge systems where I could see this kind of effect of XDoclets! Good to know about this before hand! cheers, GT http://gautam_tandon.home.comcast.net