Electronic Health Records are gaining in popularity. ISVs have been focusing on EHR technologies and systems and processes for EHR integration and implementation.
We have interacted with CTOs, technology mentors, and heads of various EHR ISVs in North America. We found that many of our concerns on the development side are similar.
We want to comment on methodology, communication, code management, and engagement in a separate blog. Here, we list the business concerns that top executives share.
Most of the time, the techie mentality prevails. This is why it needs a business and regulatory perspective. In-house and third-party development teams need to understand business issues in depth. They are happy with the technological depth but build something that has yet to be accepted by users.
While developing specifications, the healthcare industry’s knowledge transfer overheads are compounded, increasing time, effort, costs, and unhappy users.
The difficulty in integrating existing/new systems with data leads to the creation of another island application. Everyone has implemented something; the investment should be capitalized, not written off. As mandated by regulators, the approach must consider data integration and migration requirements.
Adapting to the changing dynamics of regulatory needs, such as MU1/2/3. It is crucial. Regulator guidelines for MU1/2/3 can influence the way EHRs are designed. Product and data engineering teams must understand business aspects.
EHRs generate a large amount of data. These data are a wealth of information and should be used to crunch them to find patterns, insights, etc. Predictions and decision-making can be made.
The funny situation “right hand doesn’t know what left hand is trying to do” can be caused by a lack of knowledge about clinical vocabulary. Product teams need to understand clinical terms, references, etc. To a sufficient depth to translate this knowledge into a robustly-engineered product.