Abstract
A written directive is required by the U.S. Nuclear Regulatory Commission for any use of 131I above 1.11 MBq (30 μCi) and for patients receiving radiopharmaceutical therapy. This requirement has also been adopted and must be enforced by the agreement states. As the introduction of new radiopharmaceuticals increases therapeutic options in nuclear medicine, time spent on regulatory paperwork also increases. The pressure of managing these time-consuming regulatory requirements may heighten the potential for inaccurate or incomplete directive data and subsequent regulatory violations. To improve on the paper-trail method of directive management, we created a software tool using a Health Insurance Portability and Accountability Act (HIPAA)–compliant database. This software allows for secure data-sharing among physicians, technologists, and managers while saving time, reducing errors, and eliminating the possibility of loss and duplication. Methods: The software tool was developed using Visual Basic, which is part of the Visual Studio development environment for the Windows platform. Patient data are deposited in an Access database on a local HIPAA-compliant secure server or hard disk. Once a working version had been developed, it was installed at our institution and used to manage directives. Updates and modifications of the software were released regularly until no more significant problems were found with its operation. Results: The software has been used at our institution for over 2 y and has reliably kept track of all directives. All physicians and technologists use the software daily and find it superior to paper directives. They can retrieve active directives at any stage of completion, as well as completed directives. Conclusion: We have developed a software solution for the management of written directives that streamlines and structures the departmental workflow. This solution saves time, centralizes the information for all staff to share, and decreases confusion about the creation, completion, filing, and retrieval of directives.
Those who regularly practice nuclear medicine are usually quite familiar with regulatory compliance. One requirement for such compliance is the creation and maintenance of a written directive every time a patient needs to receive nuclear medicine therapy. The introduction of a requirement for such directives can be traced back to a quality assurance rule proposed by the U.S. Nuclear Regulatory Commission in 1987 that would affect ordering, prescribing, administering, and keeping records on radiopharmaceuticals (1). The Society of Nuclear Medicine and Molecular Imaging (SNMMI) and the American College of Nuclear Physicians (ACNP) were not initially included in that rule-making process (2). Public statements from the nuclear medicine community and comments from SNMMI and ACNP explained that these regulations would have an adverse impact on patient care, limit patient-care flexibility, significantly increase paperwork, and place users at undue risk of regulatory violations for little if any benefit. Subsequently, the quality assurance rule was reissued in the 1990 Code of Federal Regulations (CFR), which detailed the requirements of the directive (3). Despite attempts by SNMMI and ACNP to void the quality assurance rule, and despite disapproval of the rule by the U.S. Office of Management and Budget (which sided with the physician professional communities), the U.S. Nuclear Regulatory Commission rule stood (4). Today, the scope and requirements for these directives can be found in title 10 of the CFR, part 35, sections 40 and 41, and the record-keeping requirements are in part 35, sections 2040 and 2041 (5). Agreement states are also required to implement and enforce these regulations.
In the more than two decades since the rule was made, the types of therapy and number of treatments in nuclear medicine have increased significantly. We have seen the introduction of 89Sr, 157Sm, 131I-tositumomab, 90Y-ibritumomab tiuxetan, 90Y-microspheres, and 223Ra. New therapeutic options with radiopharmaceuticals are being developed and are in clinical trials. Each of these therapies requires a directive, and thus the burden of paperwork on providers and institutions will continue to increase, as was predicted by the physician professional communities.
The established mechanisms and policies for written directives generally rely on a paper trail. Although an authorized physician user is the person who originates a directive, the subsequent steps of scheduling the therapy, ordering and receiving the radiopharmaceutical, confirming the identity and pregnancy status of the patient, and ultimately administering the therapy may all be performed at various times by various individuals. In a busy department, paper may be misplaced or duplicated, resulting in inefficient use of staff time. Further, if the directive is handwritten, doses may be misread, leading to improper patient care. Failure to comply with the policies may result in regulatory violations. With these needs in mind, the staff at our institution developed dedicated software (Written Directive Manager; www.thewrittendirective.com) to manage these directives and has used it for the past 2 y. This software—by providing a networkable solution with a secure, centrally located database that is compliant with the Health Insurance Portability and Accountability Act (HIPAA)—standardizes workflow, encourages orderly completion, prevents duplication, and serves as a permanent repository of directive information that can be quickly and easily accessed at the request of a regulator.
MATERIALS AND METHODS
This project did not change patient care in any fashion; therefore, no institutional review board approval was required.
The regulations in 10 CFR 35.40 call for a directive signed and dated by an authorized user before administration of any amount of 131I-sodium iodine greater than 1.11 MBq (30 μCi) or any therapeutic dose of unsealed byproduct material. The regulations also state that the directive must contain the patient’s name, the dose and chemical form of the radioactive drug, and the route of administration. The following section, 10 CFR 35.41, states that written procedures must be in place to ensure that the patient’s identity is verified and that the administration is in accordance with the treatment plan. Later, 10 CFR 35.2040 states that a copy of the directive must be retained by the licensee for 3 y, and 10 CFR 35.2041 states that the written procedures required by 10 CFR 35.41 must be kept in place for the duration of the license. Most institutions fulfill these requirements through the use of paper-based records.
Any software solution to address these requirements must have the flexibility to accommodate a variety of practice patterns, maintain data security, provide access to multiple users, track any interaction with the database, and ultimately maintain all the information required for patient care while ensuring regulatory compliance. Such a solution should also provide a structured workflow, prevent duplication of effort, and allow users to quickly see the status and content of any directive. In addition, some regulators require that a physical copy of the directive be signed, dated, and scanned into the permanent patient record.
A working model of our software (version 1.0) was initially authored in 2008 using the Visual Basic development environment (version 6; Microsoft). The resulting software was then integrated with an Access database (Microsoft). Visual Basic is a rapid application-development tool that promotes prototyping, a visual design, and reuse of components. The original software functioned well for several years, but when updates were made to the Windows (Microsoft) operating systems, the software also required a significant update to accommodate the newer platforms.
Visual Basic was again the chosen development tool, but this time version 2010 was used. Newer versions of Access (introduced as part of Office 2012 [Microsoft]) had both 32-bit and 64-bit platforms available. This posed a problem for development, since software written for one platform could not work in the other. On this basis, we decided to continue using an older version of Access (2007) that was agnostic to the environment and for which the support files and development tools were still available. Although this choice required installation of additional support files when the software was installed, it added the flexibility of allowing use of different platforms (Windows 7, Windows 8, and Windows 10) installed in either 32- or 64-bit environments. Incorporation of these older run-time files also obviated the purchase of a copy of Access or Office for each computer that might use the software.
Although the software was designed as a stand-alone solution, we integrated it with our radiology information system (Centricity RIS-IC) to draw demographic information about the patient using the medical record number. Integration, however, is only an option, and the software also works well in a stand-alone environment.
All possible steps have been implemented to maintain the security and integrity of the HIPAA data. First, the Access database cannot be opened without an encrypted password that prevents unauthorized use. Because the password is hard-coded into the software, the software must interact with the database. Encryption prevents users from tampering with the database content or structure. Second, the database is placed on a shared network drive. The log-in credentials to access this drive are given to only a few users. Third, the shared path to the database can be hidden in such a way that a user must have explicit knowledge of the path at the time of software installation to allow it to function. In this way, the general population with network access cannot even see the shared path when browsing the network. Finally, the drive that houses the database is automatically backed up daily. Should the database become corrupted or accidentally deleted, the back-up can be used to restore the data to a recent version.
RESULTS
For ease of use, the software has an intuitive interface with a tabbed-notebook design. Each tab becomes viewable as each stage of the directive is completed. Like flipping through pages in a notebook, the user can readily enter and access information.
“Create Directive” Tab
Password protection ensures that only an authorized user creates or modifies a directive. The user is first prompted for the medical record number (Fig. 1; patient names, dates, ages, and medical record numbers in the figures are fictional). Then, if the software is configured for integration with Centricity RIS-IC, the name, age, and sex of the patient are automatically displayed. Otherwise, the user is prompted for this information. Patient demographic information needs to be entered only once. Future directives for that patient retrieve the demographics from the medical record number alone.
“Create Directive” tab, with patient demographic information at upper right and content of directive on left. The illustrated workflow displays active directives at all stages, which can be changed to accommodate user- and filter-specific activities.
To simplify creation of the directive and minimize typing, there are customizable drop-down lists to select the type of therapy (radionuclide, chemical form, and [optionally] default dose), the referring physician, the diagnosis, and whether inpatient or outpatient therapy is planned. There is also a place for notes about the patient. The drop-down lists can be customized for each database, and if a choice is not available the information can be entered manually.
“Schedule” Tab
Any user can schedule a directive. The scheduling tab displays 4 mo of dates (Fig. 2). Standard holidays and other dates can be added as needed, to avoid scheduling a procedure on a conflicting date. A list of each currently scheduled therapy, by type, is also presented, with its date and inpatient/outpatient status. An optional scheduling wizard additionally shows prior directives for a patient, all therapies scheduled for any selected date, and all upcoming therapies, which can be filtered by type.
“Schedule” tab, displaying upcoming holidays and upcoming therapies. A schedule wizard provides even more data on prior therapies for a patient and can filter upcoming therapies by type.
“Order/Receive Radiopharmaceutical” Tab
Any user can complete the ordering and receiving sections of the directive (Fig. 3). The person ordering the radiopharmaceutical needs to confirm the patient identification number, the radionuclide, the chemical form, and the prescribed dose. The person receiving the radiopharmaceutical is prompted for the receipt date, the dose at the time of delivery, and the lot number.
“Order/Receive Radiopharmaceutical” tab, displaying prescribed radionuclide, chemical form, and dose. Patient demographic information remains constant at upper right when patient’s name is chosen from list at lower right.
“Verify Patient Data” Tab
Any user can verify the patient data. The tab includes two patient-identity verification drop-down lists, along with a prompt for whether a pregnancy test was required (Fig. 4). If “yes” is chosen, drop-down lists prompt for the type of pregnancy test, the date it was performed, and the result. If “no” is chosen, the reason must be indicated. A drop-down list of common reasons is provided (e.g., postmenopausal status, tubal ligation, and hysterectomy), or the reason can be entered manually
“Verify Patient Data” tab, with drop-down lists to facilitate use of two patient identifiers. If other identifiers are not listed, they can be manually entered. For female patients, question about pregnancy testing requires either confirmation of negative result or reason why testing is not required.
“Complete Directive” Tab
As with creation of the directive, completion is restricted to authorized users and is password-protected. The completion tab draws from the previous tabs the radionuclide, chemical form, received dose, and initially prescribed dose and prompts the user for the actual dose dispensed (Fig. 5). This tab also displays the difference between the prescribed dose and the dispensed dose as both activity and percentage. A difference of more than 10% triggers a mandatory text-entry box, where the user explains the reason for the modification. This box can also be opened manually if the user wants to document any additional information about the therapy. Checkboxes confirm that the user has personally evaluated the patient’s living and working conditions, given written radiation safety instructions to the patient, and—to estimate the radiation exposure of the patient’s family—reviewed whether the patient received any other radiation therapy within the last year. The user then indicates the disposition of the patient (i.e., whether the patient may be treated as an inpatient or an outpatient) and records the date the therapy is performed. Finally, the name of the authorized user is given.
“Complete Directive” tab verifies whether actual dose is within 10% of prescribed dose. If not, space is presented for user to explain the dose modification. Radiation safety questions and final disposition of patient are required before authorized user can complete the directive. Once completed, directive is removed from active list but can always be selected later for review or printing using a different workflow.
Additional Features
The software includes several additional conveniences, such as the ability to print a directive at any stage of completion for regulators or for scanning into another system. In addition, the active patient list is alphabetical and can be filtered by stage of completion. This feature is convenient for a scheduler who wants a list of only patients whose therapy needs to be scheduled, a technologist who wants only patients whose dose needs to be ordered, a physician who wants all patients with active directives, or a radiation safety officer who wants only patients with completed directives. Finally, the software includes a repository, shared by all users, for commonly used documents such as consent forms, physician consultation worksheets, and radiation safety information for patients.
HIPAA Security
Encryption of the database, restriction of access to it on the network, and regular backing up of data ensure the integrity of the information. If the database is not used for 5 minutes, the software is designed to close whatever work was not saved and exit. All interactions with the database are logged, are searchable by date, and include the medical record number of the patient whose information was accessed, the user identification number, and the action the user performed.
Multiple-Database Capability
When more than one institution shares a network, multiple databases can be created to organize the directives. A database for institution A can be tailored to procedures and referring physicians common to that location, whereas a second tailored database can be created for institution B. For research using investigational radiopharmaceuticals, it is even possible to create a third database to separate research patients from clinical patients. There is no limit to the number of databases that can be created on the network. Each is easily accessible from the main screen via a drop-down list in the upper right corner.
DISCUSSION
Current Use
To date at our institution, more than 562 directives have been created using this software, and our database has been accessed over 4,100 times. Initial development of version 2 of the software started in February 2014, and a working model became operational in April 2014. The software was subsequently installed in all physician offices, the reading room, the reception desk, the manager’s office, and the hot lab. The radiation safety officer also could access the software to prepare for upcoming therapies. Over the following year, problems with operation were identified and corrected, and features were added. Minor updates are still made as needed. When these are available, a user who starts the program is notified and given the option to run the update.
Before this digital solution was implemented, our directives were on paper and kept in a binder. Since implementation, we have eliminated duplication, improved clarity and communication, and centralized storage of this regulatory information. We have been able to identify directives that remained unscheduled and check whether the referring physician still wished the therapy administered. Any unused directives are easily deleted from the active list yet remain available for future reference.
Unfortunately, workflow metrics were not determined before implementation. However, it is the general consensus of our staff that the enforced structure has saved time and improved the overall efficiency and completion of the directives.
Limitations and Future Directions
Software is always a work in progress. Although our software has a full set of features that have already streamlined the workflow at our institution, we have identified some additions needed in future upgrades. Perhaps the most important of these is record locking. If two individuals access a directive simultaneously, they are not notified that someone else is looking at or modifying it. This issue carries the potential that one user may overwrite information entered by another user. To our knowledge, this has not yet happened for us, since any one record is only infrequently accessed. It is unclear whether this feature can be included in an upgrade or will require changes so extensive that a new version will be needed.
The performance of an Access database is related to its size. At more than 500 directives and a log of over 12,500 interactions, we have not yet seen a decline in performance. We intend to create a version that will allow the use of either an Access database or a dedicated Structured Query Language server. Since performance remains brisk at this time, no purging or off-loading of old data from the database is planned.
We are exploring alternative methods of securing access and integrating passwords with authentication systems such as the Lightweight Directory Access Protocol. Many institutions desire centralization of security and access, but the software must achieve a balance between larger institutions with significant infrastructure and information technology support and smaller institutions with limited or no support that might wish to implement the software in a stand-alone environment.
Some newer therapies (e.g., 223Ra) may require multiple administrations on a schedule, requiring creation and management of multiple directives. Although the software can already create multiple directives for the same patient at one time, we are planning to integrate a tool to coordinate a single therapy that requires multiple administrations.
Retrieval of patient demographic information from an institution’s existing radiology information system or electronic medical record is convenient for users. However, although such integration is desirable, it may present a maintenance problem for our software since aspects of systems designed by external vendors may change over time and are beyond our control. We will be exploring connectivity with other demographic sources of information.
For research purposes, it may be worthwhile for our software to be able to extract patient-therapy data to allow an organization to form a multiinstitution registry. The data could be anonymized to remain HIPAA-secure while still providing the registry with key elements such as type, frequency, and dose of therapy. If such an enhancement is provided, it would need to be manually triggered by the user. Local institutional review boards may also need to be involved with such transmission to a registry.
Finally, we may consider adding a module to assist with appropriate use criteria. A worksheet or wizard would help physicians collect all the patient information required to follow a decision pathway to treatment. This information could also be submitted to insurance companies in a simple, organized format to document need and appropriate use. Information of this sort not only would support the need for therapy but also might justify the need to hospitalize certain patients.
A fully functional version of the software and information about its capabilities is available free of charge at http://thewrittendirective.com. Development of new features will depend on acceptance, support, and feedback from the nuclear medicine community.
CONCLUSION
The written directive is an integral part of regulatory management by all involved in therapeutic nuclear medicine. As the types of therapy and number of treatments in nuclear medicine increase, time spent on the paperwork required to maintain regulatory compliance also increases. The inherent difficulty of managing directives on paper can be avoided through our software solution to management. This software has become an integral part of the workflow at our institution and fulfills all the requirements of the U.S. Nuclear Regulatory Commission and the State of Illinois (an agreement state). Further, the software promotes organization, saves time, increases the availability of information, and decreases confusion. We already plan several enhancements to the software, and we encourage the nuclear medicine community to suggest additional features and modifications for future releases.
DISCLOSURE
No potential conflict of interest relevant to this article was reported.
Acknowledgments
The Written Directive Manager software was copyrighted in 2015 by Robert H. Wagner, MD, and is distributed under his business name, MedAssist Software. We thank Robert Henkin, MD, for his assistance and suggestions on the design and function of the original version of software, on which the current version (2.0) is based.
Footnotes
Published online Mar. 9, 2017.
- Received for publication September 22, 2016.
- Accepted for publication February 3, 2017.
Jump to section
Related Articles
Cited By...
- No citing articles found.