Slashdot Mirror


DoD Ditches Open Source Medical Records System In $4.3B Contract

dmr001 writes: The US Department of Defense opted not to use the Department of Veterans Affairs' open source VistA electronic health record system in its project to overhaul its legacy systems, instead opting for a consortium of Cerner, Leidos and Accenture. The initial $4.3 billion implementation is expected to be the first part of a $9 billion dollar project. The Under Secretary for Acquisition stated they wanted a system with minimum modifications and interoperability with private sector systems, though much of what passes for inter-vendor operability in the marketplace is more aspirational than operable. The DoD aims to start implementation at 8 sites in the Pacific Northwest by the end of 2016, noting that "legacy systems are eating us alive in terms of support and maintenance," consuming 95% of the Military Health Systems IT budget.

186 comments

  1. A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 5, Insightful

    Jesus Christ what a waste of money and to the worst possible people.

    1. Re:A consortium of Cerner, Leidos and Accenture by invictusvoyd · · Score: 3, Interesting

      We are deeply grateful to Source Forge for providing us with our place in cyberspace for this web site.

      http://worldvista.org/AboutVis...
      Agreed, but this sounds kinda weird too

    2. Re:A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 1, Insightful

      Their only noncommercial option was the VA's VistA, requiring constant redevelopment to meet federal HITECH and ONC mandates and built entirely around a 1960s-era "key-value" database language called MUMPS. If you're a migraine enthusiast, enjoy night terrors, or otherwise are in the market for a drinking problem I recommend learning MUMPS.

      Here's a high-level summary of MUMPS:
      There is no database. Everything is stored in a multidimensional array. There are no ints or floats. Everything is stored and retrieved as a string. There are no reserved names because the entire language is context-based. There are no tables, tablespaces, or schemas. Everything in the global array is persistent and is saved directly to a disk. All program code is stored and executed within the global array alongside production data. Scared yet?

      P.S. MUMPS is also the underlying database technology of the other DoD front-runner, Epic Systems, widely regarded in the industry to be the most expensive EHR software ever developed. So all things considered, I think the DoD could have done worse.

    3. Re:A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 0

      you are an idiot and are full of shit. you should feel bad about it and stop posting.

    4. Re:A consortium of Cerner, Leidos and Accenture by Blaskowicz · · Score: 1

      There are no tables, tablespaces, or schemas. Everything in the global array is persistent and is saved directly to a disk.

      So the bloody thing is NoSQL and ready for the biggest revolution in computing soon hitting the market - persistent memory such as Memristor and 3D XPoint.

    5. Re:A consortium of Cerner, Leidos and Accenture by arglebargle_xiv · · Score: 5, Insightful

      A large-scale medical records system, a multibillion-dollar IT project, and companies like Accenture doing it, it's like combining herpes, syphillis, and gonorrhea and hoping you'll get a cure for cancer. Any of of those in isolation is pretty much pre-ordained to fail, and they're combing them all into one massive clusterfsck... why don't they just declare failure in advance and save the years of effort (and money).

    6. Re:A consortium of Cerner, Leidos and Accenture by Bonzoli · · Score: 1

      this is about acquisition officers future employment folks. Move along.

    7. Re:A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 0

      Let the ad hominems flow like wine. Fellow AC, would you care to fill us in on how wonderfully awesome MUMPS is and why it's literally the greatest thing ever?

    8. Re:A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 0

      "MUMPS" (or M as we call it) is also how one unfortunate Epic employee deleted the entire production environment of a massive hospital in the middle of the day by entering the command "k ^".

      ask me how fun that day was.

      go on, ask.

    9. Re:A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 3, Informative

      You obviously don't know anything about MUMPS.

      I'll just discuss these specific points:
      - It *is* a database.
      - The "multidimensional array" is some sort of b-tree, the same kind of approach that is used by an RDBMS.
      - The language is dynamically typed ("no ints or floats"), which in practice means it's like working in Python or Perl. Internally, numerical data is stored in a numerical format for efficiency.
      - There's no need for reserved names, that's correct. Nonetheless, coding practices dictate that you don't name a variable "if" or something silly like that.
      - There is a schema.
      - Yes, a "global array" is a database object so of course it's stored to disk.
      - "All program code is stored and executed within the global array alongside production data." It's stored in a specific location (outside the database schema) that's dedicated to program code. These are basically stored procedures. I imagine every database you're familiar with also keeps its stores procedures in the database.

      I could educate you more thoroughly, but it would be a waste of my time.

    10. Re:A consortium of Cerner, Leidos and Accenture by Trax3001BBS · · Score: 1

      You obviously don't know anything about MUMPS.

      - There's no need for reserved names, that's correct. Nonetheless, coding practices dictate that you don't name a variable "if" or something silly like that.

      A variable of NULL would have no problems? As time goes on people are not aware.

      I've nothing against MUMPS and your write up informative but that one line caught me.

    11. Re:A consortium of Cerner, Leidos and Accenture by JustAnotherOldGuy · · Score: 2

      So...you're saying it's webscale? Thank god, because we were just about to do it the old-fashioned way so we would end up with a working product before the end of the century.

      --
      Just cruising through this digital world at 33 1/3 rpm...
    12. Re: A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 0

      NULL (undefined variable) is no problem in M, you can test for existance (as you should in any language) with $DATA(var) if a variable is defined or use $GET(var, default value) in case a default when undefined is desired.

    13. Re: A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 0

      Sorry, just realized that your question was about the name, not the content.

      Nevertheless: no problem, you can name variables as you like - there are no reserved names in M, with the exception that everything starting with ^ will be global on disk instead of local to the process.

    14. Re:A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 0

      Epic Employee indeed.

      How fun was that day btw? Would have loved to be a "fly on the wall" when the management found out LOL

    15. Re:A consortium of Cerner, Leidos and Accenture by K.+S.+Kyosuke · · Score: 1

      That a pointless question since if you have a brain, you're trying to avoid NULL in any form like the plague, so the variable name is free. ;)

      --
      Ezekiel 23:20
    16. Re:A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 0

      The drive through campus to get to any of the buildings is an Epic clusterfuck as well. All that land for merger lanes from the parking garages, and they have none. Not to mention dumping several thousand employees into a residential 25mph 4-way intersection with stop-signs. Fun stuff.

    17. Re:A consortium of Cerner, Leidos and Accenture by davester666 · · Score: 1

      It gave me spots all over, and I still lived!

      --
      Sleep your way to a whiter smile...date a dentist!
    18. Re:A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 0

      Lobbyist win again !
      About $400,000 worth in 2014-2015

    19. Re:A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 0

      Same AC here.

      NULL is not even a keyword in MUMPS, so that would be a total non-issue.

      The null value in MUMPS is the empty string "", which seems like it could be a problem but in practice I've never found that it is. There's a special function $DATA that distinguishes between the null value and absence of any value at all (e.g. if a variable is uninitialized). Usually, though, you just rely on a test for (x="") and, since the language will convert a non-existent value of x to "" in this context, you can ignore which one you're working with and pretend that all uninitialized variables are initialized to "". It's something you have to be mindful of but certainly no worse than working with NULL in SQL (which requires constant vigilance).

      The syntax is structured such that there is no ambiguity about whether a particular word is interpreted as a keyword or a variable name, that's why there's no need for reserved words. You should ideally be using an editor with syntax highlighting to help further to avoid confusion.

      The syntax IS pretty horrid, but the particular aspects of it mentioned above are not especially loathsome. In fact I despise MUMPS, I just prefer that people attack it for the right reasons instead of reposting some misinformed nonsense that they read in an old Daily WTF post.

    20. Re:A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 1

      It guarantees that the DoD managers of this project are guaranteed private sector jobs for life after they leave governmental "service"... Ain't the revolving door nice?

    21. Re:A consortium of Cerner, Leidos and Accenture by lsatenstein · · Score: 1

      Jesus Christ what a waste of money and to the worst possible people.

      Think of the money you can earn, working to fix the consortium's system and then a contract to convert their systemto the open source version.

      Wow, A cast of hundreds with salaries to three times the norm.

      --
      Leslie Satenstein Montreal Quebec Canada
    22. Re: A consortium of Cerner, Leidos and Accenture by Anonymous Coward · · Score: 0

      "(and money)"

      I think your answered your own question there :-)

    23. Re:A consortium of Cerner, Leidos and Accenture by terjeber · · Score: 1

      Isn't it more like getting infected with Ebola to cure the common cold. Sure, it kills the cold. And the host.

  2. DoD by Anonymous Coward · · Score: 0

    Drink or die ?

  3. 300 million for the hardware/software/salaries by Anonymous Coward · · Score: 1

    4 billion leftover for all the people in charge.

  4. Trading one for the other by grilled-cheese · · Score: 4, Insightful

    It's interesting how they see integrating legacy systems any differently integrating just as many differently implemented commercial record systems. The data integrators will make the same money either way. By abandoning the open-source solution, you're just losing the possibility others might benefit from the work. Likewise, I'm curious how much those 3 vendors have lobbied in Washington DC.

    1. Re:Trading one for the other by Anonymous Coward · · Score: 0

      A lot of patients will move from DoD to VA as they leave the services. Interoperability that way should have been most important.

    2. Re:Trading one for the other by Anonymous Coward · · Score: 1

      I know people working on the veterans affairs stuff... if they made this choice, they didn't make it lightly...

      In particular their legacy system was a crap ton of post-it notes stuck to computer screens.

      The Obama administration has gotten a lot of help from Google's SRE groups moving in to help fix the government with everything they learned at Google. These are not bureaucratic choices being made, they're Google SRE choices...

    3. Re:Trading one for the other by drooling-dog · · Score: 2

      I have no knowledge of the particulars in this case, but lobbying isn't even really necessary. It's often just the revolving door: The procurement people on the government side now have very lucrative careers in the private sector to look forward to, and that is something you can never get by going with the open source solution. But who knows, maybe this time they did make the call purely on its technical merits.

    4. Re:Trading one for the other by Anonymous Coward · · Score: 2, Insightful

      The open source solution was not a good one in this case. You can have religious wars all you want about which language is best, but when striving for worst, MUMPS is a real contender. Please don't copy the database structure of VISTA. It's utterly useless for data integrity -- imagine a database where every field is a string. There are no numeric fields...and what happens? Oh.

      The biggest problem is that the DoD lacks the organizational and technical skills at higher levels to use anything other than a defacto standard. They need something akin to RFC's, but that is not the military way.

      The $9B price tag is actually reasonable for a good implementation and rollout. We know history too well: no one will see anything from the project for 10 years, and it will be rolled out on top of a lackluster Oracle database and dozens of middleware pieces that will ensure the system remains more expensive than current operation costs forever. And it will probably be less functional that what it replaces.

      It's a shame that such big consumer lacks the power to make a difference in the market by developing and promoting good standards.

      Yes, I'm bitching. I've been in the system long enough to lose hope.

    5. Re:Trading one for the other by phantomfive · · Score: 5, Insightful

      Regardless of whether they are starting with open source software, or closed source software........if I ever paid $4.3 billion for some software, I guarantee I would be getting the source for it. If the government pays that much for a system, one of the requirements should be that it ends up open source.

      --
      "First they came for the slanderers and i said nothing."
    6. Re:Trading one for the other by Fire_Wraith · · Score: 2

      It's not necessarily even corrupt, for that matter. It's about having the personal relationships, and moreover, knowing how the labyrinthine mess that is the DoD Acquisition process works. The rules are intended to keep it fair, but at the same time, also wind up pricing a lot of the inexperienced sorts out of the process simply because you have to know what language to use, how to structure it, etc.

    7. Re:Trading one for the other by gtall · · Score: 1

      And if DoD decided to do it inhouse, the libertards would be hanging from the lampposts crying the blues about big government.

    8. Re:Trading one for the other by Anonymous Coward · · Score: 0

      A lot of patients will move from DoD to VA as they leave the services. Interoperability that way should have been most important.

      Interoperability that way is considered to be a requirement levied on the VA's medical records system.

      Not joking. Perhaps the only good thing about that is that the VA agrees it is their responsibility.

    9. Re:Trading one for the other by j-beda · · Score: 1

      Regardless of whether they are starting with open source software, or closed source software........if I ever paid $4.3 billion for some software, I guarantee I would be getting the source for it. If the government pays that much for a system, one of the requirements should be that it ends up open source.

      At least.

    10. Re:Trading one for the other by Anonymous Coward · · Score: 0

      Note also that much of EPIC's system runs on MUMPS, nicknamed a write-only database. Though, (whether you intended it or not), your description of Cerner's system as a lackluster Oracle database and dozens of middleware pieces is pretty apt, too.

      Most EMR systems are train wrecks. It's amazing more people don't die.

    11. Re:Trading one for the other by CaptQuark · · Score: 1

      Why? The government is buying a service, not a software package.

      Imagine if the government contracted Gmail to provide unclassified email for the entire DoD for 10 years for 4.3 billion. (2 million active and civilian accounts x 10 years = $215 a year per account.) Why would DoD want the source code for Gmail just because they are paying for the service? DoD isn't going to turn it into open source and they certainly aren't going to try to maintain a separate Gmail system. Google isn't going to bid $215 per account if they have to release Gmail into open source. In this fictitious example, DoD is paying Gmail for a proven email system and the personnel to keep it running, up to date, and secure.

      Similarly, if GSA contracted Ford to supply, maintain, and refresh every government vehicle, do you think GSA would demand the design and engineering specs for every vehicle it leased?

      In most cases the government is paying for a service because it doesn't WANT to own or maintain something that is already a mature civilian industry.

      --

    12. Re:Trading one for the other by phantomfive · · Score: 1

      When things go right, you don't need the source code, but when things go wrong, you'll wish you had it.

      Also, as to your gmail example, if the DoD plans on storing medical records in someone's crappy 'cloud,' they are giving themselves even more problems. You want to be able to control that data.

      --
      "First they came for the slanderers and i said nothing."
    13. Re:Trading one for the other by CaptQuark · · Score: 1

      When things go right, you don't need the source code, but when things go wrong, you'll wish you had it.

      Again, Why?

      Do you think DoD is going to tell the company how to rewrite the code to fix it? When you write the contract you put in performance specifications (remember five 9s?) and penalties for non-compliance. You don't spend months reviewing the vendor's software code to find edge cases that cause problems. DoD is paying them for their expertise, manpower, and infrastructure that DoD doesn't have to maintain.

      --

    14. Re:Trading one for the other by phantomfive · · Score: 1

      In their case, it will allow them to switch vendors more easily.
      Also, programmers write better code when they know people will be looking at it. The open source method for motivating better programming.

      --
      "First they came for the slanderers and i said nothing."
    15. Re:Trading one for the other by Anonymous Coward · · Score: 0

      $4.3 billions... for an IT project... seriously? And you still ask "why"? They may as well hand over the whole company to the government for that amount of money.

    16. Re:Trading one for the other by Anonymous Coward · · Score: 0

      No, you're missing it. The systems in question almost integrate for free. It's a trivial cost.

      Just sign here. Trust us. Fixed price contract? No, no, we won't be needing any of that. Just don't worry about it. Hey, look, the Congresscritter we paid even agrees with us. Better sign or maybe your base will lose some funding. No one would want that!

    17. Re:Trading one for the other by K.+S.+Kyosuke · · Score: 1

      It's utterly useless for data integrity -- imagine a database where every field is a string. There are no numeric fields...and what happens? Oh.

      Somehow I don't think a computer system should have a problem with this. Ultimately, in every computer system, every field in a database is an 8-bit string. On some kind of disk. ;) Actual lack of checks is what would give you problems.

      --
      Ezekiel 23:20
    18. Re: Trading one for the other by Anonymous Coward · · Score: 0

      You would do that to sustain the "industrial base" so you can get a semblance of support when one of the vendors goes belly-up.

    19. Re:Trading one for the other by Anonymous Coward · · Score: 0

      I will tell you one reason why Epic in particular likes this aspect of MUMPS. Every hospital thinks they're special. There's always this one damn organization that insists that their IDs have to have an A or M or something in them when everyone else is using numbers.

      So, when fields are not strongly typed, you can support this without a massive data conversion.

      Epic's fields actually have types specified, but they are not typically enforced. Yes, it does cause problems. But no, they are not really MUMPS problems, they are application-level problems, and the validation problems tend to be more complex than just "this should be a number".

      More generally, though, an EMR doesn't actually have very many numbers in it. It's almost all IDs and strings. (You might think of numeric IDs as numbers, but they're aren't numbers in the sense that you will never perform operations on them; they are arbitrary identifiers that happen to be composed of digits.)

    20. Re:Trading one for the other by Anonymous Coward · · Score: 0

      The company that is known for abandoning projects after a few years helps the DoD...seems rather fitting actually.

    21. Re:Trading one for the other by Anonymous Coward · · Score: 0

      libertards? Is this a slam against libertarians or liberals? It gets hard to tell when it all sounds like angry monkeys clapping with one hand.

    22. Re:Trading one for the other by nabsltd · · Score: 1

      In this fictitious example, DoD is paying Gmail for a proven email system and the personnel to keep it running, up to date, and secure.

      The other huge difference in your example is that DoD would merely be paying for something already built and functional.

      TFA is about three companies building a system from scratch. Even if they use something that mostly already exists, it will be highly customized for DoD, to the point that it will be different from anything they have already done, and nowhere near "proven" or "tested". Since the history of those three companies shows they want nothing more than keeping their clients locked in as long as possible, it's not a recipe for long-term success.

    23. Re:Trading one for the other by Anonymous Coward · · Score: 0

      Idiot.

    24. Re:Trading one for the other by Anonymous Coward · · Score: 0

      It's not really "from scratch". It's using existing software that has already been written and tested (Cerner Millennium) but takes effort and manpower to actually implement and set up to a hospital's liking. When they say they're doing it "from scratch" it means they're standing up a freshly installed system as a blank slate and building their own custom workflows and functions as needed. "Minimum modifications" means they don't want any executables rewritten or refactored to suit their needs; they're going to do all of their customization through the existing methods built into the software (CCL/SQL scripts, custom page views and workflows, etc.)

      Source: EHR consultant. I do this kind of stuff all the time and can attest that it's a monumental effort for even a medium-sized hospital.

    25. Re:Trading one for the other by FranTaylor · · Score: 1

      Also, programmers write better code when they know people will be looking at it. The open source method for motivating better programming.

      citation required

    26. Re:Trading one for the other by Anonymous Coward · · Score: 0

      Do you think DoD is going to tell the company how to rewrite the code to fix it? When you write the contract you put in performance specifications (remember five 9s?) and penalties for non-compliance. You don't spend months reviewing the vendor's software code to find edge cases that cause problems.

      You've never had to field a product on SIPRNet have you? They will review the source code, they will try to identify security hazards, and they will make you fix them or explain how to mitigate them before they let you onto a secure network.This is usually done with the aid of an outside security consultant.

    27. Re:Trading one for the other by phantomfive · · Score: 1

      Do you think it's not true? Prima Facie it seems obvious, based on my own experience, and watching others.

      --
      "First they came for the slanderers and i said nothing."
    28. Re:Trading one for the other by CaptQuark · · Score: 1

      [comment redacted]
      The first rule of SIPRNet is you don't talk about SIPRNet. -_^

      --

  5. follow the money by Lead+Butthead · · Score: 4, Interesting

    follow the money and the answer is in front of you.

    --
    ELOI, ELOI, LAMA SABACHTHANI!?
    1. Re:follow the money by Anonymous Coward · · Score: 0, Offtopic

      Your penis must hurt like hell.

      no - it's just very, very smelly

    2. Re:follow the money by greenwow · · Score: 0, Insightful

      Exactly. This is just more disgusting Republican corporate welfare.

    3. Re:follow the money by Anonymous Coward · · Score: 0

      But how would these Republican-run corporations ever survive if we didn't have the government taking all of our money at gunpoint to give to them?

    4. Re:follow the money by Anonymous Coward · · Score: 0

      That money would be much better spend on disgusting Democratic individual welfare.

  6. $9 billion dollar project? by Anonymous Coward · · Score: 1

    Try paper, it still works.

    1. Re: $9 billion dollar project? by snowgirl · · Score: 2

      Paper doesn't scale to the level required. Trust me, I've attended presentations from ex-Googlers on the topic.

      Especially, when the paper weighs so much that it started deforming a building...

      --
      WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
    2. Re: $9 billion dollar project? by bigfinger76 · · Score: 1

      In NC, the "storage floor" for all the backlogged records is sagging, threatening to collapse. Paper is not going to work.

    3. Re: $9 billion dollar project? by Anonymous Coward · · Score: 0

      Maybe put the storage floor on ground level? Just a thought.

    4. Re: $9 billion dollar project? by Blaskowicz · · Score: 1

      Maybe it's in the basement and menacing the soil's integrity ; earth itself can collapse under the weight of a few years of DoD paperwork.

    5. Re: $9 billion dollar project? by Anonymous Coward · · Score: 0

      The reality of paper records is that they are so inconvenient that doctors don't actually read them... if they can even get their hands on them in time.

      Electronic records mean the doctor might actually have a chance to review your record before you see him.

      That's what my 75-year-old doctor told me before he retired. (He moved to an EMR in his last decade of practicing.)

    6. Re: $9 billion dollar project? by Anonymous Coward · · Score: 0

      Actually they traced the earthquakes recently to the deformation of tectonic plates under government records storage facilities. Regulations are being put in place to make sure that fault lines are protected from the weight of governmental paperwork.

  7. $4.3 billion == guaranteed failure. by serviscope_minor · · Score: 5, Insightful

    As far as I can tell, any IT project costing a billion or more is 100% guaranteed to fail.

    Also, it sounds like they decided to source IT from Lufier, Mephistopheles and Satan, which incidentally also guarantees it to fail.

    --
    SJW n. One who posts facts.
    1. Re:$4.3 billion == guaranteed failure. by wonkavader · · Score: 4, Insightful

      Tom DeMarco talks about the air traffic control software project in one of his books. The description of the hopeless situation in that case supports your idea.

      I think when you have a lot of people's butts on the line and so failure is not an option but stagnation IS, what we would perceive as failure is almost certainly coming. You can retire without any fallout so long as you make sure nothing happens for 15 years. It's easy to do: Just make the specs vague, self-contradictory, and long. Very, very, long.

      The project won't fail, but it won't succeed either. And you're safe, which is all that matters.

      They would do much better to set up a few small teams and have them compete to build something with enough in common so one can be replaced by the other. And starting with the open source base would make sense there.

    2. Re:$4.3 billion == guaranteed failure. by dinfinity · · Score: 5, Insightful

      As far as I can tell, any IT project costing a billion or more is 100% guaranteed to fail.

      No kidding.

      If you pay everybody $200 000 per year, that equates to 21 500 man-years (!) of work. I don't know what kind of problems in record keeping they're going to solve, but for that kind of money it'd better involve employees doing that in gold plated jets flown by an artificially engineered unicorn that continually snorts prime-grade cocaine.

    3. Re: $4.3 billion == guaranteed failure. by Anonymous Coward · · Score: 0

      The guys who sold the gig are probably doing just that

    4. Re:$4.3 billion == guaranteed failure. by Rich0 · · Score: 1

      Just make the specs vague, self-contradictory, and long. Very, very, long.

      When you get to software on this scale just writing the specs is an insanely difficult problem. Most big systems fail due to poor requirements, and I think that is because good requirements are a LOT harder to get right than people appreciate, especially for waterfall-style projects that are always the favorites of big RFP projects like these.

    5. Re:$4.3 billion == guaranteed failure. by Anonymous Coward · · Score: 0

      Tom DeMarco talks about the air traffic control software project in one of his books. The description of the hopeless situation in that case supports your idea.

      I think when you have a lot of people's butts on the line and so failure is not an option but stagnation IS, what we would perceive as failure is almost certainly coming. You can retire without any fallout so long as you make sure nothing happens for 15 years. It's easy to do: Just make the specs vague, self-contradictory, and long. Very, very, long.

      The project won't fail, but it won't succeed either. And you're safe, which is all that matters.

      They would do much better to set up a few small teams and have them compete to build something with enough in common so one can be replaced by the other. And starting with the open source base would make sense there.

      You're right.

      It seems you have gotten your hands on some proprietary Microsoft software dev / human resource strategies.

      distrowatch.com

    6. Re:$4.3 billion == guaranteed failure. by superwiz · · Score: 1

      Good luck finding lawyers competent with the government's requisition procedure who work for as little as 200k a year.

      --
      Any guest worker system is indistinguishable from indentured servitude.
    7. Re: $4.3 billion == guaranteed failure. by Anonymous Coward · · Score: 0

      Since DeMarcos book the FAA has run three more ATC replacement projects. $100 billion wasted, all failures.

    8. Re:$4.3 billion == guaranteed failure. by Anonymous Coward · · Score: 0

      > artificially engineered unicorn that continually snorts prime-grade cocaine

      Don't you talk shit about Snortzy! Snortzy has SEEN SOME SHIT YO, you can't judge! No judging!

    9. Re:$4.3 billion == guaranteed failure. by K.+S.+Kyosuke · · Score: 1

      These days, you could almost fly to the Moon for that kind of money.

      --
      Ezekiel 23:20
    10. Re:$4.3 billion == guaranteed failure. by dinfinity · · Score: 1

      Screw your implicit apologistic bullshit.
      You could hire 100 lawyers and pay them $1 000 000 yearly for 10 years and still have 3.3 billion dollars left.

      This is the industry suckering the government out of their cash and you know it.

    11. Re:$4.3 billion == guaranteed failure. by Anonymous Coward · · Score: 0

      Just to pick nits, the pay of a worker is much lower than the cost to the project of that worker. It's easily double the worker's pay. At one employer, we worked out what a technician took home versus what it cost my project and it was ~14x due to taxes, overhead and G&A costs.

      Okay, it's still a man-millennia or two we're talking about, but high quality software engineers are going to cost your project way more than 200k a year.

    12. Re:$4.3 billion == guaranteed failure. by Anonymous Coward · · Score: 0

      Well, this is a very similar case:
      http://www.infoworld.com/article/2614353/ehr/how-kaiser-bet--4-billion-on-electronic-health-records----and-won.html
      These huge EHR implementations are expensive, but this is something which has been done before.

    13. Re:$4.3 billion == guaranteed failure. by superwiz · · Score: 1

      Good luck getting lawyers who could get a top government contract for $1000,000 a year. This is what top divorce lawyers will bill nowadays. Top Fed-contract requisition lawyers are probably asking at least 10x as much. But they could be asking 100x or a 1000x as much. Because they'd still be worth it if they return this much on their effort.

      --
      Any guest worker system is indistinguishable from indentured servitude.
    14. Re:$4.3 billion == guaranteed failure. by dinfinity · · Score: 1

      You are veritably ridiculous.
      You are arguing that there are lawyers that could ask 1 billion dollars yearly. 'Because they'd still be worth it'.

    15. Re:$4.3 billion == guaranteed failure. by superwiz · · Score: 1

      Yes, I am definitely arguing that someone who can bring in a $4.5 billion contract which takes less than a billion to fulfill is, in fact, someone who deserves their 30% billion dollar paycheck. If someone threw $3.5 billion in free money my way, yeah, I'd say they deserve their $1 billion finder's fee.

      --
      Any guest worker system is indistinguishable from indentured servitude.
    16. Re:$4.3 billion == guaranteed failure. by dinfinity · · Score: 1

      That is not how that works. At all.
      You have at best a primary school level understanding of capitalism and economics in general.

    17. Re:$4.3 billion == guaranteed failure. by superwiz · · Score: 1

      oh. you are one of those. ok. i guess i should have known better than to argue with a millennial.

      --
      Any guest worker system is indistinguishable from indentured servitude.
  8. Accenture? by Anonymous Coward · · Score: 3, Insightful

    Project already failed.

    1. Re:Accenture? by Anonymous Coward · · Score: 0

      They are not called Ass-Enter for nothing.

  9. Accenture by Anonymous Coward · · Score: 0

    OK, years late, most promised feature not done/working, Budget 3x+ over and you will move to a proprietary commercial product with 100% lock in.
    Sweet, yes would be fun to see who's back accounts/family members got hired to land this future failure in motion ;)

    1. Re:Accenture by chipschap · · Score: 2

      OK, years late, most promised feature not done/working, Budget 3x+ over and you will move to a proprietary commercial product with 100% lock in.
      Sweet, yes would be fun to see who's back accounts/family members got hired to land this future failure in motion ;)

      You left out the part where no senior executive service (SES) people get fired but middle-level people who actually tried to make it work get the blame. Meanwhile the Beltway Bandits make off with millions and hire the SES people for fat salaries as a reward for sending all the money their way.

  10. UK NHS by martin · · Score: 3, Informative

    Sounds alot like the disasterous Nhs epr systems. After 20 years weve had progress but the number suppliers is down 1 and a major cash sinkhole

    1. Re:UK NHS by dmr001 · · Score: 2

      I thought about the NHS program when posting this, described as "the biggest IT failure ever seen". After £10 billion+ was spent, Her Majesty's government largely abandoned the effort, though the linked article notes Computer Sciences Corporation declaring victory as 3 of 220 NHS trusts managed to use portions of the system. I first heard this story a couple of years ago on a shuttle bus to the headquarters of a large privately held EMR vendor in Wisconsin, when I noticed the accents around me weren't American (like me). I was sitting amongst a group of friendly pharmacists from Oxfordshire. They were going to adopt this proprietary system for their NHS trust (ignoring, I suppose, the large chunk of it that dealt with billing).

      Besides the air of defeat of all those pounds sterling going down a lot of oddly designed British toilets, they had given up on the idea of interoperability with the systems of other NHS trusts adopting different systems from other proprietary vendors. Back in the US, we have all kinds of government prodding to promote interoperability and many self-congratulatory health IT standards organizations that have national meetings in sunny placed. But, the farthest we've got with inter-vendor communication in my medical office after 3 years of promises and finger-pointing is faxing documents to an image server from the speciality clinic 100 feet away into inscrutably named files. Then, I can hand transcribe the important bits by hand about my patient's heart conditions and colon tumors in order to have a hope of retrieving that information again when I need it.

    2. Re:UK NHS by TeknoHog · · Score: 1

      Sounds like EPR needs CPR.

      --
      Escher was the first MC and Giger invented the HR department.
    3. Re:UK NHS by Dr_Barnowl · · Score: 2

      We do have interoperability standards : I used to work for the department that specifies them.

      They just don't follow them. Case in point : the meta-standard (HL7 v3) that we used for our messaging had a mechanism for not just sending NULL values, but also sending a reason why they were null. (e.g. - the value wasn't measured, etc). The vendor had no truck with that, and was using magic numbers instead (e.g. baby weights of 9999g which is outside the realms of sanity for a newborn). I was tasked with revamping one of the messages. I specified that the proper NULL flavours get used and ditch the magic numbers.

      The vendor at this point rolled out the "full system test" clause in their contract, whereby they could charge £N * 10^6 to perform a full system test, because we'd changed the behaviour of one field. They got their way and kept their magic numbers. Other systems expecting messages that met with the conventions of the overall meta-standard for data now have an additional development cost to cope with those magic numbers.

      This is the reason for the focus on interoperability over just having standard data structures - it lets vendors continue to use their own proprietary data schemes, and raises a barrier to new participants in the market, not only do you have to implement all the standard interfaces to interoperate, but you probably also have to design in a "quirks" layer to cope with each vendors *special* variations.

  11. Sometimes updating legacy systems is a real pain. by Anonymous Coward · · Score: 1

    The hardest part of legacy is that sometimes the software just does what it does, and no one has all the official rules to recode it. So sometimes they task unwitting coders with learning some random programming language people don't use anymore, and most people didn't even use back in the day. They task them to do that to find out what rules they're operating under by reading the spaghettiest of spaghetti code. That is by no means a fun job especially when you're talking about governmental designed rules. I can't explain just how tough this job is if they don't even know their own operating procedures. If they do know their own operating procedures, then just update the database, write the fresh code in a modern language and send it out the door.

  12. As an Accenture stock holder by Anonymous Coward · · Score: 1

    As an Accenture stock holder I think this is definitely a step in the right direction.

  13. $4.3 billion by lkcl · · Score: 4, Insightful

    wow fuck. imagine how much advancement in software libre could be had for $4.3 billion if the contract had been awared. hell, even 1% of that would make a big fucking difference. someone - such as the gnumed developers to take even one random example - could, with help, have developed a medical records system for ohhh i dunno... the U.S. Dept of Defense, with that kind of money. just to take a random example, y'ken.

    1. Re:$4.3 billion by gtall · · Score: 2

      You have no idea of scale.

    2. Re:$4.3 billion by Anonymous Coward · · Score: 0

      They have a free software records system for the DOD.

      It's the one that they are replacing.

    3. Re:$4.3 billion by Anonymous Coward · · Score: 0

      Tell me about it. That might be enough money to convince RH to fire poettering and rid the world of systemd.

    4. Re:$4.3 billion by Anonymous Coward · · Score: 0

      For that sort of money you could mostly remove systemd from software libre, mostly.

    5. Re:$4.3 billion by terjeber · · Score: 1

      Really? Put that much money into open source and you'll have one fork for each $20 put in. Then the project is going to be complete in the mythical Year of the Linux Desktop (TM)

  14. Speakings of the OSS in question by ADRA · · Score: 1

    They use MUMPS. I know its all supported by some people and I know the flames are coming, but really? MUMPS. I'd say integration could very well be considered a pain point in the language. In my cursory investigation, the recommended integration for other languages / technology chains is a Node.js based web services adapter... oh well.

    --
    Bye!
    1. Re:Speakings of the OSS in question by Anonymous Coward · · Score: 0

      The MUMPS ecosystem is scrambling like mad to seem hip and with it. They open sourced VistA. They created a new ANSI standard called M that none of the major customers actually use.

      Open source advocates had better think twice before blindly supporting the OpenVistA initiative. There are other, more important factors in play. "Open source" isn't some secret sauce that cures all ills no matter how much you want it to.

    2. Re: Speakings of the OSS in question by Anonymous Coward · · Score: 0

      The 'new' standard is 20 years old (https://en.m.wikipedia.org/wiki/MUMPS) and implemented fully in all relevant dialects.

      The namechange to M was imho a try to get rid of clueless people who just make funny remarks about the name without having the slightest idea what M(UMPS) offers to solve big real world problems.

    3. Re: Speakings of the OSS in question by Dr_Barnowl · · Score: 1

      Tyson, is that you??

  15. Part of the problem by satsuke · · Score: 3, Insightful

    That is part of the problem .. trying to design a drop in replacement that replicates the current functionality and interoperability with other systems.

    With government especially, you have lists of exceptions and custom one-off code to get something working, that it becomes impracticable to replace it without an equal or additional number of exceptions.

    It's the kind of system that benefits from a "flush it all away" mentality of defining new standards and sticking to them.

    1. Re:Part of the problem by Anonymous Coward · · Score: 0

      It's the kind of system that benefits from a "flush it all away" mentality of defining new standards and sticking to them.

      People are surprisingly resistant to sticking to anything, even standards they created themselves. Shit, we can't even get people in the office to stick to a file naming convention.

  16. Eating them alive by Todd+Knarr · · Score: 1

    Well, it'll solve the problem of the system eating them alive in terms of maintenance and support. Now it'll be eating them alive in terms of development costs instead.

    No, wait, they'll need to keep the legacy systems running until the new ones are running, so it'll still be eating them alive in terms of maintenance and support too.

  17. Accenture? by msobkow · · Score: 3, Informative

    Accenture? Better double that initial estimate to $18 billion, and count on it rising further. :(

    --
    I do not fail; I succeed at finding out what does not work.
  18. Re:Good response by Anonymous Coward · · Score: 0

    You DO know that these hacked systems were mostly closed source, right?

  19. Re:Good response by Anne+Thwacks · · Score: 1
    I should have thought that it was obvious to everyone that, for infrastructure, open source is the ONLY choice.

    Iit is the only way to guarantee it can be fixed.

    I offer MS Word in evidence.

    --
    Sent from my ASR33 using ASCII
  20. EHR Gold Mine by Anonymous Coward · · Score: 0

    This will be a disaster of Epic proportions (excuse the industry pun). Cerner (medical software company) and the others Leidos (DoD contractor) and Accenture (management, services, and outsourcing company) will make bank at the expense of taxpayers and soliders. I guarantee that this project will be over budget and never deliver what was promised. Nothing is standard in the medical system business due to the "off the shelf" software companies protecting the data in their systems, which is the real product. Even implementing the HL7 standard (which version?) for interfaces is open to interpretation. The DoD has chosen to lock their soldiers medical data into a proprietary system, which will be non trivial (expensive) to share. Makes me wonder how the wheels of procurement were greased, and how much that greasing cost Cerner/Leidos/Accenture?

    Posting AC because I have to work with at least one of the mentioned companies.

  21. not enough bribes by OSS by dltaylor · · Score: 2

    US Government purchasing "works" by the payment of bribes. Usually, these are not simply cash payments, but the opportunity for lucrative "consulting contracts" at the providing companies for senior Penagon and Civil Service officials after leaving government "service". I've seen it enough to know that saving money, at equal or better performance, will not get a government contract. Maybe, if enough congresscritters and/or senaturds are bribed with campaign contributions and/or honorariums, they'll push a deal one way or the other, but that rarely has anything to do with saving purchasing costs.

    1. Re:not enough bribes by OSS by eulernet · · Score: 1

      Exactly !

      In fact, people signing large contracts always expect large kickbacks in return, at least 15% of it.
      This will probably finance the next presidential campaign.

  22. gnu project? really? by Anonymous Coward · · Score: 4, Insightful

    And who, in the gnu community, is going to take on the responsibility for all the enterprise scale stuff that needs to be done. I can see lots of folks wanting to scratch their particular itch by coding up some piece, but who's going to do the architecture design, ride herd on the developers, etc.; make sure that the documentation gets done and is usable and readable (because, ya know, all those packages out on github and sourceforge are ever so well documented)..

    I mean responsibility as in "be willing to stand up in front of Congress and explain your progress or lack thereof". I don't see a Linus or Theo or Eric or, gods forbid, Richard, filling that role.

    1. Re:gnu project? really? by Anonymous Coward · · Score: 0

      I might be wrong here, but with $4.3 billion dollars they can probably manage to assemble some sort of team of competent individuals.

      I don't see a Linus or Theo or Eric or, gods forbid, Richard, filling that role.

      No need to involve the douche brigade (well, I don't have any actual issue with ESR.) Again, just hire and vet their own people, and make sure they know how to run a software project. Not exactly groundbreaking.

    2. Re:gnu project? really? by Anonymous Coward · · Score: 0

      MUMPS was a disaster when I first worked with it 24 years ago, and it has improved little since. Every freakin' field is a string. Documentation on the system is a disaster. I am soooo glad to be out of government work where infrastructure like this is considered viable. And, at least they didn't give the job to EPIC, which has its own trail of tears: http://www.healthcareitnews.com/news/go-live-gone-wrong?single-page=true

    3. Re:gnu project? really? by Anonymous Coward · · Score: 0

      so they didn't think to charge anyone and are wondering why no money is coming in. interesting...

    4. Re:gnu project? really? by Anonymous Coward · · Score: 0

      In the current system Ahlta & CHCS, their helpdesk support crew have various lists of date ranges in which they know the records are missing during those times. That is to say, if someone had a doctors visit about cancer, the records might be missing if it happened to be on this or that day due to various database corruptions. Another example is their main central database datacenter of servers all went offline once due to a backhoe dig. They had (3) redundant network connections. Then why did it go offline? Apparently, no one thought that having all (3) network datacenter links in the same conduit throughout could ever be an issue.

    5. Re:gnu project? really? by Anonymous Coward · · Score: 0

      I don't know what the obsession with "every field is a string" is. It's not really true (any more than it is in any other dynamic language, at least), and if you think that's one of the important problems in MUMPS, you haven't thought very hard about it. (The real problem is that MUMPS has no abstract data types, which makes abstraction extremely difficult!) Documentation of Intersystems Caché, at least, is pretty good, and GT.M is not bad either; it's the things written in it that have horrid documentation, but that's no different than it is with most other middleware. (If you've never seen a poorly documented Java project then you haven't seen very many Java projects.)

      If you think that one Epic failure story is scary, consider that Cerner implementation failures are so common that the industry has coined the term "Cernover" to refer to when a Cerner customer drops them after a couple of years and buys a different EMR (usually Epic) to replace them.

    6. Re:gnu project? really? by Anonymous Coward · · Score: 0

      Maybe they could stretch the budget and hire someone?

    7. Re:gnu project? really? by Anonymous Coward · · Score: 0

      I'm in said industry and have never heard that term before. Is that just an in-joke among Epic consultants to make themselves feel better when they lose contracts? Like when someone breaks up with you and you sit in a mopey rage going, "You'll come running back! Just you wait and see!"

    8. Re:gnu project? really? by Anonymous Coward · · Score: 0

      That term popped up about 8 years ago when Cerner struck bottom in customer service and lost some clients because of it. Otherwise, you're correct, it's mostly Epic in-jokes and sales posturing, just like Cerner consultants are always bringing up overbudget or botched Epic installs like Kaiser or Maine Medical Center, or parrot on about Epic's shitty interoperability. What Epic lacks in marketing they certainly make up for in solid astroturfing campaigns.

  23. 4.3 billion is not enough. by Anonymous Coward · · Score: 0

    Part of DoD's requirement, in fact, was that the EHR interoperate with private sector systems, since somewhere between 60 percent and 70 percent of care takes place outside the DoD.

    4.3 Billion isn't enough. What they are asking for is that Cerner interoperate with every other system out there, a feature that does not yet exist.
    You can find some news here on interoperability with other non-hopeful articles..
    http://www.fierceemr.com/story...

    1. Re:4.3 billion is not enough. by tomhath · · Score: 1

      Not quite. What they want is a system which has interfaces available that any other vendor (open source or not) can use. Cerner has been moving in that direction; of the vendors out there they are probably the least bad choice.

  24. Why? by Anonymous Coward · · Score: 1

    ... part of a $9 billion dollar project ...

    We all know the US department of defense demands a fixed-cost project then signs an open-cost contract. The usual excuse being the contractor must build the software from scratch. Since this project copies the contractor's existing system, the government can easily demand a fixed-cost contract. Like that's going to happen!

    ... a system with minimum modifications ...

    So they're paying $9 billion for something that's already been built. It sounds overpriced already.

    ... interoperability with private sector systems ...

    The US DOD is always saying they need a do-everything system that prevents data fiefdoms. It's why they're always re-inventing the wheel, so copying a non-standard, legacy system is the worst possible 'upgrade' and it throws away all the work done on VistA.

    ... is more aspirational than operable ...

    Maybe this is an attempt to not re-invent the wheel: By buying whatever is available instead of building a do-everything system from rainbows and unicorns. But the VistA system is also available, so no, it's a clever way to pay kickbacks.

    ... eating us alive in terms of support and maintenance ...

    So the answer is another legacy system? I'll bet the hardware for this new system will be 2 years-old. Part of that is the slow procurement system and part is the mIl-spec approval program that all DOD purchases must satisfy.

  25. anybody surprised by Anonymous Coward · · Score: 0

    have to keep the corporate welfare train rolling!

  26. VistA is a nightmare by Gravis+Zero · · Score: 5, Interesting

    i was interested in VistA and what all the fuss was about, so i decided to check it out. turns out the backend is nightmare code that would would swear was machine generated. after some investigation i found out it's MUMPS (Massachusetts General Hospital Utility Multi-Programming System) code. a lot of useful stuff started way back in the 1970s... but MUMPS is a 1960s nightmare come to life.

    think i'm exagerating? here's a module from VistA's code which was apparently updated in 1989.

    DENTA1 ;ISC2/SAW,HAG-DENTAL TREATMENT DATA SERVICE REPORTS ; 1/10/89 11:08 AM ; ;;1.2;DENTAL;**24**;JAN 26, 1989
      D:'$D(DT) DT^DICRW S %O="OPT",U="^",S=";",O=$T(@(%O)),DENTV=$$VERSION^XPDUTL("DENT") I $D(^DOPT($P(O,S,5),"VERSION")),(DENTV=^DOPT($P(O,S,5),"VERSION")) G IN
      K ^DOPT($P(O,S,5))
      F I=1:1 Q:$T(@(%O)+I)="" S ^DOPT($P(O,S,5),I,0)=$P($T(@(%O)+I),S,3),^DOPT($P(O,S,5),"B",$P($P($T(@(%O)+I),S,3),"^",1),I)=""
      S K=I-1,^DOPT($P(O,S,5),0)=$P(O,S,4)_U_1_U_K_U_K K I,K,X S ^DOPT($P(O,S,5),"VERSION")=DENTV
    IN I $P(O,S,6)'="" D @($P(O,S,6))
    PR S O=$T(@(%O)),S=";" S IOP=$I D ^%ZIS W:IOST'["PK-" @IOF K IOP
      I $P(O,S,7)'="" D @($P(O,S,7))
      E W !!,$P(O,S,3),":",!,$$VERSION^XPDUTL("DENT")," ",$P($T(+1),S,1),!!,$P(O,S,4),"S:",!
      F J=1:1 Q:'$D(^DOPT($P(O,S,5),J,0)) S K=$S(J0 S Z2=Z1
      G:Z3=0 W I Z3>1 S DIC="^DENT(225,",DIC(0)="AEMNQ",DIC("A")="Select STATION.DIVISION: " S:$D(DENTSTA) DIC("B")=$S(DENTSTA[" ":+DENTSTA,1:DENTSTA) D ^DIC Q:Y

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      That is no doubt a big reason it's being replaced.

      Say, I'd love to see a snippet of source code from the new project when it's done.

    2. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      That is no doubt a big reason it's being replaced.

      Say, I'd love to see a snippet of source code from the new project when it's done.

      Epic which is the vendor with the most market share in the commercial EHR space is also written is M. In fact, if I remember correctly, Epic's owner/founder Judy Faulkner attended user group meetings run by the VA.

      I'm not sure but Cerner may also be using M for some part of the backend code also.

      BTW the code from VistA shown above actually looks cleaner than some of the snippets that customers are routinely expected to modify to change the default behavior of Epic.

    3. Re:VistA is a nightmare by Dutch+Gun · · Score: 2

      Wow... I mean... wow. This is the definition of a "write-only" language. I'm pretty sure you'd need external documentation just describing what these routines do, because it sure as hell looks like you're not going to derive it from this encryption disguised as source code. I thought perhaps you had chosen some particularly horrible section, like maybe it was a data definition of some sort. Nope, after sifting through a bunch of code, it pretty much all looked like that. My brain hurts just trying to parse and make sense of some of that code.

      Is it any wonder that, with a language like this, it can't be easily extended and upgraded to meet demands? Yeah, okay, it's understandable now why they're tossing the whole thing. Open source or not, I can't imagine there are many people today who are able to extend or even maintain this monstrosity in perpetuity.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    4. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      you're full of shit

    5. Re:VistA is a nightmare by Blaskowicz · · Score: 1

      If you expand the crazy one-letter commands into their full length and color them, maybe it's a bit less terrible.

    6. Re:VistA is a nightmare by Dutch+Gun · · Score: 1

      Perhaps, but that's not what they're working with, since this is the original source. This language and it's horrible style was obviously invented in a day when the size of your variables and source files was actually a real consideration, and machine efficiency was prioritized over programmer efficiency. It looks like assembly language for distributed databases.

      That's precisely the opposite of what most large-scale enterprise systems need nowadays. Computers are incredibly powerful and cheap and programmers are very costly, so modern languages should (and do) reflect that reality.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    7. Re:VistA is a nightmare by Anonymous Coward · · Score: 1

      Cerner does not use M for anything. Cerner developed an in-house language called CCL (Cerner Command Language) which is standard SQL with additional functions built in, mostly for writing, saving and running scripts. All custom functions written for Cerner are typically done in CCL. The backend server code is almost entirely C++ on the backend, with a few pieces done in Java. Frontend code is roughly the same mix.

      As for databases, it's Oracle RDBMS and MySQL.

      Source: Former Cerner software engineer.

    8. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      This looks cleaner than some of the Cache (Intersystems versions of M or MUMPS) code that runs most of the credit unions in the US.

    9. Re:VistA is a nightmare by bugs2squash · · Score: 1

      OK, so build a new system, a superset of MUMPS that adds the needed functionality but continues to support the legacy code as well as some newer, better syntax.

      That way you can transfer in all the old crap and replace it bit by bit over some time. I'm sure I've even seen technology that analyzes executables and re-factors them - perhaps similar techniques could be applied to the old MUMPS source. Sure it's hard, but with $9B and several years I'm sure a handful of CS guys at a university department could achieve something truly exceptional.

      --
      Nullius in verba
    10. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      This isn't a "Throw $9B at some people to write software" kind of deal. An EHR is not like some new Quicken software for the accounting department. Not to mention, this new system is going live in the first set of locations mid-to-late next year. It being a 10-year deal doesn't mean they're "flipping the switch" in year 10. It's a staged implementation over a global footprint.

      A small fraction of that $9B pays for software, yes. But the rest of that $9B has to go toward people installing and supporting the new system in every base, field hospital, FOB, ambulance, submarine, aircraft carrier, etc. in the entire US military. You're talking teams and teams of IT staff getting trained on the software, knowing how to address common complaints and issues. Teams and teams of clinical analysts to configure code sets, set up rules, implement existing workflows, design custom views, integrate medical devices... I could go on and on. So I will.

      You've got system architects building out and testing the system at full scale. Millions of medical records with tens of thousands of doctors and tens of thousands of nurses all using the system at once, spread out over the entire US military. Everything must be secured to DoD standards while interoperating to the extent that the system demands. Add in government bureaucracy to every single step of the process for an extra little challenge. Then you test, test, test, test, test, test, TEST.

      You've got integration architects building interfaces to existing systems so the records can move around seamlessly. They're mapping data fields in the old system to data fields in the new system. They're making sure the problem codes are being translated properly so "sinusitis, mild" in the old system doesn't come across to the new one as "rectal bleeding, moderate to severe". They're making sure that soldier A can get treated in a submarine in the middle of the Atlantic ocean, and every detail of that visit can be pulled up in that soldier's local VA hospital or their doctor's office in rural Utah. Lather, rinse, repeat for every other EHR system you need to integrate with. (Some systems are easier than others.) Then you test, test, test, test, test, test, TEST.

      You've got device engineers certifying medical devices and hooking it into the new system, and sometimes that entails building the device definitions manually if it's not a common device that's already predefined. Blood pressure cuffs, fetal monitoring, IV administration - fuck, even the beds themselves are getting integrated these days. Lather, rinse, repeat for every device type currently in use. Then you test, test, test, test, test, test, TEST.

      You've got clinical analysts defining triggers and rules so when patient A is on medication B, if physician C orders treatment D it alerts them to also add treatment E because of organizational policy F. Or when patient G goes tachycardic and their temperature rises over point H and their respiration rate increases above I, surprise, they're at risk for sepsis and you need to alert Nurse J to administer treatments K, L, M, N, O, and P because if not they'll be dead in 6 hours. Lather, rinse, repeat for every trigger and rule they have. Then you test, test, test, test, test, test, TEST.

      I love armchair quarterbacking as much as the next guy, but what you're suggesting is a suitable course of action for a new web browser, not a full suite of enterprise-grade medical software.

    11. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      I worked for Cerner for a number of years...and I never worked for a company where so many employees drank the kool aid.

    12. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      Uhh, HL7 don't look much different.

    13. Re:VistA is a nightmare by Eravnrekaree · · Score: 1

      That code is written like every byte costed $500. Don't let this reflect badly on M. The problem is they used one character variables and no formatting. You can wrote worse code in C. M is perfectly readable if you use good variable names and formatting.

    14. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      Sounds like you got fired from a place where it's pretty difficult to get fired from.

      Tell me where they touched you.

    15. Re:VistA is a nightmare by Eravnrekaree · · Score: 1

      It would have been best to hire some in house programmers , certainly could have been done with some portion of the few billion, and have them write a new system, which could then be made public like VISTA. This way the government owns it, instead, there will be an opaque system and the government will be held captive to extortion from providers.

    16. Re:VistA is a nightmare by JustAnotherOldGuy · · Score: 1

      That code gave me brain cancer.

      --
      Just cruising through this digital world at 33 1/3 rpm...
    17. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      You really have no idea.

      "A handful of CS guys at a university department" working for a few years sill wouldn't even grasp the requirements fully, let alone rewrite the system. It is that complex.

      Also, the piece-by-piece replacement of MUMPS is already underway at a certain EMR vendor that I know of. It has been underway in some form for more than a decade and I don't expect it to be complete for another decade. (The replacement is .NET.)

    18. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      I imagine that this "mumps" atrocity is to database people what being the victim of a scientist-written Fortran code is for a performance programmer. A day in the life:

      ------------
      You sit down and begin staring at page-sized blocks of global variables, heading up functions with 5-letter names based on 2-letter variables that consist of thousands of lines of completely comment- and documentation-free spaghetti. The lovecraftian horror is liberally riddled with gotos, taped together with a bizzare mass of intersecting/interacting loops, early returns, jumps, breaks, short-circuits and every other strategy you can imagine. "modern" freeform and "classic" fixed-format ALLCAPS mingle randomly.

      On and on it goes, a horrible collection of impenetrable conditionals, sometimes ending in GOTOs, sometimes not. Feeling a stroke coming on, you punch the pagedown key until a break streaks by. Page up, and the first comment you've seen in a thousand lines: you recognize the words "Tukey-Cooley Algorithm." But of course, why wouldn't any sensible code have its own implementation of the FFT? That's common sense!

      And so it goes... All of this was created by an architecture-free computerized simulation of organic evolution, until now finally the result serves no purpose other than to cause research the victim research group to asymptotically approach 100% time wastage. It's impossible for anybody to change anything without breaking it, impossible to debug, impossible to verify (because there is no -test option, no test harness, no unit tests, no anything, other than "hi guys, tried the latest version, it seems to make bad results."). Also, several key flags cause the code to completely break. This apparently happened a while ago (meaning... decades). There is, naturally, no documentation of even the year, let alone why.

      You feel sympathetic, naturally. Nobody deserves to be victimized by this, for God's sake. Then you realize that they bring it upon themselves: The scientists consider "version control" as consisting of sending each other the code file (singular - it's one .f file) in email attachments, or mailing the group list to say that they've altered something on a shared directory. Not even a _v25, _v26, ... fig leaf of version control? But before you finish boggling, someone mentions that the group is working on multiple copies simultaneously. Wait what the fu... well each of 'em which works with a different compiler, and nobody knows why this problem exists.

      One day it turns out that there's a particular problem of this thing crashing when the resolution is turned up. It occurs to you that the evil called "Fortran 77" doesn't have memory allocation; With an inward cringe of self hatred, you tell them about GCC's -mcmodel option.

      You wonder how to tell the PI that this code can never be modernized or fixed...

    19. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      OK, so build a new system, a superset of MUMPS that adds the needed functionality but continues to support the legacy code as well as some newer, better syntax.

      Congratulations, you just described the idea behind C++. /sarcasm

      That way you can transfer in all the old crap and replace it bit by bit over some time. I'm sure I've even seen technology that analyzes executables and re-factors them - perhaps similar techniques could be applied to the old MUMPS source. Sure it's hard, but with $9B and several years I'm sure a handful of CS guys at a university department could achieve something truly exceptional.

      Well yes that's an option, but the better idea would be to rewrite the needed code in a modern language using the existing code as a spec. Creating a new language would require extensive debugging before it was used to write software applications (especially if said software is for government work), and you'd blow most of your time on that alone. Rewriting the old code in a modern language avoids that and as a bonus, you get a better idea of what actually needs to be done by the software. Which considering what the DoD wants "a system with minimal modifications and interoperability with private sector systems", is a good thing. "Minimal modifications and interop" means they want it to work with what they've got. (No data / protocol format changes.) And this is a government project so the actual job to be done, as others have pointed out, is going to be buried under a ridiculous amount of conflicting mandates, false requirements, and in-general cruft that the current system either ignores out right, or only implements a subset that consists of the parts actually used.

      Writing / Buying a new software solution will not take that into account (much less an entire programming language) and will only create new bugs to track down, new failure states to avoid, and new requirements on data and procedure which all boils down to massive financial and time investment to implement.

      Of course this assumes the goal is to build a working system, and not some more kickback spending. In which case the DoD's actions on spot on.

    20. Re: VistA is a nightmare by Anonymous Coward · · Score: 1

      Anyone able to use a touring complete language in a productive way can learn basic M in a day or two.

      Expand the commands from their one-letter form and a programmer most likely can read the code within the time it takes to read up on the language: what the 26 commands do, how to apply conditionals to individual statements and the format to chain commands (use of syntactic whitespace) together inside a routine.

      Using it to the fullest will take longer because one needs to grasp the elegance of the design to realize why constructs commonly seen in other languages seem to be missing in M.

    21. Re:VistA is a nightmare by serviscope_minor · · Score: 1

      You can write MUMPS like that, sure, but then you can either write a good kernel in C or win the IOCCC. If one sticks to modern conventions such as using full length keywords, not refedining keywords and actually indenting (pretty much all things you can also do in C, even if redefining keywords is technically illegal, I've never seen it not work), then the code as far as I can tell looks fine.

      But even if all the code looks like that, for $9,000,000,000, you could reformat then refactor the entire lot, then write a new mumps compiler which enforced some coding standards and you'd still save more than $8,000,000,000.

      --
      SJW n. One who posts facts.
    22. Re:VistA is a nightmare by K.+S.+Kyosuke · · Score: 1

      He essentially suggested the use of automated techniques. From what I can tell, such automated techniques are being applied in practice. I recall a project that used a Smalltalk-based code analysis platform to refactor COBOL code. Are you saying that this approach doesn't save time and man-hours?

      --
      Ezekiel 23:20
    23. Re:VistA is a nightmare by K.+S.+Kyosuke · · Score: 1

      The one interesting thing here is that if you rewrite the execution environment, without creating a new language, you should be able to use the old code as tests for the functionality of your new code. You need some way to set up and tear down state for the snippets you're going to be executing, so the old execution environment that ran the system in production probably won't be suitable. Your best hope would probably be starting with a new "implementation" that can parse the code and either interpret it, or compile it, while recording the things that may be of interest to you (for example, if the old language was dynamic, and you need type information either for the purpose of documentation, or to generate static types for the new implementation, you can recover it by tracing).

      You can't really use old code as a spec if you lack the necessary tools. Or, perhaps you could, but you'd be doing in your head what a computer should be able to do for you automatically. Expect working very long hours if you're so intent on doing a compiler's and code analyzer's work yourself. ;-)

      --
      Ezekiel 23:20
    24. Re:VistA is a nightmare by arglebargle_xiv · · Score: 1

      E W !!

      Couldn't have put it better myself.

    25. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      Actually some automated techniques have been done by Epic. In particular, automated checks for correctness and standards compliance, and preprocessor constructs to create some abstraction constructs that the language doesn't support (mainly database-related, exploiting specific knowledge about Epic's database).

      MUMPS code is particularly difficult to reinterpret statically, though. The problem is that it runs in an extremely dynamic environment. So, inferring any properties of the code in a reliable manner is very, very difficult.

      The only thing that makes such a project like this seem remotely feasible is that we're not actually talking about an arbitrary MUMPS grokking machine: it would only have to grok the codebase that you're actually working with, and you could assume certain properties that you know are true of that particular codebase. You could even change the codebase here and there to make the job more tractable.

    26. Re: VistA is a nightmare by bill_mcgonigle · · Score: 1

      Anyone able to use a touring complete language in a productive way can learn basic M in a day or two.

      Yeah, the hospital I used to work at would take tech school kids and teach them M in six months, and then have a competent programmer. It's not work I wanted to do, but it's a real job. Jesus, hasn't anybody here done assembly?

      Using it to the fullest will take longer because one needs to grasp the elegance of the design to realize why constructs commonly seen in other languages seem to be missing in M.

      The best thing about a Jim Jones joke is the killer punchline.

      Seriously, I did Perl vs. M in the '90's with co-workers. Don't even. It was possibly a good argument in 1981.

      M persists because managers are afraid of making big changes and those big changes cost more up front than staying with the existing junk. Also they have a cartelized industry to draw resources from, so cost-competitiveness is not really a factor. Third-world countries are running their medical-records systems on "low-end" modern stacks because that's all they can afford.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    27. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      That's it, pack it in, we're all dead.

    28. Re:VistA is a nightmare by phantomfive · · Score: 1

      That is beautiful. I haven't seen code like that for a long time.

      Of course, if you look at the individual page of code for a while, you'll decipher it easily enough. Whether it's manageable or not depends on whether the overall structure is reasonable or not.

      --
      "First they came for the slanderers and i said nothing."
    29. Re:VistA is a nightmare by Anonymous Coward · · Score: 0

      You missed the point entirely, didn't you?

      This wasn't some theoretical code developed to prove a point. It was actual, production code from VistA. Furthermore, MUMPS does nothing to prevent such code from being written. I'll bet that 80%+ of the code looks exactly like this, and maybe 20%- looks like your "modern conventions".

      As for your idea of refactoring, I'll bet you a week's pay that won't happen. Management hates to spend money on refactoring. Frankly, you need to address bigger issues, so spending money on the MUMPS code base is a poor use of resources. What are the bigger issues? Very likely:

      - no native web interface. Such things may very well exist but if so have been bolted on as poorly integrated external subsystems;
      - no modern database. Really, the embedded hierarchical db is garbage, and doesn't even have proper datatypes;
      - mobile support is likely laughable;
      - no standardized error model;
      - graphics support is a joke. The best the system can do is to link to an externally supported graphic file;
      - foreign language support? How? There are no foreign language characters. Unicode? What's that??;
      - no 3rd party report writers. All MUMPS systems get around this by replicating to a relational database. Which is a viable workaround... which reveals the necessity for workarounds;
      - no database engine. Which means that field contents cannot be enforced, among many other things.

      MUMPS based systems are trapped in a time warp. They largely ignore almost 50 years of progress in Computing Science. The truth hurts, but it will set you free.

  27. Queensland balls up by bigtreeman · · Score: 1

    Of course it's costing 95% for support and maintenance, there are no licensing or purchase costs. Would that last 5% be hardware costs, management costs, biscuits for morning tea ?

    When is a commercial EHR system not proprietary and when is an open source electronic health record system proprietary ?

    Governments all over the world are busting to give OUR money away to big corporations !!!

    Projections of $11B over 18 years, who's a betting man ? will it double or triple over the 18 years ???

    The health department system implemented in Queensland, Australia was a total balls up. IBM ?

    --
    Go well
  28. More like GS employees by Anonymous Coward · · Score: 0

    They're getting rid of a MUMPS system, so it's still a good deal.

    And in the case of Accenture, if the cost actually does go over, it's the government employees fault for writing shitty requirements specifications. And it's even more the government's fault for making contractors iterate because a couple of GS 14s can't agree on what the requirements, don't fucking understand what they're asking for, and probably don't even understand what the requirements really are. Not to mention excessive overhead of paperwork to make sure they're getting what they're asking for and that Accenture isn't cheating them. Then there will be the invasive, arbitrary and ineffective security protocols because the Govt. Infosec. asshole want's to display penis size. And lastly there will be a grossly ineffective change management system that will cause huge delays in bugs actually getting fixed. And every single missed/wrong requirement will take at least twice as long to fix as it needs to--A good guess for percentage of missed/wrong requirements would probably be somewhere between 50% and 200% meaning they will let a lot of them wrong multiple times.

    I've seen both sides of this shit, and as bad as the contractors are, the GS employees are just as bad because they frequently and arbitrarily change their mind about the way something needs to be done; because they can. "Yeah, I don't like the way you did this, lets do things this other way instead." Contractor, "But this is what we were told to do last year."

    All of which will mean cost overruns in the billions.

    So my theory for this is gonna be: Govt spec: "We're going to do this and version lock on Java 1.8_54" when the project is completed, that will no longer be a supported platform, and they will spend billions more upgrading to Java 1.10_67; and repeat because they won't be allowed to upgrade as patches and releases come out.

    1. Re:More like GS employees by Anonymous Coward · · Score: 0

      1.8_54 .... government. XD

      On a government system this large, you'll be lucky if it's not on java 1.6 with libraries/frameworks laid out when the planning and requirement gathering started 7 years prior to development starting. All of whom involved in the design are already long gone having already finished snorting the cocaine bought with the absurd quantity they billed to deliver one shitty document with a vague 10,000 mile high overview. Said 20 page shitty design document will be held sacred, no reality can change it, because no one wants to admit to themselves they just got ass rammed that hard. ... yes I've been on such projects.

  29. Has anybody checked out the VistA help doc !!! by sandGorgons · · Score: 1

    Here Jeez, it seems they use the GT.M embedded database and a GUI that connects directly to this database... kind of like PGAdmin3. They use the MUMPS scripting language to build logic into the database (kind of like stored procedures). the deployment doc on Linux is a mess. Wow!

    1. Re:Has anybody checked out the VistA help doc !!! by Anonymous Coward · · Score: 0

      Has anybody compared that deployment doc to the one for the winner of the contract? Oh, it's not done yet? Surprise!

      You want a deployment doc? That'll be an extra 2.4 billion, produced on completion of the contract, but payable by 2016.

  30. Re:Good response by Dutch+Gun · · Score: 1

    I offer MS Word in evidence.

    You'd be better off choosing as an example something other than a piece of software that a significant percentage of businesses on the planet pay for and use with no significant problems whatsoever. It could be argued that MS Word may be one of the most successful pieces of software in history. There are plenty of examples of terrible closed-source, proprietary software. Why not use one of those?

    --
    Irony: Agile development has too much intertia to be abandoned now.
  31. Re:Sometimes updating legacy systems is a real pai by Curlsman · · Score: 1

    "Space is hard" and this is harder, because it's about ourselves.
    This has no chance until someone like Pres. Kennedy chooses to do it "because it is hard" to do.

    I think this, updating legacy system (something I do), is close to the second problem, which is that no one person or team has a grasp on how it works now, and what ever is put in place will be in the exact the same situation: no person knows it all. The only way I've seen this addressed is that after the Big Problem is cut into the Smaller Problems, the people involved with each Small Problem have to be to only ones who understand it: it must be accepted that there will never ever be a global "this is how it works" person or team.

    Then the first problem can be addressed: interoperability. Each Small Problem can then announce (or publish) how they solve their problems in their area of expertise. Then tell all the other vendors that they will interoperate with them in that way. This is not the way this has been stated so far, where the new system will interoperate to all the others, which won't happen for the simple fact that all the other vendors don't want to, its not in their self interest.

    The third problem is inherent in our species: we change, so no static model can be used to organize the data about us. The next versions of HIV, Ebola, anti-Vaxers, are all changes that will strain any extensibility, but most especially a government/military/project planning approach that can only deal with statically defined, long term goals. In the 18 years of this project they will always play catchup.

    So, yes, centrally defining EMR is going to fail, absolutely (or the Soviets would still be a power...).
    My only poor suggestion is to find a way to give each medical specialty, including ones yet thought of, a way to define their own representations of their expertise and publish it so those working in that field can interoperate with each other. Something like a distributed/grid processing system that includes distributed people being involved.

    Google searching still requires that you know that you have the results you want when you see it, where a library is organized to begin with, so Library Science has been trying to do this for a centuries and it might be worth studying to understand some of the problems.

  32. Not all Open source is good. by bloodhawk · · Score: 1

    VistA is a shit legacy system, so it seems DoD made Half a right choice. However given the companies they got involved they will just end up with something almost as bad, if not worse.

    1. Re:Not all Open source is good. by Anonymous Coward · · Score: 0

      The current system, Ahlta & CHCS, is much much worse than Vista. The DoD tried to get away from Ahlta, but the courts told DoD they were in a you're screwed contract. Ahlta is absolute mess. Vista is very bad, but Ahlta is worst. Ahlta requires "4GB" minimum to run. It only runs on Windows XP x86 (last I heard). Not allowed to install any other software (such as MS Office). Has no upgrade support. Need to upgrade Ahlta, that means to reimage all computers. It has hundreds of random dll files that are xcopyied to C:\windows\system32\ in which those dll files seem to be just randomly downloaded from the web from the 1990s. For example, using adobe reader 4.0 dlls to do pdf exports? What's that about! It's likely that many of those dll files aren't licensed properly for redistribution. All the servers are intel itanium. It is as though the whole system is to make the software to be vendor locked-in as much as possible. The list goes on, and only several billion has been already spent.

    2. Re:Not all Open source is good. by Anonymous Coward · · Score: 0

      You don't spend billions upgrading from one pile of shit to a slightly better pile of shit (well they regularly do but they shouldn't). The DoD made the right decision here for a change, albeit with some questionable choice of vendors.

    3. Re:Not all Open source is good. by serviscope_minor · · Score: 1

      VistA is a shit legacy system,

      From Stroustrup's FAQ:

      What is "legacy code"?

      "Legacy code" is a term often used derogatorily to characterize code that is written in a language or style that (1) the speaker/writer consider outdated and/or (2) is competing with something sold/promoted by the speaker/writer. "Legacy code" often differs from its suggested alternative by actually working and scaling.

      The VA system probably works. 50 bucks says the $9,000,000,000 system will never work.

      --
      SJW n. One who posts facts.
    4. Re:Not all Open source is good. by Anonymous Coward · · Score: 0

      The $9,000,000,000 system is already working in thousands of hospitals and clinics around the world.

      If it doesn't work, it's because the contractors setting it up aren't doing it right. But they have the benefit of thousands of reference implementations to choose from, for both good and bad examples. They'd have gotten the same with Epic also, although it would have been more expensive with a smaller install base and less implementations to study. Compare that to VistA derivatives where even the underlying code is different from place to place and it's clear that they took the safe route.

    5. Re:Not all Open source is good. by dmr001 · · Score: 1

      Guess which large-scale EMR physicians prefer above all others? That would be VistA. I've heard the same from colleagues, and found it reasonably sensible back when I rotated through the local VA as a family medicine resident. It was fast and fairly benign on the infuriation scale. Of course, the VA is apparently working with Accenture to update VistA, and are eventually looking to replace it with a commercial system. I have a feeling many VA docs will offer this to be prized from their cold, dead hands.

      And for all the griping about MUMPS, whose syntax (especially in legacy code) I agree looks like a cat walking across the keyboard, in real life on our MUMPS-based EMR it is faster and far more reliable than the Oracle-based system we upgraded from.

  33. Idots by Anonymous Coward · · Score: 0

    Just like the rest of the US government, DoD is run by idiots.

  34. Staggering Amount of Money by awol · · Score: 1

    As an outsider, who writes software for a living (proper, highly available transactional systems [finance industry but I do know some general stuff]). This amount of money is simply staggering. Even if we assume the published number (4.3B), 3% inflation, a relatively aggressive annualised ROI and 10 years over which to apply the costs, that turns into between 80 and 160 [20% ROI to 10% _annual_ ROI] million dollars per year in costs. IN COSTS. Even if you margin those costs at 33% (profit is already accounted for so the margin is on costs and risk) that's still 50 - 100 million dollars a year of costs to develop and support this system every year for 10 years. WTF kind of project are they planning? People have written software that changed the freaking world with a fraction of that amount of money.

    Now having said all that, I have a little window on the way a different government developed their budget for an IT project. They knew that the new project would make 60 people redundant so they looked at the cost of those people, multiplied it by some number of years for the scope of the new system and went... There you go 30 million dollars.

      There is something very, very, very wrong with government.

    BTW, There are about 20M veterans in the USA, give em all 200 bucks and let them keep scans of their own records on a freaking thumb drive. Backed up to, S3 or something. That might even actually work!

    --
    "The first thing to do when you find yourself in a hole is stop digging."
  35. HOW I CURED MY HERPES VIRUS by Anonymous Coward · · Score: 0

    My name is Ella Cooks, I am here to give my testimony about a doctor who helped me in my life. I was infected with HERPES SIMPLEX VIRUS in 2012, i went to many hospitals for cure but there was no solution, so I was thinking how can I get a solution out so that my body can be okay. One day I went to visit a friend and she asked why i was looking so sad i explained to her my problem, she told me that she could help, she introduced me to a doctor (Dr West Kakudu) who uses herbal medication to cure HERPES SIMPLEX VIRUS and gave me his email, so i emailed him. He told me all the things I needed to do and also gave me instructions to take, which I followed properly. Before I knew what was happening after two weeks the HERPES SIMPLEX VIRUS that was in my body got vanished. so if you are having sleepless night thinking of how to get the cure to this virus here is the answer, you can also email him at: (dr.kakuduwesthealingtemple@outlook.com)

  36. Cheaper than licences tomake OS S/W interoperate ? by fygment · · Score: 1

    Seriously, why not have paid for licences (if required) and make the OS software interoperable with commercial systems?

    With the added benefit that the result would mean the DOD and VA systems would be compatible !

    --
    "Consensus" in science is _always_ a political construct.
  37. 95% tells us nothing by jsepeta · · Score: 1

    If they were only planning to support legacy systems, of course that money is designated to support legacy systems. The only way to drop it from 95% is to increase the budget and add other line items, such as new systems.

    --
    Remember kids, if you're not paying for the service, YOU ARE THE PRODUCT THAT IS BEING SOLD.
  38. very little Open source is good. by Anonymous Coward · · Score: 0

    FTFY.

    I can't think of ANY significant open source projects that are better than their closed source competition. Linux? Don't make me laugh. Makes for an OK, if extremely unreliable and insecure, server OS, but is only popular because it was in the right place at the right time. Apache? Meh, not really a "significant" project, in that it is just a web server and few companies even care about competing in such a commodity/niche market. LibreOffice? Used by almost no serious end users, it's all about people/groups who just want to pay $0 for something that sort of works and they don't care that it actually suuuuuuucks. GIMP, same story.

    Open source is a scourge on our industry. Reducing pay for coders while simultaneously devaluing our work.

  39. Leidos Just Laid Off 100 IT Workers by Anonymous Coward · · Score: 0

    Leidos just signed an outsourcing contract with HCL. They are making 100 IT workers re-apply for their old jobs through HCL, if they even get a job. But they just got part of a $4.3 billion dollar contract. Nice. This will surely work out well!

  40. Vista by Anonymous Coward · · Score: 0

    I heard Vista sucked.

    Oh wait. *That Vista*. Never mind. Too late - my manager has run off to golf with someone promising something much better.

  41. Why Cerner and Accenture ? by Anonymous Coward · · Score: 0

    We understand if DoD does not want to go with MUMPS let them don't.
    MUMPS is outdated.

    Why Cerner and Accenture ? They are crap in Medical field.

    Their systems are too propitiatory and no code is available anywhere to compare.