Hardware needs for large company

Hey all,

I'm working on a capstone project, and we're (fictively) implementing a smart-card based health insurance system. I have one area I don't know too much about, and that's the hardware aspect of a project on this scale. What I'm looking for is someone who can give me an idea on what kind of hardware (from servers to firewalls and anything in between) we would need for what I'm describing below:

We are a health insurance company with 12,000 employees, $15 billion in revenue (2007), and 9 million members (insured people). We are implementing a smart-card based insurance system: every member gets a smart card (which will need either a PIN or a fingerprint scan), all health providers in our network (doctors, pharmacies...) will get a smart card reader which they can hook up to their PC, and the whole claims process will be automated (through 3M claims software).

What I'm looking for is the hardware infrastructure on the insurance company's side: what kind of server park does one need to store, maintain and process the health insurance information of 9 million folks? What kind of database solution? What kind of security? I'm looking for both general ideas, and for actual pieces of hardware.

Greatly appreciated!

http://www.novell.com/identityandsecurity/

I'd start here.

Hmmm,

750 members per employee???????????? hell, you must have a lot of sales drones in there:D

One very vital statistic that is missing is the number of claims and payments processed per annum.

What fields are there in the database per customer/policy? and how big is each record?

Do you have multiple policies per customer? if so, what is the average number?

Any need to hold data other than customer and policy?

What hardware redundancy is required?

Basically I would like to know what particular components of the insurance system are to be included. New business, claims, renewals, marketing solicitations? (I bet you have never heard of "spam" described that politely :lildevil:)

Any financial stuff involved (direct debits and such)?

Management reporting requirements?

I would guess that if the British IRS can lose the details of 25 million people on a couple of CDs, you don't really need rocket science?............. I would go RAID1 (cos I'm old fashioned), but a sprightly young thing like you would probably be tempted by RAID6.

What I am saying is that we need to know transaction volumes to suggest a hardware platform?

Any HIAPPA subtleties here?

OK, never done health insurance, but I have about 10 years experience in the sector in general ;)

I still stand by my first suggestion of starting out with Novel based on the fact that they have a crap load of stuff geared toward this very purpose..... They really need to hire me lol.

The link I posted to is the one for one of their areas in Identity Management and security. Also as far as I can tell I do recall Neg saying he has used SUSE before, so going with that on servers would probably be easier as well.

One I forgot to add in:

http://www.novell.com/systemsmanagement/

I'm pretty sure that would be another consideration in something of this size.

http://www.novell.com/products/

That's a list of products by category that you can look through, and I think I'd go with Novel for something like this. Not just because I'm buddies with the head of SUSE Security who does the patches but because, really, they do have some good stuff.

http://www.novell.com/products/edirectory/

eDirectory is a pretty good product from what I hear, and I've also read about it VS Active Directory which good results.

Access Manager is another you may want to look into as well. You can find that one here:

http://www.novell.com/products/accessmanager/

http://www.novell.com/products/identitymanager/

http://www.novell.com/products/audit/

Oh and http://www.novell.com/linux/security/apparmor//

That comes with the free downloaded OpenSUSE if you want a chance to toy with it. It's not hard to set up, and has a YasT2 module for configuration so it's pretty easy and nice to set up, and I'm assuming they want some type of protection like that.

Desktops are easy to handle, and with that you can pretty much just install it and set it up and let it go.

http://www.novell.com/products/consoles/

The ConsoleOne I don't have a NEW copy of, but I do have it here on DVD from Novel and it seems pretty straight forward too.

http://www.novell.com/products/opene...erver/ncs.html

OpenServer is basically what Netware became in case you want to go that route.

And of course; http://www.novell.com/products/groupwise/

http://www.novell.com/products/opene...r/ifolder.html

http://www.novell.com/products/jboss/

Paid desktops:

http://www.novell.com/products/desktop/

http://www.novell.com/products/openworkgroupsuite/

What I really love to toy with:

http://www.novell.com/products/server/

They also have Real Time:

http://www.novell.com/products/realtime/

I know that's a lot of links, and No, I don't work for Novel, though it would be nice.

anyway, I listed a crap load of links for products that you could look through with my suggestion being in there, and also they are pretty easy to set up and manage, so it's not like a huge learning curve.

Also, Novel pricing is much better than some others. I wanted to get a little server going to set up and toy with to teach myself some non home user parts of the IT world, and when I started looking around, I was looking at RedHat, Mandriva, everyone, and Novel was not only cheaper, but I know it better.

If I somehow grossly misunderstood what you were asking for and now look like an ass I'm sorry, I haven't been up for very long and I'm still waking up, but I'm pretty sure I put at least something useful in these posts somewhere lol.

More info would be nice though as Nihil said... Though I'm not sure about going with that particular Raid. I personally just set up a machine to act as a back up service and upload everything to it and then burn copies to CD and to a USB HD and then copy it over my network to another machine.

Quote:

---

Though I'm not sure about going with that particular Raid. I personally just set up a machine to act as a back up service and upload everything to it and then burn copies to CD and to a USB HD and then copy it over my network to another machine.

---

Yeah, but Neg~ did specify health insurance, so I was a little concerned about HIAPPA?

RAID1 is certain, RAID6 is only RAID5 with a mirrored recovery channel? (like you would use for HIAPPA or whatever?)

:)

Quote:

---

750 members per employee???????????? hell, you must have a lot of sales drones in there

---

That's the average I found for almost every major health insurance company in the US :)

Quote:

---

One very vital statistic that is missing is the number of claims and payments processed per annum.
...
Do you have multiple policies per customer? if so, what is the average number?

---

How about 9 million? Because of the nature of the project (more about the principles than about reality), we can make assumptions, so let's just assume that every customer has one policy, and every customer makes one claim per year.

Quote:

---

What fields are there in the database per customer/policy? and how big is each record?
...
Any need to hold data other than customer and policy?

---

Just the basics: 15 tables, anywhere from 2 to 15 or so records, with the longest one probably being a street name...

Quote:

---

Basically I would like to know what particular components of the insurance system are to be included. New business, claims, renewals, marketing solicitations? (I bet you have never heard of "spam" described that politely )

---

Spam function we don't need :)
We're just focusing on the claim function: customer ("patient") visits healthcare provider, healthcare provider files claim through the smart card system, we process the claim.

Quote:

---

Any financial stuff involved (direct debits and such)?

---

The only one is the payment to the healthcare provider (but that's not the focus of our project, so less important)

Quote:

---

Management reporting requirements?

---

For the sake of simplicity, I only implemented two time-based reports (automatic reports every day, one on claims processing effectiveness, one on customer profile trends, which can be customized)

And yes, HIPAA compliance is a must.

Oh, forgot to mention: I'd like to keep this Windows-based if possible :D

The obvious: we'll need a database server - and that's where I need help: what kind of hardware do you need to run a database that deals with this massive data need? What else is there to take into account?

Thanks for those questions, nihil :)

Gore > I'll have a look at those Novell links later - thanks!

Neg: A Database server is not my specialty or anything, but from school and so on, it seems to be more or less a machine with as much RAM as you can cram in it, and as fast a processor as you can cram in it, but in particular, FAST hard drives that can store data and retrieve it as fast as possible to avoid bottlenecks.

....Then again I just gave a bare bones outlook on every server you'd ever need too... But I do know a Database server is going to CRAWL without fast disks to keep up with transactions on the server, and of course having enough RAM and processor to power the thing. If I was hired to do a Database server, I'd probably first look at which database server / client set up was going to be used, check the requirements of that, and go from there, but I know for a fact I'd be getting the fastest disks I could get to be sure that isn't going to bottleneck.

There is an episode of BOFH where if you look between the jokes he basically gives you advice on setting up a database server. The fastest disks you can buy and as many of them as you can get so everything isn't stored on one disk causing another bottleneck, and also for bleeding file systems. That's why on Linux and UNIX machines you generally have each file system on a separate partition. This way you can prevent the one that's accessed 30 times a second from screwing with one accessed 30 times an hour.

So Neg..

You wanted Hardware advice.. how hard is the ware to be? From the service provider your looking at: the card reader.. Is it directly linked to the main server.. ? or is it connected to the Service Providers PC.. And as such you will have specific software there for the SP's records, and interfacing with their management soft.. The link from the SP premises to the HQ's main server.. is this on demand or live? is it internet, leased line, dialup or hispeed? At the HQ.. Do you have the one server handling Service provider transactions and all other functions.. (Sounds like a not so good idea to me) or Several servers handling the SP's transactions and this then replicates the needed data to the main DB/s From the HQ side of things.. You have various areas requiring access.. SP services Client Services Accounting marketing the question here is .. How will each of these acquire the data they need? Will they be domain restricted access? Will they just have a local client prog to access the data? or Will they use TSC (terminal Server) to access the software (this is handy but network intensive). This allows the software and data to remain on the server.. and the staffer is only viewing the data as video.. and reduces the storage need on the workstations.. reduces the amount of sensitive data on a workstation. etc etc.. Not much help.. just more questions.. sorry OH.. and sorry for the poor formatting.. trying workout how FF3 and the Forum soft get along

For a database solution Neg, have you looked into http://ww2.pervasive.com/Database/Pr...LOverview.aspx? May be too small for your needs, but the architecture is solid...

O

OK Neg~, please bear in mind that I can only speak from UK experience and our healthcare is rather different from yours.

Let's start with some basics? You will need:

1. A secure computer room(s).
2. Fire suppression.
3. UPS.
4. Disaster recovery facility, either at a remote location or brought onsite.
5. Local and remotely stored backups (secure).
6. Standby generator.


Your servers will need:

1. Multiple processors.
2. A lot of RAM.
3. Redundant power supplies.
4. SCSI drives.
5. Hardware RAID controllers.
6. Hot swappable drives.

If this were money market, stockbroking or commodity broking, I would suggest redundant servers, but in the case of insurance claims processing I would suggest that it is not so "mission critical"?

The last claims system I implemented was for 6,000,000 policies and about 500,000 claims per year. It ran on two IBM AS/400s with a staff of around 120!

Mind you, a claim was generally a single transaction unless it was someone's freezer that had failed, in which case there would be another claim for food spoilage.

I would imagine that in your case you are getting per visit claims from doctors/hospitals and per prescription claims for medication? That would greatly increase the number of transactions you will have to process.

When you suggest 9,000,000 "claims" per year, are those claims, or claim elements (transactions)? If they are indeed transactions, and taking the standard banking year of 360 days, that would give you 25,000 transactions per day, which is not a particularly heavy load.

I would guess that load balancing will be your main issue, which will depend on your communications and how your system works. For example is it "trickle feed" in real time, like an ATM or do the providers submit in batches?

Thanks, all - these are all great suggestions, and I'm going to start looking into everything!

OK, so let's assume 25,000 transactions per day (trickling in, not in batch) - what kind of (hardware) database server should I be looking at?

Sorry Neg~ I really am not making a good job of this one:(

OK, we have 25,000 transactions per day. I would guess that to be 8 hours, although you might get a bit more mileage if you cross time zones (see? typical bloody European, I forgot to ask that:D)

That covers the intake of claims, but what is the claims processing mechanism and its requirements? I am guessing that when you accept the initial entry, you validate that the policy exists, is current and that the item is covered?

All that you need then is to update the payment process record? Whilst actual payments will be in your finance system (I would imagine?) you still need an interface to generate a record of the indebtedness. That I would suspect could be run as a batch job?

I am afraid that I really need to get a grip on the degree of integration and segregation here? Like will you have all the policy data on the claims database?............... what I am asking is just what data do we need this server or servers to handle?

Also, am I correct in assuming that the reimbursements will go to the service and goods providers rather than the patients?......yes, I would siphon that through accounts payable, but I need to interface and create a record?

Right now I am looking at a single server with 4 Xeon equivalents and maybe 6 SCSI drives.................

I am assuming a third normal form, or maybe 2.5 normal form database? and not a lot of metadata?

Basically your policy data is just a glorified lookup table that you update in batch overnight? That is the bulk of your data holding, but is relatively static?

BTW we need to talk a bit more on reporting and internal audit reports;)

Given that this site is open, you may want to PM me, as I do not know if this exercise is competitive or not?............... actually they usually are, because you take the best answers and mark down from them?

Please pass my regards to Mel, thanks

Johnno

Yes, all policy data would be on the same database, and reimbursements go to the health provider. Third normal form, no metadata. Anything outside of the claims process (such as reporting and internal audit reports), we can ignore :)

So, a single server (Windows Server 2008, SQL Server?) could run this thing without too much trouble?