Search PubMed⌕ Search

SEARCH · Search PubMed

Results for “software”

Search indexed PubMed citations on genomics, clinical trials, systematic reviews and public health. Explore titles, authors and supplied subject terms, then open the PubMed record.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 73 records · Page 4Linked to original sources
PubMed1998

Use of project ontologies and terminology servers to support software engineering.

Complex medical software imposes new requirements on the methods and tools used for maintenance. Appropriate maintenance tools can increase software reliability and quality by providing means to trace dependencies among software artifacts for reducing unexpected impacts in software caused by software changes. We have used the GRAIL concept-representation language for medical terminologies to build a project ontology that models relationships among software artifacts. Our approach involves modeling of the terminology used in software projects, which enables us to describe, classify and relate individual software artifacts. A networked repository accessible to the entire software development staff stores the conceptual model, source code and associated documents. We present an architecture for a maintenance tool, and show how developers can use GRAIL to build a project ontology.

Databases as Topic↗
PubMed2000

Gamma knife radiosurgery as a primary treatment for prolactinomas.

OBJECT: The purpose of this study was to estimate the efficacy of gamma knife radiosurgery (GKS) in controlling tumor growth and endocrinopathy associated with prolactinomas. METHODS: Between 1993 and 1997, 164 of 469 patients with pituitary adenomas treated by GKS harbored prolactinomas. The dose to the tumor margin ranged from 9 to 35 Gy (mean 31.2 Gy), and the visual pathways were exposed to a dose of less than 10 Gy. The mean tumor diameter was 13.4 mm. The mean follow-up time for 128 cases was 33.2 months (range 6-72 months). Tumor control was observed in all but two patients who underwent surgery 18 and 36 months, respectively, after GKS. Clinical cure was achieved in 67 cases. Clinical improvement was noted with a decrease in the hyperprolactinemia after GKS. Nonetheless, in 31 (29%) of 108 patients who were followed for more than 2 years no improvement in serum prolactin levels was demonstrated, although this could be normalized by bromocriptine administration after treatment. Nine infertile women became pregnant 2 to 13 months after GKS and all gave birth to normal children. There was no visual deterioration related to GKS. Five women experienced premature menopause. In these patients there was subtotal disappearance of the tumor and an empty sella developed. CONCLUSIONS: Gamma knife radiosurgery as a primary treatment for prolactinomas can be safe and effective both for controlling tumor growth and for normalization of prolactin hypersecretion. A higher margin dose (> or = 30 Gy) seemed to be associated with a better clinical outcome. Gamma knife radiosurgery may make prolactinomas more sensitive to the bromocriptine.

Humans↗
PubMed1995

Software safety in medical applications.

The use of software in safety-critical medical applications permits sophisticated functionality that would otherwise not be achievable. However, it is very difficult to ensure that software in these systems is dependable. In particular all software development techniques have limitations, and none can provide any guarantee of overall software dependability. Given this shortcoming, the approach that we have taken is to develop techniques that emphasize the verification of properties that are important to overall software dependability. In this paper we describe two techniques that support the implementation and verification of dependable software for an experimental neurosurgical device and safety-critical applications in general. The first technique involves the assurance of critical safety properties by a relatively simple software component known as a safety kernel. Situated between the application software and the application devices, the safety kernel enforces rules that govern the safe operation of the devices. The simplicity of the safety kernel facilitates its implementation and verification. In most cases, it is not possible to rely on testing to provide the necessary verification of the software in a safety-critical application. However, testing can play an appropriate and vital role in the demonstration of safety properties. The second technique takes this approach, utilizing automated testing and selected test cases to demonstrate useful system properties.

Neurosurgery↗
PubMed1998

Availability of software services for a hospital information system.

Hospital information systems (HISs) are becoming more important and covering more parts in daily hospital operations as order-entry systems become popular and electronic charts are introduced. Thus, HISs today need to be able to provide necessary services for hospital operations for a 24-h day, 365 days a year. The provision of services discussed here does not simply mean the availability of computers, in which all that matters is that the computer is functioning. It means the provision of necessary information for hospital operations by the computer software, and we will call it the availability of software services. HISs these days are mostly client-server systems. To increase availability of software services in these systems, it is not enough to just use system structures that are highly reliable in existing host-centred systems. Four main components which support availability of software services are network systems, client computers, server computers, and application software. In this paper, we suggest how to structure these four components to provide the minimum requested software services even if a part of the system stops to function. The network system should be double-protected in stratus using Asynchronous Transfer Mode (ATM) as its base network. Client computers should be fat clients with as much application logic as possible, and reference information which do not require frequent updates (master files, for example) should be replicated in clients. It would be best if all server computers could be double-protected. However, if that is physically impossible, one database file should be made accessible by several server computers. Still, at least the basic patients' information and the latest clinical records should be double-protected physically. Application software should be tested carefully before introduction. Different versions of the application software should always be kept and managed in case the new version has problems. If a hospital information system is designed and developed with these points in mind, it's availability of software services should increase greatly.

Computer Communication Networks↗
PubMed1998

Writing software for the clinic.

Medical physicists often write computer programs to support scientific, educational, and clinical endeavors. Errors in scientific and educational software can waste time and effort by producing meaningless results, but errors in clinical software can contribute to patient injuries. Although the ultimate goal of error-free software is impossible to achieve except in very small programs, there are many good design, implementation, and testing practices that can be used by small development groups to significantly reduce errors, improve quality, and reduce maintenance. The software development process should include four basic steps: specifications, design, implementation, and testing. A specifications document defining what the software is intended to do is valuable for clearly delimiting the scope of the project and providing a benchmark for evaluating the final product. Keep the software design simple and straightforward. Document assumptions, and check them. Emphasize maintainability, portability, and reliability rather than speed. Use layers to isolate the application from hardware and the operating system. Plan for upgrades. Expect the software to be used in unplanned ways. Whenever possible, be generous with RAM and disk storage; hardware is cheaper than development and maintenance. During implementation, use well-known algorithms whenever possible. Use prototypes to try out ideas. Use generic modules, version numbering, unique file names, defensive programming, and operating system and language/compiler defaults. Avoid binary data files and clever tricks. Remember that real numbers are not exact in a computer. Get it right before making it faster. Document the software extensively. Test continuously during development; the later a problem is found, the more it costs to fix. Use a written procedure to test the final product exactly as a typical user would run it. Allow no changes after clinical release. Expect to spend at least an additional 50% of the initial development effort on testing, fixing errors, and getting the software into routine operation.

Documentation↗
PubMedDate not supplied

Evaluating software for the clinical laboratory.

A set of guidelines to assist in structuring the software-evaluation process is presented. In recent years, laboratory professionals have increasingly assumed responsibility for the evaluation of software to be used in the laboratory for patient testing or administrative functions. This is a positive trend that brings user expertise to the selection of computer software but one that mandates the development of appropriate software evaluation procedures on the part of laboratory personnel. Software should be chosen that best conforms to the needs of the laboratory. Proper evaluation of available software is critical. Documentation should be reviewed, the software should be tested, capabilities must be compared with accrediting or licensing bodies' standards, and vendor support should be assessed. Development of a well-defined procedure for software evaluation will ensure selection of software that solves, not creates, problems.

Accreditation↗
PubMed1995

Médicarte software developed for the Quebec microprocessor health card project.

The Quebec Patient Smart Card Project is a Provincial Government initiative under the responsibility of the Rgie de l'assurance-maladie du Québec (Quebec Health Insurance Board). Development, implementation, and assessment duties were assigned to a team from Université Laval, which in turn joined a group from the Direction de la santé publique du Bas-St-Laurent in Rimouski, where the experiment is taking place. The pilot project seeks to evaluate the use and acceptance of a microprocessor card as a way to improve the exchange of clinical information between card users and various health professionals. The card can be best described as a résumé containing information pertinent to an individual's health history. It is not a complete medical file; rather, it is a summary to be used as a starting point for a discussion between health professionals and patients. The target population is composed of persons 60 years and over, pregnant women, infants under 18 months, and the residents of a small town located in the target area, St-Fabien, regardless of age. The health professionals involved are general practitioners, specialists, pharmacists, nurses, and ambulance personnel. Participation in the project is on a voluntary basis. Each health care provider participating in the project has a personal identification number (PIN) and must use both an access card and a user card to access information. This prevents unauthorized access to a patient's card and allows the staff to sign and date information entered onto the patient card. To test the microprocessor card, we developed software based on a problem-oriented approach integrating diagnosis, investigations, treatments, and referrals. This software is not an expert system that constrains the clinician to a particular decisional algorithm. Instead, the software supports the physician in decision making. The software was developed with a graphical interface (Windows 3.1) to maximize its user friendliness. A version of the software was developed for each of the four groups of health care providers involved. In addition we designed an application to interface with existing pharmaceutical software. For practical reasons and to make it possible to differentiate between the different access profiles, the information stored on the card is divided in several blocks: Identification, Emergency, History (personal and family), Screening Tests, Vaccinations, Drug Profile, General follow-up, and some Specific follow-ups (Pregnancy, Ophthalmology, Kidney failure, Cardiology, Pediatrics, Diabetes, Pneumology, Specific parameters). Over 14,000 diagnoses and symptoms are classified with four levels of precision, the codification being based on the ICPC (International Classification for Primary Care). The software contains different applications to assist the clinician in decision making. A "Drug Advisor" helps the prescriber by detecting possible interactions between drugs, giving indications (doses) and contraindications, cautions, potential side-effects and therapeutic alternatives. There is also a prevention module providing recommendations for vaccination and periodic examinations based on the patient's age and sex. The pharmaceutical, vaccination, and screening tests data banks are updated every six months. These sections of the software are accessible to access card holders at any times, even without a patient card, and constitute in themselves an interesting clinical tool. We developed a software server (SCAM) allowing the different applications to access the data in a memory card regardless of the type of memory card used. Using a single high level command language, this server provides a standardized utilization of memory cards from various manufacturers. It ensures the compatibility of the applications using the card as a storage medium. (abstract truncated)

Aged↗
PubMed1998

[Major statistical software usable in epidemiology].

Quality assurance of biostatistical data analysis is becoming mandatory. The aim of this review of statistical software was to guide uses who are faced with the increasing number of these tools. A list of softwares was obtained from statisticians and computer scientists, computerized databases, computer science lay press, and commercial documents. The softwares were described and their possibilities measured. The following functions were studied: functions considered as essential (descriptive analysis, Student's t, Mann-Whitney or Wilcoxon, ANOVA, Kruskall-Wallis, Pearson's chi 2, Fisher's exact test, Pearson's r), survival and multivariate analysis (logistic regression, proportional hazards modelling, times series). User-friendliness and quality of graphs were also studied. Among the 220 listed softwares, 26 could be considered as general softwares and were extensively analyzed. Statistical softwares may be classified into four categories: easy-to-use general public softwares with limited functions, such as EPI INFO; simple reference softwares with satisfactory user-friendliness and performing most of the statistical analyses, such as PCSM, STATISTICA or STATA; complex reference softwares intended for statisticians (EPILOG PLUS, SAS); specific cases such as EGRET performing only multivariate analysis or SUPERANOVA performing only analysis of variance. Such a review should be regularly updated.

Analysis of Variance↗
PubMed2007

Influence of 4- and 6-color flow cytometers and acquisition/analysis softwares on the determination of lymphocyte subsets in HIV infection.

BACKGROUND AND OBJECTIVES: Lymphocyte immunophenotyping provides valuable information for the diagnosis and monitoring of patients with cellular immunodeficiencies, such as HIV/AIDS. In this study, we have assessed the influence of 4-color and 6-color flow cytometers, and respective analytical softwares on the enumeration of lymphocytes in HIV infected individuals. METHODS: The expression of various cell surface markers on lymphocytes was measured from the EDTA blood of 66 HIV infected patients on the FACSCalibur (4-color) and FACSCanto (6-color) flow cytometers. Percentage of lymphocytes expressing a particular cell surface marker was analyzed on FACSCalibur using the Cell Quest Pro software (v 5.2), while the analysis on FACSCanto was done using FACSCanto (v 1.0.3) and FACSDiva (v 4.1) softwares respectively. RESULTS: The data shows significantly higher mean CD3 T-cell counts on FACSCalibur, Cell Quest Pro (1,864 +/- 1,044 cells/microl) as compared to FACSCanto (1,840 +/- 1,040 cells/microl) (P < 0.05). The CD4 T-cell counts were also higher on FACSCalibur, Cell Quest Pro (885 +/- 770 cells/microl), and FACSDiva (892 +/- 773 cells/microl) versus FACSCanto (867 +/- 767 cells/microl) (P < 0.05). FACSCalibur, Cell Quest Pro, and FACSDiva showed similar values except for CD8 T-lymphocytes where FACSDiva had significantly lower values (P < 0.05). The B-cell counts were unaffected when either of the instruments or softwares were used, while the natural killer (NK) cells (CD16 + 56 positive cells) showed similar trend like CD3 and CD4 counts with significant differences in the mean cell counts between FACSCalibur, Cell Quest Pro (240 +/- 165 cells/microl), and FACSDiva (238 +/- 163 cells/microl) versus FACSCanto with higher NK cell counts (260 +/- 176 cells/microl). CONCLUSIONS: The enumeration of lymphocyte subsets was comparable between FACSCalibur, Cell Quest Pro, and FACSDiva, based analysis and it was significantly different than FACSCanto software based analysis. Our observations suggest that FACSDiva software should be preferred over the FACSCanto software for immunophenotyping on FACSCanto flow cytometer and the laboratories should report the instrument and software used for the specimen analysis while reporting immunophenotyping results.

Antigens, Surface↗
PubMed2002

Software compensation improves the analysis of heterogeneous tumor samples stained for multiparameter DNA flow cytometry.

BACKGROUND: High concentrations of propidium iodide (PI), in combination with fluorescein isothiocyanate (FITC) and R-phycoerythrin (RPE) used for multiparameter DNA flow cytometry (FCM), cause spectral cross-talk into the green fluorescence channel (FL1). We have evaluated the use of post-acquisition software compensation (N-Color Compensation) in order to correct this spectral cross-talk caused by PI. METHOD: Cell mixtures were prepared consisting of keratin 8/18 FITC labeled, keratin 8/18 RPE labeled, and unlabeled MCF-7 breast carcinoma cells. DNA was stained with PI (100 microM). Post-acquisition software compensation was applied to correct the spectral cross-talk of PI fluorescence. Secondly, the distribution of the Ki-67 (FITC) protein during the cell cycle (PI) of SiHa cervical carcinoma cells (no software compensation) was compared to the Ki-67 expression pattern of SiHa cells, simultaneously stained for keratin 8 (RPE), after applying software compensation. Finally, software compensation was used to compare the relative levels of PCNA and p53 expression in two clinical ovarian cancer ascites specimens, stained for PCNA or p53 (FITC), keratin 8/18 (RPE), and DNA (PI), with a known p53 status (positive and negative, respectively). RESULTS: The Ki-67 cell cycle-dependent pattern of a triply stained sample (Ki-67 (FITC), keratin 8 (RPE), and DNA (PI)) is restored after software compensation and the results are comparable to the Ki-67 distribution of a sample stained solely for Ki-67 and DNA. P53 expression could only be resolved after using software compensation in the p53 positive ovarian ascites (OA) sample. CONCLUSIONS: We conclude that software compensation is a robust and reliable post-acquisition method for the correction of RPE/PI spectral cross-talk, permitting better identification of weakly expressed proteins in heterogeneous clinical tumor samples stained for multiple cellular antigens and DNA using PI.

DNA, Neoplasm↗
PubMedDate not supplied

New statistical software for intralaboratory and interlaboratory quality control in clinical cytology. Validation in a simulation study on clinical samples.

OBJECTIVE: To design a statistical software package to provide automated calculations of normal and weighted and 3 indices. STUDY DESIGN: Prompted by the lack of commonly available software to compute weighted kappa and the nonproportionate workload needed to calculate our 3 variability indices manually, the new statistical software package was designed. To demonstrate the performance of the new CONQUISTADOR software, a simulation study (both intralaboratory and interlaboratory) was designed using 5,000 clinical samples randomly selected from a data file of > or = 200,000 conventional Pap smears and programmed to become "analyzed" by 12 cytologists in 5 imaginary laboratories. RESULTS: A representative set of both complete and partial outputs provided by the software, in Excel format (Microsoft, Redmond, Washington, U.S.A.) are shown to illustrate the different functions of the program. In the interlaboratory mode, the software calculates accuracy indicators (sensitivity, specificity, positive and negative predictive value, and their 95% CI), which are not common features of regular statistical packages; kappa and weighted kappa; and their 95% CI (comparison of single laboratories to all laboratories and pairwise comparisons between single laboratories). The 3 diagnostic variability indices can be computed separately for all samples or for only the positive samples. In the intralaboratory mode, the software calculates the same indices for individual cytologists. CONCLUSION: The CONQUISTADOR statistical package has properties that are useful in monitoring cytologic laboratory quality in both intralaboratory and interlaboratory settings. The software will be distributed by the National Institute of Health, Rome, for the delivery costs only.

Clinical Laboratory Techniques↗
PubMed2004

STING Millennium Suite: integrated software for extensive analyses of 3d structures of proteins and their complexes.

BACKGROUND: The integration of many aspects of protein/DNA structure analysis is an important requirement for software products in general area of structural bioinformatics. In fact, there are too few software packages on the internet which can be described as successful in this respect. We might say that what is still missing is publicly available, web based software for interactive analysis of the sequence/structure/function of proteins and their complexes with DNA and ligands. Some of existing software packages do have certain level of integration and do offer analysis of several structure related parameters, however not to the extent generally demanded by a user. RESULTS: We are reporting here about new Sting Millennium Suite (SMS) version which is fully accessible (including for local files at client end), web based software for molecular structure and sequence/structure/function analysis. The new SMS client version is now operational also on Linux boxes and it works with non-public pdb formatted files (structures not deposited at the RCSB/PDB), eliminating earlier requirement for the registration if SMS components were to be used with user's local files. At the same time the new SMS offers some important additions and improvements such as link to ProTherm as well as significant re-engineering of SMS component ConSSeq. Also, we have added 3 new SMS mirror sites to existing network of global SMS servers: Argentina, Japan and Spain. CONCLUSION: SMS is already established software package and many key data base and software servers worldwide, do offer either a link to, or host the SMS. SMS (Sting Millennium Suite) is web-based publicly available software developed to aid researches in their quest for translating information about the structures of macromolecules into knowledge. SMS allows to a user to interactively analyze molecular structures, cross-referencing visualized information with a correlated one, available across the internet. SMS is already used as a didactic tool by some universities. SMS analysis is now possible on Linux OS boxes and with no requirement for registration when using local files.

Algorithms↗
PubMed2006

Comparison of simulated periodontal bone defect depth measured in digital radiographs in dedicated and non-dedicated software systems.

OBJECTIVES: To compare simulated periodontal bone defect depth measured in digital radiographs with dedicated and non-dedicated software systems and to compare the depth measurements from each program with the measurements in dry mandibles. METHODS: Forty periodontal bone defects were created at the proximal area of the first premolar in dry pig mandibles. Measurements of the defects were performed with a periodontal probe in the dry mandible. Periapical digital radiographs of the defects were recorded using the Schick sensor in a standardized exposure setting. All images were read using a Schick dedicated software system (CDR DICOM for Windows v.3.5), and three commonly available non-dedicated software systems (Vix Win 2000 v.1.2; Adobe Photoshop 7.0 and Image Tool 3.0). The defects were measured three times in each image and a consensus was reached among three examiners using the four software systems. The difference between the radiographic measurements was analysed using analysis of variance (ANOVA) and by comparing the measurements from each software system with the dry mandibles measurements using Student's t-test. RESULTS: The mean values of the bone defects measured in the radiographs were 5.07 mm, 5.06 mm, 5.01 mm and 5.11 mm for CDR Digital Image and Communication in Medicine (DICOM) for Windows, Vix Win, Adobe Photoshop, and Image Tool, respectively, and 6.67 mm for the dry mandible. The means of the measurements performed in the four software systems were not significantly different, ANOVA (P = 0.958). A significant underestimation of defect depth was obtained when we compared the mean depths from each software system with the dry mandible measurements (t-test; P approximately equal to 0.000). CONCLUSIONS: The periodontal bone defect measurements in dedicated and in three non-dedicated software systems were not significantly different, but they all underestimated the measurements when compared with the measurements obtained in the dry mandibles.

Alveolar Bone Loss↗
PubMed2002

Characteristics of educational software use in 106 clinical laboratories.

The University of Washington, Seattle, has developed educational software for clinical laboratories. We used a 32-question survey to study software implementation. Of 106 clinical laboratories (response rate, 60%) that purchased the software and completed the survey, 89 laboratories (84%) that reported using the software formed the basis for the study. The most common software users were laboratory personnel, followed by medical technologist or medical laboratory technician students, residents, and medical students; the mean (SD) number of personnel categories using the software per laboratory was 1.8 (0.8). The most common reasons for use were initial instruction, cross-training, and competency assessment. The most frequent setting for software use was an area where laboratory testing occurred, followed by a dedicated training location, a location chosen by the employee, a classroom, and a distance learning mode. On a scale of 1 (poor) to 5 (excellent), the average satisfaction rating as an instructional tool was 4.4 and as a competency assessment tool, 4.2. Compared with laboratories in hospitals with 400 beds or fewer, laboratories in hospitals with more than 400 beds used the software for more categories of users (P = .008), had a higher proportion of laboratories using it for residents (P = .003), and had a higher proportion of laboratories with dedicated training areas (P = .02).

Clinical Laboratory Techniques↗
PubMedDate not supplied

[Development of ophthalmologic software for handheld devices].

INTRODUCTION: The formulas for calculation of intraocular lenses have evolved since the first theoretical formulas by Fyodorov. Among the second generation formulas, the SRK-I formula has a simple calculation, taking into account a calculation that only involved anteroposterior length, IOL constant and average keratometry. With the evolution of those formulas, complexicity increased making the reconfiguration of parameters in special situations impracticable. In this way the production and development of software for such a purpose, can help surgeons to recalculate those values if needed. PURPOSE: To idealize, develop and test a Brazilian software for calculation of IOL dioptric power for handheld computers. METHODS: For the development and programming of software for calculation of IOL, we used PocketC program (OrbWorks Concentrated Software, USA). We compared the results collected from a gold-standard device (Ultrascan/Alcon Labs) with the simulation of 100 fictitious patients, using the same IOL parameters. The results were grouped for ULTRASCAN data and SOFTWARE data. Using SRK/T formula the range of those parameters included a keratometry varying between 35 and 55D, axial length between 20 and 28 mm, IOL constants of 118.7, 118.3 and 115.8. RESULTS: Using Wilcoxon test, it was shown that the groups do not differ (p=0.314). We had a variation in the Ultrascan sample between 11.82 and 27.97. In the tested program sample the variation was practically similar (11.83-27.98). The average of the Ultrascan group was 20.93. The software group had a similar average. The standard deviation of the samples was also similar (4.53). CONCLUSION: The precision of IOL software for handheld devices was similar to that of the standard devices using the SRK/T formula. The software worked properly, was steady without bugs in tested models of operational system.

Computers, Handheld↗
PubMed2006

Development and implementation of pharmaceutical care planning software for nursing homes based on the Fleetwood Model.

PURPOSE: The effectiveness of pharmaceutical care planning software for nursing homes and the extent to which the software assisted in the implementation of the Fleetwood Model are described. METHODS: During the study, one long-term-care pharmacy identified 13 nursing homes to participate in the intervention group of a study evaluating the effectiveness of the Fleetwood Model. To successfully implement the Fleetwood Model, which demands prospective drug regimen review and collaborative practices between dispensing and consultant pharmacists, a software system that exchanged information between these pharmacists was deemed necessary. Pharmacists' self-reported assessments of the use of the software and the technical difficulties reported with its use were collected. The number of interventions performed by pharmacist type, the proportion of residents receiving interventions by multiple pharmacists, and the extent to which the interventions were prospective and performed before the mandated 30-day review were estimated from data documented in the software. The consistency of software use by the pharmacists was also estimated. RESULTS: Seventy-one percent of dispensing pharmacists and 40% of consultant pharmacists reported using the software most or all of the time. Fourteen percent of dispensing pharmacists and 40% of consultant pharmacists reported technical difficulties with the software. Over half of newly admitted or readmitted residents received a Fleetwood intervention within 3 days of admittance into the nursing home-71.2% occurred in less than 30 days of admission. CONCLUSION: The use of information technology to increase communication among health care professionals and assist in providing prospective drug regimen review in long-term-care facilities is feasible. Collaboration and extensive field testing with end users, realistic expectations, appropriate training, and technical support are necessary when implementing new technology.

Aged↗
PubMedDate not supplied

United States government regulation of medical device software: a review.

A brief history of the regulation of medical device software within the United States is presented, along with a discussion of the reasoning that the US Food and Drug Administration (FDA) presents for modifying the requirements for software regulation from those previously used for hardware devices. The current regulatory status is discussed for the two categories of medical device software, software used within medical devices and software used to produce or test medical devices. The published FDA documents which determine the current environment for the regulation of software are summarized and discussed. The two types of medical device software are related to the two areas of FDA regulation, good manufacturing practices and permission to sell medical devices. The expected direction of future medical device software regulation, and its relationship to the European Economic Community (EEC) and international markets is discussed.

Equipment and Supplies↗
PubMedDate not supplied

What can bibliographic software offer you?

This article provides an introduction to bibliographic software products, common uses for bibliographic software, and some suggestions on how to choose the right software product. The focus of this article is on software for individual, rather than institutional, use. Bibliographic software is designed to allow information to be catalogued and retrieved with ease. Bibliographic software products range from catalogue database software to more specialized bibliographic database and management software products. Each type of product meets the needs of a specific user group.

Choice Behavior↗