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
Healthcare Services Specification Project (HSSP): SOA standards in Healthcare Alan Honey Enterprise Architect (Kaiser Permanente) Co-chair HL7 SOA SIG October 2007
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.
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 Reference Model
Also, other important components are:
Profile and Template / Static Model Registries
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
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
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?
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
Not necessarily good or bad …. Just different
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
HSSP Process for producing Service Specifications. Covers both Functional (HL7) and Technical (OMG) processes
Interim methodology (Balloted HL7 Informative document) for producing Service definitions in advance of Standards being availabe
Ongoing work with other HL7 committees (InM, MnM, ITS SIG) on new approaches to dynamic modeling
Part of the Dynamic Model work to consider similarities and differences between Services, Messaging and Document based methodologies and looking for commonality where possible.
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
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
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