Alan Boucher

786 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
786
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Cost Center Validation Business service shouldn’t be concerned with data fields in edw.
  • TTD = Time to Deployment
  • Organizations implementing SOA frameworks need a way to include HL7 V3 in a consistent manner that maximizes value of SOA and HL7, using (cheap) industry standard tooling. Messaging and SOA are different paradigms, but share a great deal of common ground. Content definition is common, but interaction implementation and infrastructure are different. Separation of concerns across standards. For SOA, HL7 should define information content, but only infrastructure that is truly specific to HL7. The Transmission Wrapper and possibly some or all of Control Act Wrapper may not be needed in SOA implementations. Web Services standards, Process Orchestration and Interaction/Interface Contract cover transmission issues. Layered Conformance and Profiling may help to address some of the issues.
  • Alan Boucher

    1. 1. HIMSS.ORG; Integration & Interoperability Web Cast March 2006 Using Service Oriented Architectures to Support RHIO Development Alan Boucher Director, Health Care Architecture Digital Health Group , Intel Corporation
    2. 2. Today’s Agenda <ul><li>Service Oriented Architecture (SOA) Overview </li></ul><ul><ul><ul><li>Service Oriented Architecture Construction </li></ul></ul></ul><ul><ul><ul><li>Interoperability (Semantic, Syntactic & Structural ) </li></ul></ul></ul><ul><ul><ul><li>Anatomy of a Business Processes & Services </li></ul></ul></ul><ul><ul><ul><li>Expected Benefits of a Service-Based Architecture </li></ul></ul></ul><ul><ul><ul><li>SOA and HL7: “One RHIO Services Network” </li></ul></ul></ul><ul><ul><li>The Role of Services in a National Health Care System </li></ul></ul><ul><ul><ul><li>Using Best Known Methods </li></ul></ul></ul><ul><li>The Role of Services in RHIOs & RHINs </li></ul><ul><ul><ul><li>Service Delivery in a Centralized Model </li></ul></ul></ul><ul><ul><ul><li>Service Delivery in a Peer-to-Peer Model </li></ul></ul></ul><ul><ul><ul><li>RHIO Architecture Development </li></ul></ul></ul><ul><ul><li>Summary & Next Steps for RHIOs & RHINs </li></ul></ul>
    3. 3. <ul><li>Service-oriented architecture : A design approach to standardize functions or services, so that numerous dissimilar applications and technologies can share them—both inside and outside of the providing entity </li></ul><ul><li>Service : A distinct, self-contained, well-defined function or capability that operates through a contractually defined service interface </li></ul><ul><li>Service Interface : A technology and implementation independent way to systematically define a service’s: </li></ul><ul><ul><li>Features, i.e. capability and output </li></ul></ul><ul><ul><li>Terms, i.e. requirements and input </li></ul></ul><ul><ul><li>and SLA, i.e. operating performance and quality of service </li></ul></ul>Service Oriented Architecture (SOA) Construction Key principle: Contractual separation of concerns between a service provider (RHIOs) and Service Consumer’s (Patient, Provider, Payer & Pharma) through an interface
    4. 4. SOA’s & Interoperability <ul><li>Main Entry: in•ter•op•er•a•bil•i•ty </li></ul><ul><ul><ul><li>: ability of a system … to use the parts or equipment of another system </li></ul></ul></ul><ul><ul><ul><li>Source: Merriam-Webster web site </li></ul></ul></ul><ul><ul><li>Interoperability </li></ul></ul><ul><ul><li>: ability of two or more systems or components to exchange information and to use the information that has been exchanged </li></ul></ul><ul><ul><ul><li>Source: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990 </li></ul></ul></ul>Semantic interoperability entails a co-ordination of meaning. Semantics is defined as the meanings of terms and expressions with regard to content description standards. Hence semantic interoperability is “ the ability of information systems to exchange information on the basis of shared, pre-established and negotiated meanings of terms and expressions,” and is needed in order to make other types of interoperability work. <ul><li>Syntactic Interoperability : Conveying agreed upon grammars for semantics & structure. </li></ul><ul><li>The challenges of syntactic interoperability become: </li></ul><ul><li>identifying all the elements in various systems (in RHIOs); </li></ul><ul><li>establishing rules for structuring these elements; (between RHIO entities) </li></ul><ul><li>mapping, bridging, creating crosswalks between equivalent elements using schemas etc.; </li></ul><ul><li>agreeing on equivalent rules to bridge different cataloguing and registry systems </li></ul>Structural interoperability uses agreed upon framework models, such as HL7 Reference Information Model (RIM), the Clinical Document Architecture (CDA), the ASTM Continuity of Care Record (CCR) or even models based on the Integrating the Healthcare Enterprise (IHE) - Cross Enterprise Document Sharing (XDS) Profile, which stores documents as ebXML.
    5. 5. Anatomy of a Business Process Activity <ul><li>Trigger </li></ul><ul><ul><li>Time </li></ul></ul><ul><ul><li>Event </li></ul></ul><ul><li>Input </li></ul><ul><ul><ul><li>Data Required for Decision/Action </li></ul></ul></ul><ul><li>Output </li></ul><ul><ul><ul><ul><li>Data produced by </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Decision / Action </li></ul></ul></ul></ul><ul><li>Decision / Action </li></ul><ul><li>Steps completed </li></ul><ul><li>Decisions Made </li></ul>Next Activity / Process Process Approval & Return Data Receive Request To Acquire Data Determine Requestor Credentials Send Request To RHIO Rules Engine Make Policy Decision Reject Requestor & Return Event
    6. 6. Anatomy of a Service The anatomy of a service maps directly to the anatomy of process. Process & data needs drive requirements for service interfaces EHR Lookup Service Op: InitiateEHRlookup() IA&M Service Op: AssertionLookup() Governance Service Op: PolicyLookup() Process EHR Service Op: GetEHRRecord() Format EHR Service Op: FormatEHRCCR() Process Error Service Op: ReturnError() .OR. Process Approval & Return Data Receive Request To Acquire Data Determine Requestor Credentials Send Request To RHIO Rules Engine Make Policy Decision Reject Requestor & Return Event Activity <ul><li>Trigger </li></ul><ul><ul><li>Time </li></ul></ul><ul><ul><li>Event </li></ul></ul><ul><li>Input </li></ul><ul><ul><ul><li>Data Required for Decision/Action </li></ul></ul></ul><ul><li>Output </li></ul><ul><ul><ul><ul><li>Data produced by </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Decision / Action </li></ul></ul></ul></ul><ul><li>Decision / Action </li></ul><ul><li>Steps completed </li></ul><ul><li>Decisions Made </li></ul><The Name> <operations> Policies & SLA Features ( capability + output) Terms ( requirements + input ) Created by A Service the RHIO
    7. 7. Expected Benefits of SOA Micro (per adaptation) $ Return Time Development Productivity TTD With SOA Traditional Development RHIO Benefit Program “development time to release” improves greatly based on services leveraged in design Macro (subsequent adaptations) $ Return Time RHIO Value SOA savings realized Traditional savings Expected aggregate effects are more $$ available for new RHIO capabilities & improved business processes for RHIO participants Service Re-use
    8. 8. SOA and HL7: “One RHIO Services Network” <ul><li>RHIO’s may implement their interoperability models in HL7 V3, yet many participating organizations still use HL7 V2, X.12, NCPDP & others. </li></ul><ul><li>How will HL7 “play” in an SOA implementation? </li></ul><ul><ul><li>RHIO SOA framework’s should be built with industry standard (commonly acceptable) infrastructures, tools & methods (commercial & open source) </li></ul></ul><ul><ul><li>HL7 should be implemented on an SOA framework as; </li></ul></ul><ul><ul><ul><li>Content: HL7 defines information content and should be a separate element from Messaging </li></ul></ul></ul><ul><ul><ul><ul><li>e.g. RHIO data should be separated from transport, messaging & infrastructure, which will evolve over time. SOA messaging architecture’s typically support varying messaging & transports, including web services. </li></ul></ul></ul></ul><ul><ul><ul><li>Support multiple standards related to RHIO records (HL7, DICOM, X.12, NCPDP etc) </li></ul></ul></ul><ul><ul><ul><li>Develop “common” HL7 service extensibilities: </li></ul></ul></ul><ul><ul><ul><ul><li>Business - Patient Consent, Record Locators, RHIO Entity Identification, Semantic Libraries & Normalization </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Infrastructure – Authentication & Authorization, Governance & Policy, Security, Auditing </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Data Services - Data Mining, Disease Management, Outcomes-based Medicine, Pharma Interactions, e-Pharma Gateways </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Financial Services - Scheduling Services, SMB Concierge, Claims Mgmnt, HSA, CMS etc.. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Gov’t extensibility – Epidemic / Pandemic Management, Bio-terrorism, DHS, CDC etc </li></ul></ul></ul></ul>
    9. 9. The Role of Services in a National Health Care System <ul><li>Goal 1: Inform Clinical Practice: Incentives for EHR adoption and create tools that ensure 100% success in EHR implementation and use. </li></ul><ul><li>Goal 2: Interconnect Clinicians: Identify interoperability as a major milestone for achieving improved health care delivery; encourage regional health care information exchanges and a National health information network. </li></ul><ul><li>Goal 3: Personalize Care: Foster patient-centric care delivery and more informed health care consumers. </li></ul><ul><li>Goal 4: Improve Population Health: Encourage the collection, analysis, and dissemination of timely and accurate information that impact public health. </li></ul>© 2005 The Interoperability Consortium
    10. 10. ONCHIT NHIN Framework and Standards Certification Of RHIOs Services NHIC – Board Private National Health Information Corporation (NHIC) P & P Certification Certified Private Companies & HISPs Services Bus Services Bus Standards RHIOs Data Models, Data Exchange Governance, Policy, Auditing Orchestration, Transformation & Business Rules Providers Payors (including CMS) Employers Citizen Service Doctors Pharma Exposed Services (Pub / Sub) Organizational Information between RHIOs & the NHIN Exposed Services (Pub / Sub) PMO National Health Technology Standards and Certification (NHTSC) Contract Contract Using Service Oriented Architectures to Support RHIO Development March 2006 HIMSS.org Web Cast © 2005 The Interoperability Consortium
    11. 11. Best Known Methods… learning from the NHS UK <ul><li>Major IT Project for 50M+ UK NHS Patients & Citizens </li></ul><ul><li>(the ~Size of California) </li></ul><ul><li>Live, interactive 24x7 patient record service across care settings and organizations </li></ul><ul><li>Service-Providers deliver support and software for patient record and infrastructure services </li></ul><ul><li>Services delivered based on patient confidentiality and security </li></ul><ul><li>Performance and Security are core to TMS & SPINE design </li></ul><ul><li>Services allow for horizontally scaleable infrastructure </li></ul><ul><li>Services decrease deployment time for individual clusters </li></ul><ul><li>Services accelerate implementation of Gateway require zero-coding for local clusters </li></ul><ul><li>Services improved stability, resilience and availability </li></ul>Data Services for Secondary Uses Services Services Services Services Services SHAs / Trusts / Units / Primary Care / Social Care care & services for patients LSPs deliver a range of local applications, services & functionality TMS processes all messages SPINE (NASP) delivers national services Electronic Booking Personal Demographic Service (PDS) Personal SPINE Information Service (PSIS) Electronic Transmission of Prescription A Cluster Bi-directional Message Traffic NHS Care Record Service Local Data & Applications RHIO Gateway Services Bus Providers Citizen Services IPAs, Doctors Pharma Exposed Services (Pub / Sub) RHIOs Data Models, Data Exchange Governance, Policy, Auditing Orchestration, Transformation & Business Rules NHIN Payors (including CMS) Employers
    12. 12. Applying Best Known Methods.. Deployable RHIO Service Technologies Internet Orchestration Messaging Bus Service Container Data Transform Business Rules, Algorithms Meta Data Store Audit, Monitoring & Management AAA, Data Security Queue Queue XML Firewall Payor, Provider, Pharma, Physician Organizations RHIOs & RHINs Orchestration Messaging Bus Queue Queue Service Container Data Transform Business Rules, Algorithms Meta Data Store Audit, Monitoring & Management AAA, Data Security XML Firewall Deployable Business Rules RHIO Standard Transforms (XSLTs) Publish & Subscribe Services Development of Common Services & Libraries, Directories & Registries Isochronous & Asynchronous messaging Reliable Messaging & Queue Management SOAP Encapsulated XML HTTP SSL VPN SSL VPN PtP HL7 Wrapper HL7 v2.x, v.3, HL7 CDA, ASTM CCR, openEHR etc.. HL7 Wrapper HL7 v2.x, v.3, HL7 CDA, ASTM CCR, openEHR etc.. HL7 Content Model or XML, ebXML, other Option : File Exchange Formats could be <encapsulated> XML in the cloud
    13. 13. High-Level Service Operations in RHIOs & RHINs Data / Web Service Provider Published Web & Data Services Access based on Object IdM Assign Data Resources Based on HISP or RHIO / RHIN Object Identity (IdM) HISP/ RHIO / RHIN Data Access Data Provider RHIO / RHIN Services Directories Data / Web Service Requestor HISP Objects: Physicians, Providers, Payor’s GVT Entities and Commercial Services Federated Services Model Business Integration Layers Bind or Latent Bind Web Service & Data Components to Object IdM Policy, IdM & WbS Invocation RHIO Object IdM Access Using Service Oriented Architectures to Support RHIO Development March 2006 HIMSS.org Web Cast WbS Management, Routing & Governance Services
    14. 14. Services create New Opportunities for RHIOs RHIO Participating Organizations RHIOs & RHINs RHIO Access Portal Patient Browse Container RHIOs must build self-sustaining business models through Services Orchestration Messaging Bus Service Container Data Transform Business Rules, Algorithms Meta Data Store Audit, Monitoring & Management AAA, Data Security Queue Queue XML Firewall Orchestration Messaging Bus Queue Queue Service Container Data Transform Business Rules, Algorithms Meta Data Store Audit, Monitoring & Management AAA, Data Security XML Firewall Record Locator Services RHIO Storage Payor Authorizations Patient Consent Provider Directory Claims Processing RHIO UDDI Services Registry Data Analytics Loosely-Coupled Services Primary Care Physician Billing Specialist Specialist Physician Service Request Search Authorization Authentication Workflows Policy & Consent Mgmt Identity Additional RHIO Services Storage Audit Commercial Messaging Content Mgmt Physician Concierge Services
    15. 15. RLS Lookup and Access Peer-to-Peer Data & Transformation (RLS) Data Providers – Doctors, Facilities, Payors etc.. Peer Trust DNS Like Services SOAP SOAP SOAP SOAP Using Service Oriented Architectures to Support RHIO Development March 2006 HIMSS.org Web Cast Claims Processing Peer-to-Peer RHIO SOA Model RHIO Entity Peer RHIO Entity Peer RHIO Entity Peer RHIO Entity Peer Trust RHIO Entity Peer GW RLS Meta-data RLS Meta-data RLS Meta-data GW GW GW Patient Directory Consent Services Provider Directory RHIO UDDI Services Registry Data Analytics Payor Authorizations
    16. 16. Service Abstraction Layer RHIO RHIO HISP Governance HISP Governance NHIN Service Abstraction Layer NHIN NHIN GW GW GW GW Trust Domain Trust Domain Trust Domain “ On behalf of” Trust Doctor GW Provider Pharma Payor GW GW Web/GW Patient Web Doctor GW Provider Pharma Payor Web GW Patient Web Web/GW Using Service Oriented Architectures to Support RHIO Development March 2006 HIMSS.org Web Cast Centralized RHIO SOA Model Structured Data, stored in each RHIN, Accessed & Transformed via RHIO Services RHIO UDDI Services Registry Record Locator Services RHIO Storage Payor Authorizations Patient Consent Provider Directory Claims Processing Data Analytics Search Authorization, Authentication & Auditing Custom Service-based Workflows Identity Additional RHIO Services Commercial Messaging Physician Concierge Services RHIO UDDI Services Registry Record Locator Services RHIO Storage Payor Authorizations Patient Consent Provider Directory Claims Processing Data Analytics Search Authorization, Authentication & Auditing Custom Service-based Workflows Identity Additional RHIO Services Commercial Messaging Physician Concierge Services
    17. 17. RHIO Business Architecture Segmentation PROCESS DRIVEN STRATEGY FOCUSED PLATFORM DEFINITION SERVICE ORIENTED The RHIO Business Architecture RHIO BUSINESS STRATEGY SERVICE ORIENTED INFRASTRUCTURE & COMPOSITION PLATFORM COMPONENTRY JAVA .Net LAMP RHIO BUSINESS PROCESS EXECUTION AND MONITORING Packaged Apps. http://www.momentumsi.com/index01.html
    18. 18. RHIO SO Architectural Considerations http://www.momentumsi.com/index01.html Platform Architecture Black Boxed Architecture Domain Architectures <ul><li>Application </li></ul><ul><li>Integration </li></ul><ul><li>Data </li></ul><ul><li>J2EE </li></ul><ul><li>.Net </li></ul><ul><li>Packaged Apps </li></ul><ul><li>ASP / leased systems </li></ul>Reference Architectures <ul><li>Model 1 </li></ul><ul><li>Model 2 </li></ul>Candidate Architectures <ul><li>The Proposed RHIO Architecture </li></ul>Solution Architecture <ul><li>The Actual RHIO Architecture </li></ul>Gray Boxed Architecture <ul><li>Semi-Packaged Apps </li></ul><ul><li>App Frameworks </li></ul>Architectural Requirements Specific RHIO Objectives Architectural Constructs <ul><li>Participants </li></ul><ul><li>Patterns </li></ul><ul><li>Practices </li></ul>Architectural Themes <ul><li>Model Driven </li></ul><ul><li>Service Oriented </li></ul><ul><li>Process Driven </li></ul>Deployment Architectures <ul><li>Network </li></ul><ul><li>Computing </li></ul><ul><li>Distribution </li></ul>RHIO Architecture Models
    19. 19. Summary & Next Steps <ul><li>Evolution to SOA is inevitable in most industries ; </li></ul><ul><ul><li>RHIOs have a green field opportunity to drive “industry change” </li></ul></ul><ul><li>SOA’s impact is profound but evolutionary – won’t be fully realized on initial deployment </li></ul><ul><li>SOA development is a journey with multiple phases of increasing maturity </li></ul><ul><li>The aim of any SOA should be based on clear Business Benefit and Implementation Goals up front. </li></ul><ul><li>RHIOs must; </li></ul><ul><ul><li>Develop architectural decisions in a consistent & standardized way </li></ul></ul><ul><ul><li>Develop SOA methodologies for interacting with all entities & organizations in viable process driven manner </li></ul></ul><ul><ul><li>Enable new business processes and capabilities for all entities whether they be large or small; </li></ul></ul><ul><ul><ul><ul><li>Business - Patient Consent, Record Locators, RHIO Entity Identification, Semantic Normalization </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Infrastructure – Authentication & Authorization, Governance & Policy, Security, Auditing </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Data Services - Data Mining, Disease Management, Outcomes-based Medicine, Pharma Interactions, e-Pharma Gateways </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Financial Services - Scheduling Services, SMB Concierge, Claims Mgmnt, HSA, CMS etc.. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Gov’t extensibility – Epidemic / Pandemic Management, Bio-terrorism, DHS, CDC etc </li></ul></ul></ul></ul>
    20. 20. HIMSS.ORG; Integration & Interoperability Web Cast March 2006 Using Service Oriented Architectures to Support RHIO Development Alan Boucher Director, Health Care Architecture Digital Health Group , Intel Corporation Thank You!
    21. 21. Backup
    22. 22. SOA Philosophies <ul><li>1. Consumers and Producers are Loosely Coupled </li></ul><ul><ul><li>Provide Functional Encapsulation </li></ul></ul><ul><ul><li>Factor Out Non-Functional Concerns </li></ul></ul><ul><ul><li>Force Ubiquity at the Edge of the Service </li></ul></ul><ul><ul><li>Performance is an Implementation Decision </li></ul></ul>
    23. 23. SOA Philosophies <ul><li>2. Leverage Network Computing and Resource Virtualization </li></ul><ul><ul><li>Network the Services </li></ul></ul><ul><ul><li>Provide mediation in the network </li></ul></ul><ul><ul><li>Resolve resources at runtime (latent bind) </li></ul></ul>
    24. 24. SOA Philosophies <ul><li>3. Systems are Loosely Bound </li></ul><ul><ul><li>Integration and Composition are One </li></ul></ul><ul><ul><li>Functionally Structured </li></ul></ul><ul><ul><li>Operationally Amorphous </li></ul></ul>
    25. 25. SOA Philosophies <ul><li>4. RHIO Service Networks Scale Efficiently </li></ul><ul><ul><li>The RHIO Vocabulary is Managed </li></ul></ul><ul><ul><li>Facilitate Service Use and Reuse </li></ul></ul><ul><ul><li>Create Federated Solutions </li></ul></ul>
    26. 26. SOA Philosophies <ul><li>5. SOA Enables new Opportunities </li></ul><ul><ul><li>HC Enterprise Boundaries are Removed </li></ul></ul><ul><ul><li>Unstructured Data Finds Structure and Meaning </li></ul></ul><ul><ul><li>The Value of Data is Redistributed </li></ul></ul><ul><ul><li>All Service Network Users have the same Value / Impact in the System </li></ul></ul>

    ×