Healthcare Data QA
This website provides an overview of the software processing of medical data, with an emphasis on the traps that are often present.  
Home
Introduction
Software Design
Basic Obstacles
Data Input Problems
Human Obstacles
EHR DataBases
CSV Files
XML Files
Reports
Statistics
Legal
Other


© 2022 Kevin Pardo
    

Human Obstacles

Differing educational backgrounds, levels of arrogance, and years of hands-on experience make cooperation on tech projects difficult. Here are a few highlights for healthcare IT.

          Sometimes we let our guard down and believe that a project will be simple. Wait until you hear the requirements and see the data before expecting a happy project.
 
          A lot of people care more about harassing workers than project success.
 
          EHR vendors tend to consider independent programmers as somewhere between competitors and parasites. Certainly the tech world has a lot of opportunists, but the hassles from EHR companies can be unjustified.
 
          Even individuals who are well educated often are not able to articulate what they want. People are just not trained in organizing their thoughts. It is as if an architect asks what dimensions a dining room should be, and a rock star client simply replies, "BIG." If people don't organize information regularly, they will be incapable of defining data and software behaviors. Expect to spend a lot of time rewriting documents from users.

Divisive Beliefs: New college graduates often join projects believing that certain rules or priorities are straight from God. Conversely, if they have not heard of them, they believe that some practice must be worthless. Here are some of the beliefs which may arise on technical projects and cause strife.

  • Software developers are low-status and their work is trivial.
  • Software developers must implement everything the client has requested, mentioned, or imagined.
  • All projects should have large releases. Prototypes and staged releases are not needed.
  • Technical people benefit from many "helpers" to document requirements.
  • High-status team members have the right to trash the database schema.
  • Software should produce perfect results.
  • Projects should use only the newest technologies.
  • Java software design should maximize the use of interfaces.
  • Core data should be normalized.
  • Reports should be formatted to be easy to understand and explore.
I generally support the last two, but there are always real world problems which will interfere. If you are going to "battle" over project decisions, it should be with the goals of keeping a design simple and the database schema coherent. Once a design is trashed, all future work will be handicapped.