mucadele-cs319 / bilhealth Goto Github PK
View Code? Open in Web Editor NEWCS 319 Project - Health Center Management
License: GNU General Public License v3.0
CS 319 Project - Health Center Management
License: GNU General Public License v3.0
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:
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.
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.
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:
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.
These are mostly the same as what is in our README.md.
Here are some of the relevant key terms we could expand on:
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.
Help wanted.
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.
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:
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.Case
s that they are involved in.Case
s that they have opened. Additionally, there would be a list of references to rows on a table of test results.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)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 Case
s 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 Case
s 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.
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.