What Issues Should I Take Into Account?
As is the case with much modern software, computer-based patient record applications work as advertised assuming certain conditions to be true. None will perform a function for which it was not designed. A corollary to this is that your success will generally be proportional to your willingness to let the application do what its good at without trying to adapt it to what you're comfortable doing. There are many more important issues that will consume your attention:
| Complexity | None of the current generation of products could honestly be called simple. Practically all of them are LAN-based, database-oriented applications with sophisticated user interfaces. You should be ready to learn several new technologies and prepared to relearn about half of what you know every 18 months or so. The pace of change does not appear to be slowing at all. (If you want to follow this, visit Jeffrey Harrow's Rapidly Changing Face of Computing site.) |
| Privacy/Security | Matters of privacy and security are still not well defined. Everyone agrees that healthcare information should be private, so security surrounding it should be tight. What "surround" and its relevant context mean help drive the current debate. Only a few systems implement a security model designed to enforce enterprise rules. Allowing database access only through an intermediate software layer (or 2nd tier) normally accomplishes this. If a vendor says that any ODBC compliant report writer can be used to get reports from the database, the security model associated with that product is probably not terribly strong. This is because most LAN-based relational database servers expect the application to control record-level security. If you are querying the database directly (as you would be with ODBC), you may be able to access records you shouldn't. Make sure you define your security needs and compare them to vendor capabilities. |
| Authoritative Identification | Patients or members whose data will be read or updated as part of a visit, encounter, or stay must be identified unambiguously. Anonymity is going the way of privacy. If your system does not provide a way to authoritatively identify a patient or member, you can end up with multiple records for an individual (bad), records for an individual lost under an unknown name (very bad), or records associated with one patient accidentally stored among those of another (terrible, even life threatening). Most applications have some strategy for dealing with this, and most expect you will take the issue seriously enough to make sure your workflow is compliant. If you cannot adapt your workflow, analyze the effects of your decision carefully. Authoritative identification is the keystone of a data quality program. |
| Digital Signature | Digital signature is a specific technology that ties an authoritative and theoretically tamper-proof identification to computer data. Standards related to digital signature will eventually be the basis for much electronic commerce, even electronic cash. The same standards will allow authoritative sign-off for clinical information. No system currently offers any kind of comprehensive support for this and the first is probably several years away. Lack of this should not stop your progress toward implementing a computer-based patient record, but make sure the vendor has made clear commitments to a coherent approach. To follow some of the progress in this regard, start with The American Society of Testing Material (ASTM), the Medical Records Institute, or ANSI. |
| Data Quality | Since the clinical information in the database is directly related to a person's welfare through patient care, it must be accurate and authoritative. How do you know it is? What processes will you put in place to make sure the data stays as clean as possible? How will you audit yourself to make sure that the data is as clean as you think it is? Data hygiene is still a fairly unexplored technical frontier in healthcare. The extent to which you cannot certify the data may also be the extent to which you cannot be certain about the quality of the decisions based on the data. |
| Training | Everyone will need a lot of training, and it will need to be refreshed frequently. As a rule of thumb, assume the shelf life of any training to be about 18 months at the very most. If your key technical resources are not in training for at least one week (low-end systems) to four weeks (high-end systems) per year. They will probably lack the skills to run the system reliably. You will not know this, however, until after the fact. |
| Recoverability | What are the backup and recovery procedures? Backup is usually a lot more straightforward than recovery, and you need to know about both. If the size of the database makes the recovery time seem impractical, what do you need to do? Similar concerns will need to be addressed with regard to database consistency checking. How long does the operation take? Can it be done on line? What is the performance impact? What happens if the process uncovers a problem? If these questions do not seem clear, refer to the comments on training above. |
| Murphy's Laws | Forget Murphy's laws. If something can go wrong, fix it. |
Consider, too, the experience of others in determining areas of the effort that may be problematic in a given situation. Some useful "Laws of Information Technology" are included in this site as well.