What do Secure, HIPAA Compliant, Clouds Mean to SOA in Healthcare? By Shahid N. Shah, CEO

Transcription

1 What do Secure, HIPAA Compliant, Clouds Mean to SOA in Healthcare? By Shahid N. Shah, CEO

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 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) Author of Chapter 13, You re the CIO of your Own Office 2

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 3

4 HIPAA DISCUSSION

5 What does HIPAA compliance mean? The rules: Read the rules, don t take anyone else s informal legal opinion (these are federal regulations). 5

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 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)

7 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

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 (e) 8

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. 9

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. 10

11 CLOUD SAFEGUARDS

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) 12

13 Administrative Safeguards Standards Section Implementation Specifications (R) = Required, (A) = Addressable Security Management Process (a)(1) Risk Analysis (R) Risk Management. (R) Sanction Policy (R) Information System Activity Review (R) Assigned Security Responsibility (a)(2) (R) Workforce Security (a)(3) Authorization and/or Supervision (A) Workforce Clearance Procedure (A) Termination Procedures (A) Information Access Management (a)(4) Isolating Healthcare Clearinghouse Function (R) Access authorization (A) Access Establishment and Modification (A) Security Awareness and Training (a)(5) Security Reminders (A) Protection from Malicious Software (A) Log-in Monitoring (A) Password Management (A) Security Incident Procedures (a)(6) Response and Reporting (R) Contingency Plan (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 13

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

15 Technical Safeguards Standards Section Implementation Specifications (R) = Required, (A) = Addressable Access Control (a)(1) Unique User Identification (R) Emergency Access Procedure (R) Automatic Logoff (A) Encryption and Decryption (A) Audit Controls (b) (R) Integrity (c)(1) Mechanism to Authenticate Electronic PHI (A) Person or Entity authentication (d) (R) Transmission Security (e)(1) Integrity Controls (A) Encryption (A) Source: HHS, Walsh summary 15

16 MU Privacy, Security, Transport Standards Item Encryption and decryption of electronic health information Record actions related to electronic health information Verification that electronic health information has not been altered in transit Record treatment, payment, and health care operations disclosures Transport Standard NIST FIPS 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 SHA-1 or higher (NIST FIPS PUB 180-3) 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 REST, DDS, XMPP 16

17 HEALTHCARE SOA IN THE CLOUD

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 Source: Attachmate 18

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 Invocation Service Categories Process Services Activity Services Entity Services Data Services 19

20 Recap of SOA Reference Architecture 20

21 SOA & Cloud are about integration Source: Geoffrey Raines, MITRE 21

22 Cloud and SOA Overlap Source: Geoffrey Raines, MITRE 22

23 Expectations of SOA in the Cloud From Function oriented Build to last Prolonged development cycles 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) 23

24 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

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? 25

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. 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 The Cloud is Nothing New Complexity Mainframes with terminals Client/Server Computing Network Computing Cloud Computing 1960 Single Computer Centralized Time Distributed 27

28 Beware of Cloud Washing Not everything is really a Cloud something Image source: 28

29 Nothing to fear, it s Hosting Evolved 29

30 The Promise of Clouds Source: 30

31 Not all Clouds Are Created Equal Technology Can I get out as easily as I get in? Cloud Company How financially strong is the company? Can it compete long term? Likelihood of being acquired? Survive downturns? Is security tackedon or built-in? Processes Do they understand HIPAA? 31

32 How to Buy Cloud Computing Services IaaS PaaS 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) 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 NIST Cloud Models in Health Systems Outsourced Cloud Sourcing Models Health System High Trust (Security and Data Privacy) Public Cloud Private Commercially Hosted Cloud Public Internet (TIC) Dedicated Health System Network (VPN, TIC) Health Info Exchange (HIE) Cloud Private Health System Cloud Hybrid Health System Cloud Low Source: NIST 33

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 Security Requirements Web Analytics and Reporting Employee Information Financial Information Customer Information Government DR Mission Critical/ OLTP Software Development/ Test LOW Routine Applications Business Applications Critical Applications Source: UNISYS 34

35 Health Apps in the Secure Cloud HIGH Cloud Secure Cloud for Regulated Traditional & Protected Health Info Traditional Mail and Collaboration Conventional business applications with: Patient Data Document Management Financials and Planning Security Requirements Analytics and Reporting Web Employee Information Financial Information Customer Information Government DR Mission Critical/ OLTP Software Development/ Test LOW Routine Applications Business Applications Critical Applications Source: UNISYS 35

36 Where Hype meets Reality What happens when the Network fails? Does it make economic sense? How will we handle legal matters? Once we re in, how do we get out? (portability) How will we handle security and compliance? Will there be a big switch? How do we interoperate with our existing stuff? 36

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. 37

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. 38

39 Benefits of SOA in the Cloud Potential (Direct) Business Benefits Acceleration of business process automation and optimization 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. Potential (Indirect) Technology Benefits Reuse of functionality and interfaces Decoupling of architecture building blocks Reduction of architecture complexity Indirect technology benefits should be seen as tangible and not just guesses. 39

40 How to Ensure SOA is Working SOA IT Driver Reuse of functionality and interfaces Decoupling of architecture building blocks Reduction of complexity of architecture as a whole Reduced effort for connecting to functionality Reduced effort for new interfaces Less errors in acceptance tests Reduced downtime in operation 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 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 Faster delivery of new functionality Collect maintenance effort Setup interdependencies matrix Measure IT phases for each major requirement Conduct satisfaction surveys Setup IT architecture management Continuously Measure and report efficiency Make each phase measurable Continuously survey and report 41

42 The Government is Vetting Vendors 42

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 No visibility into storage consumption Inefficient storage tiers A lot to maintain hw, sw, security, etc. Disaster Recovery & Business Continuity Compliance Storage Management Inability to access data when & where needed CD/DVD headaches Concerns over data loss Study sizes growing Number of images increasing Storage growth exploding Storage Related Costs Data Access & Sharing Archiving Costs 43

44 Case Study: Symantec Medical Data Archiving and Sharing Modality PACS transmits images to and from the Gateway using DICOM Optimizes bandwidth and minimizes PACS latency PACS workflow and performance remains intact Symantec Data Centers PACS Symantec Gateway Local Storage Image Archive(s) Image transmission over the Internet using HTTP over SSL Encryption secures at-rest images (AES-256) 44

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 In-depth storage analytics Enables efficient storage tiering No management overhead Disaster Recovery & Business Continuity Compliance 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 45

46 Additional Cloud Benefit: Centralized Image Sharing (real collaboration) Centralized Image Sharing Hospital Specialty Clinic Physician Office Imaging Center Radiology Group 46

47 Questions? CONCLUSION