What do Secure, HIPAA Compliant, Clouds Mean to SOA in Healthcare?


Published on

Technical discussion about service oriented architecture (SOA) and HIPAA compliant clouds. This talk was presented at the Object Management Group's (OMG) SOA in Healthcare working group in the Summer of 2011. It covered the following major topics:
* What does HIPAA mean in the cloud?
* Are cloud providers covered by HIPAA?
* Cloud safeguards that can meet HIPAA requirements
* Healthcare SOA In the cloud

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

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

No notes for slide

What do Secure, HIPAA Compliant, Clouds Mean to SOA in Healthcare?

  1. 1. What do Secure, HIPAA Compliant, Clouds Mean to SOA in Healthcare? By Shahid N. Shah, CEO www.HealthcareGuy.com
  2. 2. Who is Shahid? • 20+ years of software engineering and multi-site healthcare system deployment experience • 12+ years of healthcare IT and medical devices experience (blog at http://healthcareguy.com) • 15+ years of technology management experience (government, non-profit, commercial) • 10+ years as architect, engineer, and implementation manager on various EMR and EHR initiatives (commercial and nonprofit) www.netspective.com Author of Chapter 13, “You’re the CIO of your Own 2 Office”
  3. 3. Agenda What does HIPAA mean in the cloud? Are cloud providers covered by HIPAA? Cloud safeguards that can meet HIPAA requirements Healthcare SOA In the cloud www.netspective.com 3
  5. 5. What does HIPAA compliance mean? The rules: – http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule – http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule – http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/securityrulepdf.pdf Read the rules, don’t take anyone else’s informal legal opinion (these are federal regulations). www.netspective.com 5
  6. 6. Protected Health Information (PHI) • Name • Address -- street address, city, county, zip code (more than 3 digits) or other geographic codes • Dates directly related to patient • Telephone Number • Fax Number • email addresses • Social Security Number • Medical Record Number • Health Plan Beneficiary Number • Account Number • Certificate/License Number • Any vehicle or device serial number • Web URL, Internet Protocol (IP) Address • Finger or voice prints • Photographic images • Any other unique identifying number, characteristic, or code (whether generally available in the public realm or not) • Age greater than 89 (due to the 90 year old and over population is relatively small) http://www.ibm.com/developerworks/industry/library/ind-findpii/index.html
  7. 7. Most important considerations Participants (Specific) • Covered Entities [CE] (plans, providers, clearinghouses) • Business Associates [BA] (needs data to help a CE) http://www.cms.gov/HIPAAGenInfo/06_AreYouaCoveredEntity.asp Safeguards (Guidance) • Administrative • Physical • Technical http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/businessassociates.html www.netspective.com 7
  8. 8. Are cloud providers BAs? • A “business associate” is a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity. • A member of the covered entity’s workforce is not a business associate. A covered health care provider, health plan, or health care clearinghouse can be a business associate of another covered entity. • BAA: A covered entity’s contract or other written arrangement with its business associate must contain the elements specified at 45 CFR 164.504(e) www.netspective.com 8
  9. 9. HHS examples of BAs • A third party administrator that assists a health plan with claims processing. • A CPA firm whose accounting services to a health care provider involve access to protected health information. • An attorney whose legal services to a health plan involve access to protected health information. • A consultant that performs utilization reviews for a hospital. • A health care clearinghouse that translates a claim from a nonstandard format into a standard transaction on behalf of a health care provider and forwards the processed transaction to a payer. • An independent medical transcriptionist that provides transcription services to a physician. • A pharmacy benefits manager that manages a health plan’s pharmacist network. www.netspective.com 9
  10. 10. HHS examples when BAA is not required • With persons or organizations (e.g., janitorial service or electrician) whose functions or services do not involve the use or disclosure of protected health information, and where any access to protected health information by such persons would be incidental, if at all. • With a person or organization that acts merely as a conduit for protected health information, for example, the US Postal Service, certain private couriers, and their electronic equivalents. www.netspective.com 10
  12. 12. Required vs. Addressable Controls If a control is addressable, cloud providers can: • Implement it if it is reasonable and appropriate • Implement an equivalent measure, if that is reasonable and appropriate • Not implement it at all Cloud providers can assess if an implementation specification is reasonable and appropriate based upon factors such as: • Risk analysis and mitigation strategy • Current security controls in place • Costs of implementation (to an extent) www.netspective.com 12
  13. 13. Administrative Safeguards Standards Section Implementation Specifications | (R) = Required, (A) = Addressable Security Management Process 164.308(a)(1) Risk Analysis Risk Management. Sanction Policy Information System Activity Review Assigned Security Responsibility 164.308(a)(2) Workforce Security 164.308(a)(3) Authorization and/or Supervision Workforce Clearance Procedure Termination Procedures (A) (A) (A) Information Access Management 164.308(a)(4) Isolating Healthcare Clearinghouse Function (R) Access authorization Access Establishment and Modification (A) (A) (R) (R) (R) (R) (R) Security Awareness and Training 164.308(a)(5) Security Reminders Protection from Malicious Software Log-in Monitoring Password Management (A) (A) (A) (A) Security Incident Procedures 164.308(a)(6) Response and Reporting (R) Contingency Plan 164.308(a)(7) Data Backup Plan Disaster Recovery Plan Emergency Mode Operation Plan Testing and Revision Procedure Applications and Data Criticality Analysis (R) (R) (R) (A) (A) www.netspective.com Source: HHS, Walsh summary 13
  14. 14. Physical Safeguards Standards Section Implementation Specifications (R) = Required, (A) = Addressable Facility Access Controls 164.310(a)(1) Contingency Operations Facility Security Plan Access Control and Validation Procedures Maintenance Records Workstation Use 164.310(b) (R) Workstation Security 164.310(c) (R) Device and Media controls 164.310(d)(1) www.netspective.com Disposal Media Re-use Accountability Data backup and Storage Source: HHS, Walsh summary (A) (A) (A) (A) (R) (R) (A) (A) 14
  15. 15. Technical Safeguards Standards Section Implementation Specifications (R) = Required, (A) = Addressable Access Control 164.312(a)(1) Unique User Identification Emergency Access Procedure Automatic Logoff Encryption and Decryption Audit Controls 164.312(b) Integrity 164.312(c)(1) Person or Entity authentication 164.312(d) Transmission Security 164.312(e)(1) www.netspective.com (R) (R) (A) (A) (R) Mechanism to Authenticate Electronic PHI (A) (R) Integrity Controls Encryption Source: HHS, Walsh summary (A) (A) 15
  16. 16. MU Privacy, Security, Transport Standards Item Standard Encryption and decryption of electronic health information NIST FIPS 140-2 Record actions related to electronic health information The date, time, patient identification, and user identification must be recorded when electronic health information is created, modified, accessed, or deleted; and an indication of which action(s) occurred and by whom must also be recorded Verification that electronic health information has not been altered in transit SHA-1 or higher (NIST FIPS PUB 180-3) Record treatment, payment, and health care operations disclosures The date, time, patient identification, user identification, and a description of the disclosure must be recorded for disclosures for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501 Transport REST, DDS, XMPP www.netspective.com 16
  18. 18. What we expect from “real” services • • • • • • • Well defined, easy-to-use, somewhat standardized interface Self-contained with no visible dependencies to other services (almost) Always available but idle until requests come “Provision-able” Easily accessible and usable readily, no “integration” required Coarse grain Independent of consumer context, – but a service can have a context • New services can be offered by combining existing services • Quantifiable quality of service – – – – Do not compete on “What” but “How” Performance/Quality Cost … www.netspective.com Source: Attachmate 18
  19. 19. Recap of Service Orientation Service orientation is not a technology you can buy and deploy but a way of architecting and designing distributed systems. Service orientation means different things to different people, especially in the cloud. Between Companies Between Divisions Between Apps Within Apps Trading Partner Integration System Integration Application Integration SODA Service Infrastructure Enterprise Service Bus Routing & Transformation Discovery & Directory Security & Authentication Service Categories Process Services Activity Services Entity Services Data Services Service Invocation 19
  20. 20. Recap of SOA Reference Architecture www.netspective.com 20
  21. 21. SOA & Cloud are about integration Source: Geoffrey Raines, MITRE 21
  22. 22. Cloud and SOA Overlap Source: Geoffrey Raines, MITRE 22
  23. 23. Expectations of SOA in the Cloud From • • • To Function oriented Build to last Prolonged development cycles • • • Application silos  Tightly coupled  Object oriented  Known implementation   www.netspective.com Coordination oriented Build to change Incrementally built and deployed Enterprise solutions  Loosely coupled  Message oriented  Abstraction Source: Microsoft (Modified) 23
  24. 24. From Components to SOA in the Cloud • Requires a client library • Loose coupling via – Message exchanges – Policies • Client / Server • Extendable • Stateless • Peer-to-peer • Composable • Context independent • Fast • Small to medium granularity • Some overhead • Medium to coarse granularity
  25. 25. What keeps health IT folks up at night Meaningful Use is reprioritizing everything Legacy systems utilize very little resources but consume lots of hardware Our infrastructure and network is held hostage by legacy requirements I have lots of data, but not enough analytics Not sure how we’re going to manage user provisioning across so many apps How will we implement HIPAA 5010 and ICD10? www.netspective.com 25
  26. 26. How can the cloud achieve SOA goals? Infinite Storage You’re generating more data than you can handle; but, there are specialists that can do that for you. Hardware Utilization Go from 20% average utilization on fixed assets to pay as you go with hardware on demand. www.netspective.com Infrastructure Maintenance Move IT resources from infrastructure maintenance to higher-value customer-facing tasks. New Deployments Deploy software faster to more workstations and with fewer IT resources. 26
  27. 27. The Cloud is Nothing New 2000 Complexity 1990 1970 2012 Network Computing Cloud Computing Client/Server Computing Mainframes with terminals Single 1960 Computer Time Centralized www.netspective.com Distributed 27
  28. 28. Beware of Cloud Washing Not everything is really a “Cloud” something www.netspective.com Image source: http://infreemation.net/cloud-computing-linear-utility-or-complex-ecosystem 28
  29. 29. Nothing to fear, it’s Hosting Evolved www.netspective.com 29
  30. 30. The Promise of Clouds www.netspective.com Source: http://www.slideshare.net/markusslideshare/do-clouds-compute-a-framework-forestimating-the-value-of-cloud-computing-presentation 30
  31. 31. Not all Clouds Are Created Equal Technology Can I get out as easily as I get in? How financially strong is the company? Cloud Company Likelihood of being acquired? Survive downturns? Can it compete long term? Is security tackedon or built-in? Processes Do they understand HIPAA? www.netspective.com 31
  32. 32. How to Buy Cloud Computing Services IaaS Infrastructure as a Service Renting use of computing power or storage over the Internet (e.g., Symantec hosted services (70 Petabytes of hosted data), Amazon’s EC2 & S3) PaaS Platform as a Service Renting use of an application environment over the Internet (e.g., Google App Engine, Symantec Health) SaaS Software as a Service Renting execution of software solutions over the Internet (e.g., salesforce.com, Symantec Health Image Share and Analytics Tools) 32
  33. 33. NIST Cloud Models in Health Systems Outsourced Cloud Sourcing Models Health System High Trust (Security and Data Privacy) Private Commercially Hosted Cloud Public Cloud Public Internet (TIC) Dedicated Health System Network (VPN, TIC) Private Health System Cloud Health Info Exchange (HIE) Cloud Hybrid Health System Cloud Low Source: NIST 33
  34. 34. Applications in the Hybrid Cloud Cloud On Premises (traditional) HIGH Mail and Collaboration Conventional business applications with: Document Management Financials and Planning • Patient Data Analytics and Reporting Security Requirements • Employee Information • Financial Information DR • Customer Information Web Mission Critical/ OLTP • Government Software Development/ Test LOW Routine Applications Business Applications Critical Applications Source: UNISYS 34
  35. 35. Health Apps in the Secure Cloud Cloud Traditional Secure Cloud for Regulated & Protected Health Info Traditional HIGH Mail and Collaboration Conventional business applications with: Document Management Financials and Planning • Patient Data Analytics and Reporting Security Requirements Web • Employee Information • Financial Information • Customer Information DR Mission Critical/ OLTP • Government Software Development/ Test LOW Routine Applications Critical Applications Business Applications Source: UNISYS 35
  36. 36. Where Hype meets Reality What happens when the Network fails? Does it make economic sense? Once we’re in, how do we get out? (portability) How will we handle legal matters? How will we handle security and compliance? www.netspective.com Will there be a “big switch”? How do we interoperate with our existing “stuff”? 36
  37. 37. SOA in Cloud Hype & Misconceptions • Vendors first replaced “web services” terminology with “SOA” and now “Cloud” • Once you implement a web service, it does not mean you have an SOA. • An SOA should not be the goal: a loosely coupled IT system that enables new business models and revenue/cost savings opportunities is the goal. • There is no need to turn working code into services unless there is a need to connect in a way that would improve the business. • SOA is not for “average” teams. It takes very smart engineers and architects to develop a useful SOA with a good ROI. www.netspective.com 37
  38. 38. SOA in Cloud Hype & Misconceptions • You can not buy an SOA. SOA is almost an emergent property of a system that is designed with service orientation in mind. – Loose coupling, developing against schema rather than types, using open protocols, black boxing your functionality • Asynchronous services that are loosely coupled are not easier to write, they are actually harder (but worth it). • Versioning and deployment of loosely coupled services are not always easier than monolithic systems. • Reliability of services is still hard, especially with multiple Cloud providers and internal data centers. www.netspective.com 38
  39. 39. Benefits of SOA in the Cloud Acceleration of business process automation and optimization Potential (Direct) Business Benefits Increased capability to support M&A activity and trading partner integration Better reactivity of IT regarding new business requirements Direct business benefits are difficult to measure so an SOA project needs to know the goals ahead of time. Reuse of functionality and interfaces Potential (Indirect) Technology Benefits Decoupling of architecture building blocks Indirect technology benefits should be seen as tangible and not just guesses. Reduction of architecture complexity www.netspective.com 39
  40. 40. How to Ensure SOA is Working Reduced effort for connecting to functionality Reuse of functionality and interfaces Reduced effort for new interfaces Less errors in acceptance tests Reduced downtime in operation SOA IT Driver Decoupling of architecture building blocks Reduction of complexity of architecture as a whole www.netspective.com Easier replacement of components Faster releases through independence Faster IT delivery of new requirements Reduced testing efforts Better performance and improved SLA Better forward engineering and CM 40
  41. 41. Sample of How to Measure SOA ROI Measure Data to collect Implementation Reduced effort for connecting functionality Collect development and maintenance effort Document reuse plan vs. actual Harmonize and define structures and processes Collect maintenance effort Setup interdependencies matrix Setup IT architecture management Continuously Measure and report efficiency Easier replacement of components Faster delivery of new functionality Measure IT phases for each Make each major requirement phase measurable Conduct satisfaction surveys Continuously survey and report www.netspective.com 41
  42. 42. The Government is Vetting Vendors 42
  43. 43. Case Study: PACS / Image Archiving • Single copy of data • Secondary copy nearby • Business continuity during PACS outage • Audits • Abiding by HIPAA/ HITECH guidelines • Internal & external security threats Disaster Recovery & Business Continuity Compliance • Inability to access data when & where needed • CD/DVD headaches • Concerns over data loss Data Access & Sharing • Study sizes growing • Number of images increasing • Storage growth exploding • No visibility into storage consumption • Inefficient storage tiers • A lot to maintain – hw, sw, security, etc. Storage Management Storage Related Costs Archiving Costs www.netspective.com 43
  44. 44. Case Study: Symantec Medical Data Archiving and Sharing • PACS transmits images to and from the Gateway using DICOM • Optimizes bandwidth and minimizes PACS latency • PACS workflow and performance remains intact Modality Symantec Data Centers PACS Symantec Gateway • • Local Storage Image transmission over the Internet using HTTP over SSL Encryption secures at-rest images (AES-256) Image Archive(s) www.netspective.com 44
  45. 45. Case Study: Symantec Health Cloud Benefits • Redundant copies in different states • Highly available • Retrieve to PACS • Instant access to images • Meets HIPAA privacy & security guidelines • Audit logs of all sharing activity • Highest levels of security on all vectors Disaster Recovery & Business Continuity • Secure online image sharing • Eliminates CD incompatibility & security issues • No downloads or training required Data Access & Sharing Compliance • In-depth storage analytics • Enables efficient storage tiering • No management overhead Storage Management • Low price per TB can reduce archiving costs by 50 % • No excess capacity • A single, predictable quarterly service fee Archiving Costs www.netspective.com 45
  46. 46. Additional Cloud Benefit: Centralized Image Sharing (real collaboration) Centralized Image Sharing Specialty Clinic Hospital Physician Office www.netspective.com Imaging Center Radiology Group 46
  47. 47. Questions? CONCLUSION