I belong to a group of LinkedIn members who are trying to provide advice and assistance to individuals who have gone through various Healthcare IT training programs where, it seems, there is undue concern about Databases.
Not sure who started this DB is a DB is a DB thing but it is not relevant to the discussion.
In healthcare we have moved beyond this quite a number of years ago to where it is like worrying about what type of transistors are in an electronic device such as a PC. Most people just want to know where the On button is.
Purchasers of advanced software systems no longer need to worry about tables/fields because all of the steps can be automated.
In the case of all Civerex mainline software products (health, law enforcement, manufacturing), we long ago removed the requirement for our customers to build databases. It’s not mainstream to what healthcare professionals do in rendering healthcare services to patients.
Our customers build workflows in a drag and drop graphic environment, they also use a drag and drop form painter to build data collection facilities – all of what they do to configure their application systems is visual and graphic.
Hand-crafting commodity level applications is no longer needed if you have access to software that is more sophisticated than legacy software based on the model:
“enter data> store it >retrieve it >display/print”.
In many applications, healthcare included, the workflow goes like this
intervention > intervention > intervention . . .
and where the data goes and how it is stored is not front and center.
What is important in any individual patient EMR is the ability to view data, as it was, at the time it was collected, on the form versions that were in service at the time. (again visual – go to the EMR, point to what you want, click). End of. . .
In an EHR, if you care to make the distinction, the requirement is to be able to carry out data mining/statistical analysis ACROSS patient populations and here, yes, in the normal course of events, you will want a data warehouse with choices re how data should be stored so as to optimize whatever it us you are trying to accomplish.
One of our customers took one of our healthcare products and added 5,000 custom data elements. Many DB experts will tell you this is “difficult”. One even told me it is “impossible” until I made him build a workflow himself on-the-fly. It’s hard to say things are impossible when you are actually doing them yourself.
Not difficult, nor impossible, in the products we build – you could easily add 50,000 or 500,000 custom data elements (not that anyone is likely to want to do that).
The other thing that worries me is the great concern at many levels (employers, recruiters, prospective employees, educational facilities) regarding specific products.
Do people only buy cars they have experience with older models of? No. So, the only reason anyone cares about experience with vendor A’s product versus vendor B’s product, again, is because that product is difficult to use.
It would be disconcerting to have to take a 6-month course to work for a company that hands out Honda’s to their sales staff.
Again, go back to workflow.
What is it all of us do, every day, all day long? We attend to our fixed time commitments and then we perform all other work between these fixed time appointments. So, who needs a UI that has more than ONE split screen that shows a calendar and a to-do list?
Does it not make sense that if you map out your best practice protocols and put these in line so that auto resource allocation. leveling and balancing software will be capable of posting tasks to the right people such that the rendering of services to a patient along an individual pathway of care ends up being guided by the mapped, compiled best practice protocol?
if the users see THEIR workflows posting THEIR forms, how much training is likely to be needed?