Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What do Secure, HIPAA Compliant, Clouds Mean to...

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

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

Shahid N. Shah

July 14, 2011
Tweet

More Decks by Shahid N. Shah

Other Decks in Technology

Transcript

  1. What do Secure, HIPAA Compliant, Clouds Mean to SOA in

    Healthcare? By Shahid N. Shah, CEO www.HealthcareGuy.com
  2. 2 www.netspective.com 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 non- profit) Author of Chapter 13, “You’re the CIO of your Own Office”
  3. 3 www.netspective.com 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
  4. 5 www.netspective.com 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).
  5. 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
  6. 7 www.netspective.com Most important considerations Participants (Specific) • Covered Entities

    [CE] (plans, providers, clearinghouses) • Business Associates [BA] (needs data to help a CE) Safeguards (Guidance) • Administrative • Physical • Technical http://www.cms.gov/HIPAAGenInfo/06_AreYouaCoveredEntity.asp http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/businessassociates.html http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule
  7. 8 www.netspective.com 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)
  8. 9 www.netspective.com 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 non- standard 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.
  9. 10 www.netspective.com 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.
  10. 12 www.netspective.com 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)
  11. 13 www.netspective.com Administrative Safeguards Standards Section Implementation Specifications | (R)

    = Required, (A) = Addressable Security Management Process 164.308(a)(1) Risk Analysis (R) Risk Management. (R) Sanction Policy (R) Information System Activity Review (R) Assigned Security Responsibility 164.308(a)(2) (R) Workforce Security 164.308(a)(3) Authorization and/or Supervision (A) Workforce Clearance Procedure (A) Termination Procedures (A) Information Access Management 164.308(a)(4) Isolating Healthcare Clearinghouse Function (R) Access authorization (A) Access Establishment and Modification (A) Security Awareness and Training 164.308(a)(5) Security Reminders (A) Protection from Malicious Software (A) Log-in Monitoring (A) Password Management (A) Security Incident Procedures 164.308(a)(6) Response and Reporting (R) Contingency Plan 164.308(a)(7) Data Backup Plan (R) Disaster Recovery Plan (R) Emergency Mode Operation Plan (R) Testing and Revision Procedure (A) Applications and Data Criticality Analysis (A) Source: HHS, Walsh summary
  12. 14 www.netspective.com Physical Safeguards Standards Section Implementation Specifications (R) =

    Required, (A) = Addressable Facility Access Controls 164.310(a)(1) Contingency Operations (A) Facility Security Plan (A) Access Control and Validation Procedures (A) Maintenance Records (A) Workstation Use 164.310(b) (R) Workstation Security 164.310(c) (R) Device and Media controls 164.310(d)(1) Disposal (R) Media Re-use (R) Accountability (A) Data backup and Storage (A) Source: HHS, Walsh summary
  13. 15 www.netspective.com Technical Safeguards Standards Section Implementation Specifications (R) =

    Required, (A) = Addressable Access Control 164.312(a)(1) Unique User Identification (R) Emergency Access Procedure (R) Automatic Logoff (A) Encryption and Decryption (A) Audit Controls 164.312(b) (R) Integrity 164.312(c)(1) Mechanism to Authenticate Electronic PHI (A) Person or Entity authentication 164.312(d) (R) Transmission Security 164.312(e)(1) Integrity Controls (A) Encryption (A) Source: HHS, Walsh summary
  14. 16 www.netspective.com 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
  15. 18 www.netspective.com 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 – … Source: Attachmate
  16. 19 Recap of Service Orientation Between Companies Between Divisions Between

    Apps Within Apps Trading Partner Integration System Integration Application Integration SODA Service Infrastructure 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. Service Invocation Enterprise Service Bus Routing & Transformation Discovery & Directory Security & Authentication Service Categories Process Services Activity Services Entity Services Data Services
  17. 23 www.netspective.com • Function oriented • Build to last •

    Prolonged development cycles From To • Coordination oriented • Build to change • Incrementally built and deployed  Application silos  Tightly coupled  Object oriented  Known implementation  Enterprise solutions  Loosely coupled  Message oriented  Abstraction Source: Microsoft (Modified) Expectations of SOA in the Cloud
  18. From Components to SOA in the Cloud • Requires a

    client library • Client / Server • Extendable • Stateless • Fast • Small to medium granularity • Loose coupling via – Message exchanges – Policies • Peer-to-peer • Composable • Context independent • Some overhead • Medium to coarse granularity
  19. 25 www.netspective.com 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?
  20. 26 www.netspective.com 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. 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.
  21. 27 www.netspective.com The Cloud is Nothing New Single Computer Mainframes

    with terminals Client/Server Computing Network Computing Cloud Computing 1960 1970 1990 2000 2012 Complexity Time Distributed Centralized
  22. 31 www.netspective.com Not all Clouds Are Created Equal Cloud Technology

    Can I get out as easily as I get in? Company How financially strong is the company? Likelihood of being acquired? Survive downturns? Can it compete long term? Processes Is security tacked- on or built-in? Do they understand HIPAA?
  23. 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)
  24. 33 NIST Cloud Models in Health Systems Public Internet (TIC)

    Cloud Sourcing Models Outsourced Health System Trust (Security and Data Privacy) High Low Private Commercially Hosted Cloud Public Cloud Health Info Exchange (HIE) Cloud Dedicated Health System Network (VPN, TIC) Private Health System Cloud Hybrid Health System Cloud Source: NIST
  25. 34 Applications in the Hybrid Cloud Cloud Routine Applications Critical

    Applications HIGH LOW Security Requirements Business Applications DR Document Management Conventional business applications with: • Patient Data • Employee Information • Financial Information • Customer Information • Government Financials and Planning Mission Critical/ OLTP On Premises (traditional) Web Analytics and Reporting Software Development/ Test Mail and Collaboration Source: UNISYS
  26. 35 Health Apps in the Secure Cloud Cloud Routine Applications

    Critical Applications HIGH LOW Security Requirements Business Applications DR Document Management Conventional business applications with: • Patient Data • Employee Information • Financial Information • Customer Information • Government Financials and Planning Mission Critical/ OLTP Traditional Web Analytics and Reporting Software Development/ Test Mail and Collaboration HIGH LOW Security Requirements Web DR Conventional business applications with: • Patient Data • Employee Information • Financial Information • Customer Information • Government Analytics and Reporting Financials and Planning Document Management Mission Critical/ OLTP Software Development/ Test Mail and Collaboration Routine Applications Critical Applications Business Applications Cloud Secure Cloud for Regulated & Protected Health Info Traditional Source: UNISYS
  27. 36 www.netspective.com Where Hype meets Reality Does it make economic

    sense? How will we handle security and compliance? How will we handle legal matters? Will there be a “big switch”? Once we’re in, how do we get out? (portability) How do we interoperate with our existing “stuff”? What happens when the Network fails?
  28. 37 www.netspective.com 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.
  29. 38 www.netspective.com 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.
  30. 39 www.netspective.com Benefits of SOA in the Cloud Potential (Direct)

    Business Benefits Acceleration of business process automation and optimization Direct business benefits are difficult to measure so an SOA project needs to know the goals ahead of time. Increased capability to support M&A activity and trading partner integration Better reactivity of IT regarding new business requirements Potential (Indirect) Technology Benefits Reuse of functionality and interfaces Indirect technology benefits should be seen as tangible and not just guesses. Decoupling of architecture building blocks Reduction of architecture complexity
  31. 40 www.netspective.com How to Ensure SOA is Working SOA IT

    Driver Reuse of functionality and interfaces Reduced effort for connecting to functionality Reduced effort for new interfaces Less errors in acceptance tests Reduced downtime in operation Decoupling of architecture building blocks Easier replacement of components Faster releases through independence Reduction of complexity of architecture as a whole Faster IT delivery of new requirements Reduced testing efforts Better performance and improved SLA Better forward engineering and CM
  32. 41 www.netspective.com 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 Easier replacement of components Collect maintenance effort Setup interdependencies matrix Setup IT architecture management Continuously Measure and report efficiency Faster delivery of new functionality Measure IT phases for each major requirement Conduct satisfaction surveys Make each phase measurable Continuously survey and report
  33. 43 www.netspective.com Case Study: PACS / Image Archiving •Single copy

    of data •Secondary copy nearby •Business continuity during PACS outage Disaster Recovery & Business Continuity •Audits •Abiding by HIPAA/ HITECH guidelines • Internal & external security threats Compliance • No visibility into storage consumption • Inefficient storage tiers • A lot to maintain – hw, sw, security, etc. Storage Management •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 Archiving Costs Storage Related Costs
  34. 44 www.netspective.com Modality PACS Local Storage Image Archive(s) Symantec Gateway

    Symantec Data Centers • PACS transmits images to and from the Gateway using DICOM • Optimizes bandwidth and minimizes PACS latency • PACS workflow and performance remains intact • Image transmission over the Internet using HTTP over SSL • Encryption secures at-rest images (AES-256) Case Study: Symantec Medical Data Archiving and Sharing
  35. 45 www.netspective.com Case Study: Symantec Health Cloud Benefits •Redundant copies

    in different states •Highly available •Retrieve to PACS •Instant access to images Disaster Recovery & Business Continuity •Meets HIPAA privacy & security guidelines •Audit logs of all sharing activity • Highest levels of security on all vectors Compliance •In-depth storage analytics •Enables efficient storage tiering •No management overhead Storage Management •Secure online image sharing •Eliminates CD incompatibility & security issues • No downloads or training required Data Access & Sharing •Low price per TB can reduce archiving costs by 50 % •No excess capacity • A single, predictable quarterly service fee Archiving Costs
  36. 46 www.netspective.com Additional Cloud Benefit: Centralized Image Sharing (real collaboration)

    Hospital Specialty Clinic Physician Office Imaging Center Radiology Group Centralized Image Sharing