We have implemented a module outside of OSCAR that is specific for Methadone doctors. It adds functionality that doesn't necessarily make sense within OSCAR proper.
We are looking to have this approved as a 'Trust App' within the OSCAR eco-system.
The application is designed to interact with the OSCAR database directly, and both reads and writes data. OSCAR is the canonical source of data
in our application. That is, all notes, prescriptions, and measurements entered in the external application are stored in the OSCAR database whenever possible.
This allows our doctors to still use OSCAR as they would normally, and use our module when they require Methadone specific functionality / workflows.
There is some data that is stored in a new database, which stores data specific for Methadone workflows, or extra information pertaining to measurements or
prescriptions that don't have a proper place in OSCAR.
There is a single change that we have added to OSCAR to allow us to interact with it. It fixes a bug with the way user password hashs are generated. Beyond that,
no changes need to be made to OSCAR.
The password hash fix would require proper release management - that is, once deployed, users on the system would be required to change their passwords. Users would
need to be informed of this.
For OSCAR, OSPs would need to know about the password hash changes, and how this affects their users. Once a user changes their password, everything
works in OSCAR the same as before.
For OSCAR, changes are already done.
Please let me know if you need any further details.
SHA1 fix commit is here: https://source.oscartools.org:8080/10692
Last edit: Jarrett Chisholm 2014-07-16
An app can not touch the database directly. Apps must use the web service api calls. If an api call does not exist then they will need to be built. This is needed for security and logging. If you access the database directly the data read will not be logged and it will not be checked to verify the requesting user has access to that data.