# Instance-Based Learning Following Physician Reasoning for Assistance during Medical Consultation
## 5 Medical Consultation Flows
### Selecting an Already Defined Case Type
If \(CT^{M}_{chron}\) was used in any previous consultation of the same patient (line 6), then its _chronic_ components are taken into account each time the physician decides to apply the case type, since _chronic_ components are used to monitor the evolution of a chronic condition. However, the first time that \(CT^{M}_{chron}\) is used to monitor the evolution of a patient, the physician needs to define all entities that they want to use as monitoring items (lines 7-12). In addition, it is mandatory that the physician specify the frequency of each new unit of thought, included in an element of a chronic component (lines 13-16). All entities defined in new chronic components are used to monitor the patient's chronic condition in subsequent consultations (line 17). Finally, the units of thought of the elements referenced in _chronic_ components are marked as in use by applying _setUnitsInUse_ procedure (lines 19-20). ```
1:A chronic case type \(CT^{M}_{chron}=\) <name, components, true, chronicComponents> is selected
2:if name \(\
otin\) P.chronicCaseTypes then
3: elements \(\leftarrow\) getAllElementsIncludedIn(components) \(\triangleright\) First time of case type for patient P
4: setUnitsInUse(elements,CT\({}^{M}_{chron}\))
5:else
6:if chronicComponents = \(\emptyset\)then
7: Evolution component \(\text{CC}_{Evolution}\) emerges \(\triangleright\) Chronic components defined by physician
8: Physician defines all conceptual elements included in \(\text{CC}_{Evolution}\)
9: \(\text{CC}_{others}\) can be defined to better monitor the chronic condition
10: \(\text{CC}_{new}\) = \(\text{CC}_{Evolution}\)\(\bigcup\text{CC}_{others}\)
11: newMonitorEims \(\leftarrow\) getAllElementsIncludedIn(CC\({}_{new}\))
12: newChronUnits \(\leftarrow\) getAllUnitsIncludedIn(newMonitorEims)
13:for newChronUnit in newChronUnits do
14: Physician needs to specify the frequency of newChronUnit
15: newChronUnit.ctSchedule is updated
16:endfor
17: chronicComponents \(\leftarrow\) CCs\({}_{new}\) the chronic case type is updated
18:endif
19: elements \(\leftarrow\) getAllElementsIncludedIn(chronicComponents)
20: setUnitsInUse(elements,CT\({}^{M}_{chron}\))
21:endif
```
**Algorithm 4**applyChronicCaseType(P, \(CT^{M}_{chron}\))

### Usual Attention Flow

During an attention flow, a physician can take advantage of an already registered case type. Algorithm 5 shows how a case type can be used to record a frequent medical consultation scenario. In Algorithm 5, a procedure waits until the physician selects a case type and applies it to the current consultation (lines 1-2). After a case type is applied, the physician can also make modifications in order to describe the accurate information of the entire clinical meeting (line 3). Each unit of thought marked as unique to the patient being evaluated is stored as personal data, and is removed from the current case type (lines 4-6). The algorithm continues by applying \(T^{*}\) transformation, which generates a new medical record for the patient's history (lines 7-8). All chronic conceptual elements used in the case type are associated with the patient. Furthermore, if the case type is chronic, it is associated as permanent patient data (lines 9-13). Each unit of thought marked as unique to the current consultation is removed before updating the \(CKB^{M}\) of the physician (line 14). To update \(CKB^{M}\), the physician needs to specify if the current case type refers to a new workday scenario, or it is only an improvement over the previously selected case type (lines 14-21). Two data sets are modified after the usual attention flow: physician \(CKB^{M}\) and patient history, including an \(MR^{p}\) increment.