AVOID: Decades out of date, nickel and diming and more manual work.
Use Cases and Deployment Scope
Pros
- The program is aesthetically acceptable
Cons
- Cannot scale. This system was originally built for use within a hospital mainframe and has limitations baked in as a result. Modern reporting is nearly impossible due to the nonsensical data structure required by the ancient (by computer standards) 1970s era bones of the backend. This is uniform throughout the system.
- Must have technical staff versed in what's essentially a dead programming language, MUMPS (created in 1966 and last updated in 1995), to make meaningful changes to customization. Permissions are extremely granular with no way to make changes across multiple permissions. Meaning if a person cannot see an item on a dropdown menu, or if a new dropdown menu is added, it then has to be added manually to every single other permission that you'd like that menu to appear in. This is naturally a big opportunity for errors to occur and is also a problem that has been solved in even 1990s era software.
- Support is lacking and setup staff don't put effort into making sure that the system is set up in a way that makes sense. Staff are happy to present entry tables with duplicate fields, fields that will give an error that gives no information as to what needs to change for the error to go away (quite literally '???'), fields that are laid out nonsensically. Example: The USPS address format: address, city, state, zip? No, they'll be scattered across the fields with city and state somehow combined into one field. Staff will present this to you as normal and how things should be structured despite two centuries of USPS address structuring precedent.

