mucadele-cs319 / bilhealth Goto Github PK

Moving this here from #41.
The backend PR to make the following UI possible was just merged, so my next big PR should hopefully complete this roadmap.

Roadmap:

• View recent audit trails on staff panel
• A profile card for a patient or any staff member to grant access permission to a nurse, with a duration of expiry
• A case list where
  • doctors see cases to which they are assigned
  • nurses see cases belonging to patients whose profiles they are allowed to access
  • staff see all cases
• Pages/components to interact with cases, such as
  • Add message (with edit/delete)
  • Add diagnosis (with edit)
  • Add prescription (with edit/delete)
  • Create triage request (with approval)
  • Request an appointment (with edit/approval/cancel)
  • Create appointment visits (also modify?)
  • Close/reopen case
  • Create new case (a dedicated page should suffice)
• Make input fields that ask for ID more usable (timed grant and new case)
• Disable unavailable dates for a doctor
• Add a case list to patient profiles for anyone but the patient viewer
• If user can't access a profile, show warning

Disable unavailable dates for a doctor

This is definitely something the instructor will ask us about, but we missed our chance to implement something in that vein. The current appointment implementation does not care about the duration of the appointment, so we don't really know for how long an appointment should block other appointments.

The current system at Bilkent's health center does not do triaging on these two case types. Our system currently requires all cases to go through a triaging process.

IIRC, there should be samples from previous semesters on the schedule sheet shared by the instructor.
The existing parts of the UI work well and are ready for a demonstration. However, #70 is blocking demonstrating case related features. Hopefully I should be able to close that issue before Tuesday (Tuesday morning at worst?).

I don't remember what exactly this was about, maybe activity diagrams?
There are probably samples from previous semesters on the spreadsheet sent by the instructor.

AuthController was the first controller to be implemented, so Staff wasn't added to the Register action's authorization attribute at the time. It should be added though.

Buggy line

Correct example

This is supposed to be so that the insurance-related services are accomplished through inheritance.
I'm not sure EF Core support multi-level inheritance so this needs to be investigated first.
If this is a breaking change in any major part of the code base, it's probably not worth doing.

One alternative is to simply add an insurance-related property to the Patient class, possibly an enum.

Currently, the vaccination service seems to be setting its own date regardless of what the user sends.
For vaccinations, this shouldn't be the case. The service should set a date only if the user hasn't sent one.

The problematic line

This was one of the core ideas behind why we decided not to have public registrations.
It would be good to have this implemented.

The authentication service already has a RegisterMany method that should accomplish this, but it is not being used anywhere currently. We could use a controller action through which to receive the student data and consequently register them.

This controller should be exposed through the "Staff Panel" page on the UI.

The exact calculator types need to be determined.
BMI and ideal weight were the two known ones I think.

The insurance integration for health center management software is not as fancy as it sounds, see the two sources below:

After a patient receives medical services, this system processes the patient's treatment record and submits it to the patient's insurance company to facilitate the payment process.
Source

Insurance service integration allows patients to submit their insurance online before visiting a doctor. With the help of an integrated module, the software would be able to record and store the patients’ insurance information:
*policy number
*insurance company
*any additional information about policies
Source

I am guessing the university health center follows a similar flow. In which case, this integration can be implemented into BilHealth through these two functional requirements:

• The system should be able to generate a case report
• The Patient user should have insurance details saved to their profile.

The former is already a requirement of BilHealth, albeit being unimplemented so far: #28.
The latter requires that we create an InsuranceDetails table/model, which will be embedded into the existing Patient model. Similar to our DomainUser class, we might want to split the InsuranceDetails class into multiple classes like StudentInsuranceDetails, ExternalInsuranceDetails, etc.

Pursuing an insurance integration further than this would venture into the domain of accounting software, which is not essential for this project in my opinion. We should explicitly assume in our analysis report that the health center will use dedicated accounting software.

This was one of the main features listed in our reports. It is completely missing at the moment.

This would mainly involve using EF Core inside Services to pull the data from the database, then create a controller action as a proxy to this generation service. The profile page on the UI could be a good place to add a button for accessing this API controller.

Do a refactor from within the enum file CaseState.cs.
Also, cases whose triage is approved should be moving to this state.

Assigning this to myself.

Since we're using React as our presentation layer, we won't be able to draw an OOP-based diagram similar to our back-end ones. Instead, we should use the component names as our "objects", and draw relations between them. Their relations are actually somewhat clear from the directory structure too:

However, since the UI is still being developed, whoever is going to draw this diagram should wait a bit more for more components to be finished.

A doctor being assigned to a case should not be irreversible. A doctor may resign or be unassigned so that a specialist is assigned in their place, for example.

I'm not sure this feature currently exists, but it should still be linked to the triage request mechanism which mostly works already.

Functional Requirements

These are mostly the same as what is in our README.md.

Non-Functional Requirements

Here are some of the relevant key terms we could expand on:

• Confidentiality
• Privacy
• Security
• Usability
• Reliability
• Scalability
• Maintainability
• Deployment
• Extensibility
• Fault tolerance
• Integrability
• Testability

Pseudo Requirements

These are supposed to be kind of like non-functional requirements that aren't directly concerned with "quality".
I don't have specifics on my mind at the moment, so help wanted.

Diagrams

Use Case Diagrams

Help wanted.

Object/Class Diagrams

These are a pain to design entirely in advance, so I think I should just keep working on #11 so we can model the existing classes.

User Interface

These are an even bigger pain, as we're not design majors. I don't think we should bother to get accurate mock-ups, in fact, I'd prefer to have no visual mock-ups. I think listing the pages and their functions should suffice.

Security is a pretty integral part of our project. Although we have previously discussed it, there have been a few corner cases that were hard to cover. I think the following is a decent final design:

• A doctor can access a patient's full profile only while the doctor is assigned to an open case with the patient.
• A nurse can access a patient's full profile only while granted permission by the patient or a staff member. This access should expire after some amount of time.
• A staff member can always access a patient's full profile. However, this access is fully tracked. I believe this is also called an "audit trail".

I think this is rather close to how many places around the world implement medical record security.

Relevant issue: #39

Currently, many of the controller methods do not check for access control beyond a user belonging to a role.
For example, this means that any doctor may be able to take actions on cases that they aren't assigned to.

There are currently two service methods implemented at a basic level to achieve some granularity. These are only used in a few places across the controllers.

For the back-end side to make progress, designing the database model seems like it should be one of the first steps. Doing so also requires thought regarding the workflow users will follow.
With the features we've currently planned, I've drawn up a rough model that might be decent for the kind of user workflow I had in mind (explained below):

This sketch mostly describes the relations between database tables. The properties that each object should contain are left for the actual EF Core implementation. To make the model more concrete, here is another limited representation:

• User relates to a row in one of patient/doctor/staff information tables, which would contain the kind of values to be displayed on a user's profile.
• A doctor info row would contain a list of references to rows on a table of Cases that they are involved in.
• Likewise, a patient info row would contain a list of references to rows on a table of Cases that they have opened. Additionally, there would be a list of references to rows on a table of test results.
• Each Case would contain a list of events, consisting of items such as: [message, appointment, prescription, system_message, embedded_item] (an embedded item could be a case or test result)

Justification

I'll explain the typical user workflow I had in mind. I'm not thinking anything out of the ordinary for usual/trivial interactions like opening cases, etc., but I think Cases need to be where the heart of the project lies. They will be the main medium of interaction between patients and medical staff, containing all relevant data as seen in the model above. As for how Cases are to be interacted with and represented, I'm actually imagining something very close to the way GitHub does it in issues and PRs. For any issue, GitHub allows interactions by messages, and also lists any additions and changes to the thread besides messages. In our case, these could be prescriptions and appointments. As for system messages, again similar to GitHub, these could be changes made to existing items in the Case, such as editing or approving the date of an appointment. Patients should also be able to embed their personal test results and other cases, to provide data and context to the medical staff.

Summary

What I have in mind is more or less the workflow GitHub uses for issues/PRs, adapted to a health-centered application. I think it covers most of the functionality we should be working towards.

This issue can be used to discuss the ideas above, and also any other ideas that you may have come up with regarding the user experience and database design.
Once we have a more concrete idea of what we are going for, we can open a linked PR for the EF Core implementation. It's likely that there will need to be some changes to the model at the implementation stage as well, considering the constraints EF Core and PostgreSQL will pose.

Just a string column on the Case model to hold the diagnosis might suffice. However, controller/service/dto/DtoMapper, and most likely the UI would need updating.

Currently, all triage requests are created by nurses, which doesn't allow the patient to pick their doctor voluntarily.
Perhaps patients should also be allowed to create triage requests?