Warfarin Design
(→Warfarin predictor design) |
|||
| Line 1: | Line 1: | ||
| + | == Background == | ||
| + | |||
| + | Warfarin predictor was a result of my cosc366 research project. It is a web based application that uses machine learning algorithms to predict a right dose for hart-valve transplant patients. The importance of determining a correct dose comes from a fact that there is a very real danger of blood clots occurring on the heart-valve of a patient . In order to prevent blood clotting Warfarin is taken by patients as a blood thinner. | ||
| + | By taking a right dose a patient has a minimal chance of clotting, while still ensuring that patient has enough clotting ability so that he or she does not bleed to death. | ||
| + | |||
| + | Even though I did try to do this project in OO style, the functionality that needed to come out of it were more important for the project so I haven’t spent too much time on putting it in right OO space. There is a good chance I will need to work on this project again ( add some more functionality) in the near future so before I do start I would like to see it being refactored. | ||
| + | |||
| + | == Initial Requirements == | ||
| + | |||
| + | * System users: administrators, doctors. | ||
| + | * Administrators can add new doctors. | ||
| + | * Doctors adds patients, patient records. | ||
| + | * Main use case is to record a new blood test (INR reading), get a dose prediction. | ||
| + | * Dose predictions may be returned in several ways, probably not advisable to just give the dose to prescribe because of liability issues. For example, could give a graphical representation of the likelihood of being below the safe range, in range or above. | ||
| + | * The system will also need the facility to raise warnings if the patient's INR goes beyond certain limits or the dose alters beyond allowed limits (to prevent the system making dangerous recommendations). | ||
| + | * We have historical data; this will need to be entered into the system. | ||
| + | * The system needs to be able to "learn" a model from the historical data. This involves transforming the data into a special format (an "ARFF" file) and submitting this to the learning algorithm. | ||
| + | * The data-to-arff step needs to be flexible (i.e. able to be easily changed if the learner's data requirements change. | ||
| + | * Models will need to be persisted. | ||
| + | * The data needs to be reliably persisted. | ||
| + | * There may be a need to record other data for the patient, possibly temporally, such as diet, other drugs taken, smoking and alcohol consumption. | ||
| + | * The learner algorithm has not been finalised; there is potential for working on this. In any case, the data transformation will require some thinking about what form the data needs to be in for the problem to be learnable. | ||
| + | |||
== Warfarin predictor design == | == Warfarin predictor design == | ||
Revision as of 12:15, 29 July 2010
Background
Warfarin predictor was a result of my cosc366 research project. It is a web based application that uses machine learning algorithms to predict a right dose for hart-valve transplant patients. The importance of determining a correct dose comes from a fact that there is a very real danger of blood clots occurring on the heart-valve of a patient . In order to prevent blood clotting Warfarin is taken by patients as a blood thinner. By taking a right dose a patient has a minimal chance of clotting, while still ensuring that patient has enough clotting ability so that he or she does not bleed to death.
Even though I did try to do this project in OO style, the functionality that needed to come out of it were more important for the project so I haven’t spent too much time on putting it in right OO space. There is a good chance I will need to work on this project again ( add some more functionality) in the near future so before I do start I would like to see it being refactored.
Initial Requirements
- System users: administrators, doctors.
- Administrators can add new doctors.
- Doctors adds patients, patient records.
- Main use case is to record a new blood test (INR reading), get a dose prediction.
- Dose predictions may be returned in several ways, probably not advisable to just give the dose to prescribe because of liability issues. For example, could give a graphical representation of the likelihood of being below the safe range, in range or above.
- The system will also need the facility to raise warnings if the patient's INR goes beyond certain limits or the dose alters beyond allowed limits (to prevent the system making dangerous recommendations).
- We have historical data; this will need to be entered into the system.
- The system needs to be able to "learn" a model from the historical data. This involves transforming the data into a special format (an "ARFF" file) and submitting this to the learning algorithm.
- The data-to-arff step needs to be flexible (i.e. able to be easily changed if the learner's data requirements change.
- Models will need to be persisted.
- The data needs to be reliably persisted.
- There may be a need to record other data for the patient, possibly temporally, such as diet, other drugs taken, smoking and alcohol consumption.
- The learner algorithm has not been finalised; there is potential for working on this. In any case, the data transformation will require some thinking about what form the data needs to be in for the problem to be learnable.
Warfarin predictor design
Warfarin predictor was a result of my cosc366 research project. It is a web based application that uses machine learning algorithms to predict a right dose for hart-valve transplant patients. The importance of determining a correct dose comes from a fact that there is a very real danger of blood clots occurring on the heart-valve of a patient . In order to prevent blood clotting Warfarin is taken by patients as a blood thinner. By taking a right dose a patient has a minimal chance of clotting, while still ensuring that patient has enough clotting ability so that he or she does not bleed to death.
Even though I did try to do this project in OO style, the functionality that needed to come out of it were more important for the project so I haven’t spent too much time on putting it in right OO space. There is a good chance I will need to work on this project again ( add some more functionality) in the near future so before I do start I would like to see it being refactored.
The high level design:
