Service oriented architecture (SOA) deserves service oriented data

Service Oriented Architecture
Deserves Service Oriented Data
Monolithic databases are just as bad as monolithic
applications - how can data make a difference?
By Shahid N. Shah, CEO

View Slide

NETSPECTIVE
www.netspective.com 3
Who is Shahid?
• 20+ years of software engineering and multi-
discipline complex IT implementations (Gov.,
defense, health, finance, insurance)
• 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”

View Slide

When does data matter?
Only when we use it.

View Slide

When will we use the data?
When we can trust it.
When we can access it.

View Slide

When will we trust the data?
When it doesn’t “suck”. 

View Slide

How do we know data doesn’t “suck”?
When it’s “actionable” – or probably
when we can use it to make decisions
based on it (e.g. for jobs to be done,
workflow, etc.).

View Slide

Can’t I just wait to use data
until it doesn’t suck?
Nope.

View Slide

What are we supposed to do?
Treat data like code.
Fix broken windows.

View Slide

Unused data never gets better.
Iterate your way to better
data by forcing its use.

View Slide

NETSPECTIVE
Application focus is biggest mistake
Application-focused IT instead of Data-focused IT is causing business problems.
Healthcare Provider Systems
Clinical
Apps
Patient
Apps
Billing
Apps
Lab
Apps
Other
Apps
Partner Systems
Silos of information exist across
groups (duplication, little sharing)
Poor data integration across
application bases

View Slide

NETSPECTIVE
NEJM believes doctors are trapped
It is a widely accepted myth that medicine requires
complex, highly specialized information-technology (IT)
systems.
This myth continues to justify soaring IT costs,
burdensome physician workloads, and stagnation in
innovation — while doctors become increasingly bound
to documentation and communication products that are
functionally decades behind those they use in their
“civilian” life.
New England Journal of Medicine “Escaping the EHR Trap - The Future of Health IT”, June 2012

View Slide

NETSPECTIVE
Real world requirement: Reduce heart failure readmissions
Allocating scarce resources in real-time to reduce heart
failure readmissions: a prospective, controlled study
http://qualitysafety.bmj.com/content/early/2013/07/31/bmjqs-2013-001901.full
“This study provides preliminary evidence that technology
platforms that allow for automated EMR data extraction, case
identification and risk stratification may help potentiate the effect
of known readmission reduction strategies, in particular those that
emphasize intensive and early post-discharge outpatient contact.”

View Slide

NETSPECTIVE
The business needs
• Quality and performance
metrics
• Patient stratification
• Care coordination
• Population management
• Surveys and other direct-
from-patient data collection
• Evidence-based surveillance
The technology strategy
• Aggregated patient registries
• Data warehouse / repository
• Rules engines
• Complex event processing (CEP)
• Expert systems
• Reporting tools
• Dashboarding engines
• Remote monitoring
• Social engagement portal for
patient/family
Tech required for move from FFS to ACOs
Integrated and aggregated data is the only way to get to ACOs and PCMHs

View Slide

NETSPECTIVE
NCI
App
NEI
App NHLBI
App
Healthcare Provider Systems
Clinical
Apps
Patient
Apps
Billing
Apps Lab
Apps Other
Apps
Master Data Management, Entity Resolution, and Data Integration
Partner Systems
Improved integration by services
that can communicate between applications
The Strategy: Modernize Integration
Need to get existing applications to share data through modern integration
techniques including minimal meta data.

View Slide

NETSPECTIVE
Common approach, low data interop
Application A
Data
Functionality
Presentation
Feature Y
Feature X
Application B
Data
Functionality
Presentation
Feature Y
Feature X
Feature Z
Copy features and enhance (everything is separate)
Application A
Data
Functionality
Presentation
Feature Z
Feature X
Application B
Data
Functionality
Presentation
Feature Y
Feature X
Feature Z
Connect to directly to existing data, but copy features and enhance

View Slide

NETSPECTIVE
Services
Sophisticated, better data interop
Application A
Data
Functionality
Presentation
Feature Y
Feature X
Application B
Data
Functionality
Presentation
Feature Y
Feature X
Feature Z
Create API between applications, integrate data, create new data
Application A
Data
Functionality
Presentation
Feature Z
Feature X
Application B
Data
Functionality
Presentation
Feature Y
Feature X
Feature Z
Create common services and have all applications use them
REST
SOAP, RMI
SOA
APIs
WOA

View Slide

NETSPECTIVE
What’s being offered to users What users really want
What users want vs. what they’re offered
Data visualization requires integration and aggregation and then homogenization

View Slide

NETSPECTIVE
The myth of mobility in healthcare
Sexy but wrong: Device-centric closed systems Dull but right: Workflow-centric open solutions

View Slide

NETSPECTIVE
The myth of med device data interop
Device
Serial
Converter
USB
Converter
Concentrator
Local
Network
Gateway to
EHR
Cloud EHR
DDS MQTT REST SOAP AMQP XMPP WCTP SNMP SMTP MLLP

View Slide

Treat data as code
Fix broken windows by using service oriented data

View Slide

NETSPECTIVE
Architecture transitions
Mainframes Client/Server Web 1.0
Service-oriented
Architecture
(SOA)
Web 2.0 & APIs
Web-oriented
Architecture
(WOA)
Event-driven
Architecture
(EDA)
Data-driven
Architecture
(DDA)
Prevalent healthcare industry architectures
EDI HL7 X.12 MLLP
DDS MQTT SOAP AMQP XMPP WCTP SNMP REST SMTP MLLP

View Slide

NETSPECTIVE
Data attributes fix broken windows
Provenance /
Source
Ownership Steward
Units of
Measure
Location
Device
Confidence /
Probability
Subject area /
Classification
Confidentiality Privacy
Creation User /
Org
Transformed? Analyzed? Interpreted? Quality Metrics
Curated? Revisions?
Combinable /
Aggregatable?

View Slide

NETSPECTIVE
Monolithic Apps Approach
Blob Tables
Browser
Modules
Themes
Workflow
Server Pages
Drupal CMS
Custom App
Models
Views
Monolithic MVC
Controllers
Application Server (AS) RDBMS Server
Workstation
Domain
Tables
Data Tables
User Tables
• Custom IAM
• Data only available to AS
• Lots of FK constraints couple
tables
• All views, controllers, models maintained on the server side
• All security and data translation done on the server and sent to the
client

View Slide

NETSPECTIVE
Well intentioned SOA
Blob Tables
Browser
Support
API
Workflow
Pages
Service 1
Service 2
Support
Widgets
Service 3
Controllers
Application Server (AS) RDBMS Server
Workstation
Domain Tables
Data Tables
User Tables

View Slide

Source: http://www.sun.com/products/soa/benefits.jsp

View Slide

Modern Microapps and Services Approach
Identity
Manager LDAP
Patient
Services RDBMS
Domain
Services NoSQL
Analytics
SQL/Cube RDBMS
Limited FK
Constraints
oData
JSON
oData
oData
SQLV
oAuth
SAML
oData
LDIF
Domain
Services
Widgets
Patient
Services
Dashboard
oData
Micro Apps
No Direct Table
Access
Separate Schemas
No FK Constraints
Bootstrap
AngularJS
Bootstrap
AngularJS
Backplane
Reporting
Apps
Third Party
Bootstrap
Backplane
RDFa
HTML5 DA
RDFa
HTML5 Data Attrs
RDFa
HTML5 Data Attrs
ETL
Bootstrap
Backplane
Rich client only
or tiny server
frameworks
(Mojo, Rack, etc.)
XACML
oData
Search
Service
ElasticSearch iCal
syslog
Log/Monitor
Service
CalDAV
Service
Rules
Service
Doc/Blob
Service
oData
Browser Accessible
Device
Services
DDS

View Slide

NETSPECTIVE
Old way to architect:
Monolithic RDBMS-based data warehouse
The centralized clinical data warehouse (CDW)
model, where a massive multi-year project
creates a monolithic relational database that all
analytics will run off was fine when retrospective
reporting is what defined analytics. This old
architecture won’t work in modern predictive
analytics and mobile-centric requirements.
Better way to architect:
Service-oriented databases on RDBMS/NoSQL
• Drive transactional ACID-based data
requirements to RDBMS and consider column-
stores, document-stores, and network-stores for
other kinds of data
• Break relationships between data and store
lookup, transactional, predictive, scoring, risk
strat, trial associated, retrospective, identity,
mortality ratios, and other types of data based on
their usage criteria not developer convenience
• Use translucent encryption and auto-de-
identification of data to make it more useful
without further processing
• Design for decentralized sync’ing of data (e.g.
mobile, etc.) not centralized ETL
Move to service-oriented (de-identifiable) data
Don’t assume all your data has to go into a giant data warehouse

View Slide

NETSPECTIVE
Hard to secure data structures Easier to secure data structures
An example of structuring data for analysis
Preparing data is important
http://www.ibm.com/developerworks/data/library/techarticle/dm-ind-ehr/

View Slide

NETSPECTIVE
HL7 and X.12 aren’t the only formats
The general assumption is that
formats like HL7, CCD, and X.12 are
the only ways to do data integration
in healthcare but of course that’s
not quite true.
Consider industry-neutral protocols
• Consider identity exchange
protocols like SAML for integration
of user profile data and even for
exchange of patient demographics
and related profile information.
• Consider iCalendar/ICS publishing
and subscribing for schedule data.
• Consider microformats like FOAF
and similar formats from
schema.org.
• Consider semantic data formats
like RDF, RDFa, and related family.
Industry-specific formats aren’t always necessary
Reliance on heavyweight industry-specific formats instead of lightweight micro formats is bad

View Slide

NETSPECTIVE
• Most non-open-source
EHR solutions are
designed to put data in
but not get data out
• Never build your data
integration strategy with
the EHR in the center,
create it using the EHR as
a first-class citizen
Don’t assume your EHR will manage your data
The EHR can not be the center of the healthcare data ecosystem
Why EHRs are not (yet) disruptive
http://www.christenseninstitute.org/why-ehrs-are-not-yet-disruptive/

View Slide

NETSPECTIVE
• Clinicians usually go
into medicine because
they’re problem solvers
• Today’s permissions-
oriented culture now
prevents “playing” with
data and discovering
solutions
Encourage clinical “tinkering” and “hacking”
It’s ok to not know the answer in advance

View Slide

NETSPECTIVE
Promote “Outside-in” architecture
Think about clinical and
hospital operations and
processes as a collection
of business capabilities or
services that can be
delivered across
organizations.

View Slide

NETSPECTIVE
Patients
External
HCPs
HCP and
Staff
Evaluators
Internal
business
users and
HCPs
IT
Personnel
Focus on the real customer
Unsophisticated and
less agile data focus
Sophisticated and
more agile data focus
Inside-out focus Outside-in focus
HCPs = healthcare providers

View Slide

NETSPECTIVE
Proprietary identity is hurting us
• Most health IT systems create their own
custom identity, credentialing, and access
management (ICAM) in an opaque part of
a proprietary database.
• We’re waiting for solutions from health IT
vendors but free or commercial industry-
neutral solutions are much better and
future proof.
Identity exchange is possible
• Follow National Strategy for Trusted Identities
in Cyberspace (NSTIC)
• Use open identity exchange protocols such as
SAML, OpenID, and Oauth
• Use open roles and permissions-management
protocols, such as XACML
• Consider open source tools such as OpenAM,
Apache Directory, OpenLDAP
, Shibboleth, or
commercial vendors.
• Externalize attribute-based access control
(ABAC) and role-based access control (RBAC)
from clinical systems into enterprise systems
like Active Directory or LDAP
.
Implement industry-neutral ICAM
Implement shared identities, single sign on (SSO), neutral authentication and authorization

View Slide

NETSPECTIVE
Old way to architect:
“What data can you send me?” (push)
The "push" model, where the system that
contains the data is responsible for sending the
data to all those that are interested (or to some
central provider, such as a health information
exchange or HL7 router) shouldn’t be the only
model used for data integration.
Better way to architect:
“What data can I publish safely?” (pull)
• Implement FHIR or syndicated Atom-like feeds
(which could contain HL7 or other formats).
• Data holders should allow secure authenticated
subscriptions to their data and not worry about
direct coupling with other apps.
• Consider the Open Data Protocol (oData).
• Enable auditing of protected health information
by logging data transfers through use of syslog
and other reliable methods.
• Enable proper access control rules expressed in
standards like XACML.
• Consider Direct for connectivity if you can’t get
away from ‘push’.
Pushing data is more expensive than pulling it
We focus more on "pushing" versus "pulling" data than is warranted early in projects

View Slide

NETSPECTIVE
Legacy systems trap valuable data
In many existing contracts, the
vendors of systems that house the
data also ‘own’ the data and it can’t
be easily liberated because the
vendors of the systems actively
prevent it from being shared or are
just too busy to liberate the data.
Semantic markup and tagging is easy
• One easy way to create semantically
meaningful and easier to share and
secure patient data is to have all
HTML tags be generated with
companion RDFa or HTML5 Data
Attributes using industry-neutral
schemas and microformats similar to
the ones defined at Schema.org.
• Google's recent implementation of
its Knowledge Graph is a great
example of the utility of this
semantic mapping approach.
Tag all app data using semantic markup
When data is not tagged using semantic markup, it's not securable or shareable by default

View Slide

NETSPECTIVE
Proprietary data formats limit findability
• Legacy applications only present
through text or windowed
interfaces that can be “scraped”.
• Web-based applications present
HTML, JavaScript, images, and
other assets but aren’t search
engine friendly.
Search engines are great integrators
• Most users need access to
information trapped in existing
applications but sometimes they
don’t need must more than access
that a search engine could easily
provide.
• Assume that all pages in an
application, especial web
applications, will be “ingested” by
a securable, protectable, search
engine that can act as the first
method of integration.
Produce data in search-friendly manner
Produce HTML, JavaScript and other data in a security- and integration-friendly approach

View Slide

NETSPECTIVE
Healthcare fears open source
• Only the government spends more per
user on antiquated software than we do
in healthcare.
• There is a general fear that open source
means unsupported software or lower
quality solutions or unwanted security
breaches.
Open source can save health IT
• Other industries save billions by using
open source.
• Commercial vendors give better pricing,
service, and support when they know
they are competing with open source.
• Open source is sometimes more secure,
higher quality, and better supported
than commercial equivalents.
• Don’t dismiss open source, consider it
the default choice and select commercial
alternatives when they are known to be
better.
Rely first on open source, then proprietary
“Free” is not as important as open source, you should pay for software but require openness

View Slide

Thank You
Visit
http://www.netspective.com
http://www.healthcareguy.com
E-mail [email protected]
Follow @ShahidNShah
Call 202-713-5409

View Slide

NETSPECTIVE
Abstract
Centralized, monolithic databases primarily built using relational approaches have ruled for decades; they’ve given us
tremendous advances such as vertically scaled business-critical transactional systems and web applications. The next
generation of microapps, microservices, and web widgets demand a scale that vertical scale application-centric
relational databases are having difficulty with so we need to move to a more service-oriented database approach in
which even small services like those that service patients in a patient portal or specific modules of EHRs can and
should have their own databases.
This talk will discuss the idea of service-focused databases and how they differ from application-centric databases;
using this new approach allows faster delivery of applications, less coupling, and better scalability. Healthcare and
biomedical databases are notoriously complex and no single database technology can serve its needs so we need a
more service-oriented approach to database design.
You’ll learn how to choose the right database technology for each service, how to model service-oriented databases
differently than application-oriented ones, and how to keep service databases running smoothly.
Service Oriented Architecture Requires Service Oriented Data

View Slide

Service oriented architecture (SOA) deserves service oriented data

Service oriented architecture (SOA) deserves service oriented data

Shahid N. Shah

More Decks by Shahid N. Shah

Featured

Transcript