NCHICA - Contracts with Healthcare Cloud Computing Vendors


Published on

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

NCHICA - Contracts with Healthcare Cloud Computing Vendors

  1. 1. Contracting with the Healthcare Cloud Service Provider Workshop on Health Information in the Cloud: Business Strategy, Security and Deployment NC Healthcare Information and Communications Alliance March 2011 Randy Whitmeyer Whitmeyer Tuffin PLLC
  2. 2. Topics• Legal Backdrop• Cloud Computing v. Traditional IT Structures• The “Contract Circle”: • Selecting a Health Care IT Vendor • Negotiating Key Contract Terms • Dealing with Vendor Non-Performance
  3. 3. Legal Backdrop• HIPAA/HITECH Privacy and Security Rules• HITECH Meaningful Use• NC and other State Identity Theft Rules• NC Destruction of Personal Information Records Law• EU Data Protection Directive and Cross-Border Data Flows• PCI Rules• Electronic Discovery
  4. 4. Cloud Computing v.Traditional I.T. Structures
  5. 5. Graphic Courtesy of Hosted Solutions
  6. 6. Graphic Courtesy of Hosted Solutions
  7. 7. Cloud Computing Services• Software as a Service (SaaS)• Platform as a Service (PaaS)• Infrastructure as a Service (IaaS)
  8. 8. Cloud Computing and SecurityAdvantages Disadvantages• Data Dispersal • Lack of Transparency• Data Fragmentation • Lack of Responsiveness• “Tier 1” Data Centers • “Trading Market” of• Multiple Customer Demands Subcontractors • Vendor Lock-In• Easier Patching and Updates • Lack of Security Details
  9. 9. Cloud Computing Contract Structures• Typically service-based, not licensed• OPEX, not CAPEX• Often offered via “click and accept” agreements• Sometimes incorporate by reference other terms of use and policies• Sometimes purport to be changeable without notice by the vendor
  10. 10. Selecting the Cloud Computing Vendor: DueDiligence and Key Contract Terms
  11. 11. Keys to Selecting a Cloud Computing Vendor• Approach project realistically, in light of personnel, time and budget• Document your requirements • Obtain consultant as necessary• Remember the need for training on new systems and new processes • More realistic to adapt process to system than adapt system to process, in most cases• Perform due diligence on vendor. Rigorously check with other similar users on their experiences. Check certifications• Last but not least: enter into a good contract!!
  12. 12. Negotiation Ideas• Early on in discussions, alert vendor that you want certain key adjustments to contract terms, identifying the issues • If possible, use your own form of contract rather than vendor’s form• Try to keep multiple vendors in the process as long as possible to keep competitive pressure on both price and terms• Consider a formal RFP/response process for larger systems
  13. 13. Security and Privacy Terms• Confidentiality• Third-Party security audits• Right to review detailed security/disaster recovery policies• Obligation to maintain security and security policies• Right to audit and test security• Notification in the case of breach• Indemnification for breaches/payment of costs of required notices to customers• Encryption
  14. 14. Business Associate Agreement• Whose form of BAA? • NCHICA form, of course!• How much embellished?• How does it relate to other confidentiality, security and privacy provisions in contract?
  15. 15. Regulatory Issues• Certification by ONC-ATCB, such as CCHIT• Meaningful use criteria• Cooperation with certification and attestation• Timing of implementation
  16. 16. Other Key Data Issues• Ownership of Data• Disposition of Data on Termination• Location of Data• Legal / Government Request to Access Data
  17. 17. Service Level Agreements• Uptime• Performance & Response Time• Error Correction Time• Infrastructure / Security• Performance Credits• Use of Measurement Technology• Notice/Reporting Obligations
  18. 18. Pricing Terms• Monthly service fees • Per user or provider, or based on transactions? • When does it start?• Implementation fees • Commitment to start date?• Add-on pricing• Payment terms• Caps on increase in fees
  19. 19. Term & Termination• Length• Termination Penalties• Data Rights upon Termination• Vendor Termination or Suspension• Automatic Renewal
  20. 20. Warranties• Warranty to specifications and requirements • Avoid limited warranty to just documentation • Include key functional specifications as an appendix to the document. Sometimes can pull these straight from vendor’s web site• Warranty against noninfringement• Anti-virus warranty• Warranty that documentation is complete and gets updated with new releases in a timely fashion• Services warranty – vendor should use reasonable skill in accordance with industry standards, and supply qualified and experienced personnel
  21. 21. Third-Party Software/Services• Vendor will want to disclaim responsibility (e.g., for performance or IP issues) for third party software components of solution, especially open source• Buyer’s perspective: • I’m buying a solution, and it shouldn’t matter to me whether vendor chose to implement parts of the solution with third-party pieces• Resolution varies and is often fact-specific:• Well-known, off the shelf components more likely to be excluded
  22. 22. Support and Maintenance• Rights to new versions• Timeframes for responding to and fixing problems• Target/efforts versus commitment with financial repercussions
  23. 23. Intellectual Property• Proprietary software company will jealously guard ownership of its products• Dispute often arises over ownership of any custom developed IP, such as interfaces• Buyer’s argument: • I paid for it, I should own it• Vendor’s argument: • You are paying for accelerated development • I would never be able to have a product if each piece of custom IP was owned by the buyer• Possible compromises: • Exclusive use for a period of time • Sharing in royalties
  24. 24. Other Terms • Modification of Contract• Acceptance Terms/Procedures • Assignability• Limitations of Liability • Choice of Law/Jurisdiction• Indemnification • Subcontractor approval• Insurance • Source Code escrow
  25. 25. Project Failure (The typical scenario)• Buyer: The service is late, has not been delivered at all, or has excessive errors• Vendor: Buyer unilaterally expanded the scope of the project, or failed to understand the service and its effect on the practice.
  26. 26. Project Failure (Buyer’s Perspective)• Strategies: • Document problems early and often, and communicate to Vendor • Avoid unduly flattering emails; always come back to haunt in dispute situations • Send formal notice of breach • Provide opportunity to cure • Withholding payment: must be done carefully
  27. 27. Project Failure (Vendor’s Perspective)• Document changes in scope/obtain agreement• Document unforeseen technical issues• Consider when/if to withhold software/services, if unpaid
  28. 28. Key Takeaways• Due Diligence is critical when choosing Cloud Computing Vendors . This includes not only direct questioning but also third-party review such as dun and bradstreet reports, ongoing litigation review, and merger activity.• Insist on transparency• Risk can vary depending on type of data involved and type of cloud• Form contracts rarely handle key issues satisfactorily
  29. 29. Any questions? Randy WhitmeyerWhitmeyer - Tuffin PLLC 919-880-6880