Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce state-based patient model #614

Draft
wants to merge 3 commits into
base: dev
Choose a base branch
from

Conversation

ClFeSc
Copy link
Contributor

@ClFeSc ClFeSc commented Jan 23, 2023

Closes #335
Closes #402

Continuation of #490. Note that the remarks and comments made there were not incorporated here, so they're still relevant.

Design by @hpistudent72

@hpi-sam/bp2022hg1 You can assign reviewers at your own discretion.

@ClFeSc ClFeSc added enhancement New feature or request shared Issues mainly related to shared Legacy Issues that were created by the 2021 BP labels Jan 23, 2023
@ClFeSc ClFeSc self-assigned this Jan 23, 2023
* Continuation of #490

Co-authored-by: Florian <[email protected]>
@benn02 benn02 self-requested a review February 1, 2023 10:09
Copy link
Contributor

@benn02 benn02 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few general Things: It would be nice if there were more than 1 Test Patient available w/o an external CSV. Not only for testing, but also it would be nice if basic usability was demonstrable w/o said external file. I would suggest a build in CSV that then must also adhere to our new licence(keep in mind). I would also suggest that the Speed in which Patients switch between phases is communicated more clearly to the user. In the offline equivalent, the trainers do also control the time, not a transparent factor. I would suggest changing the UI in a way where the trainers can control the time between phase changes directly. Lastly, migrations are missing. Since there is no direct translation between old and new patients, maybe deleting all patients would be an option. but keep in mind to keep statistics so exercises done before this change can be evaluated with the software after this change.

patient,
state.configuration.pretriageEnabled,
state.configuration.bluePatientsEnabled
) !== 'black' && !Patient.isInVehicle(patient)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use isOnMap(patient) instead

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And even Patients that are in Vehicles should experience State Changes, but this is maybe out of scope for this

@IsOptional()
@IsNumber()
@Min(0)
public readonly latestTime?: number;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really understand the need for two variables with not so clear names. Earliest Time What And why do we need two Variables to display how long the patient is in the current state, isn't one enough? This was not changed, but I feel like this could be made clearer maybe in this PR.

Comment on lines +76 to +101
const randomizedNextStateConditions = Object.values(
state.nextStateConditions
).map((condition) => {
let newEarliestTime = condition.earliestTime;
if (newEarliestTime) {
newEarliestTime = randomizeValue(
newEarliestTime,
0.2
);
}
let newLatestTime = condition.latestTime;
if (newLatestTime) {
newLatestTime = randomizeValue(newLatestTime, 0.2);
}
return ConditionParameters.create(
newEarliestTime,
newLatestTime,
condition.isBeingTreated,
condition.requiredMaterialAmount,
condition.requiredNotArztAmount,
condition.requiredNotSanAmount,
condition.requiredRettSanAmount,
condition.requiredSanAmount,
condition.matchingHealthStateName
);
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really understand why there needs to be randomization involved apart from Names. I think it shouldn't be the software that chooses specific details about the patient that influences the optimal behaviour of participants. As a trainer, I would want full control. If I want randomization, I could either randomize the CSV Data or I would like to choose what is randomized and what not.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea was that not every patient should be identical, meaning they would be easier to predict. With a little randomness, it's possible to generate a more natural behavior of patients without blowing up the CSV file.

Comment on lines +104 to +115
if (currentPatient.treatmentHistory.length === 0) {
for (let i = 0; i <= (60 * 1000) / tickInterval; i++) {
currentPatient.treatmentHistory.push({
gf: 0,
material: 0,
notarzt: 0,
notSan: 0,
rettSan: 0,
san: 0,
});
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this needs a Comment

export function parsePatientData(importString: string) {
const patientData: PatientData[] = [];

const splitString = importString.split('|');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This applies to the one CSV File that we got I would like to discuss whether we should support more generic CSVs but most likely not in this PR

healthStateInformation: string[],
pretriageInformation: PretriageInformation
) {
const phaseTime = 12 * 60 * 1000;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have seen this or similar constants (x * 60 *1000)as throughout all the Changes, and I don't really understand them. Maybe I would put them in a combined place.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just because I saw this now: that's 12 minutes (min * s * ms).

currentPatient.stateTime = patientUpdate.nextStateTime;
currentPatient.treatmentTime = patientUpdate.treatmentTime;
currentPatient.realStatus = getStatus(currentPatient.health);
if (currentPatient.treatmentHistory.length === 0) {
for (let i = 0; i <= (60 * 1000) / tickInterval; i++) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Magic Number

@christianzoellner
Copy link
Member

Is this PR still ongoing?

@ClFeSc
Copy link
Contributor Author

ClFeSc commented Mar 26, 2023

Is this PR still ongoing?

Theoretically, yes. Practically, I haven't had enough time over the course of the semester and time with the exams to work on this. Also, I have had some problems understanding the code as I have not written it. But I'll try to look into this again in the next few weeks.

@Dassderdie
Copy link
Collaborator

Theoretically, yes. Practically, I haven't had enough time over the course of the semester and time with the exams to work on this. Also, I have had some problems understanding the code as I have not written it. But I'll try to look into this again in the next few weeks.

Was there already a consensus about how to handle migrations of patients here? While I believe it is in theory possible to migrate them, this would be a lot of work.

In addition, I believe the code as @hpistudent72 wrote it would be significantly less performant than now (I estimate ca. one order of magnitude) . I proposed a solution to not only fix this, but also improve the performance by ca. one order of magnitude and reduce the size of history exports. Implementing this would also require even more work.

TLDR: this PR could be more work than just a simple merge.

@christianzoellner
Copy link
Member

Thanks @ClFeSc and @Dassderdie for your responses and your continued activities as a volunteer developers on this project!

I really do not want to push you by raising this issue again, but the topic of the patient model came up during a meeting I had this weekend at BABZ.

Sadly I am not really familiar with the code, but I am available to answer any questions you might have about the underlying model and concept.

@Dassderdie
Copy link
Collaborator

Maybe it would also help if this PR would be split up into multiple smaller ones. For example, the refactored patient system could be separated from the CSV import and the smaller UI improvements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Legacy Issues that were created by the 2021 BP shared Issues mainly related to shared
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Change Patientsystem from life-point-based to state-based Allow changing the treatment factor
4 participants