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

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

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

4. HIPAA DISCUSSION

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

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)
www.netspective.com
12

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

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
…
www.netspective.com
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
Categories
Process
Services
Activity
Services
Entity
Services
Data
Services
Service
Invocation
19

20. Recap of SOA Reference Architecture
www.netspective.com
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
•
•
•
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. 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. 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. 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. 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. 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. Nothing to fear, it’s Hosting Evolved
www.netspective.com
29

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
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. 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. 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. 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. Questions?
CONCLUSION