So, my father is currently in the process of "hacking" together a database using FileMaker Pro, a GUI based databasing tool for his small (4 doctor) practice. The database will be used to help ease the burden on reporting from medical machines, streamlining quite a clumsy process.

He's got no programming background, and seems to be doing everything in his power to not learn things correctly. He's got duplicate data types, no database-enforced relationships (foreign/primary key constraints) and a dozen other issues. He's doing it all by hand via GUI tool using Youtube videos.

My issue is, that whilst I want him to succeed 100%, I don't think it's appropriate for him to be handling these types of decisions. How do I convince him that without some sort of education in these topics, a hacked together solution is a bad idea? He's can be quite stubborn and I think he sees these types of jobs as "childs play"

How should I approach this? Is it even that bad an idea - or am I correct in thinking he should hire a proper DBA/developer to handle this so that it doesn't become a maintenance nightmare?

NB: I am a developer consultant of 4 years and I've seen my share of painful customer implementations.

Update:

So it's a few years later now, and I've had time to reflect on this question. My dad ended up implementing a solution using Google Docs, FileMaker Pro and some email hooks. He set the whole thing up himself, and he says he is getting immense value from it. 

If you are an experienced developer, you are perhaps reading that description and cringing. But I learnt a pretty good lesson from the whole thing actually - that people only care about the results, and not the implementation. All my dad cares about is the fact he doesn't need to enter patient information down on paper manually, and can instead quickly fill out a Google docs form. What's great is he's looking to hire a junior dev/ops person to focus solely on automation within his practice.

I've been engineering Healthcare solutions for many years. I won't go into all the different reasons that your father shouldn't be doing this; most of the reasons being academic: meaning, if you've been in the industry long enough you know how these things snowball and develop a life of their own.

Instead your father, as a physician, needs to understand the professional reasons and real-life, non-academic, reasons why what he is doing is dangerous and possibly life-threatening; dangerous to his colleagues, dangerous to his patients privacy and identity, and dangerous to his practice from a legal standpoint.

The danger is multi-faceted:


patient privacy (HIPAA, ARRA, Meaningful Use, HITECH Compliance)

what are the fields that are considered patient identifying fields (many professionals in the industry don't understand this, and just because you eliminate some of the obvious fields like last name, address, zip code there are still many other fields that would make it easy to associate clinical data to a specific patient; this, in itself, is difficult; there are companies out there making lots of money de-identifying clinical data - it's a whole domain in itself).

HIPAA, HITECH and newer legislation spells out clearly how

auditing should be done
security should be done
password requirements
should the data at rest be encrypted
should the data transmitted be encrypted, and how
you must consider the controls if you are using any kind of hosted service (IaaS, PaaS)
do you have proper BAA and DSA in place
how do those hosting your servers control access
how do they handle multi-tenancy (you'd be amazed at how some of these large entities do NOT handle this appropriately)
if you terminate the contract with those hosting your infrastructure, how will they ensure permanent deletion of your data (NIST regulations)

what are the governing controls in place for your development

do you have an sdlc in place
do you have traceability from requirements to code to QA
do you validate 'intended' use of your medical application/device

is your software being QA'd, and do you have a User Acceptance Test (UAT) environment 

how do you secure this environment, because you'll be using real patient data

is he going to handle medicare patients, if so is he planning to use his database to report out?

the government has strict controls in place for the exchange of this data to their Health Information Exchange (HIE)
which leads to how will he implement his own exchange if he wants to take advantage of his clinical data repository (CDR)

does he understand the particular NIST regulations he needs to abide by for data security

such as permanent deletion of data (if using a hosted infrastructure)

you mentioned he will be taking data from medical machines

does he understand the new FDA medical device standards?
starting in 2013, any digital system that displays data from medical devices can be categorized as a medical device ... this means he must meet the FDA regulatory requirements for medical devices

will his team and staff be making medical decisions based on the data in his database?

has he developed a solid clinical data model, flexible enough to handle the ever changing requirements (i.e., ICD-9 to ICD-10 to ICD-11 coding standards)?
how will he version the data model and keep it in sync with the data (i.e., if he changes the clinical data model how will older data be represented?)
will his system be able to produce an exact snapshot of the clinical data as it was seen on the day that a clinical decision was made? there are legal repercussions if he can't
does he know the difference between a real delete and a logical delete, and the implications to his data model; to his storage requirements; to his practice's policies?
does he have a vocabulary solution in place to handle all the different services he will need to use; much of the data needs to be coded (as opposed to free text), because he will want to take advantage of his CDR to produce ICD-9 compliant reports. And then he needs to take into account the changing of these standards; e.g., ICD-9 to ICD-10.
for vocabulary, terminology or Health Data Dictionary (all basically synonyms) how will he implement and ensure that old terminology can still be rendered for old clinical decisions?

will he be storing allergy data? 

how will his 'medical terminology' or 'vocabulary' definitions be stored? 
will he integrate with other terminology systems like LOINC and First Data Bank? 
does he have an understanding of terminology services (i.e., Health Data Dictionary)

will he want to have data interfaced into his system, and maybe out to a health information exchange (HIE)? 

if so, does he understand HL7 and its impact on his database?
does he understand interface engines and all that goes along with that?

does he understand how to de-identify information?

this is important in the development phase and the bug fixing phase



These are just a few questions, and by no means should it be considered a comprehensive list. And for each answer there will be countless more questions.

In a Healthcare database there should not be any deletion or over-writing of previous data. This means there are never going to be 'delete from  where...' or 'update  set ...'. Instead you will only have inserts. You can imagine how this changes your data model and your queries. Now you can be creative and come up with different solutions to attain this goal, but the fact remains that this is a requirement that is unique to the Healthcare Clinical Data repository.

Just one more thought regarding the life-threatening side of this issue: 

Let's take, for example, allergy information; I raise this one up because institutions who have been doing this digitally for years have learned that their processes need to ensure that allergy data is captured and that we can't assume that because technology captured the data in a database it is somehow inherently correct forever. This is why patients are asked for their allergies every single time as they move from one department to another, even within the same hospital. A patient's allergies can't be deleted (updates to a row delete the old information). A clinical decision based on digital data needs to capture what was 'presented' to the clinician at the time of the decision.

I know much of this may seem to be geared to a large institution. However, the regulatory parts aren't. And in any case, Healthcare Information Systems are inherently complex. Healthcare system engineering depends and recognizes the expertise and experience of good clinicians. However, there is a larger than average impedance mismatch (to borrow terminology from the ORM technology) in the Healthcare IT domain ... I venture to say larger because every domain has its mismatches.

Good luck!
