circuitfox/vitae-net

vitae-net's Issues

Integration landing page

We need a simple landing page to link the two modules. It can be really simple and dirty, we'll change it.

Database factories for orders and labs tables

These tables don't have any factories to generate values for testing, and we'll need to write tests for their controllers at some point. As we're merging things, we should probably write them now.

MAR views

There will be two view additions for the MAR. One will be added onto the patients show view, which will show the MAR entries for that patient; the other will be a medication management view for assigning/editing/deleting that patient's medications.

Merge database docs

After the databases formats are merged, we'll need new docs describing them.

Rewrite labs and orders views to conform to project style

Similar to how we managed patients and medication, labs and orders should have the following view layout, where model is lab or order

• models - The index route
• models.create - The create route
• model - The show route
• model.edit - The edit route

Formatters break Javascript outside of their views

The Javascript used for the QR formatters has the nasty side-effect of failing if an element with the specified id does not exist on the current page. This prevents any other Javascript from executing. Because the needed ids only exist in the formatting views, this means that they effectively disable Javascript everywhere else. Which means that the barcode scanner won't work. Code won't be pushed to master without this being fixed.

Merge layouts

The orders and medication layouts need to be merged. We'll want to figure out how navigation will look and what will be required there.

Patient name lookup causes travis to fail spuriously.

Sometimes faker will generate names with characters that must be replaced by escape sequences when used in views (like Vernice O'Conner Jr., as an example from a travis failure). This means that phpunit will fail when looking for the name, as it doesn't see the character that it's looking for because it had been escaped. This will cause travis to indicate failure where it shouldn't. This is a bug in the test (specifically PatientPageTest::testHasPatient) that should be fixed.

Update docs for medications

After #78, the docs and ERD need to be updated to reflect the new columns.

Docs for generating QR codes and barcodes

User-facing documentation for generating QR codes and barcodes for a student worker or instructor.

Merge routes

The routes files need to be merged and any conflicts resolved.

Update tests with new medication columns

Add policies for accessing the Lab model

Similar to what we use already to control accessing medications. These policies should control who can access creating, viewing, updating, and deleting labs.

Merge and test patients views

Define MAR database format

We need to figure out the database format for the MAR and write a migration for it.

@kschick02 @carlgoshert there's already been some discussion on this but I want to get a clear picture of what it's going to look like.

Add secondary information to medication

As discussed in #22, the medication table needs to get three new columns. all nullable: secondary_amount, secondary_unit, secondary_type.

Add policies for Order model

Similar to what we use already to control accessing medications. These policies should control who can access creating, viewing, updating, and deleting orders.

Tests for labs controller

We need unit tests for the labs controller, using the new factory to verify that the controller methods behave correctly.

Medication QR codes are unworkable with the current database format

QR codes for medications have (from the sample documents) one of the following
formats:

(1) <dosasge> <units> <name>
(2) <dosage><units> <name>
(3) <dosage><units>/<dosage><units> <name>
(4) <dosage><units> / <dosage> <units> <name>
(5) <name>
(6) <dosage> <units> <name> <dosage> <units>
(7) <name> <dosage> <units>/<dosage> <units>
(8) <name> <dosage> <units>
(9) <name> <dosage> <units> in <dosage> <units> <name>

Where:

name   = the name of a medication or substrate, can include percentage
         e.g. 0.9% Sodium Chloride, distilled water
dosage = the amount of a medication or substance. Always a number, can be
         decimal
units  = the units a quantity is in e.g. mg, mL, units/mL.
         May contain any practically any kind of character.

This represents a problem: the format of these medications is very irregular. Fields are ambiguous. For example, medications with formats (3), (4), (6), (7), and (9) have two things that could be conceivable called their dosages and units. One of them is clearly the primary unit, but the other one still needs to be represented. Medications with format (5) have no dosage at all; this would suggest this field is optional. Medications with format (9) have an additional name in addition to an additional dosage, would this go with the units of the second dosage? How should the second dosage be represented? As dosage 1 per dosage 2? As completely separate quantities? Some medications follow each form.

Possible solutions

• Make dosage_amount and dosage_unit nullable to satisfy medications of type (5)
• Add secondary name, dosage_amount, and dosage_unit fields, all nullable. This satisfies the medications of types (3), (4), (5), (6), (7), and (9)
• Add a field for what the secondary values represent. Possible values could be combo (as in e.g. Tylenol 300mg/30mg where the 30mg quantity represents Codeine), amount (as in e.g. 10mL insulin 100 units / mL), and in (e.g. Ancef 1 g in 50mL normal saline).

These are by no means final solutions and I'm open to different ones.

@carlgoshert you may have thoughts on this.

Reprint QR labels in new format

As shown in #22, QR codes for medication are inconsistently formatted, which makes the information difficult to parse. It would be nice to format the QR codes in a more easily machine-readable format, like colon or comma separating the values.

@carlgoshert you wanted to tackle this before #22.

Define new roles for students.

We should really have a proper set of roles. We should develop some, document them, and implement them.

Fix collapsing navbar

The collapsed navbar doesn't expand to show the elements that are hidden. Small displays aren't a huge usecase, but it's possible someone could pull this up on their phone to check something so we should support that.

Stat attribute of Medications migration was not removed

This slipped through the cracks. This line of the medication migration file was supposed to be removed per new ERD, but I forgot to delete it and no one else noticed. This needs to be corrected.

Tests for labs views

The labs views all need feature tests. These can be done after or concurrently with #71, but shouldn't be done before it.

Update views with new medication columns

Create a single user homepage

We should merge the old admin pages and the student home page into one page, showing either a student or admin dashboard depending on role. Partials can be used to separate these portions.

MAR model & relationships

Merge controllers

The controllers need to be merged in and tested. Just focus on the merging part for now. PatientController appears to be the only controller that can't be merged as-is, but some of the auth controllers might cause trouble.

Tests for new models

The Orders and Lab models need tests to show that their factories work without error.

Patient QR codes are unworkable with the current database format.

QR codes for patients have (from the example documents) one of the following
formats, as they will appear when scanned:

<first_name> <last_name>DOB: <dob>MRN: <mrn>
<first_name> <last_name><dob>
<first_name> <last_name><dob>MRN:<mrn>

Where:

dob = mm/dd/yyyy | mm.dd.yyyy | mm.dd.yyXX
mrn = 6 digit code

This means that the current database format is unworkable; these code formats cannot all exist in our current patients schema. The problem lies with how the date of birth is encoded. The date of birth can be either a traditional mm/dd/yyyy date or a mm/dd/yyXX date. The former is completely workable with the current schema, it is parsed into the proper yyyy-mm-dd format before it is added to the database. The latter is unworkable because the year is incomplete; a 'year' of 19XX could be anywhere from 1900 to 1999, and assuming a value for it is impossible.

Additionally, for verification purposes, only the name and date of birth of the patient can be trusted to exist. The MRN is nice to have for verification, but cannot be relied on. When creating patients, this also means that the MRN field may need to be filled in separately.

Potential Fixes

• Treat the date field in patients as a string rather than a date, and change code to reflect that by converting date inputs to text inputs and removing existing date validation.
• Change the verification code to search the database primarily by name and date of birth, and use the MRN if it exists.

These fixes should be mostly backwards-compatible with current code, but they will likely still break some tests. Those will need to be fixed accordingly.

Remove instructions attribute from medications table

Client clarified that instructions is an attribute of medication administration records, not medications themselves. Needs to be removed from migration, docs, erd, and all other project files.

Documentation for formatted barcode data

Write a single document describing how to format medication and patient data for barcode use (1D and 2D).

MAR controller

Merge database formats

The orders and medication modules contain some similarly-named tables (users, patients), and we'll want to rectify any differences between them. We can also use this opportunity to fix the issues outlined in #22.

Rewrite patient QR parser

Because we've update the patient QR format, we need to rewrite the parser like we did for medication.

Update PatientFactory to reflect new table format

The PatientFactory needs to be updated now that we've change the format of the underlying table.

Add policies for Patient model

Similar to what we use already to control accessing medications. These policies should control who can access creating, viewing, updating, and deleting patients.

Fix AWS Buildscripts

AWS buildscripts are currently broken (they leave the deployment in an unusable state). We should try to have them fixed and working soon.

Tests for orders view

The orders views all need feature tests. These should be done after or with #71.

Move discrete css in views to resources

There's a bunch of css in the views in orders/resources that need to be moved to one location in resources/assets/sass/app.scss and have any redundancy removed.

Add new medication columns to scanner parsing

The new medication columns need to be properly parsed by the scanner.

Test Javascript

The javascript components used for the scanner need to be tested, as we've already had several errors during demonstration and we want to avoid those in the future.

Make sure MAR has stat and instruction attributes

These were removed from medication migration in anticipation of having them in the MAR

Merge views

Merge all the views together, along with any image assets. This one can't be done until #35 and #42 are done, and it will probably be one of the last things we do for integration.

Reprint patient QR codes and rewrite parsing

Implement barcode verification

This includes parsing and the related verification methods in the controllers.

Tests for orders controller

The orders controller needs tests using the factory to verify its behaviour.

Remove unnecessary Laravel config files

There's a lot of files in /orders that are likely identical to the ones that we already have. A good first step towards integration is to remove those so we can take stock of what's left.

Tools for formatting medication and patient data for barcodes

A Javascript tool that takes information from text boxes, compiles them into the appropriate format, and prints out the formatted data so the user can copy-paste it into a barcode encoder (1D and 2D).

Update the README

We need to provide documentation to get someone up to speed with how to set up the application. This is the first thing someone maintaining our application will see.