аЯрЁБс>ўџ NPўџџџMџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџьЅС №ПуMbjbjрр "\‚j‚jOI“џџџџџџlММММвввц8 8 8 8 L $цut| | | | | | | | єіііііі$щ  ”в| | | | | № М Ц | | /№ № № | pв| в| є№ | є№ И№ Ј:˜,вви| p `ийуъ,УцR8 ь ФФ иE0uЮ А @и№ ццММввй WHAT WE SOFTWARE VENDORS ARE WANT TO SAY Unabridged version of Article published in LINKS as: Points to consider as you further your IT Investment. LINKS, American Network of Community Options and resources (ANCOR), Alexandria, VA (January, 2002, Vol 32, No. 1) pages 17-18 ANCOR by John Ashbaugh June 18, 2001 Agencies must make greater use of information technology (IT) if they are to support persons with DD in keeping with today’s individualized, inclusive policies, and in the face of related and growing administrative demands and staffing constraints. Information technology today is much advanced over that available only a few years ago, and will continue to improve. Agencies that know or learn how to make effective use of it will benefit themselves and those they serve. That said, making cost effective IT investment decisions is difficult. No less than other vendors of application software for agencies serving persons with developmental disabilities I believe in the product and company I represent. While I try not to overstate the capabilities of the software, I am sure to emphasize the many benefits that accrue to agencies using it. What I don’t emphasize are the downsides or limitations associated with software of its genre or with agency efforts to automate generally. I’m not alone. The purpose of this article is to point up some common downsides to automation that deserve mention and agency attention. Agencies would be well-advised to keep these points in mind as they further their investments in IT. Software may be designed for use on desktops, on networks of computers linked by cable or wireless technology, or on the world wide web (database sites connected over the internet). Each type of software has important strengths and limitations. Much off-the-shelf software is desktop software. It is designed to do everything on one personal computer (PC). The software is typically fashioned for the mass market, it is well-designed and highly functional. Word processing, spreadsheet, database, desktop publishing and other applications easily pay for themselves when used on small numbers of machines. However, as the number of machines on which an application runs increases, the cost effectiveness of the desktop software progressively declines. The cost of the added licenses outweighs the cost of housing the software on one computer and sharing or serving it up to others 1) over a network as is possible with client/server software or 2) over the internet as is possible with web-based software. The value of desktop software especially declines in the case of database software (e.g. Microsoft Access) where a common database needs to be shared and kept in synch across many users (computers). Whenever there are changes to the database, the entire changed database must be transmitted to all of the users. The added traffic slows network performance and often requires the expensive build-up of the network to accommodate it. Client / server software is designed to work on a computer network where a dedicated computer (server) houses the central database and handles many of the processing tasks while distributing others to the networked PCs. It is designed to minimize network volume and thereby improve system performance. Only changes to the database need to be transmitted between the clients (user) and server. Client / server software is expressly designed to run robust, integrated, enterprise-wide applications over a network. Client / server systems require “fat” powerful client devices for local execution and “fat” expensive pipes to accommodate the high-speed transmission of bandwidth-intensive applications. Because the software applications are integrated, the same data need not be entered multiple times and it is easier to write comprehensive reports that rely on data from multiple applications and related data. Nonetheless, client / server software has its problems. No less than with desktop software, the software must be loaded on the server as well as client machines. This means that software upgrades must be loaded onto each machine. It means that user mistakes and errors invariably corrupt the client software and demand considerable troubleshooting. It means that someone, typically one system administrator, must assume overall responsibility for securing, developing and maintaining the enterprise-wide system(s). The concentration of knowledge and power in one system administrator is a necessary evil--evil only in the event they depart the agency. Last but not least, client / server, enterprise software is a jump up in cost, not only in the price of the software, but in the cost to configure the software to suit the various needs of the agency, the cost of agency-wide training and the cost of the one-time migration of data from old to new systems. Web-based systems are like the mainframe systems of the past in that the software and database can be housed entirely on the server and the processing can be done entirely on a central server as well. Users can access and make use of the system from computers or other devices limited in terms of processing power and memory (i.e. thin-client devices) and thus relatively inexpensive. Because the software and database are housed on the server, the time required to install software updates and upgrades is minimal, and the amount of time that must be spent troubleshooting user-created PC problems is greatly reduced. For the same reason, the server-based model will make it easier to meet the technological and physical security requirements coming out of the Health Insurance Portability and Accountability Act (HIPAA). Finally, the software is written in interoperable code that can be universally managed by the hardware and software of different vendors thereby facilitating the exchange of data within and across networks. In describing web-based (“thin-client”) systems, it is often said that only keyboard, mouse and display information need be transmitted over a network or internet; the implication being that the bandwidth requirements and corresponding problems with speed are minimal. While this may be the case with smaller, less robust applications, it is not the case with larger, more robust “enterprise” systems. These systems involve the generation of sizeable lists, reports and displays requiring more bandwidth than most agencies can access. T1 lines can manage 1500 kilobytes per second (kps), but cost between $500 and $1,500 per month—too costly to connect the many smaller sites agencies typically have. Digital subscriber lines (DSLs) can manage 384-1500 kps at $100 - 500 per month depending on how far the agency is from the central office (“Switch”), but only work for agencies located within 2.6 miles of the switch. Beyond that distance, the maximum speed drops to 144kps. Cable Modems can manage over 1000kps but slow considerably as more users come on. Satellite-based broadband, at 128 – 256kps, is generally perceived as working anywhere; however, it only works where there is a clear southern exposure ruling out sites near tall buildings and in mountainous areas. Moreover, setup costs can be prohibitive and weather (storm) interruptions, a problem. When it comes to the bandwidth available to most agencies you are down to that available through phone lines. There are dial-up Integrated services digital network (ISDN) lines and always-on Integrated Services digital (ISDL) lines at 64 – 128kps, and regular phone lines at up to 56kps. It is important to remember that, except for T1 lines and above, actual speeds typically run about half of the capacities advertised. In order to achieve an acceptable level of speed given this everpresent bandwidth constraint, web-based software developers have had to resort to the distributed processing architecture of client/server systems. They have had to place applets (portions of the software) on the workstations in order to distribute some work and data to the client machines and thus reduce the volume of network traffic. The giveaway with such software is in the published workstation specifications—generally the equal of those published for client / server systems. This effectively eliminates the system maintenance, security and workstation cost advantages held out by web-based vendors. Application server systems, namely Citrix, its counterparts and offshoots, e.g. windows terminal server, are often touted—sometimes legitimately and sometimes not—as the way to turn fat-client, client / server applications into thin-client, web-based applications and deliver them over low-bandwidth with the attendant advantages. They do this by translating the applications and parent operating systems (e.g. Windows, Unix, …into a browser-operable form. Indeed, Citrix can be used to web-enable most any desktop and client / server application run today. One downside is the cost. The software and hardware (Citrix server) costs come on top of the costs of the client / server application software. The other downside is that Citrix solutions face the same bandwidth constraint faced by the straight web-based developers. In addition, they inherit design inefficiencies characteristic of client/server and desktop software, e.g. overly extensive, non-segmented drop-down lists that consume bandwidth and slow performance as they travel from server to client. In the case of robust, enterprise solutions, the economically feasible bandwidth available to carry the application load may well be insufficient to maintain an acceptable level of performance (speed). Always load-test your application(s) before contracting for a Citrix or other application server solution. Document Imaging entails the scanning (electronic capture) of an image, e.g. photo, page of handwritten notes, or a diagram. The image is rendered into a series of white/black/or color dots otherwise known as a bitmap. This bitmap (there are many industry formats) is then stored on magnetic media such as a hard drive, on a magnetic/optical disk or a one write CD-ROM. The principal selling points are: 1) savings in filing time and thus the cost of filing, 2) savings in storage costs, and 3) savings in access / retrieval time. A common practice of vendors is to prepare estimates of time and dollar savings; they tend to be overstated. Filing time. Imaging requires indexing in order to find documents quickly. Indexing involves an individual’s scanning in an image and making decisions as to what tags (names, key words, categories) to associate with it. These categories are then used to access the document image. Each piece of paper needs to be categorized at least as well as it is now. At DDC they use a three ring binder which has 8 to 14 sections. The scanning operator would need to scan each piece of paper and assign a client identifier, a category and perhaps a form number or other useful identifier in order that the images might be readily retrieved. Ask yourself whether there will really be much savings in time over manual filing after all this. If there are any savings in this area they are seldom significant. Storage costs. Nor should one expect significant savings in file storage space and associated costs at least for dead files--that is files not likely to be retrieved once archived. Commercial storage space rents for about one third of office space rentals in most areas. The contents of a 4 drawer filing cabinet fits in 8 storage boxes and would cost approximately $15 to store off-site per year. On the other hand, the costs of retrieving files stored off-site is high. If one needs to recall a box it would cost $15-$18 to get a scheduled one-day retrieval delivered. Same day emergency retrieval could be as high as $50. The costs of data imaging compares favorably to the cost of off-site document storage in the case of documents that must be retrieved with any frequency. The prudent approach is not to electronically store all documents, only those where there is a distinct possibility that they will have to be retrieved. Retrieval Time. Data imaging systems have the greatest payoff in allowing multiple user access to records, particularly where users are spread far and wide. However, even here, there are obstacles and limitations. The legal standing of scanned documents and digital signatures has still not been legislated in most states. HIPAA has yet to settle on the methods to be used to authenticate the electronic images. Moreover, document images are large files, typically 1500 kilobytes. Transmitting just one over a satellite connection can be expected to take at least 8 seconds, 16 seconds, over an ISDN line, and 30 – 60 seconds over a phone line. Multiply this by the dozens, even hundreds of such files that could be active on a network and the effective drag on system performance becomes obvious. Many electronic record systems today boast the ability to store and retrieve document images. However, while the technological capability may be there, the network capacity is probably not. Electronically transmitting document images in any number is certain to clog most networks and slow the performance of any and all agency applications competing for network bandwidth. Knowing that agencies are concerned about the looming HIPAA requirements, vendors are quick to claim that they are “HIPAA compliant.” Such general claims mean little and at this point in time are a little premature. There are three compliance areas: 1) electronic transaction and code sets for financial and administrative electronic data interchange (EDI), 2) security and privacy standards for the protection of individually identifiable healthcare information, and 3) unique identifiers for consumers, providers, payers and employers. In the first instance, vendors of software for payers and / or providers (billers) must be in compliance with the American National Standards Institute (ANSI) X12N standards governing claims/encounters, eligibility verification, enrollment, and related transactions. They must also be able to handle the code sets recognized by HIPAA at least to the extent that the codes must be used by the agencies using their software. Code sets approved thus far include: Pharmaceuticals National Council for Prescription Drug Programs (NCPDP) Medical diagnoses and procedures International Classification of Diseases (ICD) 9th Edition Professional Services Current Procedural Terminology (CPT) 4th Edition Dental Services Current Dental Terminology (CDT) Note: Additional codes / code modifications will almost certainly be adopted after October, 2002 to cover “non-medical” services and supports of the sort provided by agencies serving persons with developmental disabilities. These standards were adopted by HIPAA in August, 2000 and take effect October, 2002. In the second instance, Standards for Privacy of Individually Identifiable Health Information will be effective April, 2003. Standards for the Security of Individual Health Information are not yet finalized. Even when they are, no vendor will be able to make a blanket claim that their product is HIPAA security compliant. The Notice of Proposed Rule Making (NPRM) clearly indicates that HIPAA will leave it to each covered agency to define its own security policies and procedures so long as the procedures engender “reasonable and appropriate administrative, technical and physical safeguards to ensure integrity, confidentiality and availability of information.” Hence, the most a vendor might claim in the security arena is that it meets the security requirements of particular organizations, or that it contains particular technological security features favored, endorsed or required by HIPAA (e.g. 128 bit encryption, authentication (that the electronic information and / or source are genuine), repudiation (the person to whom the message was addressed read the message) and integrity (that the information sent is the information received). In the third instance, vendor systems must be able to tie unique numeric codes of nine digits with a tenth check digit to individual consumers, providers, payers and employers. The specific coding conventions have been decided for all but consumers. The most credible vendor claims would be from vendors whose clients (covered entities) or who themselves are certified as HIPPA compliant by the Electronic Healthcare Network Accreditation Commission (EHNAC), National Committee for Quality Assurance (NCQA) or other recognized third party. Vendors of billing and payment software can subscribe to EHNAC’s Standard Transaction Format Compliance System (STFCS) whereby their software is tested and certified as compliant with the HIPAA Transaction Formats. EHNAC expects to complete a system to provide HIPAA security accreditation in early 2002. What does the system cost? When asked for quotes, software vendors are often led to confine their estimates to their own costs to the agency. Not included are many other costs that an agency is likely to face. Depending on the agency’s current infrastructure and the system architecture, such costs might include: Middleware or custom bridges to integrate the application software with other applications Operating system software or utilities upon which the efficient operation of the application depends (e.g. Microsoft SQL Server), Application server to house the application System backup measures to avoid the loss of data and debilitating system downtime Hardware and Network improvements necessary to accommodate the application (server(s), lines, routers, hubs, …) Porting or keying existing data into the application from legacy systems Physical and technological security provisions—the time and expense necessary to safeguard the data System / database Administration—in-house costs to help develop and manage the application to meet the ongoing and ever-changing needs of the agency Change Management—the organizational development time and expense necessary to ensure the successful implementation and operation of the system . I have written this article in good conscience, not out of a guilty one. These downsides should be taken as cautions by agencies investing, as they must, in the automation of their operations. These limitations are by no means all-inclusive. If you haven’t the technical knowledge needed to make a smart IT investment decision, secure the services of a technical consultant to help. When you are listening to we vendors wax on about our products and services keep these cautions in the back of your mind. Caveat Emptor.  It appears unlikely that the Joint Commission on the Accreditation of Healthcare Organizations (JAHCO) will offer HIPAA accreditation per se. +-.^c˜™ž!/12@EFДg5   0 @ Фм/ќ q8з$ё$<*L*4568Ћ8К8%<Р<Т< = =(>'E(E_F§їђцнвн§§ЯШНШНИШЋИЅИЅИЅИŸИŸИЅИ—ШИЅИˆˆИ}Иj0JOJQJUCJH*OJQJ CJOJQJ5CJOJQJ OJQJh 5OJQJ<B*CJOJQJphOJQJB*CJOJQJph CJOJQJCJ>*B*OJQJphB*OJQJph6B*OJQJ]phOJQJ 5OJQJ51+,-.!"012@ACDEgh5 6   §§ћљљєєєєєєєљљя§§§§чткччк$dha$$a$$dha$$a$$a$OMтM§§    ~  УФ)*-"."ж$з$;*<*Г+Д+У,Ф,ц/ч/’3“33545їїїїїїїїїїїїїїїїїьььььььььь $ & Fdha$$dha$456878U:V:%<o<Ы<=G=(>„>…> C CDD^F_FœGGњG|HЈHћHkIДI§ѕѕѕѕъъъъѕѕѕѕѕѕѕѕѕѕѕпппппп $ & Fdha$ $ & Fdha$$dha$_FyFNMOMPMуMљєэ j0JUOJQJ 5OJQJДIJ­J?KAKOMсMтMуMєєєььъшь$dha$ $ & Fdha$ 1hАа/ Ар=!А"А# $ %А i4@ёџ4 Normal_HhmH sH tH 6@6 Heading 1$$@&a$CJ <A@ђџЁ< Default Paragraph Font*B@ђ* Body TextCJ,+@, Endnote Text6*@Ђ6 Endnote ReferenceH*NP@"N Body Text 2$ & Fdha$CJOJQJ^J'AуI’•уI\џџџџ+,-.!"012@ACDEgh56~У Ф )*-.ж з ;&<&Г'Д'У(Ф(ц+ч+’/“/31416474U6V6%8o8Ы89G9(:„:…: ? ?@@^B_BœCCњC|DЈDћDkEДEF­F?GAGOIсIфI˜0€€˜0€€0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€ž0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜0€€˜0€€˜0€€˜0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜0€€˜0€€š@0€€ 0_FуM', 45ДIуM(*+-тM)ќџ'/sv "ju 6Ї6dAkAOIфI "0)*УЯinДЛЃ'Ј'J*V*-Л-Ї2Ў2Q:X:ѕ:ћ:fEjE6G>GOIфI33333333333333.X^//лхNIфIџџPreferred Customer2C:\My Documents\765MSS\mktg\AncorArt\ancorartf.docPreferred CustomerMC:\WINDOWS\Application Data\Microsoft\Word\AutoRecovery save of ancorartf.asd John Ashbaugh2C:\windows\TEMP\AutoRecovery save of ancorartf.asd John AshbaughD\\DANICUSANT41\disk2\STAFF\John Ashbaugh\mktg\AncorArt\ancorartf.doc John AshbaughD\\DANICUSANT41\disk2\STAFF\John Ashbaugh\mktg\AncorArt\ancorartf.doc John AshbaughD\\DANICUSANT41\disk2\STAFF\John Ashbaugh\mktg\AncorArt\ancorartf.doc John AshbaughD\\DANICUSANT41\disk2\STAFF\John Ashbaugh\mktg\AncorArt\ancorartf.doc jashbaughC:\mktg\AncorArt\ancorartf.doc John Ashbaugh-C:\Papers\what we vendors are want to say.docDavidC8C:\webpage\documents\what we vendors are want to say.docбn†˜”[џџџџџџџџџбfPўњ|џџџџџџџџџh „а„˜ўЦа^„а`„˜ўOJQJo(и№h „ „˜ўЦ ^„ `„˜ўOJQJo(oh „p„˜ўЦp^„p`„˜ўOJQJo(Ї№h „@ „˜ўЦ@ ^„@ `„˜ўOJQJo(З№h „„˜ўЦ^„`„˜ўOJQJo(oh „р„˜ўЦр^„р`„˜ўOJQJo(Ї№h „А„˜ўЦА^„А`„˜ўOJQJo(З№h „€„˜ўЦ€^„€`„˜ўOJQJo(oh „P„˜ўЦP^„P`„˜ўOJQJo(Ї№h „а„˜ўЦа^„а`„˜ўOJQJo(и№h „ „˜ўЦ ^„ `„˜ўOJQJo(oh „p„˜ўЦp^„p`„˜ўOJQJo(Ї№h „@ „˜ўЦ@ ^„@ `„˜ўOJQJo(З№h „„˜ўЦ^„`„˜ўOJQJo(oh „р„˜ўЦр^„р`„˜ўOJQJo(Ї№h „А„˜ўЦА^„А`„˜ўOJQJo(З№h „€„˜ўЦ€^„€`„˜ўOJQJo(oh „P„˜ўЦP^„P`„˜ўOJQJo(Ї№бfPбnџџџџџџџџџџџџOIсIфIџ@€//\—A//уI@@џџUnknownџџџџџџџџџџџџG‡z €џTimes New Roman5€Symbol3& ‡z €џArialA& ‡ŸTrebuchet MS;€Wingdings?5 ‡z €џCourier New"qˆ№аho3s†ё9vЦRzVІš r<€$№ ZД‚‚20d;J2ƒQ№пџџWhat we vendors say and don tPreferred CustomerDavidCўџр…ŸђљOhЋ‘+'Гй0Є˜ Шд№ќ ,8 T ` l x„Œ”œфWhat we vendors say and don’tMihatPreferred Customer refref Normal.dotuDavidCd3viMicrosoft Word 9.0 @0@Дz™ѕР@€cфТ@ожШъ,Уš r<ўџеЭеœ.“—+,љЎ0 hp˜ Ј АИРШ а њфManaged Support Systems€;J What we vendors say and don’t Title  !"#$%&'()*+,-.ўџџџ0123456789:;<ўџџџ>?@ABCDўџџџFGHIJKLўџџџ§џџџOўџџџўџџџўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџRoot Entryџџџџџџџџ РF щуъ,УQ€1Tableџџџџџџџџџџџџ/WordDocumentџџџџџџџџ"\SummaryInformation(џџџџ=DocumentSummaryInformation8џџџџџџџџџџџџECompObjџџџџjObjectPoolџџџџџџџџџџџџ щуъ,У щуъ,Уџџџџџџџџџџџџўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџўџ џџџџ РFMicrosoft Word Document MSWordDocWord.Document.8є9Вq