Before BODi was launched in the USA, a surgical physician can have no certainty of the history of any given implant that is made available during surgery. Typically a surgeon may order multiple devices to be available during surgery and delivered to the operating theatre. For any of those devices that are not used during the surgery, it is expected practice to sterilise and irradiate devices before going back into circulation. Every time a device is 'washed' it will deteriorate the device to some extent, and it's for that reason that devices should be decommissioned after the threshold has been reached. However, implant devices are not currently tracked and therefore it is unknown how many times each devices has been washed. This increases the risk that implants may fail after implantation.
For this reason, a platform is required where:
- Physicians can have implant devices ordered for their surgeries and where those devices are not held in store, are ordered directly from the manufacturers.
- Implants and surgery orders can be managed by admins of the platform.
- Different user roles can view and update orders in a restrictive way as defined by their role.
- Manufacturers can view and update all new orders they receive directly on the BODi platform.
- Distributors can track orders and ensure devices are delivered where they need to be.
- Case representatives can can update surgery orders to confirm which devices were used in surgery or later washed.
- Each implant is designated with a QR code that is used for identification throughout its entire life-cycle.
- Each time an implant is moved or processed, it has a time-stamped and signed 'event' saved to the database.
- The QR codes can be scanned via the platform using either the camera on a mobile device or webcam.
- All users of the system need a communications suite to allow easy messaging to all other members to ensure the seamless operations.
As this system primarily manages users and content, Drupal 8 was a perfect fit.
Because of the highly complex nature of managing flows of many different entity types within the system, how they interact with each other, and how they can often trigger chain reactions etc, a significant amount of attention was needed to design the information architecture of this system.
With all complex systems, it is paramount to hide this complexity from the end user, so we also had to work hard to understand how the users would want to interact with this system in the simplest possible manner. We needed to determine what would be the easiest set of steps required by each user to complete their respective tasks. With the use of story-boards and wire-frames we were able to do so by incorporating the feedback and opinions of target users.
A series of custom modules were created to manipulate Drupal entity types that would allow us to achieve their goals as defined by the client.
A carefully crafted custom theme was also developed with the aid of our UI/UX experts to ensure all areas of the platform were intuitive to use.
The project proved to be a far greater challenge than we had initially thought. The information architecture at the heart of this system has made even some of our senior developers go cross-eyed trying to understand it, but as a result of this implementation we have hit the brief and the client is very happy with what we have produced.