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!
