Your SlideShare is downloading. ×
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
2007_10_HSSP_BCBS_0-1.ppt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

2007_10_HSSP_BCBS_0-1.ppt

261

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
261
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Arc Building blocks Solve problems and create opportunities for a developer / architect to improve healthcare with technology Should make sense from the point of view of an organization (efficiencies, management)
  • HL7 brings… Healthcare semantic interoperability expertise Rich, extensive international community perspective Diverse membership base OMG brings Distributed systems architecture and modeling excellence Effective, efficient, rapid process Premise that standards must be implemented
  • HL7 supports the requirements modeling and through a ballot process, issues a Draft Standard for Trial Use. OMG supports open standards, and supports a technically rigorous process to issue RFPs and vote on submissions. The final draft of the HL7 DSTU, which is influenced by the RFP Responders, can go on to become an American National Standards Institute (ANSI) standard Becoming TC …..
  • The services in Green are already DSTUs. They cover quite a bit of territory: Entity Identification (EIS): Provides capabilities to manage and retrieve identifying information for various kinds of entities (people, organizations, devices etc.). Retrieve, Locate, Update (RLUS): Provides capabilities through which information systems can access and manage information. RLUS allows health data to be located, accessed and updated regardless of underlying data structures, security concerns, or delivery mechanisms. Common Terminology (CTS I): Note – this service pre-dated HSSP. This provides capabilities to manage and access terminologies through two APIs, Message and Vocabulary. Decision Support (DSS): Provides machine-interpretable, patient-specific assessments and recommendations given requisite data.
  • Describe Functional, Semantic and Conformance profiles
  • In a SOA the business is first - IT and SOA principles derive from Business Principles Run time policy management (conformance checks) based on declarative rules.
  • Teleconferences usually weekly; meetings (HL7 or OMG) approximately bimonthly
  • Transcript

    • 1. Healthcare Services Specification Project (HSSP): SOA standards in Healthcare Alan Honey Enterprise Architect (Kaiser Permanente) Co-chair HL7 SOA SIG October 2007
    • 2. Agenda
      • HSSP Overview
      • Background
      • What is HSSP?
      • Deliverables and Status
      • Roadmap and Reference Architecture
      • Methodology
      • Technical Specification - RFP Process and submissions
      • Value Proposition and Getting Engaged
      • Questions / Discussion: (Open)
    • 3. Audience Assumptions
      • Familiarity with SOA concepts and the basic value proposition of SOA
        • Business agility
        • Cost and efficiency (especially integration)
        • Simpler (at least it should be)
      • Familiar with messaging standards (HL7, X.12 etc.)
        • HL7 V2.x: well established in US but has well publicized weaknesses
        • HL7 V3 (separates model from implementation, which is in all known cases based on XML) but heavy infrastructure and difficult to implement
    • 4. Refresher: Web Services v Services v SOA
      • Web Services is technology (a platform in OMG-speak)
        • Classic web services stack: XML, SOAP, WSDL, UDDI
        • Usually HTTP based, but may use MQ (JMS, AMQP) or SMTP
        • Can support SOA, but also can support messaging or document paradigms
      • Services
        • Well defined Functional Components, cohesive collections of business or infrastructure functionality, exposed through well-defined interfaces
        • Separation of interface from implementation, service clients depend on the interface contract only, not internals of the implementation.
    • 5. Refresher: Web Services v Services v SOA
      • Service Oriented Architecture
        • Overall cohesive framework and approach for defining and using Services, with a focus on business perspective.
        • Architecture focus: e.g. loose coupling, separation of concerns
        • Focus on model driven solution delivery
        • Common, standards-based infrastructure for distributed computing, providing the “…ilities” (availability, reliability, scalability, performance)
        • Uses declarative policies / rules to drive decisions in processing
        • Complements Business Process automation, separation of Process from Service
        • SOA does NOT actually require Web Services, however web services is the technology that is being used to deliver it today by almost every organization doing SOA and this will continue for the foreseeable future.
    • 6. Evolution of SOA/Services in HL7
      • Web Services as Transport (Phase 1)
        • HL7 WS Profile
      • Web Services as Enabling Technology (Phase 2)
        • SOA 4 HL7
        • Provides some degree of durability
      • Standard Services (Phase 3) – In Progress
        • HSSP Service Specifications
        • Services Interoperability Paradigm
      • SOA (Phase 4) - Future
        • Compliant with Reference Architecture
          • Metamodel
          • Implementation Guides
          • Profile Registry
          • Template / Static Model Registry
    • 7. Healthcare Service Specifications
      • Take good principles and practices learned from standardizing messaging and apply to Services, OR…
      • Tie good SOA practices and patterns to the rich models of HL7, CEN, OpenEHR
      • Create true Interoperability specifications, not just Integration specifications
      • Provide architectural building blocks
      • Helping to make SOA a reality for healthcare organizations that mainly buy vendor software, and providing direction for those that build.
    • 8. Agenda
      • HSSP Overview
      • Background
      • What is HSSP?
      • Deliverables and Status
      • Roadmap and Reference Architecture
      • Methodology
      • Technical Specification - RFP Process and submissions
      • Value Proposition and Getting Engaged
      • Questions / Discussion
    • 9. What is HSSP?
      • The Healthcare Services Specification Project (HSSP) is a joint venture between Health Level 7 (HL7) and The Object Management Group (OMG).
      • HSSP relies on HL7’s national and international domain expertise and world-class information models to provide Functional requirements and specifications
      • OMG brings the technology industry to the table by issuing a Request for Proposal (RFP). Submitting organizations create the Technical Specification
      • HSSP is young – it has been around for around 2 years or so, and is growing
    • 10. What is HSSP?
      • An effort to create common service interface specifications for Healthcare IT
      • Its objectives are:
        • To create useful, usable healthcare standard services that address functions, semantics and technologies
        • To provide a framework for tying the specifications together into a coherent overall Service Oriented Architecture
        • To complement existing work and leverage existing standards where possible
        • To focus on practical needs and not perfection
        • To capitalize on industry talent through open community participation
      • Participation (past and current) from many organizations, including: VA, DoD, NCI, HL7 Finland/SerAPI, HL7 Australia, Ocean Informatics, Kaiser Permanente, CSW (UK), Intel, IBM, Oracle, Software Partners, Northrop Grumman, Initiate Systems, many others
    • 11. The HSSP Process OMG HL7 HL7 DSTU Service Functional Model OMG RFP Technical Specification ANSI Standard
    • 12. Agenda
      • HSSP Overview
      • Background
      • What is HSSP
      • Deliverables and Status
      • Roadmap and Reference Architecture
      • Methodology
      • Technical Specification - RFP Process and submissions
      • Value Proposition and Getting Engaged
      • Questions / Discussion: (Open)
    • 13. What has HSSP delivered to date?
      • Functional Specifications - HL7 DSTUs:
        • Decision Support Service (DSS) receives patient data as the input and returns patient-specific conclusions as the output
        • Retrieve, Location, and Update Service (RLUS) provides a set of interfaces for accessing and managing health information
        • Entity Identification Service (EIS) for identification of patient, providers and other entities participating in the care
      • OMG-issued technical Requests for Proposal (RFPs) finalized or drafted for all DSTUs
        • Initial Submissions received for RLUS and EIS and LOIs from four organizations for DSS
      • A Service Specification Framework (methodology) for developing the service specifications
      • An informative HL7 ballot document on Messaging-to-SOA Transition Methodology (SOA4HL7)
    • 14. Current Service Specifications
    • 15. Other Current HSSP Activities
      • Reference Architecture
        • - Taxonomies
        • - Business Rules
        • - Choreographies
        • - Service Meta-model
        • - Implementation guide
      • Profiles
      • Methodologies
      • Template Registry
      • Evangelizing SOA within the Healthcare community
      • Technical Specifications (EIS, RLUS, DSS)
    • 16. Agenda
      • HSSP Overview
      • Background
      • What is HSSP
      • Deliverables and Status
      • Roadmap and Reference Architecture
      • Methodology
      • Technical Specification - RFP Process and submissions
      • Value Proposition and Getting Engaged
      • Questions / Discussion: (Open)
    • 17. Roadmap and Reference Architecture
      • Roadmap: High level summary of HSSP Services work and direction – v1.0 complete and published on HSSP Wiki.
      • Reference Architecture: Detailed framework relating services wihin an overall Service Oriented Architecture (work in progress). Includes:
        • SOA Principles
        • SOA Reference Model
        • Service Taxonomy
        • Service Portfolio
        • Governance
        • Methodologies
      • Also, other important components are:
        • Profile and Template / Static Model Registries
        • Tooling Support
    • 18. Services Taxonomy (example) SOA Business Functional Business Information Infrastrucutre Information Infrastructure Functional Business Process Business Functional: (e.g. Lab Order Management Service) Infrastructure Functional: (e.g. Choreography Engine, Logging) Functional Business Information: (e.g. RLUS Retrieve CCD Service) Infrastructure Information: (e.g. RLUS Update Security Key Service) Information Focus Business Infrastructure Layer HSSP Service Taxonomy
    • 19. Service Portfolio (example)
    • 20. Services Metamodel
    • 21. Service Profiles
      • Service definition defines consistent overall functionality based on business requirements
      • Profiles provide means to specialize and test conformance (for function and information)
      Service Instance (e.g. EIS) Service Instance (e.g. EIS) Semantic Signifiers Business Drivers Business Service Realizes Realizes Functional Profile Semantic Profile
    • 22. Principles and Policies: The foundation of SOA Governance Governance Business Principles / Objectives IT Principles SOA Principles IT Architecture (SOA, Service Interfaces) Methodology and Standards HSSP Policies Service Instances Conformance?
    • 23. Service Design - The Semantic Spectrum
      • Why does this matter?
        • Affect the way that your governance model will work
        • Affect the way you will structure your services
        • Affect how you will (or won’t) maintain architectural integrity
          • Development and Design
          • Reusability
          • Contracts
          • QoS
      • Not necessarily good or bad …. Just different
      Information Function
    • 24. Spectrum of Semantics (Function and Information) Functional semantics encompass informational semantics. Zero reusability. Silly. Demographic Service Ack:ChangeKenAgeTo25() 9 Functional semantics are very explicit, information supports functionality implicitly. Classic OOP without any design or reuse. Inappropriate functional granularity. Demographic Service Ack:ChangeKenAge(age age ) 8 Functional semantics are reasonably explicit, information supports functionality implicitly. Classic OOD Demographic Service Ack:ChangeAge(person person , age age ) 7 A constrained and functionally complete DAM, neatly mapped to both information and functional semanitcs Lab Order Management Service Ack:CreateLabOrder(order order ) Order:LabOrderNotification() 6 As above with more tightly constrained information semantics, as well as a more constrained DAM RLUS with a LabOrderManagement Profile LabOrder:Retrieve(labOrderTraits traits ) 5 Functionally simplistic, but reasonably mapped to business semantics because of the constrained information semantics and a manageable DAM RLUS with an Order Management Profile Order:Retrieve (orderTraits traits) 4 Functionally simplistic, but bound to variable Information. Business semantics are not explicit RLUS (without a profile) Stuff: Retrieve (stuffTraits traits ) 3 Information is explicit in the object through early binding, while the functionality is fixed REST style HTTP GET, PUT 2 Behavior is enclosed in the message and is not expressed in the operation MessageHandler Ack:Do(message message ) 1 Notes Potential Interface Operation Signature
    • 25. Agenda
      • HSSP Overview
      • Background
      • What is HSSP
      • Deliverables and Status
      • Roadmap and Reference Architecture
      • Methodology
      • Technical Specification - RFP Process and submissions
      • Value Proposition and Getting Engaged
      • Questions / Discussion: (Open)
    • 26. HSSP Methodology Work
      • SSF
        • HSSP Process for producing Service Specifications. Covers both Functional (HL7) and Technical (OMG) processes
      • SOA4HL7
        • Interim methodology (Balloted HL7 Informative document) for producing Service definitions in advance of Standards being availabe
      • Dynamic Model
        • Ongoing work with other HL7 committees (InM, MnM, ITS SIG) on new approaches to dynamic modeling
      • Interoperability Paradigms
        • Part of the Dynamic Model work to consider similarities and differences between Services, Messaging and Document based methodologies and looking for commonality where possible.
    • 27. Towards an HL7 Design Methodology Orchestration, Choreography, and Interaction Patterns Contents: Domain & Document Models Trading Partner Agreements: Binding Services and Content Models Made by HL7, IHE, Realms, Projects Messaging: Binding the Services and Contents to a transportation Platform (HL7 Wrappers & ATS) Services Interoperability Paradigm
    • 28. Agenda
      • HSSP Overview
      • Background
      • What is HSSP?
      • Deliverables and Status
      • Roadmap and Reference Architecture
      • Methodology
      • Technical Specification - RFP Process and submissions
      • Value Proposition and Getting Engaged
      • Questions / Discussion: (Open)
    • 29. Technical Specifications and RFPs
      • Coordinated by OMG Healthcare Domain Task Force (DTF)
      • HL7 SFM used as basis for Request for Proposal (RFP)
        • Request for specification of a platform-independent model (PIM) and at least one platform-specific model (PSM) (e.g. SOAP/XML) conforming to SFM requirements
      • Letters of intent to specify and implement within 12 mo.  initial specifications  single revised specification based on merged efforts
      • Approval by Healthcare DTF  Architectural Board  Technology Committee  Board of Directors
      • Specification not adopted unless at least one implementation available commercially
    • 30. OMG Technology Adoption Process
      • Any interested vendor with OMG membership may submit
      • No submissions pass on initial submission
      • Vendors choose to partner to form joint submissions 95% of the time
      • All OMG standards are reviewed by OMG Architecture Board
      • The speed of the adoption is driven by marketplace pressure, not the process
      • The standards committee may either accept or reject submissions – nothing more
      • The approach assures business relevance and promotes rapid timelines and quality
      • The OMG Standard is published when software is available
    • 31. Feedback loop to HL7
      • DSTU is ideally suited to this process
        • Allows two years for “practical experience”
        • OMG Technology adoptions are typically 18 months
      • Throughout the process we will collect ‘lessons learned’
      • Outcomes of the technology adoption will be incorporated and balloted into the SFM
    • 32. Current RFP Progress
      • EIS
        • Submission Team: Intel, Software Partners, Ocean Informatics, Initiate, NG, Satyam (also Oracle, Care Data).
        • Initial submission discussed in Jacksonville in September. Working on revised submission, including profiles for V3, V2 and OpenEHR.
      • RLUS
        • Submission Team: Intel, Software Partners, Ocean Informatics, NG, Satyam (also Oracle).
        • Initial submission discussed in Jacksonville in September. Working on revised submission, including profiles for V3, V2 and OpenEHR
      • DSS
        • Submission Team (forming): Software Partners, Religent, 88Solutions (also EDS, CDC, MHS)
        • Work just starting on technical specification.
        • Discussions with IHE progressing
    • 33. Agenda
      • HSSP Overview
      • Background
      • What is HSSP
      • Deliverables and Status
      • Roadmap and Reference Architecture
      • Methodology
      • Technical Specification - RFP Process and submissions
      • Value Proposition and Getting Engaged
      • Questions / Discussion: (Open)
    • 34. Value for Kaiser Permanente
      • Integration is very expensive, mainly COTS vendor packages (HL7 for clinical, also X.12, DICOM, others) mainly batch or messaging, and changes slow and difficult
      • Turned to SOA to address this problem, however no standard service interfaces, and each vendors services very variable, semantically and technically. Good lessons learned from messaging standards not being applied to Services
      • Part of initial HSSP kick-off and have been promoting the development of Service standards ever since. Return is long term but perceived to be very significant
      • Apply pressure on software vendors to produce standard interfaces
    • 35. More value … Lower cost = wider deployment = higher quality service Participation by provider and payer community is direct expression of business need Requirements definition – influence vendors in a direct way Availability of an industry-accepted component interface eases product development burden Time to market Unity in purpose and consistency in interface eases integration burden Facilitates integration Consumer demand will create increased marketplace competition Increased buyer/product offerings Using compliant products means side-by-side interoperation of multiple product offerings Multiple vendor product use/ interoperability Standard interfaces means that conformant components are substitutable Consistency at the interface level assures asset protection Specifications will support multiple topologies and technologies Promotes deployment ease and flexibility Rationale Value
    • 36. Why participate?
      • This effort is focused on and driven by business-need
        • It is not an “academic exercise” striving for perfection
        • For standards to be useful they must be used
        • Focused on the practical and achievable
        • Based upon business value and ROI
      • Being run like a “project” and not a committee
      • Recognize participation as an investment and not an expense
      • Significant “networking” opportunities—you will gain access to the best and brightest in the industry and the world
      • Prime opportunity to directly engage with complementing stakeholder groups (provider-to-vendor, vendor-to-payer, SDO-to-SDO, etc)
      • Benefit from “lessons learned” from others
      • Establish market presence and mindshare as industry leader
      • This is happening—the only way to influence the outcome is to engage
    • 37. How do I Participate?
      • Determine areas of interest and priorities
        • Involvement in current specification work?
        • New Profiles for existing services (any time) ?
        • Propose New Service needs (any time) ?
        • Reference Architecture?
      • Allocate resources to actively engage in the project
        • Engage knowledgeable resources in the areas they are working already in day job
        • Involve the staff that can best address your business needs
        • Organizations that commit resources garner more influence and more mindshare
        • Your business interests are being represented by your attendees
    • 38. 2008 HSSP Schedule (planned, major milestones) Dec: OMG Santa Clara (Dec 8-12) Jun : OMG Ontario (CA) (Jun 23-27) EIS, RLUS RFP Finalization? Nov: May : HL7 Phoenix (May 4-9) (possible CTS II, Provider/Services Directory SFM Ballots) Oct: Apr: SOA in Healthcare conference (Chicago) Organized by HSSP Sep: HL7 Vancouver (Sep 14-19) OMG Orlando (Sep 22-26) Mar: OMG Washington (Mar 10-14) EIS, RLUS RFP Final submissions DSS RFP Initial Submission Aug: Feb : Jul: Jan : SFM Ballots (CRFQ, Security) Publish Reference Architecture v1? HL7 San Antonio (Jan 13-18)
    • 39. References
      • HL7 Website:
          • http://www.hl7.org
      • OMG Website:
          • http://www.omg.org
      • Services Project Homepage
          • http://www.healthinterop.org
      • QUESTIONS ?

    ×