Starting IT projects in the healthcare sphere always imposes a set of various challenges. It may seem quite a simple thing if you aim to add some minor features to improve the general appearance of an existing and well-working system. However, creating a new EHR/PMS system from scratch demands the help of companies providing market research services and a wide range of experienced specialists working on the intersection of medicine, legislation, insurance, billing, and other fields. Any mistakes in handling the Protected Health Information, composing fees for the provided services, or managing the claims sent to the insurance companies can ruin the reputation, workflow, and profitability of the product. That’s why starting a project with skilled physicians alone won’t inevitably end in success, though it definitely solves the problem of consulting with a subject-matter expert in a particular specialty. The best idea on how to avoid at least some of the possible problems is to reach out to a Business Analyst (BA). You can read more about the role of a BA in a project in our article on this topic. And here, we’ll focus on how cooperation with a BA helps companies to develop high-quality healthcare products. Why is a BA important right from the start? The quicker a BA gets in touch with the lead, the faster an understanding can be reached. Speaking to the BA during the Presales phase can speed up the process of documentation investigation and agreement on the general business needs and the way the software company may help in solving them. An experienced BA with a background in healthcare projects not only delivers full-scale competitor analysis services but can also easily give the lead a clear opinion on the company’s product and its features, as well as on the team’s expertise. This specialist suggests using the opportunities of existing open-source or 3PP solutions to save resources during development. In case the lead already has an EHR/PMS system, the BA would be the one to provide the benchmarking to define the product’s position on the market and check its current workflow to find the drawbacks and the ways to improve it. Asking the right questions would also help to define the right scope for the project and clarify crucial issues the lead could have overlooked. For example, the lead has come up with the idea of adding a TeleHealth feature. It seems obvious to the lead that it should be developed from scratch, as this is stated as a mandatory requirement from the security angle. After asking several guiding questions, the BA could find out that the lead had no idea about the possibility of integrating a safe HIPAA-compliant WebRTC solution and customizing it for the specified needs of the customer and end-users. Moreover, some of the available solutions provide built-in options for conducting online payments and online billing. This can reduce the number of issues associated with collecting payments and developing a separate form for patients to fill in to get advice. In that case, implementing the 3PP product would save the customer a significant sum of money. The BA’s work on the Presales phase results in drawing up a Feature list or Vision and Scope document, with the main modules listed and used by the team. This gives a rough estimation of the project’s duration and price. And here, the lead faces one of the main characteristic differentials of healthcare projects: missing one single feature may significantly affect the project’s value or even make it inappropriate according to the legislation rules of the market. That’s why it’s highly recommended to start the project with a Discovery phase. Discovering more The importance of the Discovery phase for healthcare projects is usually underestimated and hence often ignored. At the same time, applying the BA’s skills during the Discovery phase gives a real chance to perfect the rough estimation of the project and understand the product’s environment better. This stage may be partly spent on checking the existing functionality to clarify business processes and define the ways to optimize them. Furthermore, composing different kinds of artifacts (User Story map, business process diagrams, context diagram, etc.) along with preparing mock-ups will save time for developers in their attempts to understand the business logic of the product. Additionally, special attention should be paid to elicit the non-functional requirements, as this is the best way to find out about most of the limitations and legal restrictions the product should correspond to - for example, in PHI storing or data transferring. Another challenging task is to define the scope for the initial (MVP) and subsequent releases. In most cases, when adding or removing features from the list, a review of the whole feature list is needed to check that the interdependencies have been preserved. Helping the customer to find the balance between the speed of the development, its cost, and crucial functionality for the particular clinic requires a deep understanding of the customer’s business processes, which can hardly be expected from the development team or a Project Manager. We had a case when the lead approached the outsourcing company with a question about whether it’s possible to update an existing system by simplifying its UI/UX for end-users and adding a few additional features, including a chat for secure communication between a patient and a physician. During the Discovery phase, the Analyst investigated the solutions used by well-known EHR/EMR systems and came to the conclusion that, in most cases, the problem had been solved by creating a separate Patient Portal as a secure tool for communication. Also, the creation of the Patient Portal allowed for transferring a considerable amount of functions for the users there, reducing the number of tabs and elements on the user page. What a miracle! In some cases, during the Discovery phase, the BA may compose a set of User Stories for the initial sprint or find the API integration documentation for outer systems. All these actions are aimed at helping developers by estimating the project’s running time more precisely and saving their resources during the development phase. Productive production Conducting a successful Discovery phase doesn’t make the BA’s presence in the rest of the healthcare project phases any less necessary. Involving physicians into the development phase won’t contribute much to business process optimization or the fruitful collaboration between the team and stakeholders, as both sides provide diversified expertise with little convergence. The absence of a BA may dramatically affect the quality of any ordinary project, let alone a healthcare one. In addition to common risks connected with the scope creep, missing documentation, and partial feature implementation, we may face non-compliance of a product with the existing legislation rules, contravention, incompleteness of the developed workflows, and lack of integrity and consistency of the system. Moreover, violation of regulations on secure data collecting, storing, and transferring might result in failing the certifications that are essential for launching the product onto the market - or in huge fees to the healthcare service provider. Though the above mistakes can be elicited and amended with the help of companies that conduct audits and provide IT consulting services, the project’s terms and budget would be overrun. That may lead to irreversible reputational harm and spoil the image of the company. To avoid such problems and maximize the profit from the product, involve qualified Business Analysts in your project as early as possible.
