• Seven Points for Implementing HIPAA Security
  
  
• HIPAA Privacy and Security Factual Questions
  
  
• Preliminary Checklist for Security and Privacy Issues in HIPAA Implementation Projects
  
  
• Preliminary Checklist for Computer and Telecommunications System Purchases

Seven Points for Implementing HIPAA Security

HIPAA Privacy and Security Factual Questions

Fact Issues (each of which also requires knowing the applicable legal standard):

1. What sort of access control is required? Is it true that each view of protected health information (PHI) in a patient's record must be logged, showing who viewed what? Can a doctor look over another doctor's shoulder and not log the access? Same if a nurse is involved? What about doctors and medical students on grand rounds? What are the penalties for not implementing proper logging procedures? For not enforcing them vigorously? What kind of software can perform this kind of logging? Is it available today on the market?
2. What protections must be implemented for terminals where PHI will be accessed? Must nurses' stations be secure areas? If so, how secure? What about monitors in ICUs and similar facilities? What surveillance must be implemented for these areas?
3. What kind of access procedures will satisfy HIPAA requirements? Passwords alone? Passwords with SecureID or similar procedures? Biometrics?
4. What happens if a health care professional attempts to log on to get access to medical records in an emergency, and makes a mistake in their input of the password or other required information? How many attempts can be allowed before the system locks them out? What are the emergency access procedures? Must the doctor or nurse then be physically identified by a member of the security staff, in essence to revalidate that staff member? How will that be done? How long might it take, especially in an emergency setting? What if patient care suffers - what are the malpractice issues?
5. How can the logon, identification, and other required attributes of data protection, in transit and at rest, be satisfied without resort to asymmetric encryption techniques?
6. How can a medical professional or an administrator determine what the "minimum necessary" disclosure is to an examining physician? Where does one find the industry-standard guidelines to make these judgments? Do they change in the face of a medical emergency? What procedures are required (or prudent) for a hospital or a physician practice to review these determinations after the fact? What if there is a finding of excess disclosure? Can the professionals involved in the original decision appeal? To whom? ? Must the provider report the matter to HHS, and, if so, at what point? What guidelines will HHS use to review the disclosure and its review? What malpractice jeopardy is there for making too narrow a disclosure?
7. To what extent will the standard of care in the security industry require that protected health information (PHI) be stored in encrypted form? Are systems available on the market to perform this kind of storage?

Return to top of page

Preliminary Checklist for Security and Privacy Issues in HIPAA Implementation Projects

November 9, 2000

NOTE: Because HHS representatives state explicitly that the final privacy regulations will change substantially from those proposed, this checklist concentrates in the interim on the security regulations. It is of course possible that the final security rules will differ substantially from those proposed.

1. Will the enterprise's systems

• create, store, manipulate, or transmit
• internally within the organization or externally
• data
• about a patient's
• past, present, or future
• physical or mental health condition, health treatment, or payment for health care?

2. Are the systems

• clinical
• business
• administrative
• email?

3. Will the systems include

• backup
• storage
• archives
• transmission (internally or externally)?

4. Is the patient identifiable ("individually identifiable")?

5. Where will individually identifiable patient data be displayed, stored, or transmitted in electronic form or in paper derived from electronic form?

• Terminals: consoles, desktops, or laptops (at work, home, or travel)
  • registration
  • clinical
  • business
  • research
  • administration
• Storage
  • Current data bases
    • central
    • distributed
  • Archived data bases
  • Current physical (paper) files (including mixed files, those containing some pure paper records and some paper records derived from electronic files)
  • central
  • distributed
  • Archived physical (paper) files
• Networks, internal and external
  • protected transmission path (VPN or comparable)
  • public (Internet, public switched telephone network or comparable)

6. Have all personnel with access to system components been cleared by an appropriate background check

• initial
• recurring (what is the interval in years)?

7. Are all components of the system physically secure?

• Can any affected terminals be viewed by
  • the public
  • any staff member who lacks authorization under
    • "need to know"
    • "minimum necessary disclosure"?
• Is each affected terminal under some form of surveillance?
  • active (e.g., cameras with recording systems)
  • passive (access logging)
  • area surveillance (located in a secure area where ingress-egress is surveilled)?

8. Are all access features of the system controlled sufficiently to assure irrefutable identification and detect attempts at improper access?

• Access controls
  • password (PIN) plus smart card, SecureID, etc.
  • biometrics
• Network protection
  • firewalls, etc.
  • intrusions detection
  • anomalous event detection
  • active and passive surveillance
• Comprehensive logging and audit trails

9. Will the system produce sufficient audit trails?

• Purposes:
  • security incident procedures and response
  • security configuration management (i.e., making changes to the system so that no specific vulnerabilities are created)
  • assessing compliance with self-reporting and colleague-reporting requirements
  • responding to patient requests for access records
  • certification and accreditation
  • cooperation with law enforcement so as to meet statutory and administrative standards
• What data architecture is required
  • existing industry practice for logging
  • field-level logging?

10. If compliance is achieved in part by implementation of asymmetric encryption (public key infrastructure or PKI)

• what is the system for managing digital certificates
• is the public key infrastructure interoperable with that of business partners?

Return to top of page

Preliminary Checklist for Computer and Telecommunications Systems Purchases

Our clients have come to believe that legal planning -- describing a project, negotiating specifications, anticipating the inability to fulfill technical or performance claims -- is as integral to success as technical planning.

Negotiating a contract for a computer system, or for software, is - or should be - a systems planning process as much as it is an exercise in defining legal rights and duties. Inevitably, analysis will go hand-in-hand with pre-installation tasks, and the purchaser and vendor will learn significant new information about the purchaser's needs and how they must be fulfilled. In addition, contract negotiations are a means to identify problem areas, assign responsibilities and develop a framework for ferreting out problems so that they can be dealt with in a systematic way. In short, the aims of the contracting process are to:

• Explain the project to all parties, and develop an implementation plan;
• Furnish a process for discovering and accommodating the purchaser's new or changing requirements during the development and installation process;
• Supply a project management framework, including the means to adjust responsibilities and schedules as obstacles arise and as new needs are revealed;
• Preclude disputes, or specify a means for their quick resolution;
• Avoid litigation; and
• Establish a favorable litigation posture.

Consider the following questions when a project is initiated:

1. Will the system be crucial to business operations, or is it a subsidiary or support system whose operation, while important, can be foregone for a period of time?

2. Is it realistic to expect sustained parallel operation after the system is installed, or will an immediate or rapid cut-over to the new system be necessary? To what extent can the old system be retained as a short-term backup?

3. Is there a need for an RFP? If so, to what extent will the RFP contain preliminary criteria that will need to be refined either (a) between issuing the RFP and awarding the contract or (b) after the contract is negotiated and signed?

4. Are you buying both hardware and software? If so, will one vendor stand behind - and service - the whole system, or will you have to determine whether you are facing a hardware, software or telecommunications problem in order to decide which vendor to call?

5. If you are buying hardware, has the equipment been installed and used before in the same configuration, with the same communications facilities and for the same throughput?

6. Does the project require the tailoring of existing (or "off the shelf") software, or does it involve substantial software development?

7. What is the installation and implementation plan?

8. What is the installation and implementation schedule?

9. Who can change items 7 and 8, and by what process? How much flexibility is necessary to be able to modify items 7 and 8 as the project moves along?

10. How can system performance be described and tested? What performance is satisfactory?

11. Who is authorized on behalf of the vendor to make representations about the system's performance and capacity?

12. Who (or what group) is authorized on your behalf to agree to the contractual description of system performance, and to agree with the vendor to vary that description as the system is developed (or tailored), installed, activated and tested?

13. Is installation, including debugging, to be done at a fixed price or an hourly rate? Are installation and software development commingled, and is it essential to combine them? Is it feasible to separate them?

14. Will the project be installed and implemented in phases? If so, how will the phases be defined?

15. Will you specify both installation and acceptance tests for the project (or for each phase)?

16. How will "acceptance" be defined?

17. How can pricing be combined with installation and acceptance benchmarks to reinforce contract aims?

18. What protection is offered under warranty, and how does that relate to contracted maintenance?

19. If maintenance service is unsatisfactory, is a switch to third-party maintenance feasible?

20. Who owns the copyright to the software? (Was an independent contractor involved anywhere along the way?) How long can you use it? Who can debug, enhance or create new versions of it? Will you have the right to use enhancements and new versions?

21. Is software "lock-in" a problem and, if it is, how can it be dealt with?

22. Must the system be protected by security measures? If so, is the level of protection apparent, or is a threat analysis necessary? What legal standards govern the level of security? What level of security measures is realistic in terms of cost and the organization's culture? Is that level at odds with the governing legal standard?

23. Will the system be used in applications with the potential to create liability to third parties? If so, what prudently should be done to minimize that potential?

24. How will a breach be identified? What about identifying problems short of a breach? Will the opportunity to cure certain breaches be permitted?

25. In the event of breach, what remedies will be effective? What impact will proposed remedies have on the ability to conduct business?

26. When is the time to negotiate sensitive items? When does the purchaser have maximum leverage, and when is the purchaser's bargaining power gone?

27. How fair is the deal to both sides? Do both parties have incentives to follow the plan, or are there incentives to slow down, back out, or minimize performance

return to Publications main page