The ehealth Quartet – what is an ehealth (digital health) team comprised of?

The right composition of a team is critical to a team’s success, that’s true in any field for any type of work. In the multidisciplinary world of ehealth, it ensures that a correct mix of talent and a correct mix of perspectives are present to tackle difficult healthcare problems from all angles. Among this mix are four main types of roles: clinical, business, technical, and project. This is the ehealth quartet.

In this blog, we'll have a brief introduction to these four roles and take a look at some examples to what each one does through a sample ehealth project to build a health analytics software to be implemented in the Emergency Room (ER).

Clinical

Also known as subject matter experts, the clinical member of the team provides the ehealth team with key knowledge about healthcare and clinical processes to help steer an ehealth project in the right direction. Their clinical expertise helps guide the design and implementation of ehealth solutions to ensure the end product will fit existing workflows and meet the expectations of end users – ie. usually clinicians themselves.

The clinical member’s familiarity with healthcare also helps them to identify opportunities for clinical improvement using ehealth. As a result, they are usually the ones to propose for ehealth projects in the first place. This leads them to a critical role of championing (or finding a champion for) the ehealth solution – pushing forward the ehealth project to be successfully adopted by a healthcare team.

In our health analytics example, the clinical subject matter expert may be an ER nurse who sees a pattern in patients that consistently return to the ER for preventable reasons. As a result, the ER nurse proposed a health analytics software to help catch these patients that match this pattern so that the team can plan for early and targeted interventions.

The field experience and knowledge of this pattern in patients (clinical expertise) of the ER nurse (clinical subject matter expert) helps for both the technical design of analytics software and also the field implementation of the analytics within the ER’s workflow. For example, they may hint the technical team member to analyze for patients with specific traits A, B, and C. Further, to make their idea a reality, the ER nurse may motivate his/her colleagues to drive its adoption, and raising the idea to senior management who will be able to further champion the solution across the ER and sponsor a project team with assigned resources.

Business

Consider healthcare as an enterprise – where its business is staffed by clinicians to serve patients (clients) and financially reimbursed by, in the case of Canada, the government.

The business member (usually called business analyst) focuses on describing and analyzing the business process of healthcare to identify the value of ehealth solutions. This can include articulating process improvements and identifying cost containment opportunities associated with the delivery of care. In the context of ehealth, business analysts will consider the cost, risk, impact, and benefits of technology in the analysis of their implementation in healthcare workflows.

In our health analytics example, the business analyst will map out the old (as-is) care process for the target patients for the proposed analytics software in detail. Their mapping will follow the journey of both the patient and the care provider. This prepares them to evaluate the cost and the benefit (clinical outcome) of the original care process to establish a baseline for comparison with the new proposed process. This endeavour typically requires back and forth between the business analyst and the clinical subject matter expert or even with other stakeholders (such as patients), if necessary, for the business analyst to fully comprehend the complexities in care and the financial and clinical implications (and caveats) of the care process.

With that exercise, the business analyst can then consider the proposed analytics software or another solution to design the new (to-be) process. In so doing, they determine the requirements of the new ehealth solution. For instance, they can suggest to add patient analytics during ER admissions to flag patients for home support after discharge because that will generate the most savings for healthcare. Again, this analysis process will require extensive consultations with experts (either part of the team or not). Finally, they will then pass along the requirements of the new ehealth solution to the technical members who can develop the actual analytics software.

Technical

The technical team member of the ehealth quartet is responsible for the actual technical design and development of the ehealth solution. Their technical expertise helps the ehealth team navigate oceans of technologies to pick out the most suitable. Usually equipped with some healthcare knowledge, the technical member's understanding of the underlying healthcare process is useful to making informed technology recommendations.

The technical member's work involves extensive collaboration with the entire team. Clinical experts and business analysts will help them grasp how the software they're building will be used - this is especially important for building technology components that require user interaction (such as the design of page flows).

In addition, the technical team members also help plan and estimate cost and timelines associated with the development of the ehealth solution so that an adequate amount of budget and resources can be allocated for the ehealth project.

In our analytics software example, the technical team members will help choose the analytics engine and provide to the team cost estimate and timelines for its development. Finally, they will develop the software together with clinical and business members to make it available in the ER.

Project

Arguably the most organized person in our quartet, the project manager finalizes the detailed plan for ehealth solution development including cost and amount of resources required and when. This member also coordinates team’s touchpoints and regularly tracks team’s progress toward completing the desired goal. Typically, the project manager will report updates to the project sponsor (a senior executive). These regular updates avoid surprises before it's too late if things don’t go as planned.

Project managers often work with ad hoc teams formed resulting from specific needs of projects. The team composition may also change with time as the project progresses. With so many moving parts, much of the organization and administrative work involved is taken care of by the project manager.

In our case of implementing analytics software in ER, the project manager will first plan with the team how much it will cost and how many people are needed and for how long to complete the project. This information will be summarized and presented to the project sponsor (ie. vice president of the hospital) who will allocate resources for the analytics software project. During the actual implementation, the project manager will actively call meetings from all parties to track status of work and compare with the plan to make adjustments or more requests to the VP as needed.

The ehealth Team

The ehealth quartet is defined by four areas of expertise required in any ehealth project – reflected in the team's composition. While quartet members will assume the roles of clinical subject matter expert, business analyst, technical wizard, or project manager, their expertise are often not limited to their respective roles. For instance, the project manager may have some technical background while the business analyst may also know about project management. Oftentimes, team members will also wear multiple hats as human resource may be constrained.

The ratio of different members within the ehealth team may vary across different ehealth projects. For instance, ehealth projects that involve building a new software from scratch may need more technical members while projects outsourcing existing technology may need less technical members. The specific composition of the team may also vary to include additional roles, but that's beyond the scope this discussion.

Note that the organization of this quartet is not exclusive to ehealth. Software development project teams in any field typically has project manager, business analyst, technical developers, and also someone with domain expertise in that particular field. But teams working in ehealth field in Canada face unique challenges such as poor funding, low tolerance to risk in healthcare, privacy concerns, sentiment against technology, resistance to change, to just name a few. That said, the benefits of technology use in healthcare along with shifts in care delivery models have given ehealth teams a tailwind to move forward to the success of their ehealth projects.