The Enterprise Edition of Medication Tracking is a large
enterprise level system dedicated to helping Care Givers within small to large organizations
ensure patients always have continuity of medications without having to remember
when to perform various events to ensure patient's medications are always available
to them. Medication Tracking allows for an unlimited amount of Care Givers to process
patients medications. There are 3 distinct roles within the Medication Tracking
System, the Administrator, Supervisors, and Medtechs. Only one Administrator is
permitted within each organization's Medication Tracking System. The Administrator
initially setups all Medication Tracking System User Accounts as well as maintains
them on an ongoing basis. The Administrator has total ownership of the Medication
Tracking Database and has the capability of executing numerous network engineering
commands on the Data Server, which houses the Medication Tracking Database, to control
all the activity of each user within the Medication Tracking System. The Administrator
is also responsible for importing any existing data into the Medication Tracking
System upon the inception of the system itself. Supervisors typically add, delete,
and assign patients to Medtechs for medication processing. Supervisors can transfer
ownership of patients to other Supervisors and even the Administrator if necessary
and vice versa. Although Medtechs typically process individual patient's medications
within the Medication Tracking System, the Administrator and Supervisors can process
patient's medications they have permissions to, which are all patients for the Administrator
and patients owned by Supervisors. Administrators, Supervisors, and Medtechs have
the capability of entering an unlimited amount of medications for each patient within
the Medication Tracking System as well as create an unlimited amount of scheduled
background jobs to execute and search for patients they have permissions to whose
medications require attention. Each user can create background scheduled jobs from
an unlimited amount of combinations of frequencies, intervals, and dates and times.
The Medication Tracking System allows users to enter in all the necessary information
to process all patients'
medications in a timely and efficient fashion along with the capability of communicating
electronically with pharmacies, physicians, insurance companies, and other contacts.
Below is a brief summary with some of the responsibilities and aspects of processing
Acquiring New Prescriptions for Expired Medications
Acquiring New Prescriptions for No Refills Left
Medication Authorizations and Reauthorizations
Create Schedules for Notifications choosing
from unlimited frequency and interval combinations
Store Pharmacy, Physician, Reasons for taking Medications,
Insurance Company, and Contact Information
Track Medication Ordered and Received Date, Days of Supply,
Number of Refills Left, Expiration Date, Dosage, Physician's Instructions, Date
Permitted to Refill Again, Days Elapsed after Permitted to Refill Date, Date Medication
Run Out, and Date Requiring Reauthorizations
Database Backups with Warning Mechanism
Pre-defined Requests for Medication Refills, New Prescriptions,
Medication Authorizations and Reauthorizations, and Sending Copies of Insurance
Cards built and submitted in the background electronically to Pharmacies, Physicians,
Insurance Companies, and Other Contacts which the Individual can query, maintain,
and setup a size tolerance limit frequency
Pre-defined Request Logging, Querying, Maintainability,
and Mechanism to check log size against set tolerance size limit
Medication Reasons Repository
Integrated High Performance Relational Database
Medication Tracking Integrated Help System, Help Notifications,
and Help Popups
Tracking Change History which can maintained and queried
along with a set tolerance limit warning mechanism
Printing capability of Current and Past Medication lists
Above is just a very simple summary of the Enterprise Edition of Medication Tracking.
There are numerous other features and functions within the Medication Tracking System.
For an in-depth walkthrough of the entire Enterprise Edition of Medication Tracking,
please refer to the Overview of the Enterprise Edition of Medication Tracking which
you can get to by the menu to the far left. Meanwhile, please review some of the
features within the Medication Tracking System that are below.
Easy Connection Settings
When connecting to a network Data Server, each user can setup their connection through a very flexible
"Connection Settings" screen. Every user has the capability of bringing the Data Server online if it
is offline as long as the user's computer has Wake On Lan (WOL) capabilities which is very common.
Also, all scheduled tasks, which we will discuss below, can automatically bring the Data Server back online
if desired. Within the "Connection Settings" screen, each user can also have the network Data Server mapped
automatically to one of their network drives on their computer. So, this allows Medication Tracking to perform
network administration functions automatically freeing each user from waiting for a network administrator
to help with these tasks. Medication Tracking was designed to make using the product as easy as possible,
especially installation tasks. We want all our clients and customers to purchase services from us which gives
them value, especially not having our clients pay for messy installations. We wish to satisfy all our clients
and customers, not surprise them.
Designated User Roles
There are 3 roles for users within the Medication Tracking System. First, there is the Administrator who has
privileges to perform any action throughout Medication Tracking, with the exception of viewing user passwords.
They can track and edit any patient they desire. They can perform all administration tasks. They can, and only
administrators, create, update, delete, and reset passwords for login user accounts. Also, administrators can
view all statistics on all users within Medication Tracking, including individual and all Supervisors. Passwords
are encrypted preventing anyone from viewing user account passwords. Every company which uses the Enterprise
Edition of Medication Tracking must have only one administrator within the Medication Tracking System. We only
allow one administrator within the Medication Tracking system to avoid administrators from stepping all over
each other. The next role is a supervisor. Supervisors can perform some administration tasks, but not all of them.
Supervisors can only view patients and their statistics owned by that supervisor. Supervisors can create, update,
and delete patients. When a supervisor creates a patient, only that supervisor owns the patient, however;
supervisors can transfer ownership to other supervisors or administrators, if desired. Supervisors can only
track and change patient's medications they have ownership of, however; typically, this would be the
responsibility of Medtechs. Supervisors can assign patients, they have ownership of, to users, typically
Medtechs, to track and make changes to the patient's medications. Finally, a Medtech has the lowest
privileges within Medication Tracking. They can only view, track, and make changes to patients assigned
to them by supervisors or administrators.
Built-In Custom Job Scheduler
The Enterprise Edition of Medication Tracking also has a comprehensive custom job scheduler to create schedules
to launch Medication Tracking if any of the patients you can view require actions, schedule backups, only by
administrators, although, all users can view all schedules in Medication Tracking except only their schedules
to launch Medication Tracking automatically if any of their patients require actions, and, finally, schedule a
job to search and set patients who require action within the Medication Tracking (Patient) Database, which only
Supervisors and the Administrator can create. As we claimed, any user can view all job schedules within the
Medication Tracking Job Scheduler, however, users can only update and delete jobs they created. Users can
enable and disable scheduled jobs very easily only they own. We encourage users strongly to at least enter
in one schedule, not necessarily the Administrator, to search for patients they only have permissions for
and bring up Medication Tracking automatically if there are patients who require any action. Within the Medication
Tracking Job Scheduler, users can also create more than one schedule for all types of background jobs at numerous
intervals to choose from. A user can create schedules to run onetime, daily, weekly, and monthly with many
intervals for each. Any user can almost create an unlimited amount of schedules for various intervals. Users,
with permissions, can also create as many schedules as they wish for any one type of background job. You will
find the Medication Tracking Job Scheduler is a very powerful tool within the Medication Tracking System.
Within the Job Scheduler, among other background jobs, a backup of the entire Medication Tracking Database can
be scheduled in practically any frequency and time period, which only the Administrator can do. Also, the
Administrator can create as many backup job schedules as desired, without interfering with the users within
the Medication Tracking System. The Medication Tracking System and Database has been designed thoroughly to
handle user and job contention management, however, the impact on overall performance needs to be a strong consideration.
Integrated Comprehensive Help System
There is also a very extensively integrated Medication Tracking Help System within Medication Tracking. Within the Medication Tracking System, you can press the F1 key anywhere, and the help topic relating to the exact location you are in the Medication Tracking System will pop up along with the entire Integrated Help System. If you desire, at that point, you can also browse through the entire Medication Tracking Help System or just learn as you use the product. One to all discussion topics with the Integrated Help System can be printed off if desired. The help system has various tabs for easy navigation, contents tab, index tab, search tab, and favorite's tab.
Within the Medication Tracking System, there are so called "Help Notifications" which are basically help tips which popup all throughout the Medication Tracking System randomly that give you information on the area you are currently at. You have the capability of turning each of the help notifications off one by one as you get proficient with the Medication Tracking System, although you also have the capability of turning all the help notifications all off or on at once. However, we strongly don't recommend turning all the help notifications off all at once until you are very familiar with the Medication Tracking System. After you become very familiar with the Medication Tracking System and end up turning off all the help notifications, if you forget how to process some area within the Medication Tracking System, you can turn all the help notifications on at once, and read the help notification(s) you are interested in. After you are finished, you then turn them all off again. When you turn off or on all the help notifications at once, this will take effect throughout the entire Medication Tracking product for each individual user. Medication Tracking has various mutually exclusive individual user components within the boundaries of it, so turning all of the help notifications all off or on at once will communicate with all of the components within each individual user's Medication Tracking Product. For example, if a user has open the screen to list all of the patients they are permitted to view along with each patient's individual status and associated information, and the same user has open multiple patients' medications, which are mutually exclusive technical components, when the user turns off or on all their help notifications, this will take effect within all of these components.
Extensive Patient Medication Processing
When tracking and editing patient's medications, there are literally hundreds of edits, checks, and balances to assure patient's medications don’t lose continuity of use. Since there are numerous reasons and situations where a patient could not get their medication on time, the patient can potentially be left without critical medications, periods at a time. Medication Tracking prevents this from happening to patients by warning Care Givers patients require new prescriptions or refills before current refills run out allowing lead time to retain these to avoid being without critical medications. Within the Medication Tracking System, a Care Giver can even build a buffer of medications overtime for patients in some cases, by Medication Tracking helping the Care Giver be proactive with refilling prescriptions exactly on time, to avoid being without critical medications even more. This can be very helpful when refills are delayed, especially with mail order and/or medications requiring a new prescription or even a reauthorization, which the Medication Tracking System also keeps track of. When Care Givers are managing multiple patients, it can be very difficult to remember refilling medications, requesting a new prescription, requesting a reauthorization, which can take a long time to acquire, etc. The Medication Tracking System makes sure all these events are tracked for you. If there is nothing for the Care Giver to respond to, Medication Tracking will remain dormant, like a watch dog always protecting Care Giver's patients from going without medications, especially critical ones.
The Medication Tracking System was inspired by many factors including experience in the IT medical field along with personal and others true life scenarios of either going without critical medications, and suffering very bad side effects, or paying high prices for a medication(s) to get by until the drug insurance companies provided the medications after delays. We have had, heard of, and witnessed countless experiences where these types of situations occurred. Also, if Care Givers don't realize their patients don't have refills left, when they or someone else goes to refill medications, the pharmacy will demand new prescriptions, and this can take some time, especially with requiring reauthorizations, mail order and various patients to manage. A lot of insurance companies are now forcing or plan on forcing patients to use mail order drug companies and Medication Tracking works excellent for mail order.
Thorough Security Model
The Medication Tracking System has an extensive and thorough security model which is geared towards satisfying Patient HIPAA Requirements. With a built-in security model, the entire Medication Tracking (Patient) Database is locked down tightly with the designated Medication Tracking System Administrator. The Medication Tracking System manages Machine Store, NTFS, and Universal Access Control List (UACL) security for all patient and medication data. As we explained above, there are a lot of network engineering functions and features built right into the Medication Tracking System, so the Medication Tracking System Administrator can handle all levels of security just as a designated resident Network (Administrator) Engineer would. We make all the various security features and functions very understandable and easy to perform for any person your organization determines to be the Medication Tracking System Administrator. All the nuts and bolts of the network engineering commands are built and placed in the background of the Medication Tracking System, so the Medication Tracking System Administrator doesn't have to understand or bring any prior network engineering skills to the Medication Tracking System as well as learn any. We do everything in the background for your organization. There are also mechanisms in place to warn the Medication Tracking System Administrator if there are any predatory intruders into the Medication Tracking (Patient) Database, even with it being remote. The Medication Tracking System Administrator will have total ownership of the Medication Tracking Database where absolutely no user account on the Data Server will be permitted to access it unless allowed by the Medication Tracking System Administrator, not even other Administrators on the Data Server itself. The Medication Tracking System Administrator has the capability to transfer total ownership of the Medication Tracking Database with all necessary background access rules and permissions being deleted from the existing Medication Tracking System Administrator and transferred to the new Administrator cleanly and appropriately. No access rules or permissions will be orphaned with an unknown security identifier (SID), which happens more than people think The Administrator can override all user account passwords, force password expirations, set password expiration dates, enable and disable users, lock and unlock users based on bad password attempts, add and delete users, create, rename, and delete security groups, change user, security group, and directory access rights, create and send various custom notifications to users with attachments if desired, observe login history, bad password attempts in terms of the amount and time of last one, password change times, last login and logout times, etc. The Medication Tracking System Administrator determines which other groups all the users within the Medication Tracking System have permissions to. An example of this would be if the Administrator decided to give each user within the Medication Tracking System access to the same rights as users of another totally different application other than the Medication Tracking System. Each user is forced to choose a security question and give it an answer, so if they forget their password, they can retrieve it through the answer to the security question they chose. All users are governed by a timeout limit which is set by the Medication Tracking System Administrator. If a user isn’t interacting with the Medication Tracking System either by using the keyboard, mouse, or waiting on a process for the set limit by the Administrator, they will timeout. Once the user times out, they must re-enter their username and password to re-enter the Medication Tracking System. This prevents others from getting on their Medication Tracking System session while their away from their computer.
Electronic Email Transmission (EET) Requests
When processing medication changes, users send medication Refill Requests, New Prescription Requests, Preauthorization Requests, and Insurance Card Copies in very professional rich formatted emails to pharmacies, physicians, insurance companies, and other contacts. The Administrator can solely predefine the formatting of these 4 Electronic Email Transmissions (EET) themselves or allow each individual user to predefine their own. These email transmission requests can have any background or trailing image the user determines. These images can represent the distinct image of your organization if desired. The Medication Tracking System comes with 12 images already created to give these requests a very professional looking background. Users can also manipulate the fonts, text coloring, and back color of these emails with an unlimited amount options to choose from. Placeholders can be dragged and dropped onto the requests which get filled in with the corresponding data from the Medication Tracking Database when the requests are sent out to pharmacies, physicians, insurance companies, and any other contacts the user wishes. As email addresses are entered for these contacts, a contact repository is created with identifying information for each contact for easy reference. These contacts are maintained by the Administrator and individual users. Each of the 4 types of EET requests will have their own pre-defined format with all these characteristics to be used when sent to their corresponding contacts. So, your organization can either have the Medication Tracking System Administrator maintain total control of how the Electronic Email Transmission (EET) Requests look as well as what content they have based on specific data from the Medication Tracking Database or have individual users maintain their own EET Requests. As each individual EET is sent to its associated contact, an entry will be placed in a log file to track the outgoing EET. Individual users can only view the EETs they were responsible for sending out while the Administrator can view the total of all EETs sent out by all users within the Medication Tracking System. Also, the Administrator can set a tolerance limit of the total size of all the entries within the log file of the EETs sent. If this limit is breached, the Administrator will be warned and have the opportunity of scaling down the log file if desired. The Administrator will always be able to view the total size of the log file at all times. Your organization will have the opportunity of creating the most impressive professional looking emails most likely ever seen from anywhere with the formatting tools and features available within the Medication Tracking System. We have basically pioneered these features which were tailored for the Medication Tracking System.
Statistics and History
There are various statistics and history built into the Medication Tracking System which allows all users the capability of researching almost any discrepancies or issues which may arise. Among these statistics, users with permissions can view all the distinct medications within the Medication Tracking System along with the patients whom use them. Other statistics include evaluating user performance and patient change frequency within any month of any year. The amount of history that is stored in the Medication Tracking Database is controlled by the Medication Tracking System Administrator through many different deletion functions and features. They are various tolerance limits the Administrator can set on patient medication history and, as said above, the log file for sent Electronic Email Transmission (EET) Requests. If the limit is breached, the Administrator will be warned accordingly. Other statistical data can be deleted manually on request when the Administrator determines the data is obsolete. Most statistical data can be used in conjunction with other statistical data to bring to light various interpretations of the data within the Medication Tracking System. Please review the help system for other statistics and history within the Medication Tracking System. Also, statistical data will always be an envolving and ongoing type of entity of its own bringing to light more and more ways of interpreting activities within the Medication Tracking System.
Data Audit Trails
All data is tagged with the date and time of which user updated or created the data. This aids tremendously with investigating any discrepancies or issues within the Medication Tracking System for all users. It also lends to user accountability. The Administrator and especially Supervisors will be capable of querying the activity of all users within the Medication Tracking System they have access to. The audit trails put in place allow Administrators to evaluate all or individual Supervisors performance and for Supervisors to evaluate Medtechs performance within the Medication Tracking System. These audit trails pave the way for the statistics within the Medication Tracking System allowing for the capability of identifying what date and time as well as which user created or updated any piece of data within the Medication Tracking Database. These audit trails will allow users outside of the Medication Tracking System, given permissions by the Administrator, query general or specific types of information. Every table within the Medication Tracking Database has these audit trails associated with them. This type of data also helps determine what data to delete in the Medication Tracking Database. Incorporating auditing data within any database is always a good general practice for these types of scenarios among many others.
Sufficient Error and Exception Handling
All errors are handled in a formal and proper manner. User exceptions are reported directly and understandable to the user for resolution. True product errors can be reported directly to Medical Resource Management very easily with the press of one button giving us all the information we need to resolve any errors or issues which arise within the Medication Tracking System. Product errors sent to us will never contain any of your organization's specific data. They will only contain technical data required by us to resolve any product programming errors. Before a user sends any product errors to us, they will have the opportunity to review the specific information being sent to us very easily to assure themselves none of their specific sensitive organizational data is sent to us. Users should never get any other types of errors other than understandable user exceptions and product errors, with the opportunity to view the information being sent to us. With the error handling methodology we incorporated into the Medication Tracking System, these 2 types of errors should be the only errors any user should ever see, and hopefully, product errors should be very infrequently, however; user exceptions will typically be based on the understandability of each individual user of the Medication Tracking System. As users become more and more proficient with the Medication Tracking System, these errors should become more and more infrequent. Any quality developed software application should always have a good methodology for handling these 2 types of errors, user exceptions and product/application specific errors.
User Time Out and Database Re-connection Capabilities
The Medication Tracking System has built-in user time out capabilities. A user time out occurs when an individual user does not interact with the Medication Tracking System either by not pressing a key on their computer's keyboard, not clicking their computer's mouse, or is not waiting on some particular type of processing to complete for a set amount of time. Once the time out occurs, all screens and components within the Medication Tracking System the user has open will begin to close extremely quickly with bringing up a small box to re-enter their Medication Tracking User Account Username and Password. While the user's session within the Medication Tracking System is timed out, there will be absolutely no impact on their computer's CPU at all. If you were to look into your computer's Task Manager while a time out was active, you would see zeros next to the associated components currently open for your Medication Tracking session within the CPU Usage column. Once the user decides to re-enter their Username and Password, all Medication Tracking screens and components, which were open at the time the time out occurred, will begin to re-open very quickly with ultimately having the focus on the screen the user had focus on prior to the time out occurring. The Administrator has sole responsibility for setting the user time out period with many various time out periods to choose from. Once the Administrator changes the time out period, it will immediately take effect with every user within the Medication Tracking System, whether they are currently in the Medication Tracking System or not. If any particular user is getting close to the time out period, with no interaction in the Medication Tracking System, once they interact with the Medication Tracking System in any way, the elapsed time to the time out period will be automatically reset back to zero, meaning the time out period will start all over again from scratch. This is an extra security measure within the product, in the event, another person attempts to get into any user's session in the Medication Tracking System while the user is away from the computer they have the Medication Tracking System active on. In terms of re-connecting to the Medication Tracking Database, if something happens to a user's connection to the database or something happens to the database itself, in terms of online availability, each user, as well as background jobs, has the capability of bringing the Medication Tracking Database back online no matter where it exists, depending on certain requirements which is discussed in another topic. If a user is timed out along with losing their connection to the Medication Tracking Database, once they enter their user account Username and Password, not only will they be brought out of the time out, but also, an attempt to re-connect to the Medication Tracking Database will happen automatically as well. If the user is not timed out but loses their connection to the Medication Tracking Database for whatever reason, the Re-connection screen to the Medication Tracking Database will come up, assuming the database is on a remote server, which is typically the case. For these 2 mechanisms to work properly, an enormous amount of programming was required as well as extensive testing of the Medication Tracking System. These 2 features work very well which allows the handling of time outs and database re-connections to be as easy as possible for each user within the Medication Tracking System. Each feature also works very well in conjunction with each other.
Import Existing Patient Data
This feature allows your organization to import its patient and medication data almost anyway required. This is a very sophisticated tool developed for optimal flexibility. There are various import file types you can choose from, which should cover most types of files our clients would need to import. Your organization can import files with data of fixed lengths and fixed positions as well as many file types where your organization chooses which columns contain the data it wants. With all of these file types; it doesn't matter if the order of the data changes over and over again. Your organization can easily change which positions or columns in the import file your organization wants each field of the patient and medication data to reside in. There is the capability to save records which have errors, fix the errors, and re-import just the records with errors. The import feature allows control of which fields of data are required to import. The last imported statistics can be viewed at all times. All of the data within the Medication Tracking (Patient) Database can be deleted, except for login accounts, if an import polluted the database severely enough to allow a new import to run against a clean database. With color coding, there will be distinct ways to identify various types of imported data within the Medication Tracking System very easily. The import tool is a product from years of various experiences with many types of import features. You will discover much more to this feature as you start using it. If your organization has specific needs, outside of the scope of the import feature, we will work with your organization to discuss ways to get its data imported into the Medication Tracking System.
If there’s an update for Medication Tracking available, each individual user will be automatically notified the next time they bring up the product by a small update box on the bottom right of their screen. If they choose to update, their version of the Medication Tracking Product will be automatically closed, and they will be taken to the download page for the Enterprise Edition of Medication Tracking update. Updates are extremely easy to install which are very similar to Microsoft Updates, however; they will be much smaller and quicker to install. It is up to each individual user as to when to implement the new update of the Medication Tracking Product. They can either do it immediately or wait as long as they wish, however; each time they bring up the Medication Tracking System, they will be notified of the new update until it is implemented. This is to ensure every user of the Medication Tracking Product has the latest version of the product, in the event; there are critical updates to the product they will require.
Reset and Retrieve Data from the Backup
for all types of data
In the event, any user totally corrupts an area of data within the Medication Tracking Database, in most cases, they will be able to recover the data from the Backup of the Medication Tracking Database, and only the specific area of data they are concerned about, not the entire Medication Tracking Database. Throughout the Medication Tracking System, various screens have a “Retrieve from Backup” button in the color blue allowing the user to recover and revert to the backup data of the specific area they are in. This will ensure only the data of the area they are currently at will be affected by the recovery. This is typically within Patient’s Medications for certain reasons. This is the most likely place for mistakes due to the nature of processing. The areas within each session of processing any particular patient’s medications are isolated well from other data within the Medication Tracking System. The data outside of each patient's medication data is typically controlled by the Administrator only, with the exception of managing patients that is typically controlled by Supervisors. Recovering from the Medication Tracking Database Backup is a last resort because the user could potentially lose any changes made since the last Backup of the Medication Tracking Database was performed. There are other excellent ways of recovering the total data without having to revert to the Backup, like session resets, undo, redo, back to the beginning, back to the end, multiple exiting confirmation types, etc. Within areas of data deemed sensitive or prone to mistakes, we make sure these areas were well managed in terms of making the user think about the changes they made first with allowing them numerous opportunities to back out of changes if there were mistakes in any form. Our staff has decades each of IT experience, so we are well seasoned with how users can and likely will make mistakes when entering data and how to minimize mistakes from ever being committed to the database. This is one area that is reflective of the caliber of experience of the developers, like error handling, standardizations, conventions, and methodologies. If you’ve ever used a software application that gave you the most meaningless and frequent errors you’ve ever seen, it is most likely that application was developed by software engineers with minimal experience. Software developed in that manner would not be permitted by experienced seasoned IT Professionals no matter what the cost to themselves. Many experienced software engineers take great pride in the software they send out to clients and customers alike, in terms of quality and performance.
Patient Medication Processing
In terms of processing patients’ medications, within the Medication Tracking System, users can only see and process patients they have been assign to or own, therefore; in terms of roles, Medtechs can only view the patients, as well as process their medications, they have been assigned to by their Supervisor or Supervisors, Supervisors can only view, assign, and process the medications of patients they own either by creating the patients themselves or having the patients transferred to them by another Supervisor or the Administrator, and Administrators can do anything within the Medication Tracking System. This pecking order of permissions to patients also coincides with automatically launching the Medication Tracking System if the user has patients whom require action. So, if there are patients whom require action with the Medication Tracking System, but a particular user doesn’t have permissions to any of those patients and the user has a schedule to launch the Medication Tracking System automatically if there are patients they have permissions to and whom require action, when the schedule runs, the Medication Tracking System won’t launch automatically for that user showing them they have patients whom require action. There are patients whom require action, however; that particular user doesn’t have permissions to them, so they don’t have any responsibilities to them. So, it would appear like those patients don't even exist within the Medication Tracking System as far as they're concerned.
When a user has responsibility, permission, to a patient, there is a wide spectrum of responsibilities they could perform on that patient, especially if they are the Medtech. In an ideal situation, the Medtech would perform all the necessary medication processing responsibilities of only the assigned patients to them, however, not administrative tasks. The Supervisor would assign patients to Medtechs as well as perform certain administrative tasks, but not all administrative tasks like the Administrator. Typically, the Administrator would perform very high level duties, like within most medium to large sized organizations, dealing with permissions, storage requirements, making sure password requirements are satisfied, creating and deleting user accounts, locking and unlocking users based on bad password attempts, disabling or enabling users, assigning security group rules and permissions, assigning and removing users to the Medication Tracking Security Group, assigning the Medication Tracking Security Group to other groups with the Data Server, expiring passwords, notifying users of administrative activities, etc. Supervisors would handle the supervision of Medtechs where, not only would they assign patients to Medtechs, they would also generate and analyze statistics of their subordinate users, make sure certain background processes are running and running correctly, maintaining and monitoring certain data requirements, etc. We do realize that most organizations are not so clear cut. So, these roles will definitely overlap. Your organization will need to understand the responsibilities of all the roles within the Medication Tracking System and determine which person does what as well as which role does what. So, there are certain organizations which will or does perform all the roles with the clear boundaries as the roles are theoretically defined here, which the medium to larger organizations do typically, and there are some organizations where one or two people do everything. Even though the Medication Tracking System only permits one Administrator, in some cases, 2 to 3 people only work on the Medication Tracking System, and they just use the same user account, each logging in at different times. So, there is only one login account of the Administrator doing everything. Logically, the larger the organization, the more specialized and defined the roles will become due to the quantity and separation of duties. With the inception of the Medication Tracking System in your organization, the initial involvement of the 3 roles will most likely be the Administrator will have the most then the Supervisors and maybe, in some cases, the Medtechs to a certain extent. Due to the Administrators having to setup all the security, user accounts, creating the security group, determining access rules and permissions, playing an integral part in any required data migration, laying the ground work for the Database, etc., the Administrator will have the most involvement in the beginning stages of the Medication Tracking System in an environment. Next, the Supervisors will need to work with the Administrator to make sure all users get setup correctly, be involved in certain aspects of required data migration, and propagate setup information to supervised personnel, etc., so the Supervisors will have the next highest level of involvement in the beginning stages of the Medication Tracking System in an environment. In the beginning, there may be some involvement with the Medtechs, but if so, there most likely won’t be much. Once the Medication Tracking System gets installed and setup correctly, the involvement of the 3 roles will start to reverse to the Medtechs having the most, next the Supervisors, to the lesser, the Administrator. This will be true because most of the continuing activities will be processing patients' medications, which would be logically the Medtech. This is usually typical of any software application or even business process in general, which software applications typically mimic.
When processing a patient’s medications, there are several basic responsibilities, however; these responsibilities can become alarming very quickly, especially, the more patients are being processed, the higher the probability of alarming situations arises quicker and more often. The responsible user, typically the Medtechs, must make sure all current medications are entered and maintained accurately and timely. All refills, new prescriptions, reauthorizations for certain medications must be watched and taken care of in timely manners. As medications are entered into the Medication Tracking System, each medication’s associated physician’s information, medication reason or reasons, associated pharmacy, and associated insurance information must be entered into the Medication Tracking System as well. Then, as there are changes to all of this information, they need to be not only entered but entered in very timely fashions because filling medications can be very sensitive to time, especially controlled substances. As these duties are administered, correspondences with the appropriate contacts, for each of the duties, needs to happen, and to a certain degree, these will be handled with Electronic Email Transmission (EET) Requests. As all EETs are sent, they will be logged accordingly within the Medication Tracking System for reference at a later time if necessary and to gather statistics. Certain medications, usually brand named medications but not always, will require reauthorizations. With reauthorizations, the responsible user must understand there can be very time sensitive overlaps in requesting new prescriptions and acquiring reauthorizations. This can sometimes be a nightmare, so the user must take full advantage of the Medication Tracking System to handle this for them. If the user has to deal with mail order pharmacies, the user needs to be well aware of lead time with not just requesting refills but also requesting new prescriptions and reauthorizations if necessary. This can turn into a cascading effect very quickly out of nowhere. Well, the Medication Tracking System is designed to handle these types of scenarios very well. So, each user is going to have to understand the entire benefit of the Medication Tracking System as well as be monitored by their immediate Supervisors for taking responsibility in entering all the necessary information into the Medication Tracking System for it to be effective for these types of situations. So, the Supervisors will have to be proactive in making sure all the Medtechs are entering and maintaining patients' medications accurately and in a timely fashion. They will, in some respects, be the quality control. Certain medications will not be used as tightly prescribed by the physician as others. These types of medications need to be handled accordingly within the Medication Tracking System. The user will need to work with the inactive status, expiration dates, in terms of warnings to not expire remaining refills to avoid getting new prescriptions, etc. If these types of mechanisms which are built into the Medication Tracking System are not taken advantage of, the Care Givers will not only have more work to do, but will be running around in emergency mode a lot more than necessary. So, Supervisors need to review their direct reports, Medtechs, for entering the appropriate fields and their associated values they contain to take advantage of all the various warning mechanisms within the Medication Tracking System. Supervisors can easily see the values Medtechs are entering to get a clear picture of what is happening with each patient’s medications. Also, there are statistics built into the Medication Tracking System that Supervisors can reference for Medtech performance. Administrators can perform these same actions on all users of the Medication Tracking System as well as review all Supervisory areas for performance statistics. As medications are being processed, issues will more than likely arise, so there will be troubleshooting tasks put on top of all the responsibilities to getting patients’ medications processed accurately and in timely fashions. As Medtechs are entering and updating medication data, there will likely be mistakes. Patient Medication Processing has session handling built into it where the user can extremely easily undo and redo changes to a patient’s medication data if there are mistakes of any kind. The user can easily undo one, many, or all changes as well as redo one, many or all changes at once. This session processing will help the user dramatically. Plus, there are embedded strategically placed confirmations to ensure changes to patients’ medications are committed intelligently and not by mistake. If all else fails, the user can revert back to the backup for lost data very easily as well, although any changes from the last Backup will be lost. With session processing, there is a lot the user can do as well as having the Medication Tracking System ensure patient’s medication data is handled correctly. With patient medication session processing, there are a lot of fast keys, duplicate functions, numerous navigational keys, etc. to aid the user in processing patient’s medication changes in a timely manner with minimizing mistakes, plus to allow the user the freedom to concentrate on the accuracy of the patient’s medication data. So, there’s really a lot going on here that the Medication Tracking System is solely designed for. Each patient medication processing user will be able to find that special way of theirs, flavor, of entering the patient’s medication data in a fast and accurate way that fits their style. Patient medication processing was developed with sessions to allow processors the fastest way to process each patient's medications along with controlling and managing the accuracy of the data entered into each patient's medication list.
Now, when processing a patient's medications, entering and editing all their medications, there are hundreds of edits and verifications to ensure the integrity of the data being entered. We won't list all of these because, obviously, this would be a lot, however; let us suffice to say these edits and verifications are for the most part logically performed. For example, all dates need to meet certain criteria like the user must enter in the correct year, the received date can't be earlier than the ordered date, the expiration date can't be earlier than the ordered and received date, if there are zero refills left and the user enters in an ordered date, the user will be told, if they continue, the new order will be treated like a new prescription, the user will be warned if they enter in a date earlier than the date allowed to refill again, which is a derived date, etc. There are literally hundreds of these, so we won't list them, but these edits and verifications make sure the user enters all patient medication data as intelligently as possible to minimize any mistakes because, due to the nature of filling medications in general, any mistakes can be significant, even life threatening is some case.
Within patient medication processing, users can print various lists of the patient’s medications. The user can print the current list of the patient’s medications as they currently exist in time. Also, the user can print the patient’s medication list as it looked from any moment in time, as long as there was at least one change to a medication at that time, as far back as their history dictates and the Administrator decided to keep. Also, a user can print all the physician and medication reason information about any patient's list of medications, however; this can only be done for the current medications as they exist, not as they were in history.
Each medication a patient uses has a medication reason, obviously. As medications are entered into the Medication Tracking System for patients, medication reasons will be associated with medications and new medication reason entries will be placed into a medication reason repository. This medication reason repository can be very structured and formalized or loosely flexible. This is up to your organization's needs. For example, an organization can determine it will have specific distinct medication reasons along with some sort of coding identification for each medication reason. The Administrator can then enter in all the available medication reasons with their associated identifications into the medication reason repository. Once all the medication reasons are entered into the repository, each individual user can select from all available medication reasons within the entire Medication Tracking System, through the medication reason repository, and choose the best medication reason or reasons that match the medication they are entering into the Medication Tracking System associated with a particular physician. In this case, the Administrator would forbid any other user from creating new medication reasons through the settings within the Medication Tracking System. The Administrator will be able to maintain all the medication reasons within the Medication Tracking System Medication Reason Repository where they can enter in new medication reasons, update existing medication reasons, and remove medication reasons. All users, other than the Administrator, within the Medication Tracking System will be capable of viewing and associating medication reasons with patients' medications, but not be capable of creating medication reasons. Or, all medication reasons within the Medication Tracking System can be associated with medications by each individual user by either selecting existing medication reasons or entering new medication reasons of their own. In this case, the Administrator would allow other users the capability of creating new medication reasons if desired. Medication Tracking can handle either scenario very well. Either way, the Medication Tracking System will build a working repository of all medication reasons for all patient medications within the Medication Tracking System. Within the Medication Reason Repository, the patients whose medications are associated with each medication reason can be seen as well as the number of patients associated with each medication reason. If the Administrator deletes any medication reason, and only the Administrator can delete medication reasons in either case above, not only will the medication reason be deleted, but the patients whom have the medication reason associated with any of their medications will have that particular medication reason dissociated from those medications. So, when the Administrator attempts to delete any particular medication reason, if there are any patients' medications associated with that medication reason, the Administrator will be warned and given the opportunity to go ahead and delete the medication reason or abort. Within the Medication Reason Repository, your organization will easily be capable of identifying the relationships between patients' medications and medication reasons for statistical purposes, especially with the sorting mechanisms in place within the medication reason repository. There potentially could be a lot of statistics your organization can interpret from the Medication Reason Repository, so the repository could prove to be a value asset to your organization on an ongoing basis.
Find & Replace Tool
This is a tool which allows your organization to change any word or phrase within all files in a directory and all files in the subdirectories within a selected directory. This tool was developed as an aid for data conversions into the Medication Tracking System to be used in conjunction with the Import Feature if necessary. Also, since the Medication Tracking Database is a built-in database, this tool is given to take the place of any third party tool users would typically use when making aggregate changes to overall databases. The tool will basically allow an individual to change some word or phrase throughout the entire Medication Tracking Database or the file or files which your organization plans on importing into the Medication Tracking Database during initial data migration. So, your organization can either use it or not use it. This just depends on your organization's importing data requirements. This tool can also be used for many other reasons during the life of the Medication Tracking System. For example, let's say the Administrator discovers there are two different spellings for the same medication, and the Administrator would like to be consistent. The Administrator would then back up the Medication Tracking Database then use the Find & Replace tool to change the spelling they wish to change for the medication all across the Medication Tracking Database. Once completed, the Administrator, among other users if desired, should spot check the Medication Tracking System to make sure all is well, and if so, keep the new copy of the Medication Tracking Database to continue the processing of the Medication Tracking System within your organization. As your organization uses the Medication Tracking System more and more, your organization will most likely find many other purposes for this tool, even possibly outside of the scope of the Medication Tracking System. This tool gives you the same capabilities as other packaged database utilities. This was the driving force for developing and including the Find & Replace Tool. This is a very powerful tool, so make absolutely sure the Medication Tracking Database is first backed up before the tool is run, and make absolutely sure your organization verifies the results before continuing on with them included in the Medication Tracking Database.
We briefly addressed the background jobs within the Medication Tracking Job Scheduler, Medication Tracking (Patient) Database Backups and Search and Set Patients Requiring Action. With these 2 background jobs, there are various schedules your organization can create through the built-in Job Scheduler. As these schedules run, no matter what settings were used, they will correspond with the Medication Tracking Database in the background away from the view of any user within the Medication Tracking System, even the Administrator. The Medication Tracking System and Database have been setup, as we talk about in another discussion topic, to handle database contention management very well. Fortunately, with the use of temporary tables and waiting queues, we were able to manage the processing of these large tasks concurrently with the everyday activities of users processing patients and their associated medications. Along with the Administrator having the capability of manually requesting a backup of the Medication Tracking Database on demand, the Administrator can setup one or multiple schedules to run the Backup in the background of the Medication Tracking System. This means any scheduled Backup will run mutually exclusive of the Medication Tracking System, however; it will impact the Medication Tracking Database at the same time users within the Medication Tracking System are performing their everyday processing. Even though scheduled backups are mutually exclusive of the Medication Tracking System, contention management is still handled with the users of the Medication Tracking System. Also, multiple backups can in theory run at the same time without impacting each other from a processing standpoint, however; the Administrator needs to pay special attention to any performance issues, in regards to the Medication Tracking Database, which may arise based on the frequency of running these scheduled backups. Basically, the rule of thumb is to run backups off hours, if possible, away from any user activity on the system unless there is some sort of maintenance event intruding on this concept, however; in this type of situation, the Administrator could run the manual request backup from within the Medication Tracking System Administrative Tasks instead, which would yield the same results. Another background scheduled job type, which can also be run manually from within the Medication Tracking System Administrative Tasks, is the Search and Set Patients whom require action. This job searches the entire Medication Tracking Database for patients whom have medications which require some sort of attention, and if they have any medications which require attention, they are marked as requiring attention. This particular background job can also be run from multiple schedules and at the same time in theory as well. This job also has the same contention management properties as the Backup of the Medication Tracking Database job type. So, all the same boundaries apply. This job type also runs mutually exclusive from the Medication Tracking System, although it also maintains contention management with all the users of the Medication Tracking System.
Now, the Backup Job type and Search and Set Patients whom require action Job type are administrative jobs, however; there is one final background job type which is specific to individual users, which isn't necessarily the Administrator, that is the scheduled background job type which automatically launches the Medication Tracking System only if there are patients whom require action that have been assigned to the particular individual user, unless the user is the Administrator or Supervisor. If the user is the Administrator, this job would yield all patients within the entire Medication Tracking System whom require action, and if this user is a Supervisor, this job would yield all patients the Supervisor owns whom require action, which could be the sum of patients for multiple users which the Supervisor assigned patients to. So, as you can see, among many other places with the Medication Tracking System, the Medication Tracking System is more than just a simple product tool. The Medication Tracking System is an entire Patient and Medication Business Management System. So, within the Job Scheduler, in terms of Background Processing, there are 3 Job Types, actions, which schedules can be setup for. Two are administrator job types, the Backup of the Medication Tracking Database Job Type and the Search and Set Patients Whom Require Action Job Type, and one job type which any user can setup a background schedule for of automatically launching the Medication Tracking System if there are any patients whom require any action which the particular user, who created the background schedule, has permissions to.
We talked about backups of the Medication Tracking Database from a scheduling standpoint, within the "Custom Built-in Job Scheduler" and “Background Processing” sections. When the Administrator sets up the parameters for backing up the Medication Tracking Database, part of these parameters is to determine when to be warned if the last Backup of the Medication Tracking Database is late based on a warning tolerance time limit set by the Administrator. If the last Backup is on time or late, this will be relayed to the Administrator within the administrative services within the Medication Tracking System. The Administrator has a range of selections for the tolerance time limit to choose from. Not only will the Administrator be informed of whether or not the last Backup ran on time, but also the date, time, and location of the last Backup will be relayed to the Administrator as well. Within the administrative services, the Administrator can also manually request to run a Backup on demand as opposed to setting up a schedule within the Job Scheduler. It doesn’t matter, whether the last Backup was run manually or within a schedule, the date and time as well as the location of the Backup will be shown in the administrative services of the Medication Tracking System. If the Administrator hasn’t setup the appropriate backup parameters yet, the Administrator will be notified and warned. So, there are mechanisms within the Medication Tracking System in place to make sure the Backup of the Medication Tracking Database is taken seriously, especially at least making sure it ran and on time. The tolerance time limit frequencies are based on typical industry wide timeframes for backing up databases in general. As Backups are run, the date and time of the last Backup is portrayed within various locations within the Medication Tracking System where specific areas of data, within the last Backup, have the capability of retrieval, in regards to data recovery. Within the Administrative Services area, the Administrator also has the capability of moving the Medication Tracking Database to another location on the Data Server or moving the entire Medication Tracking Database to another Data Server altogether.
Throughout the Medication Tracking System, color coding is used extensively to identify various statuses and states of data in relation to patient and medication data. As you use the Medication Tracking System more and more, you will become more and more familiar with the color coding associated with various data states. This will in turn help you move much more easily and confidently throughout the Medication Tracking System. In many cases, it’s much easier to interpret something more quickly by its color coding than texted wording. As you move through the various components of the Medication Tracking System by viewing the Integrated Help System or going into the screens themselves, you will see just how easy the system is to follow from the associated color coding and their associated meanings. Not only will this aid throughout the normal processing of the Medication Tracking System, but also with importing data during the Medication Tracking Startup stage as well as exception researching. You will find color coding very handy with all these aspects within the Medication Tracking System.
Either up front or as your organization has been using the Medication Tracking System, your organization may identify functionality which it would benefit greatly from. Please let us know, and we will definitely work with your organization to figure something out because our main goal is to tailor towards our clients' needs as much as possible because we feel our clients are the true knowledgebase of our products when it comes to how the Medication Tracking System should be and how it should evolve. We feel our clients should always set the direction of our products not our company. With our clients leading the way, our company will definitely be going in the correct direction it should be. So, we welcome any and all feedback from our existing clients as well as potential clients. We also realize a certain percentage of our clients require custom development for data conversion requirements. This is always a potential and likely activity when moving to a new system. This was the driving force behind the import utility, however; we realize this may not meet all our potential clients needs, so we will be more than happy to assist your organization if there are any special needs your organization requires.
Client Training and Installation
It’s not only in your organization’s best interest to have a smooth installation of the Medication Tracking System; it’s our best interest as well. This is why we worked especially hard with developing an easy installation process with the Medication Tracking System, Import Feature, and other background processes. We realize a lot of software companies make a lot of money off messy installations, either planned or unexpected. This goes against our company’s mission. We want all our clients as happy as possible throughout their entire Medication Tracking System experience, not just the middle and end. We don’t want our clients to feel a lot of pain in the beginning then reap the benefits. We especially don’t wish to make unjust money off staged and planned work for ourselves. This also goes against all our current staff’s philosophy to the extreme. We are either honest or we go out of business. There is no compromising this principal. Also, we will train whatever personnel your organization wishes, either the current people going to be using the Medication Tracking System immediately or both the immediate users and project users, if desired. Also, our training will be long enough to be sufficient, and we will make sure we’re available always for questions. Just by our Integrated Help System, Help Notifications, and Help Popups alone we hope your organization can see how committed we are to any organization’s success in learning our product. Building the Medication Tracking System alone was a large effort, plus placing the development of the Integrated Help System, Help Notifications, and Popups on top was even more effort, but we really wish all our clients to be successful with our product, not just take the money and run, so to speak. We will also be right by your organization's side as you install the Medication Tracking System. We will make sure everything is setup as it should be yielding the optimal usage of the Medication Tracking System for your organization. Also, we don’t want any of your people getting headaches while trying to setup the Medication Tracking System. We wish your organization’s transition to our system goes as smoothly as possible without any kinks. And, if any unforeseeably arise, we will fight through them with you, however; we have done a lot to prevent any such kinks from happened. Not only have we spent a lot of time developing the entire Medication Tracking System, but we have spent an enormous amount of time making sure the installation process was as simple as possible by loading all prerequisites, setting initial settings correctly and automatically, building the entire database architecture in the background automatically as all users start using the system, installed reference data automatically, built as much network administration functions and commands in the background as well as automatically implemented them, automatically setup working files and directories for each user as they begin to use the system, implemented role level permissions within the system instead of having to set these up prior to users using the system, automatically setup a security model as the Administrator and other users begin using the system, etc. These are just a few of the procedures we incorporated to make sure the installation of the Medication Tracking System goes as smoothly as possible for each client, not matter what size they are or what type of organization they are. All of these types of procedures took a lot of time and knowledge to implement which will make your organization's installation process as easy and smoothly as possible. When the Medication Tracking System is loaded, it brings in everything you need. Your organization doesn’t have to load things one by one by one by one and so on.
Simultaneous Patient Medication Processing
As individual users process patients’ medications, each patient’s medications being processed will be locked out from any other users within the Medication Tracking System until the processing of that patient’s medications has completed, however; as a user is processing any one particular patient’s medications, the session the user is in, with that patient’s medications, will always be up to date real time. Meaning, if any changes within the entire Medication Tracking System that affects that particular patient’s medications occurs, the user will instantly see the changes applied as they occur. Also, any other user attempting to query or change that particular patient’s medications, while being processed by another user, will receive a message indicating that particular patient’s medications is locked revealing the user whom has the patient’s medications currently locked. Permitted users can even patrol which patients’ medications are currently locked and not locked within an overall list of patients they have permissions to along with the total statuses of each patient. In viewing the overall statuses of all the patients the user has permissions to, the user can set the refresh rate frequency, from a range of frequencies, to view the updated status of each of the patients they have permissions to as they occur. All screens within the Medication Tracking System have or don’t have refresh rates, either automatic or manually set, which correspond to projected real world refresh requirements allowing for users to view all data within the Medication Tracking System in a real time fashion.
Each user with permissions to multiple patients’ medications can simultaneously view and make changes to each of those patient’s medications. For example, a user can have 5 sessions open corresponding to 5 patients’ medications at once, so they can easily go back and forth between each patient’s medications as desired. While each of these patients’ medications is an opened session, other users within the Medication Tracking System will be locked out of these patients’ medications until the current user with sessions opened on these patients’ medications has finished, either one by one or all at once. This ensures the data integrity of all the patients’ medication data. As multiple sessions of patients’ medications are open at once and as each of these individual patient’s medications are currently being processed one at a time, the current patient being processed will be up to date real time at all times while the other patient sessions sleep in the background of the user's computer alleviating impact on the user’s computer's CPU. If the user walks away or is doing something else on their computer for an extended time passed the set time out period, all open sessions of the various patients’ medications, including the last patient's medications being processed, will go to sleep with still keeping those patients’ medications locked from other users. Once the user comes out of the time out lock, the patient’s medications which were last being processed will come back into focus first with the others being in the background. The total number of simultaneous sessions of patients’ medications any one user can have open at any one time is set by only the Medication Tracking System Administrator, therefore; the Administrator needs to make sure the optimal amount of allowable patients' medications sessions is identified based on the current configuration of each user’s personal computer’s primary CPU RAM potential. This can be trial and error is most cases. This can also be based on the feedback from the primary users processing patients' medications within the Medication Tracking System. Once this limit is set by the Administrator, it can never be breached by any users other than the Administrator.
The goal of simultaneous patient medication processing sessions is to allow users the fastest and easiest way of processing the patients’ medications they are responsible for without impacting each users computer’s CPU as well as other users sessions of processing their own patients’ medications. All of this processing coincides with our effort to create a Database for the Medication Tracking System which has all the capabilities of other similar relational databases without compromising performance and data integrity, which this model seems to work well for.
Even though this overview seems long, this is just a brief introduction with only some highlights among many functions and features within the Enterprise Edition of Medication Tracking. The entire Enterprise Edition of Medication Tracking is a very large system with many benefits to organizations with various characteristics. Identifying all the functions and features within the Medication Tracking System is difficult to sum up within just the confines of this overview. For more details on the above as well as discussions on other functions and features within the Medication Tracking System, please review the detailed discussions of each of the components within the Medication Tracking System. These are very informative with every screen and surrounding component within the Medication Tracking System. Within the Integrated Help System, these discussions also serve as the official Manual for the Enterprise Edition of Medication Tracking, the Medication Tracking System.
Data Server vs. SQL Server Database or
some other 3rd party database utility
Medical Resource Management designed and created an integrated database to use in the Medication Tracking Product, which we refer to as a Data Server throughout Medication Tracking. So, why did we create our own database architecture as opposed to using some other 3rd party utility for the Medication Tracking System? To totally understand this subject matter, it may take a little software engineering background and experience, however; even without this background, you can still get the gist of what the basic driving reason is behind this decision which is very important to understand for many reasons. Even if you're not a software engineer, it's always a good idea to understand the high level technical architecture you're using for a product of this size because, in the end, this understanding will help you use, understand, and appreciate the product much better.
The type of database Medication Tracking uses is called an XML (eXtensible Markup Language) database. Fortunately, this kind of technology comes with free distribution rights as part of .net technology, which as we claimed before is the technology used to develop Medication Tracking. To give a little comparable background to help understand how an XML database can serve a large enterprise multiple user environment, let's talk a little about VSAM (Virtual Sequential Access Mode) files and DB2 (IBM's comparable relational database to Microsoft's SQL Server database). VSAM files were originally developed to handle large amounts sequential data. DB2 tables are actually stored as linear VSAM files. Now, originally, VSAM files did not support indexes, keys, however; over time, VSAM files were complimented with additional technology to support indexes. Referential Integrity and Concurrency could always be handled within the application code where it is handled at the database level within DB2. XML, in the micro world, is the underlying file system for SQL Server tables, just as VSAM files are the underlying file system for DB2 tables in the mainframe macro world. So, to have a head start in understanding how XML could be used with indexes, XPATH, Referential Integrity, and Concurrency, having a good understanding how to accomplish this same thing with VSAM files goes a long way. If you look on the internet, you will see a lot of software engineers addressing using XML as opposed to SQL Server or some other relational micro database to handle Concurrency, Referential Integrity, and Indexes. It appears like most software engineers claim the only way to incorporate these requirements is with a third party high level database like SQL Server. This is not true. The difference is where each of these objectives, Concurrency, Referential Integrity, and Indexes are handled. With XML, Concurrency, Referential Integrity, and Indexes are developed within the actual programs themselves through the code. With SQL Server, all of these objectives are built into the SQL Server database itself, therefore; performance tuning, optimization, and maintenance are performed within the high level database. This is why an environment which uses a high level database would need someone who is specialized in the high level database with understanding the internal commands, tools, and procedures to accomplish Indexing, Referential Integrity, and Concurrency. To accomplish Indexing, Referential Integrity, and Concurrency using an XML Database, these have to be programmed within the actual code of the application. If these concepts are understood well enough, common routines and classes can make performing these concepts all the more easier, therefore; eliminating the need, for any environment using an XML Database, to retain IT support for these concepts because it is taken care of in the application or product itself by Medical Resource Management. To really get a good handle on developing and rolling out an excellent XML Database to support Indexing, Referential Integrity, and Concurrency, one needs to work intimately with application code and databases of different backgrounds and technologies getting a variety of experience of how these concepts interact between application code and databases.
To give a basic example to emphasize the point above, let's talk about the origin of SQL Server Databases, 1.0 and 2.0, and Visual Basic 3.0 and 3.1, which were near the original integration of SQL Server and Visual Basic. Let's discuss stored procedures. There used to be a big struggle between programmers of application code wanting to place more and more functional, business, code into stored procedures within an SQL Server Database rather than the application code, and Database Administrators pushing programmers to place functional code into the application code and only have the bare minimum SQL Commands with the stored procedures. Putting functional code into stored procedures was perfectly doable, however; the original SQL Server Databases were very limited in their storage capacity as opposed to today. So, if the programmers were putting a lot of their code into stored procedures rather than the application code, the SQL Server Database's storage would be eaten up fast. This would have dramatic impacts on many areas of the SQL Server Database, like lessening the available handles for user connections to the SQL Server Database itself. For example, I believe the literature claimed SQL Server 2.0 could handle 251 potential possible connections at once, however; this number declined dramatically in direct proportion to the amount of available storage. To approach the upper limit of possible connections within the SQL Server Database, the lesser on the SQL Server Database the better. One of our staff led the development effort of an application where initially only 4 to 5 users could concurrently access the SQL Server Database at any one time due to way too much functional code living within the stored procedures in the SQL Server Database. Eventually, what a lot of Database Administrators did to prevent this was to deny programmers permissions to access stored procedures altogether, therefore; only the Database Administrators had authorization to change and migrate stored procedures to the SQL Server Database. So, what typically transpired was configuration change management environments consisted of programmers developing stored procedures, but they could not run them at all. They had to basically just write the stored procedures with text files and give them over to the Database Administrators to run and check for syntax errors and results, run the database plans for performance and optimization, and approve or disapprove the code contained within them, the structure and content. If there were any problems with the stored procedures, they were typically given back to the programmers to fix, and then the programmers would give the stored procedures back to the Database Administrators for retesting and verification and so on. It was very restricted and hard for the programmers to develop stored procedures for SQL Server Databases. Then, programmers embedded SQL Commands within business code, which is another can of worms. Typically, stored procedure only consisted of SQL commands and that's it, no functional, business, code, no functions, no other procedures, etc. But, now stored procedures have all kinds of functional code in them, even specialized functions such as service brokers (messages and queuing), recursive stored procedures, etc. So, the point here is that a lot of things done within the database side can also be done within the application code and vice versa. There are benefits and disadvantages for a lot of these types of scenarios.
So, anyhow, to make a very long story short, to save all our clients the cost of purchasing a third party high level database and having to retain either a resident Database Administrator or purchase an expensive ongoing service contract, we decided to do the work on our side and place the responsibility of handling Indexing, Referential Integrity, and Concurrency within the product. It's by no accident or fault of their own why a lot of software engineers don't really understand or know anything about how this works because, to really just understand that all of this can be handled within application code is possible, it makes itself more obvious in much earlier technology, if you're a software engineer who's have the opportunity to be very proficient on the mainframe and micro technology sides of application programming with having a deep understanding of how application code interfaces with databases in terms of Indexing, Referential Integrity, and Concurrency. Actually, this particular knowledge is fairly rare which we gather from our experience. So, fortunately, we can pass this onto you, our clients, and have you reap the benefits.
Built-in Relational Database
Just to reiterate a little of what we said in the section above, the underlying database architecture is relational, just as Microsoft's SQL Server and IBM's DB2, with referential integrity as well as primary, secondary, and foreign keys. The database is normalized sufficiently and separated logically based on the product's functional requirements giving way to optimal performance. With having a built-in database architecture, there is no compromise in performance at all. Since we have decades of experience with, not only databases from an applications standpoint, but also a technical standpoint, we have the experience to design and build a fully integrated relational database with our product where your organization gets the best of all worlds. Your organization doesn't have to buy a third party database package and the database has high performance, easy access, is self optimizing, has a combination of self maintaining and user maintainability, is only limited to the storage constraints of the machine it is placed on, doesn't have to contend with a lot of overhead, has built-in pessimistic and soft locking mechanisms, has built-in contention handling, timeout management, etc. Actually, within the software engineering arena, a database of this nature is fairly rare because developing it takes decades of practical experience with various databases along with a formal education in a variety of functional databases. The best way to look at the development of our database is to compare VSAM files to IBM's DB2 Database and XML files to Microsoft's SQL Server Database. The underlying file system for IBM's DB2 Database is VSAM files, Virtual Sequential Access Mode Files. The underlying file system to Microsoft's SQL Server Database is XML files, eXtensible Markup Language Files. Basically, each of the two types of databases has their file systems as the bottom layer with the database package as a layer on top of the file system. What we have done with the Medication Tracking (Patient) Database is use XML files, as Microsoft's SQL Server Database, and created our own layer on top of that. We have also incorporated WOL, Wake On Lan with WIFI to communicate with a remote database, Data Server. In doing this, we have managed to contain the entire database architecture within the product itself. As your organization begins to use the Medication Tracking System, the database architecture begins to unfold and start being built. With this approach, along with the functionality of the product, we have managed to self maintain most of the database with the users maintaining the rest through functions and features within the product. This is a very simplistic way of explaining what we have done, but it's fairly accurate as well. Our goal was to create a product which could be used by organizations of many different flavors, which would be organizations with their own internal technical support personnel to organizations without any technical support personnel at all. We have witnessed many times where companies have passed on excellent opportunities simply due to the lack of technical support. With the way technology has migrated today, we knew we could overcome this hurdle with some effort, which was challenging to a certain degree but well worth it now that's it's been completed. So, now your organization can benefit from this effort, and if your organization is small, it doesn't have to weigh opportunities against technical support any longer, not to mention price for surrounding technical software. Typically, the larger organizations can take advantage of the opportunities because they have the internal technical support in terms of personnel and supporting software, but with Medication Tracking, your organization doesn't need to weigh this any longer.
Built-in Network Engineer
Now, to take the Enterprise Edition of Medication Tracking one step further to help your organization, we have built in many network engineering functions and features to alleviate your organization from supporting these areas by securing a resident network engineer or purchasing an expensive service contract to support network engineering activities. Due to the based class library within the .net framework, active directories, domain stores, and machine stores, we were able to incorporate within the product most, and in many cases, all of the network engineering functions and features you will most likely ever need to support the Enterprise Edition of Medication Tracking. The actual Network Engineering features, functions, and commands are built in the background of the Enterprise Edition of Medication Tracking. Some of these include creating and changing user accounts, managing user account passwords in terms of expiring, recovery, notifications, locking users out of the Data Server after so many bad attempts, managing the security of the Medication Tracking Database in terms of creating and renaming security groups, assigning user accounts to security groups with various privileges, transferring total administration privileges between users, managing security groups privileges, enabling and disabling users, viewing user account history and tracking, having the Medication Tracking System Administrator explicitly notified of intruders into the Patient Database, allowing the Administrator to easily prevent users from accessing the Medication Tracking System, Patient Database, and/or Data Server altogether, etc. These activities typically need to be performed by an experienced Network Engineer or sometimes Pseudo Internal IT Support Personnel whom work with vendors to perform these activities at a price.
Medication Tracking - A Frontier of Technology
If you take together both the advantages of using an XML Database and incorporating Network Engineering functions and features within the Enterprise Edition of Medication Tracking as well as many other functions and features throughout the Enterprise Edition of Medication Tracking (i.e. Job Scheduling, Find & Replace Tool, Re-Connect to Database utility, Custom Notifications, Professional Electronic Email Transmissions (EET), Administrator functions and features, Integrated Help System, Background Jobs, Importing data of various file types and formats, automatic product updating and notification, remote and WIFI Data Server connecting, etc.), the Enterprise Edition of Medication Tracking implements many functions, features, tools, functionality, etc. which paves the way for many other applications other than Medication Tracking and even expansion and the evolution of the Enterprise Edition of Medication Tracking along with other products Medical Resource Management may develop in the fairly near future. So, if your organization looks at the Enterprise Edition of Medication Tracking in terms of this approach, it is a great investment, not only for your organization's needs now, but for its long term needs and objectives as a whole. With all of these components already implemented in your environment as well as your organization's exposure to these components, this will make it fairly easy to incorporate these components within many other areas within your organization's business processes, procedures, and policies. So, the Enterprise Edition of Medication Tracking is sort of a stepping stone of technology and a frontier of benefit to other areas within your organization.