Updated 31 August, 2021
When it comes to industry-specific custom development, there is a one-of-a-kind area where enhanced experience is required. It is known as Health Care (or Healthcare). The following article is a concise explanation of some special aspects we were faced with while working on the development of medical software for the United States.
Table of contents
HIPAA-compliance
Healthcare software is often referred to as EMR - electronic medical record - or EHR - electronic health record. Such systems store personal data of patients, which demands high security standards.
There are security standards for Healthcare software regulated by the government. They are defined in a Health Insurance Portability Accountability Act - HIPAA. It contains a variety of rules to assure safety of personal data.
The whole act is quite long. However, requirements related to the technical side are much shorter and have only two mandatory provisions: unique user identification and emergency access procedure (in whatever form - see technical safeguards in paragraph 164.312). A medical software which has these two requirements can be called HIPAA-compliant if other administrative safeguards are met.
There are some other addressable requirements in the regulation text which should be taken into account in medical records software development. Our experience showed that encrypting all the data in the database or at the time of transmitting the data by HTTP has more disadvantages than advantages. The same is valid for automatic sign-offs which can make users mad.
There is no need to complicate their work in such a manner because web applications are well protected by standard means. The same is valid when we build a database for electronic medical records - they are protected by an SQL server and by the Secure Shell protocol.
What is EMR in healthcare?
Developing a custom EMR electronic medical records system can be challenging due to the overwhelming number of medical forms and standards that must be adhered to, rather than just security rules. These standards can typically be found on the website of the Centers for Medicare and Medicaid Services.
Our team has experience with MDS 3.0, OASIS forms, RUG IV, EDI, and other similar issues. These forms contain a vast number of fields that must follow specific consistency rules and be arranged in the correct sequence.
For instance, MDS 3.0 forms have over 800 fields that must comply with more than 200 validation rules, while OASIS forms are only slightly smaller. Additionally, it is important to note that completing these forms in the correct order requires a specific workflow tied to particular dates.
RUG, EDI, CAT, CAA and other "smart abbreviations" were actually complicated calculations, sometimes with traces of "bad medical legacy". This way, there was much more than enough room for custom development.
In some situations, additional complexity was caused by changes in the standards which were appearing constantly. Nowadays, it seems that the regulations are finalized, so a developer can deal with them without returning back again and again. This is definitely a very positive aspect.
Another good point is that there are some people who have experience with the CMS standards and can share it. Back in 2010, we could not find a person who would know how to correctly process MDS 3.0, because the huge set of forms was new to nurses in all medical facilities. We had to extract the right information from the specifications and test the result by sending EDI files to CMS servers instead of simply asking people.
This way, on many occasions when working on a Healthcare project, we were impressed by the amount of work required to build the system, but it was a good opportunity to apply our skills and come up with elegant solutions. Also, it was a wonderful opportunity to facilitate the work of the nurses who had to deal with those overwhelming forms and fill out them manually.
Technology
In all our Healthcare projects (e.g. OnTrac), we used the proven Ruby on Rails stack and found it effective. However, there was some specificity related to the way of using it.
A fast database that allows writing flexible SQL queries is important for such products. It will be required to store a lot of data and most likely to build reports obtaining information from several tables. These reports have to be fast, so native SQL scripts can serve well.
We prefer using PostgreSQL as a flexible and predictable server for this class of tasks.
Also, it is reasonable to think about what to use on the front-end. Since medical forms are complicated and fields should abide by some rules, they will have hundreds of "moving" elements. Such elements should be enabled, disabled or recalculated depending on several factors; then the whole form should be sent to the server at once. Electronic medical charts make it easier for doctors to operate the system.
Some other features such as Care Plans may have hierarchical structure. Implementing them, a developer may need elements that expand and collapse and sometimes can be dragged.
Therefore, it is important to choose the right Javascript frameworks. There is a good amount of appropriate ones. Recently, we started using ReactJS for huge forms and we are happy with how it serves the purpose.
Agile values
Due to the specifics described above, building electronic medical record systems is a sophisticated process. Many chiefs of medical facilities prefer to use paid EMR and CRM software that are in the market rather than to build their own products.
It is a good idea to use online services until they serve the purpose. I would not recommend a client to build a custom EMR just to save money. But if the client needs a unique set of features or is tired of using multiple systems and gathering pieces of data together - welcome to custom software development.
Certainly, a bespoke EMR development assumes that the owner invests his time and energy in it. A good development approach will help to reach the goal. The agile procedure works well for such projects.
Close communication with the customer allows to understand the requirements and specifics of the usual procedure in the medical facility. Software developers are good at implementing specifications, but they need help in imagining how the real work goes on. This information allows them to help the customer get a valuable product.
Feedback provided by nurses and doctors is an integral part of development. Nurses and doctors are not usual users but rather field experts. So the objective of a developer is to "extract" the knowledge and install it in the project.
Agile developers assume simplicity in every user story and it leads to a greater stability and maintainability of the entire product. Without the aspiration to keep the code simple, medical applications tend to grow over months, so the time needed to make changes in them also grows drastically.
Conclusion
Developing a custom Electronic Medical Record is a complex process. The standards supported by CMS are complicated and one should spend some time on thinking through the right project architecture. When building it, it is recommended to pay attention to the output reports and closing statements, because they may be essential for defining the workflow and the timeline of medical procedures.
Our strong preference is to use the agile approach to develop applications of this kind, because it is natural in the circumstances where frequent feedback is a part of the development procedure. Also, it allows the project owner to try and adjust the functionality as it appears.
We believe that our experience and recommendations listed in this article will be helpful for businesses that consider outsourcing development of their EMR systems. If you have a Healthcare project - either a new or ongoing one - you may contact us and ask about the best way to move it forward.
