• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Service oriented architecture (SOA) deserves service oriented data
 

Service oriented architecture (SOA) deserves service oriented data

on

  • 231 views

...



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

Statistics

Views

Total Views
231
Views on SlideShare
231
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Service oriented architecture (SOA) deserves service oriented data Service oriented architecture (SOA) deserves service oriented data Presentation Transcript

    • 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
    • NETSPECTIVE Who is Shahid? • • • • 20+ years of software engineering and multidiscipline 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 nonprofit) www.netspective.com Author of Chapter 13, “You’re the CIO of your Own Office” 3
    • When does data matter? Only when we use it. www.netspective.com 4
    • When will we use the data? When we can trust it. When we can access it. www.netspective.com 5
    • When will we trust the data? When it doesn’t “suck”.  www.netspective.com 6
    • 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.). www.netspective.com 7
    • Can’t I just wait to use data until it doesn’t suck? Nope. www.netspective.com 8
    • What are we supposed to do? Treat data like code. Fix broken windows. www.netspective.com 9
    • Unused data never gets better. Iterate your way to better data by forcing its use. www.netspective.com 10
    • NETSPECTIVE Application focus is biggest mistake Application-focused IT instead of Data-focused IT is causing business problems. Silos of information exist across groups (duplication, little sharing) Clinical Apps Billing Apps Lab Apps Other Apps Healthcare Provider Systems Patient Apps Partner Systems Poor data integration across application bases www.netspective.com 11
    • 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 www.netspective.com 12
    • 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.” www.netspective.com 13
    • NETSPECTIVE Tech required for move from FFS to ACOs Integrated and aggregated data is the only way to get to ACOs and PCMHs The business needs • Quality and performance metrics • Patient stratification • Care coordination • Population management • Surveys and other directfrom-patient data collection • Evidence-based surveillance www.netspective.com 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 14
    • NETSPECTIVE The Strategy: Modernize Integration Need to get existing applications to share data through modern integration techniques including minimal meta data. Clinical Apps NCI App Billing Apps Lab Other Apps Apps NEI App Healthcare Provider Systems Patient Apps NHLBI App Partner Systems Master Data Management, Entity Resolution, and Data Integration Improved integration by services that can communicate between applications www.netspective.com 15
    • NETSPECTIVE Common approach, low data interop Feature X Feature X Feature Y Feature Y Feature Z Presentation Functionality Data Presentation Functionality Data Application A Application B Copy features and enhance (everything is separate) Feature X Feature X Feature Y Feature Z Feature Z Presentation Functionality Data Application A Presentation Functionality Data Application B Connect to directly to existing data, but copy features and enhance www.netspective.com 16
    • NETSPECTIVE Sophisticated, better data interop Feature X Feature X Feature Y Feature Y APIs Feature Z REST SOAP, RMI Presentation Functionality Data Presentation Functionality Data Application B Application A Create API between applications, integrate data, create new data Feature X Feature X Feature Z Feature Y SOA WOA Feature Z Presentation Functionality Data Application A Presentation Functionality Data Services Application B Create common services and have all applications use them www.netspective.com 17
    • NETSPECTIVE What users want vs. what they’re offered Data visualization requires integration and aggregation and then homogenization What’s being offered to users www.netspective.com What users really want 18
    • NETSPECTIVE The myth of mobility in healthcare Sexy but wrong: Device-centric closed systems www.netspective.com Dull but right: Workflow-centric open solutions 19
    • NETSPECTIVE The myth of med device data interop Serial Converter Device USB Converter DDS www.netspective.com MQTT Concentrator REST SOAP AMQP Local Network XMPP WCTP Gateway to EHR SNMP SMTP Cloud EHR MLLP 20
    • Fix broken windows by using service oriented data Treat data as code
    • NETSPECTIVE Architecture transitions Prevalent healthcare industry architectures Mainframes Client/Server EDI Data-driven Architecture (DDA) DDS www.netspective.com Web 1.0 HL7 X.12 Event-driven Architecture (EDA) MQTT SOAP AMQP Service-oriented Architecture (SOA) MLLP Web-oriented Architecture (WOA) XMPP WCTP SNMP REST Web 2.0 & APIs SMTP MLLP 22
    • 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? www.netspective.com 23
    • NETSPECTIVE Monolithic Apps Approach Workstation Application Server (AS) Themes Browser Server Pages Views Drupal CMS Custom App Monolithic MVC RDBMS Server Modules Workflow Models User Tables Data Tables Domain Tables Blob Tables Controllers • All views, controllers, models maintained on the server side • All security and data translation done on the server and sent to the client www.netspective.com • Custom IAM • Data only available to AS • Lots of FK constraints couple tables 24
    • NETSPECTIVE Well intentioned SOA Workstation Application Server (AS) API Browser Pages Service 1 Service 2 RDBMS Server Support Workflow User Tables Data Tables Domain Tables Widgets Service 3 Support Blob Tables Controllers www.netspective.com 25
    • Source: http://www.sun.com/products/soa/benefits.jsp www.netspective.com 26
    • Modern Microapps and Services Approach Browser Accessible Bootstrap Backplane SAML Identity Manager oData LDIF Domain JSON Domain oData RDFa HTML5 DA Services NoSQL Services Bootstrap AngularJS oData Patient Services Limited FK Constraints Analytics Services www.netspective.com Micro Apps Services Rich client only or tiny server frameworks (Mojo, Rack, etc.) oData Bootstrap AngularJS Backplane SQLV RDBMS DDS Device RDFa HTML5 Data Attrs Widgets Patient RDBMS ETL No Direct Table Access Separate Schemas No FK Constraints Dashboard LDAP oAuth SQL/Cube RDFa HTML5 Data Attrs Third Party oData Reporting Apps ElasticSearch Search Service syslog iCal Log/Monitor Service CalDAV Service Bootstrap Backplane oData Doc/Blob Service Rules Service oData XACML 27
    • NETSPECTIVE Move to service-oriented (de-identifiable) data Don’t assume all your data has to go into a giant data warehouse Old way to architect: Monolithic RDBMS-based data warehouse Better way to architect: Service-oriented databases on RDBMS/NoSQL 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. • Drive transactional ACID-based data requirements to RDBMS and consider columnstores, 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-deidentification of data to make it more useful without further processing • Design for decentralized sync’ing of data (e.g. mobile, etc.) not centralized ETL www.netspective.com 28
    • NETSPECTIVE An example of structuring data for analysis Preparing data is important Hard to secure data structures Easier to secure data structures http://www.ibm.com/developerworks/data/library/techarticle/dm-ind-ehr/ www.netspective.com 29
    • NETSPECTIVE Industry-specific formats aren’t always necessary Reliance on heavyweight industry-specific formats instead of lightweight micro formats is bad HL7 and X.12 aren’t the only formats Consider industry-neutral protocols 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. • • • • www.netspective.com 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. 30
    • NETSPECTIVE Don’t assume your EHR will manage your data The EHR can not be the center of the healthcare data ecosystem • 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 Why EHRs are not (yet) disruptive http://www.christenseninstitute.org/why-ehrs-are-not-yet-disruptive/ www.netspective.com 31
    • NETSPECTIVE Encourage clinical “tinkering” and “hacking” It’s ok to not know the answer in advance • Clinicians usually go into medicine because they’re problem solvers • Today’s permissionsoriented culture now prevents “playing” with data and discovering solutions www.netspective.com 32
    • 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. www.netspective.com 33
    • NETSPECTIVE Focus on the real customer Inside-out focus IT Personnel Outside-in focus Internal business users and HCPs HCP and Staff Evaluators External HCPs Patients Sophisticated and more agile data focus Unsophisticated and less agile data focus HCPs = healthcare providers www.netspective.com 34
    • NETSPECTIVE Implement industry-neutral ICAM Implement shared identities, single sign on (SSO), neutral authentication and authorization 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 industryneutral solutions are much better and future proof. www.netspective.com 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 . 35
    • NETSPECTIVE Pushing data is more expensive than pulling it We focus more on "pushing" versus "pulling" data than is warranted early in projects Old way to architect: “What data can you send me?” (push) Better way to architect: “What data can I publish safely?” (pull) 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. • 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’. www.netspective.com 36
    • NETSPECTIVE Tag all app data using semantic markup When data is not tagged using semantic markup, it's not securable or shareable by default Legacy systems trap valuable data Semantic markup and tagging is easy 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. • 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. www.netspective.com 37
    • NETSPECTIVE Produce data in search-friendly manner Produce HTML, JavaScript and other data in a security- and integration-friendly approach Proprietary data formats limit findability Search engines are great integrators • 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. • 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. www.netspective.com 38
    • NETSPECTIVE Rely first on open source, then proprietary “Free” is not as important as open source, you should pay for software but require openness Healthcare fears open source Open source can save health IT • 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. • 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. www.netspective.com 39
    • Visit http://www.netspective.com http://www.healthcareguy.com E-mail shahid.shah@netspective.com Follow @ShahidNShah Call 202-713-5409 Thank You
    • NETSPECTIVE Abstract Service Oriented Architecture Requires Service Oriented Data 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. www.netspective.com 41