Ticket38 donor patient types

wiredsister commented 3 years ago

A Quick Guide for this Massive PR 🙌

Dont's 🛑

ignore the new intake html
ignore the illustrator files
ignore any new markdown
ignore constraints.mli file right now (out of sync with actual .ml implementation file - we've aded a ticket to fix the build and interface file to be pulled in during this sprint)

Do's ✅

PS: I will squash this when I merge, promise 😅

wiredsister commented 3 years ago

https://github.com/wiredsister/OpenTransplant/blob/b3e430ce6c6f4a9b40f2137233e1717410f71c4b/opentransplant/OpenTransplant/lib/constraints.ml#L598

This section here is kinda wrong. It should actually be hla_information: (HLA_Class_I * HLA_Class_II) information

wiredsister commented 3 years ago

Also don't forget about this feature!

MeredithStewart commented 3 years ago

Random Qs (probably more my lack of understanding of code more than anything!): https://github.com/wiredsister/OpenTransplant/blob/b3e430ce6c6f4a9b40f2137233e1717410f71c4b/opentransplant/OpenTransplant/lib/constraints.ml#L596

Does the NearDeathDonor become a RegularDonor? (ie, are those two types connected?)
Grafting Transplant and Tissue Transplant types - I don't think are every going to be known in this system. Users won't ever have access to that info to add it to the system. The grafts and tissue transplant matches are made outside the system.
DonorType info goes right into Recipient type info - grafting & tissue transplants and then is available (presumably for transplant) - I guess I don't have a concept of flow here, but DonorType seems specific to the case and not the recipients. Do we have a concept of a recipient type? Or is the waitlist data conceived of differently?

https://github.com/wiredsister/OpenTransplant/blob/b3e430ce6c6f4a9b40f2137233e1717410f71c4b/opentransplant/OpenTransplant/lib/constraints.ml#L1337

Ahh, now I see patienttype. I'm wondering if "recipient" or something more specific might help with the logical separation (in one's mind) vs. patient, which the donor is/was.

wiredsister commented 3 years ago

Does the NearDeathDonor become a RegularDonor? (ie, are those two types connected?)

Hey @MeredithStewart great questions:

We would have a Transitions module or something that the API would use to move NearDeathDonor to RegularDonor via API. Totally the plan. Just important we treat them distinctly in the system bc of OPO separation of concerns with donor hospital staff.
We might never store Tissue by ID like we do Organ, but the goal is to track them inside of the Donor.t, for example:

        (* inside of Donor.t *)
        val donortype : Human.donortype
        val accepted_by_recipients : Human.organ_transplant_type list
        val viable_organs : Human.organ_transplant_type list
        val id : Uuidm.t
        val current_cases : Human.organ_transplant_type list

So when you query Donor you would see that tissue was possible (viable_organs) and what tissue had been already given away (current_cases) which would be important for OPO to coordinate with Tissue Teams. There is no current plan to ever track or look up Tissue. Hope that helps clear up confusion. That code isn't written yet bc we don't know what cache & cold storage we are using.

Recepient = Patient in my system. I linked the code for it.

wiredsister commented 3 years ago

Ahh, now I see patienttype. I'm wondering if "recipient" or something more specific might help with the logical separation (in one's mind) vs. patient, which the donor is/was.

Wow, this is a great idea @MeredithStewart. I love that prematch they would be Recipient.t but Post-match they could be Patient.t 🤯 🤯 🤯

wiredsister commented 3 years ago

We could also have NearDeathDonors as a type of Patient.t... interesting thought... that way Patient.t only refers to people we collect EHR info on or people in surgery. Then we can keep Recipient.t for receiver and change them to Patient.t when they are recovering in hospital. We could actually be that descriptive if we wanted to.

wiredsister commented 3 years ago

I'm just going to merge this and move the refactoring work to be done in a bit after the cleanup.

wiredsister / OpenTransplant