Defining medical simulators for simulation-based education in EUS: Theoretical approach and a narrative review.

Choosing the right simulator for tasks in simulation-based education in medicine will affect the trainees' skills. However, there is a shortage in the vocabularies used for describing medical simulators and the contextual usage of simulators. We propose methods for approaching the task of choosing and defining the simulators needed, regardless of it being an acquisition or development process. It is advocated that efforts are made in defining the simulator's requirements before making any choice in regards to development processes. Multiple advantages are attained by keeping the simulator simple, both educational and development wise. Issues on validating simulators are discussed and highlighted as actions where interprofessional communication is likely to fail. The following conventional terms in medical education are problematic in regard to establishing a clear communication: Virtual reality, fidelity, validation, and simulation. The text is finalized in a short discussion on applying the methods in an EUS/endobronchial ultrasound (EBUS) context. The work is the authors' interpretation of an invitation having the title "Development of EUS and EBUS training models and simulators."

INTRODUCTION

This text was made as an invitation to write an article on “Development of EUS and endobronchial ultrasound (EBUS) training models and simulators.” It covers the subject of when and how to make a medical simulator. It does not touch whether simulation before EUS practice is needed,[1] or make comparisons of existing simulators.[2] The text is an expert opinion/narrative review on making decisions regarding medical simulators in connection to the curriculum. The only assumption is that medical simulators are designed for simulation-based education (SBE). The specifics of simulators for EUS, as a combination of skill trainers for endoscopy and ultrasound is covered in the final part.

Making medical simulators, regardless of type, is often a polytechnical venture where creators have to decide on subjects that fall within the scope of a wide range of fields, e.g., materials science, computer science, biometry, physics, electronics, educational research, medicine. Thus, there is an apparent need for acknowledging that cross-professional communication can be challenging. Especially, as one word might have different connotations or even different literal meanings between each profession. The authors’ experience is that especially; simulation,[3] fidelity,[4] virtual reality, and validation confuse the development of medical simulators. The terms are either not precise (simulation, fidelity), their connotation depending on the context (e.g., fidelity, virtual reality, simulation), or present a different meaning (e.g., validation, simulation). To make sure the text is read as intended, we do not refer to immersive virtual reality when mentioning the term but refer to virtual reality as per medical education conventions.[56]

Hence, suppose a physician can no longer improve a simulator and needs more professional advancement. In that case, it is difficult to pass on knowledge about what the modality does at its present level of development and what the modality needs to do to those outside the sector, e.g., “the pancreas needs to have higher fidelity.” Likewise, the engineering students who have developed a simulator, might present it as “ensuring patient safety,” or the data scientist not being able to get traction for her algorithm that provides “high confidence feedback to endoscopists.” As these statements are addressed to a person of different occupation, they may, at best, sound excessive or, at worst, unintelligible. Nevertheless, more frequently, they are merely expressed in one sense and heard in another, causing uncertainty rather than certainty– it is a lack of lingua franca; a common language.

This text tries to help the reader avoid confusion; we will describe general considerations when making medical simulators. There is no need to reinvent the wheel for many of the decisions and considerations. The text can be read as if wanting to develop a simulator or as if having to choose between simulators–the challenge being the same.

GENERAL CONSIDERATIONS REGARDING MEDICAL SIMULATORS

Prerequisites: What and how are you going to teach?

Deciding on how and what to teach interacts with the desired properties of the medical simulator (s) used, e.g., the processes in writing problem-based learning (PBL) scenarios.[7] In the perfect world, SBE curricula and plans are ready before developing or choosing the simulator (s).[8] However, naturally during the processes of writing PBL scenarios, see,[7] uses and limitations of simulators is likely to change with the scenario development. When the curriculum determines the properties of the simulators, establishing requirements are somewhat straight forward. However, that is only sometimes the case. Often the SBE is determined by the available simulators and not the other way around–then the initiation of simulator development focus on features lacking from other simulators. There is readily available evidence of best practice in SBE.[9] The context of designing SBE medical simulators uses cognitive interactivity, applying various learning techniques, and adjusting complexity.[9] The difficulty lies in producing what makes sense, finding the core of the skills needed, and developing something that mitigates learning these skills.

What to make?

Perdefinition, a simulator represents real conditions (Cambridge dictionary, 2020); i.e., a simulator is not the real thing. Often then, the discussion arrives at fidelity. However, as mentioned in the introduction and as discussed in Hamstra et al.,[4] fidelity is an unfortunate term, e.g., fidelity is context-dependent. In one context, the same simulator can be high-fidelity, in another low. Fidelity is not a constant property. Even the real meaning of the word makes it difficult to interpret. People do not see the same properties when presented with a simulator. The Umwelt, the perceptional awareness (vision, touch, hearing, smell, taste)[1011] of an expert endoscopist versus a novice cannot be considered the same.

A medical simulator's overall properties can be divided into physical resemblance and functional task alignment, the simulator's functional correspondence to the context in which it is used.[4] When considering people's perception, most simulators need properties that look or feel right; often, sound is included, but not of specific interest. The context in which the simulator may be used is paramount. There is no established language to describe the simulators themselves. However, the level and classification of technological simulation with advantages and disadvantages has been described by Alinier.[3] Assistive in determining the level of usage connected to the correspondence of teaching sessions to real-world scenarios.[3] The classification range from level 0, being written, to level 5 being trainee led interactive simulators, computer-driven.

Functional task alignment/functional correspondence

First, consider the simulator usage; is it examination or teaching, testing, or building competence? In the context of building competence, a decomposition of the skills needed will help set a direction. Starting simple, building each specific skill separately is preferable (see all continuing chapters) [Figure 1].

Figure 1

Theoretical progression and Change in Tasks. Changing the simulated tasks as competence in single subject is acquired

Physical resemblance

High levels of physical resemblance are commonly sought,[12] seen as positive. However, in the case of SBE, it is likely not the case. Higher resemblance adds to the complexity and enforces a higher cognitive load on the trainees.[1314] Stated in another way, more manageable tasks enable better performance.[15] Better performance is the goal of SBE. Once competent at a level of complexity, the trainee can advance. Thus, it is advantageous to have different levels of difficulty[9] in mind from the start when deciding on medical simulator requirements. See a conceptual graph in Figure 2.

Figure 2

Optimal simulator realism. Depending on the skill level of the trainee, different realism and diffuculty of the simulator and related tasks is required

A relevant example, with available evidence, is laparoscopic camera navigation. At face value, the apparent difficulties in navigating a laparoscopic camera are the oblique view, limited workspace, and hinged motion via the trocar; all contributing to many unintuitive degrees of freedom for navigating the camera. The highest resemblance, rationally, would be to practice camera navigation on patients, in which case, it suggested that using a simulator is not only as good but also more time-efficient.[16] Concerning the task correspondence and procedural resemblance, when practicing camera navigation, trainees gain competence regardless of practicing the specific skill or the more complex whole procedure.[17] Finally, a conventional in terms of medical education, i.e., nonimmersive, virtual reality simulator, with high visual complexity, is equal to a simple box trainer when gaining camera navigation skills.[18] All suggestive of simple does it; the requirements for the simulator's functional correspondence is to mitigate the skill of navigating a camera with an oblique view, limited workspace, and hinged motion. Everything above that is only relevant to higher skill levels or completely different skills altogether. For laparoscopic surgery, a review states, even conclude, that for basic skills, there is no benefit in using conventional virtual reality simulators compared to simple task trainers,[19] and continues that advanced procedures in virtual reality still need to demonstrate educational value. Developing simple things are much more straightforward, less resourceful, and seemingly more educationally rational. Discern and define what one needs (need to have), what one wants (nice to have).

A PRODUCT DEVELOPMENT APPROACH: THE MINIMUM VIABLE SIMULATOR

To think of a minimally viable simulator, it could be defined as a simulator with only the core features for practicing a specific task. The title of this section is inspired by the minimum viable product (MVP) idea, the MVP, the minimum set of features that is marketable. The minimum viable approach is another fuzzy definition, with many connotations (Lenarduzzi and Taibi, 2016). However, utilizing the way of thought supports product design, facilitates communication, and supports validated knowledge and experience generation of the product's (read: simulator) features (Duc and Abrahamsson, 2016). It is an approach that enables a learning process regarding medical simulator features and their usage.

Different approaches to fulfill the product requirements will provide different properties, good and bad. Development takes time, and the more details specified, the more resources, effort, and thus, the time required. Even though a given feature's intention is good, its effect does not necessarily equal its intention, e. g., tutoring guidance,[2021] or feedback.[22] Virtual reality simulators sometimes state that they are better because they also provide metrics (scores), helping the motivation. Nevertheless, the metrics are not necessarily useful in assessment.[2324] Suppose the metric does not vary with skill. Is it rational to emphasize it as a beneficial feature to spend resources? Avoid falling victim to the sunk cost fallacy.[2526] By testing and re-iterating the simulator, one is less likely to spend resources on unachievable features with only illusory effects.

In developing a medical simulator for SBE, the furthest step to completion is defining the minimally effective platform for the skills taught. Once version zero is built, simulate its usage, test it, determine what works, what does not. Development is iterative, and keeping it simple is an advantage. After gaining experience with the first versions, the simulator converges towards being specifically designed and optimized for teaching the specific curriculum of skills. Some peer-reviewed literature on simulator development documents this travel through versions.[2728] The goal is to reach a minimum viable simulator, use it, learn from the experience, improve what need be improved concerning functional correspondence,[4] other functionalities, design, reliability, and usability—bearing in mind that some essential features, or unintended effects, will only be discovered through the usage of the simulator (s).

As the simulator traverses through versions, more complexity is likely added [cf Figure 2]. The experience in using the simulator in the specific context (s) grows. Keep it in mind, and the realization of even simpler simulators becomes likely, emphasizing skill-building of some subschema of the defined skills. Thus, inventing a simulator that precedes the initial idea, has functional correspondences that allow the transfer of skill, and allows practice at a lower level of cognitive load– enabling better performance.

VALIDATION

In medical education, the validity of the assessment process is often referred to when discussing validity. The primary take-home message is; that it is a process that evaluates the appropriateness of interpretation of assessment results.[29] For the context of discussing medical simulators, Frameworks for Assessment in Medical Education (FAME), specifically Messick and Kane,[29] apply to simulator usage contexts via the assessment tools used. However, outside the context of assessment, observing medical simulators using the mentioned frameworks falls short.

However, as mentioned in the introduction, validation is something that has different connotations within different professions. Different professions have different references, and there is no exception in validity concepts.

Software and hardware developers have standards they can choose to follow. Validation in a technical context regards conformation to predefined conditions. It concerns whether the product meets the customer's needs, and verification concerns whether the product meets the specifications (IEEE-STD610, 1990).[30] As opposed to FAME, when completed, validation and verification are endpoints for different versions of a product, scrutinized in the scope of predefined specifications and requirements. Validation is at the core of development; it is inherently difficult to identify the customer's real needs (or yourself)[3132] and to fulfill them. Consider “I could use some coffee now” could mean coffee, but if it is the context of drinking coffee that's sought for (social, break, warm drink-feeling cold), tea would likely suffice. Establishing user needs is a field of research in itself, with frameworks for approaching the tasks.[33] Now consider an educator asking for, “I would like a simulator for EUS.” It is a spoken user need but has no clues to the requirements of the simulator. In the context of SBE, the overall need could probably be fulfilled by simulators (plural) that can assist in educating physicians in EUS. As previously stated, the process of simulator development should be preceded by a definition of the requirements–know what the needs are before beginning, otherwise, validation is impossible.

As suggested in section #2, the MVP approach allows for validated development. A standard model used for approaching technical validation is the V-model. It consists of a V-shaped flow of processes. The descending part (from the left) consists of decomposition and definitions of user needs until detailed specifications. The ascending part of the V consists of integrative steps to inspect, verify, and validate the technical aspects, from the build, specifications, to user needs.[3435] The application of the V-model can be highly controlled.[35] However, the primary take-home message is the process of decomposing the simulator and skills to allow definitions.

For development purposes, the user needs themselves can be validated in combination with updating requirements, by pilot trials, e.g., is a low physical resemblance for ultrasound imaging of the pancreas sufficient–which details need be improved, which removed (e.g., Exhibit 3 and 5 in[35]). At the bottom of the V-model, the validation of functionality can be at the level that checks (yes/no) if the required output is returned for different given inputs, e.g., add (2,3), add (1,4), add (4,1) should all return 5.

Once ready for use, more complex aspects can be validated. There is, as such, no framework for validation of a simulator itself. Validation of the simulator effect can be done by comparison, like done with the medical device products. As an example, validation of an effect can be validated by hypothesis like “Does simulator X, used in context Y, increase the competency of trainees in ultrasound ?” Simulator usage can be asserted in combination with a FAME for an assessment tool; e.g., “Does OSAUS provide a reliable assessment tool in context Z (using simulator X) ?” [Table 1].

Table 1

Validation and its differents meanings

	On validation in regards to medical simulators
	Product validation	Metric/claim validation	Context validation	How to/we have
Basic question	Does simulator X meet its defined requirements?, performance of sub-system of simulator X is	Is the interpretation of claims of the metric (s) from simulator X reasonable?	Does simulator X applied in context Y provide an effect on skill level? does simulator Z enable other contexts than simulator Y?	It is possible to make simulator X for context Z by doing Y
Approaches/framework	E.g., V model	E.g., Messick, Kane	E.g., impact evaluation, case-control, RCT, Messick, Kane	Feasibility
Predominant scientific field	If any. Then feasibility or performance in technical field (e.g., materials science, chemistry, computer science, medicine [specfic professions])	Medical education	Medical education, medicine

RCT: Randomized controlled trials

Finally, it is essential to note that in connection with FAME and assessing skills, the simulator intended usage is different from learning. The details that make a simulator sufficient for testing trainees are substantially different from optimized learning (see section 2). In a test setting, the simulator should enable expert performance, a high level of task difficulty, or detail. A simulator for assessment does not allow novices to perform perfectly–the opposite of the optimal simulator for learning.

EUS

“Please help me make training models and simulators for EUS and EBUS training.”

Definition of needs

At the time of writing, there are some criteria for competence in EUS.[36] In the same journal issue as this text, there is a needs assessment describing what needs to be.[37] Concerning the definition of a simulator, few cues as to what is required exist. There is no well-defined curriculum.[8] Focusing on the technical skills, a common need from both the sources mentioned earlier is the duodenum or esophagus's intubation–focused on procedural points, rather than specific skills. Contacting the authors of the needs assessment, we had the privilege of early access to the data. In the first round of the need assessment, 84% of the first 45 respondents mention things related to “endoscope,” 62% tasks related to “anatomy” and 6% points related to “ultrasound”– one respondent mention handling “oblique view endoscope” and one mention “fine motor movements.” An interview conducted by author MBSS (engineer) to understand these challenges of EUS confirmed that the difficulties, compared to conventional endoscopy, is the oblique view of the EUS scope (Pers. Comm., Prof. L. B. Svendsen). In our experiment of thought, this information points in the direction that the first prerequisite is handling the endoscope safely, second master ultrasound, third interpret the ultrasound image, and last perform EUS procedures such as fine needle aspiration (FNA). Further, we focus on the points “Endoscope insertion duodenum”[37] and “image and identify anatomy close to the duodenum.”[36]

Curriculum focus

Different simulators and different technological simulation levels can be utilized to obtain the competencies previously described.[36] Considering requirements for technical skills [Figure 3] and interpretative skills [Figure 4], one will not end up with the same simulator (s) neither approach to teaching the competencies. Thus, it is important again the remember to learning objectives, and progress of learning exemplified in Figure 1.

Figure 3

Relations between technical skills and medical simulator. Left is required technical skills. the middle section is the.broader terms, that the specific skills relate to. The rightmost box illustrates whether the broad term subjects can be practiced on either physical or digital simulators

Figure 4

Relations between interpretational skills and medical simulation medium. Left is required technical skills. the middle section is the.broader terms, that the specific skills relate to. The rightmost box illustrates whether the broad term subjects can be practiced on either physical, digital simulators or media at TSL0 (reading etc)

If the intended program targets already competent endoscopists, they need to be acquainted with the echoendoscope.[36] The simplest way utilizing SBE would be to practice a conventional upper gastrointestinal endoscopy model, perhaps rebuilt with hidden structures visualized with ultrasonography only, but using the new equipment. Is there any need for tiring trainees to reach the duodenum before they can practice imaging and identify the anatomy close to the duodenum? Is there any need for the simulated anatomy to have a high physical resemblance when practicing imaging and handling the echoendoscope, or will something equivalent to imaging squares and circles in a cavity work for the basic steps? That could also function as needle handling practicing phantom, e.g., FNA or lumen-apposing metal stents (LAMS).

Hence, our small curriculum requires one simulator, physical-upper gastrointestinal endoscopy, for perfecting navigation of the oblique view endoscope; one simulator (physical, anatomical resemblance not necessary, ultrasound compatible material, PVA or ballistic gel) only practicing ultrasound imaging with the endoscope; one simulator (physical, anatomical resemblance not necessary, but with physical properties simulating tissue, e.g., FNA or LAMS, only practicing ultrasound-guided invasive procedure with the endoscope. Finally, in combination with simulation on level 0 (knowledge via reading, studying),[3] a simulator having a high resemblance concerning anatomy and its appearance on ultrasound, to establish competence in recognizing and identifying anatomy on ultrasound [Figures 3 and 4]. The last steps, similar to a recent demonstration that multistage training was beneficial in the acquisition of skills in EUS.[38]

Specific simulator considerations

Different models and approaches for training EUS are available and have been described,[2] many of which would be directly utilizable in the above-described contexts. However, only in the specific regime of endoscopy and ultrasound combined. In this last section, we will expand the field of view to endoscopy.

High-quality endoscopy is multidimensional.[39] Initial training regarding EUS could likely utilize conventional criteria for competence in, e.g., colonoscopy,[40] just performed by an oblique viewing endoscope. However, one cannot assume that digital simulators will provide meaningful insight,[24] or even competence.[41] Virtual/digital simulation is not equal for all endoscopic procedures,[41] likely as contextual use is not considered. Digital simulators have their strength in possibilities of varying the visuals and making resemblant imaging and weaknesses in a lack of haptic congruence (feel). There is a, still technically contemporary, overview of digital endoscopy simulators and their usage available in the literature.[42] It is unknown, however, if any of the simulators allows practicing with an oblique viewing endoscope. The visual part and training skills within that realm solely are demonstrated in providing competence in evaluating normal anatomy and increasing efficiency in a EUS program.[43]

Considering EUS and EBUS as advanced endoscopic procedures, the trainees are likely skilled in endoscopy pretraining, allowing for high physical resemblance and high cognitive load simulators. This has been stated in other words but supported by proposing utilizing animals for advanced endoscopic techniques only.[44] e.g., porcine models do find usage for FNA.[4546] However, using animals for training pose extra considerations within regulatory demands (e.g., FELASA, IACUC), the dedication of equipment only for animals, and zoophilism among trainees, all warranting inanimate simulators, compromising some physical resemblance.[2847] Live animals (high resemblance) should be limited to advanced procedures to ensure trainees benefit from the experience.[44] Concerning the Three R's tenet within animal experimentation (Reduction, Refinement, Replacement) (Fenwick[48] et al., 2009; Russell[49], 1995), prepractice on inanimate simulators (initial replacement) would ensure that trainees have a higher level of competence, enabling more skill acquisition (combined leading to refinement) when performing on the animals models, at the end leading to a reduction in the number of animals used.

SUMMARY

Regardless of standing before an acquisition or development process, it is recommended to consider the definition of the needs as a prerequisite. Answering the simulator's real usage (learning or examination), makes you go a long way.

Further, evidence from both educational and product development research suggests starting simple. For educational purposes, simplicity enables perfection in performance at specific sub-tasks of a procedure, mitigating the cognitive load, increasing learning. From the product side, keeping it simple helps to learn the curriculum's real needs without utilizing all resources.

When communicating in connection to simulators, be aware of the pitfalls that follow the choice of words. Words do not infer the same meaning to different professions (e.g., validation, virtual reality, fidelity). To the extent that the usage of some words, like fidelity, should be abandoned in the context of medical simulators.

Financial support and sponsorship

Nil.

Conflicts of interest

There are no conflicts of interest.