1 / 49

Leveraging a Reference Architecture and Standards to Promote Interoperability

Leveraging a Reference Architecture and Standards to Promote Interoperability. Ken Rubin ( ken.rubin@eds.com ) Chief Healthcare Architect, EDS Federal Health Portfolio Chair, OMG Healthcare Domain Task Force. Learning Objectives.

Télécharger la présentation

Leveraging a Reference Architecture and Standards to Promote Interoperability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Leveraging a Reference Architecture and Standards to Promote Interoperability Ken Rubin (ken.rubin@eds.com) Chief Healthcare Architect, EDS Federal Health Portfolio Chair, OMG Healthcare Domain Task Force

  2. Learning Objectives • Understand healthcare and its unique challenges as a market sector • Define context and dimensions of Interoperability • Come to a shared understanding of Architecture and its role • Provide an overview of Standards pertinent to health interoperability • Tying the above together. How do standards, architecture, and SOA help promote interoperability

  3. A little personal background… • ~18 years of IT experience • ~10 years Enterprise Architecture and Health Informatics experience • Roles: • Chief Healthcare Architect for EDS’ Federal Healthcare Portfolio • Veterans Health Administration Enterprise “Application” Architect (held for ~7 years) • Standards • 10 years of standards participation and involvement • Chair of the OMG Healthcare Domain Task Force • Co-Chair of HL7 Service-oriented Architecture Committee • Enterprise Architect for Open Health Tools • Past Chair, HL7 Process Improvement Committee

  4. Disclaimers The information that follows is derived from either public information or personal experience. This information is a good-faith representation, and every effort has been made to assure its accuracy, currency, and vendor/product neutrality. Nonetheless, these slides do not necessarily reflect the official position of the Veterans Health Administration, the U.S. Government, EDS, or any organizational affiliation.

  5. An Introduction to Health Care

  6. The Healthcare “Vertical”: A Global Context • In almost every culture, healthcare is being viewed as “broken” • Demand ubiquitously is outpacing supply • To date, Information Technology investments in healthcare have been limited • Countries with the means to do so are investing in IT • Australia (NeHTA: http://www.nehta.gov.au ) • Canada (Infoway: http://www.infoway-inforoute.ca/ ) • United Kingdom (NPfIT: http://www.connectingforhealth.nhs.uk/ ) • United States (NHII, RHIOs, … http://www.os.dhhs.gov/healthit/ ) • Others…. • Unprecedented participation and collaboration internationally

  7. Vertical Market Sector Objectives for Healthcare • Clinical • Improve information quality • Improve information availability at point-of-care • Reduce preventable medical errors • Support adherence to clinical protocols • Administrative • Improve resource management and utilization • Improve information management, security, privacy • Financial • Improve fiscal life cycle; revenue cycle management

  8. Healthcare’s Challenges • Funding is sparse everywhere • IT is competing with direct patient care for $$$ • There are few incentives and many risks for organizations to share information • Information content is very diverse and complex, and is not consistently represented by practitioners • The volumes of data are enormous • The institutional culture is still very much paper-based • There is an inherent lack of infrastructure within and across care organizations • Software products that are available are largely proprietary

  9. The Premise … Healthcare IT is about improving health outcomes

  10. The Premise Contradicted (Today’s View) • Healthcare as a market sector has viewed IT investment as an expense and not as an investment • Most IT investment to date has been administratively or financially focused • The bulk of Healthcare IT in use address departmental or niche needs • Integration of data within departments is common • Integration of data within care institutions is not uncommon • Integration of data within enterprises is uncommon • Integration of data across enterprises is unheard of

  11. A View into Health IT Adoption Most organizations are in the early phases of EHR implementation and the market will evolve significantly over time Generation I Generation II Generation III Person-centric systems view Health outcomes based Consistent semantics Inter-Enterprise integration Population health support Continuous process improvement Enterprise or organizational deployment Limited integration across facilities Inconsistent business practices Inconsistent data quality Numbers of EHRs/ Utilization Department systems Facility-centric systems view Inconsistent deployment Time

  12. The Promise (A Vision) • The value of Health IT is measured in terms of business outcomes and not cost expenditures • Direct ties of IT to improved beneficiary health • Reduction of preventable medical errors • Improved adherence to clinical protocols • IT accountability through core healthcare business lines • IT investment owned by business stakeholders • Tangible benefits to constituents and health enterprise • Improved health outcomes • Improved data quality • Increased satisfaction by beneficiaries and system users • Higher satisfaction by users • Improved public health capabilities

  13. Business View Operates 1400+ sites of care 155 hospitals/medical centers 872 outpatient clinics 135 long-term care facilities 45 rehabilitation facilities Affiliated with 107 of 125 medical schools in the US Healthcare Statistics (2006) 7.9M beneficiaries enrolled 74.5M people potentially eligible ~775K inpatient visits 5.5M patients treated 60M+ outpatient visits Operational View (2004) 180k VHA employees 13k physicians, 49k nurses 90k health professionals trained annually USD$34.9B budget in 2007 Technical View VistA (EHR) for over 20 years Software portfolio exceeds 140 applications Reengineering effort is based upon a services architecture Case Study: The [US] Veterans Health Administration* *statistics taken from 2007 VA Fact Sheet, U.S. Department of Veterans Affairs: http://www1.va.gov/opa/fact/vafacts.asp

  14. VA’s Current Environment • VistA, the VHA EHR, is in use ubiquituously across the VA enterprise (and also outside the US) • All clinical systems are integrated (Clinician desktop, pharmacy, laboratory, radiology, etc) • Data is available from any VA point-of-care • Beneficiaries can self-enter family history and self-care progress notes • VA CPOE numbers exceed 90% • VistA is cited by the Institute of Medicine as the world’s leading EHR

  15. …And they’re re-engineering the whole thing • Why? The premise. That’s why. • Every VistA system instance is different • Data quality is inconsistent site-to-site • Not all data is represented formally using clinical terminologies • Business rules are implemented inconsistently in different parts of the application suite • [System] Quality of service differs site-to-site • High maintenance costs (in both dollars and time) • ~50% of their beneficiaries receive care outside of VA

  16. Some of their business objectives… • Improve the ability to care for veterans • Improve quality of care from improved data quality, consistency • Improve access to information where and when it is needed • Allow for better management of chronic disease conditions • Increase efficiencies allow for improved access to care (e.g., “do more with less”) • Improve consistency of the practice of healthcare via clinical guideline conformance

  17. The VA Approach… • Migrate current applications into a service-oriented architecture • Re-platform the application into current technologies • Minimize vendor lock-in risk through use of open standards • Standardize on an information model and terminologies for consistent semantics • Recognize that healthcare is a community and solving it institutionally only solves it 50% This is the reason interoperability and standards are essential!

  18. Interoperability and Standards

  19. What is Interoperability? • According to IEEE, interoperability is defined as: • the ability of two or more systems or components to exchange information and to use the information that has been exchanged • Why do we care? • No organization exists in a vacuum • Increasingly, business pressures are driving organizations to collaborate and interchange data with their peers • Integration and dependencies between market sectors are increasingly important • Our ability to integrate drives consumer value • Consumers are increasingly empowered

  20. The 20 Second Interoperability Quiz Are you interoperable… • … if you and your business partners “speak” different languages • … if gender = “01” means “male” in your business and “female” for your business partner? • …if the primary context for information sharing is e-mail or fax? • … if electronic data is exchanged via CD-ROM, or DVD-ROM? • …if you use XML? • …if you use Web Services?

  21. The 20 Second Agility Quiz How well can your organization’s IT adapt to… • … address the new business rules that resulted from a legislated policy? • … deployment changes resulting from adding a data center? • … integrating clinical information with a new business partner? • … integrating with “the new <place clinical specialty here> system” • … emerging public interest in personal health records?

  22. Measuring Interoperability • NeHTA (the Australian National e-Health Transition Authority) published an Interoperability Maturity Model • It defines a rigorous method of assessing and measuring interoperability • It is based on the maturity levels defined in the Carnegie-Mellon Capability Maturity Model (CMMI) • It identifies dimensions of interoperability, namely: • Organisational • Informational • Technical • http://www.nehta.gov.au/index.php?option=com_docman&task=cat_view&gid=123&Itemid=139

  23. Addressing the Two Dimensions of Interoperability • Behaviorally, there are a lot of solutions • Need to marry Semantic Interoperability with Behavior • The touchstone business case is the notion of automated discovery, composition, and delivery Ideal Target SNOMED-CT Semantics OWL-S ISO-11179 Web Services UDDI v3 CORBA Java RMI Behavioral

  24. Messaging Standards Terminology Standards “Functional” Standards Structured Doc Standards Services Standards Standards Profiling The beauty of standards… • HL7 • X.12 • NCPDP • ASTM • OMG • DICOM • IHTSDO/SNOMED • ICD • LOINC • IHE • CEN TC 251 • ISO TC 215

  25. Scope of HL7 Activities and Standards • Messaging • RIM • CDA • CCOW • CTS • Vocab • Arden • Decision Support • Services • EHR • Patient Care • Personnel Mgmt • Regulated Clinical Research and Information Management • Scheduling and Logistics • Structured Documents • Arden Syntax • Attachments • Clinical Guidelines • Community-based Health • Pediatrics • Electronic Health Records • Government Projects • Image Management • Java • Lab Automation and Testing • Medication • Security and Accountability • Templates • XML • Services • Public Health and Emergency Response • Modeling and Methodology • Vocabulary • Architecture Review Board • CCOW • Clinical Decision Support • Conformance • Control Query • Financial Management • Medical Records • Orders and Observations • Patient Administration Committees

  26. Entity Role Act HL7 RIM Participation 1 1 1 1 1 1 is_managed_by 0..* 0..* 1 1 specifies_ability_in 0..* 0..* 0..* 0..* 1 1 Message control Structured Documents can_accompany 1 1 1 1 1 1 1..* 1..* 1..* 1..* 1 1 returns_to

  27. Model-Driven Architecture • Fundamentally, MDA enables business-meaning to be realized in multiple technologies • MDA promotes separation of concerns • MDA facilitates service-oriented architecture • MDA provides an infrastructure to leverage commercially-available tooling • MDA allows for side-by-side technology deployments * Separation of concerns based upon ISO RM-ODP Specification

  28. What is the Healthcare Services Specification Project? • Standards specifically to support healthcare SOA • Community to establish “SOA service” definitions, demarcations, responsibilities, and behavoiur for core functions needed both within and across organizations • A joint effort involving HL7, OMG, Open Health Tools (OHT), and IHE HSSP’s Objectives: • To create useful, usable healthcare standards that address functions, semantics and technologies • To complement existing work and leverage existing standards • To focus on practical needs and not perfection • To capitalize on industry talent through open community participation

  29. The HSSP Asset Inventory…. • Healthcare Services Specification Framework • The methodology used to identify and specify services • “Boilerplate” documentation for the specification of future services • The Healthcare Reference Enterprise Architecture (under construction) • Implementation guidance to organizations implementing healthcare services • HSSP “Roadmap” -- The priorities, dependencies, relationships, and architectural context for healthcare services • Service Functional Models [describe the scope, behavior, and functions of services] • Entity Identification Service SFM [HL7 Balloted Draft Standard for Trial Use (DSTU)] • Resource Location and Update Service SFM [HL7 Balloted DSTU] • Decision Support Service SFM [HL7 Balloted DSTU] • Clinical Research Filtered Query SFM [HL7 Balloted DSTU] • Common Terminology Service SFM [Ballot expected 3Q2008] • OMG RFPs • Entity Identification Service RFP • Resource Location and Update Service RFP • Decision Support Service RFP • “SOA4HL7” Implementation Guide [HL7 Balloted Informative Document] • Actionable guide for HL7-based SOA implementations • Leverages existing standards in the context of SOA implementation

  30. Messaging Standards Terminology Standards “Functional” Standards Structured Doc Standards Services Standards Standards Profiling So, what do we do about… • HL7 • X.12 • NCPDP • ASTM • OMG • DICOM • IHTSDO/SNOMED • ICD • LOINC • IHE • CEN TC 251 • ISO TC 215

  31. Architecture

  32. Guiding Principles • Systems must add value to healthcare stakeholders (patients, caregivers, and organizations) • Information Technology (IT) cannot “fix” business problems • I.T. does not exist in a vacuum • We cannot optimize the continuum of care without considering flow between practitioners, departments, and facilities • A useful “tool” to understand large complex environments is to “separate concerns”*: • Business (Enterprise) View • Information View • Systems View • Technologies View • The difference between system success and failure lies in the “small stuff” – details matter! * *Separation of concerns based upon ISO RM-ODP Specification

  33. “Types” of Architecture

  34. What is architecture? What is Enterprise Architecture? Is Health Enterprise Architecture different? Why? Why do I care? Architecture forms the foundation for supporting and integrating IT and applications Enterprise Architecture is the discipline devoted to aligning IT investments with business needs Yes and no. The core concept is identical in healthcare as other industries. That said, the information and workflow complexities “change the game” Ultimately, systems will only fit within the fabric of a health organization if they are architected in. If not, we have standalone “one-offs” that impede workflow and adversely affect both patients and caregivers. Health IT, Enterprise Architecture, and Business Change

  35. “Enterprise Architecture 101” • The practice of aligning IT with business objectives • Identifying unplanned redundancy in work processes and systems • Rationalizing systems and planning investment wisely • Establishing target environment and a viable migration path • Addresses all facets of IT and the business: • Core business capabilities and business lines • Identification of business functions • Identification of IT needed to support the business • Multiple Views of IT: • Information content • Systems (computational) view • Technology (infrastructure) view • Process (engineering) view

  36. The Context for Healthcare Architecture… • …to serve as a catalyst positively influencing government health IT investments • …to galvanize the private sector through Government-demonstrated leadership • …to articulate and capture the “to be” and help organizations achieve it • …to characterize how and where approved standards are used • …to shape and frame interoperability intra- and inter-organizationally

  37. Driving to improve quality, care delivery, and organizational efficacy Eliminate unplanned redundancies Healthcare Business Transformation Improve reliability, information assurance, and capacity Integrated security mgmt Improve operations through performance mgmt and info assurance Security and Infrastructure Improvement Institute versioning of ontology and data Workflow improvement from HIT Drive solutions that promote health and are clinically viable Ability to budget, plan, execute SW development repeatably Realize value from existing data and software investment Promote interoperability by leveraging COTS, Standards, and SOA Data Management “Wrapper” existing applications with SOA interface Healthcare Informatics Legacy Enablement and Modernization Solution Integration and Software Development How do we use architecture to drive change? • Future Vision • Realize improved quality-of-care and cost-avoidance through HIT • Improved service delivery resulting from world-class HIT partner • Realize healthcare IT solutions that empower caregivers and beneficiaries • Facilitates patient involvement directly in their care (PHR) • Enables holistic view of health data, across enterprise and enterprises AlignAdaptTransform P4 P3 • Current Environment • Integration is within a point-of-care (but nt across points-of-care) • IT solutions are largely problem-specific or niche-based • Limited ability to support beneficiary-directed care and PHR • Inconsistent meanings and representations of data • Financials/claims not directly driven from clinical process P2 P1

  38. Driving to improve quality, care delivery, and organizational efficacy Improved efficacy, quality, and care delivery Deploy IT Governance Eliminate unplanned redundancies Baseline core org. business functions HIT-facilitated adherence to clinical protocol Increase asset utilization` Secure, redundant, high-availability infrastructure Healthcare Business Transformation Establish EA program Improve organizational agility Improved workflow Identify target operational objectives Enterprise Data Protections “Intelligent” EHR decision support Improve reliability, information assurance, and capacity IT Asset Management Evidence-based HIT Improved ‘scorecard’ grades Predictive Decision Support from EHR Phased side-by-side deployment of wrappered and refactored Integrated security mgmt Adaptive, agile, quality, repeatable delivery Improved FISMA Reporting Improve operations through performance mgmt and info assurance Establish terminology services bureau supporting evolution Deploy enterprise management tools Workflow improvement resulting from HIT adoption Security and Infrastructure Improvement Reduced number of incidents Institute versioning of ontology and data Normalize structures for complex data representation Data cleansing, transformation, load of redesigned apps Install access point controls Drive solutions that promote health and are clinically viable Determine basis for out-of-agency sharing Enterprise-wide interoperable data available and used by caregivers SOA Governance established and managed Identify and license medical knowledge sources Realize value from existing data and software investment Enterprise adoption of controlled medical vocabulary Promote interoperability by leveraging COTS, Standards, and SOA Data mapping and trans-formation from legacy Ability to budget, plan, and execute SW development repeatably Prioritize which and how much data is to be computable Informatician involvement in software life cycle Refactor, re-architect, re-design legacy applications Data Management Establish authoritative data sources Software development merges “agile” and CMMI practices Clinical data representationpromoting physician decision support Identify preferred codesets Improved ROI measurement “Wrapper” existing applications with SOA interface Clinical-oriented usability engineering Established culture of reuse and process improvement Remove point-to-point interfacing at transport layer (interface engines) Improvement compliance with architectural oversight Informatics involvement in requirements Improvement in resource competency-base Target applications for legacy enablement identified Promote community- experience sharing Healthcare Informatics Legacy Enablement and Modernization Solution Integration and Software Development Realizing sustainable health systems…. • Future Vision • Realize improved quality-of-care and cost-avoidance through HIT • Improved service delivery resulting from world-class HIT partner • Realize healthcare IT solutions that empower caregivers and beneficiaries • Facilitates patient involvement directly in their care (PHR) • Enables holistic view of health data, across enterprise and enterprises AlignAdaptTransform P4 P3 • Current Environment • Integration is within a point-of-care (but nt across points-of-care) • IT solutions are largely problem-specific or niche-based • Limited ability to support beneficiary-directed care and PHR • Inconsistent meanings and representations of data • Financials/claims not directly driven from clinical process P2 P1

  39. Bringing in Together…

  40. Guiding Principles • Seek to simplify the problem by separating “concerns”* • Business (Enterprise) View • Information View • Systems View • Technologies View • Leverage standards at interface points to minimize vendor proprietary risks • The difference between system success and failure lies in the “small stuff” – details matter! • “So, what does this have to do with MDA?”…. * Separation of concerns based upon ISO RM-ODP Specification

  41. High Ability to Interoperate Low Information Design and Technology & Semantics Designing for Interoperability Interoperability Standardized Templates Domain Services (Model Fragments) Custom "Vertical" Archetypes Domain Services (Knowledge & Structure) Enterprise Service Bus Reference Information Model Web Services/Middleware Standardized Vocabulary/Ontology Message Routing Standardized Data Types Messaging Specifications (HL7, others) Proprietary or Local Semantics Point-to-point Infrastructure

  42. An approach…. • Consider IT within the fabric of the enterprise • How does it integrate with workflow? • IT success must be evidence-based • Clarify IT responsibilities within your organization • Establish authoritative systems and data sources • Use standards “wherever systems touch” • Focus on information quality • Take a 20+ year view • The health record must be durable • The technologies will not be • You are not alone… • Healthcare is a community discipline • Organizations, systems, products, and technologies all play a role • There will be no single marketplace “winner”

  43. Make IT a Business Enabler • Conduct Enterprise Architecture planning to understand the business • What is the “state of affairs” today? • Where do we want to be tomorrow? • Work with the stakeholder community to identify desired outcomes • Focus early priorities on early returned investment • Identify and capture meaningful metrics • Validation should be “round trip” based upon observed impacts • Reflect IT as a function of the business • How effectively are business needs being captured? • How are stakeholder interests being assured during system implementation? • How are education, training, and process integration being addressed?

  44. Five success measures of your architecture… 5) Durable, with decreasing rate of change • Evolution, not revolution. If you get it right, changes become small and incremental 4) Standards-based, with variances that are localized to minimize impact. • Build on existing work • Depart only where you need to • Any time two things touch, that touch-point should be a standard • Product-neutral • Organizations cannot afford to base their entire future on a dependency of any one product • Clear • Make sure you architecture is understandable, concise, and accurate • Use “separation of concerns” and “viewpoints” • Make sure you architecture is suitable for its intent • Useful, as architectures that sit on shelves add no value.

  45. Five Keys For Overall Success • Leadership must come from the “business” community • Define success measures with meaningful business outcomes • Design your architecture to realize the impacts you hope to achieve • Recognize that while every organization is unique, their challenges aren’t • The future isn’t the hard part. Building it while you are “moving” is.

  46. SOA in Health Care: Realizing Quality of Care, Business Value, and Delivery on I.T.’s Promise Chicago, IL April 15-17, 2008http://www.omg.org/news/meetings/HC-WS/ • Three-day event featuring lessons-learned, best-practices, and experience sharing • Event features an “Executive Summit” followed by business & technical tracks • Representation from provider, payer, and public health communities • Featured speakers and panelists include • Jonathan White, M.D. Health IT Portfolio DirectorAHRQ • Vish SankaranProgram Director, Federal Health Architecture, ONCHIT • Ken LunnDirector of Data Stds and ProductsNational Programme for Health IT (UK) • Marion Ball, Ed.D.Fellow, IBM ResearchProfessor Emerita, Johns Hopkins • Steve FlamminiChief Technology OfficerPartners Health Care • Dennis GiokasChief Technology OfficerCanada Health Infoway • Don MonVice PresidentAHIMA • Stanley Huff, M.D.Chief Medical Informatics OfficerInterMountain Health Care

  47. Our Challenge… “It is cheaper and easier than ever to create badly designed applications and spaghetti integration.” Alan Honey, Enterprise Architect, Kaiser-Permanente

  48. References • Health Interoperability Portal (Launching soon!) • (educationally focused, this portal will contain information to help readers make informed decisions about health interoperability challenges and solutions) • http://healthinterop.org • HL7 Website: • http://www.hl7.org • HSSP “Wiki” • (contains all active project work, including links to each subgroup, adopted standards, and is the foundation for the HSSP community) • http://hssp.healthinterop.org • OMG Website: • http://www.omg.org

  49. Thank you! Ken Rubin Chair, OMG Healthcare Domain Task Force Healthcare Architect Kenneth_S_Rubin@omg.org ken.rubin@eds.com

More Related