Databases, specifically Structured Query Language (SQL) databases, are known for being a weak point in the different layers of security that online businesses must implement to be safe-and-secure from cyber attacks.
SQL injection attacks are responsible for many of the most egregious violations of consumer data and privacy. But in the field of healthcare and Electronic Medical Records (EMR), a database breach is not simply a Public Relations fiasco but also a violation of HIPAA law. However, the potential risks do not override the necessity of having a database structure in-place to store such information.
It is well-known that content design is an under-appreciated element of EMR system design. The role of capturing and managing information is paramount to the optimization of an EMR system.
The access time and nuances of data interaction can be orders of magnitude higher if proper structural planning is not undertaken at the project’s inception. Ideally, the database structure (this is to say, the rows and tables created and used by the EMR system) should embody and empower the standard procedures of a particular team, rather than having to wrestle with a one-size-fits-all template that may interfere with day-to-day operations.
Experts have suggested that clinical care, efficiency goals, and business goals should be reflected within the information structure (along with policy considerations) via the tables and fields within these databases. In addition, these structures should be created with outflow in mind as well (e.g. the output format of reports).
One of the most central considerations in database-driven EMR software design is specialized vs. individualized. In short: should one use separate assessments, progress notes, and treatment plans; or should one create forms to account for all of these specific scenarios.
Many believe that these types of decisions can really affect the success of new software in a given deployment. Rather than forcing one’s employees to adhere to how a system would ideally work, it’s better to design it around what already works and introduce changes to the workflow gradually
In regards to specific data types, it is possible to save complexity (and thus memory and processing power) by using standardized fields with choices. However, by using these dictionary data types, other benefits are gleaned (such as the ability to aggregate and analyze in more meaningful ways). Despite these benefits, in certain situations, a free-text data type makes more sense than a dictionary data type.
These are the types of choices that drive database structure and design for EMR systems. By keeping in mind the nature of the data, and more importantly, how people interact with it, the database can be leveraged to increase the speed and efficiency of a given implementation.
