Download
1 / 45
450 likes | 661 Vues
Proposal for HITSP Framework Restructuring – Draft 1. For Review by HITSP IRT and HITSP Project Management. Introduction.
E N D
Proposal for HITSP Framework Restructuring – Draft 1 For Review by HITSP IRT and HITSP Project Management
Introduction • This proposal represents an analysis of the current HITSP framework and what changes might be needed to make the framework “services-aware”. It is intended as a high-level overview and does not contain all detail necessary. • This proposal includes 2 appendices: • Appendix A is a draft of what HITSP process changes might be involved • Appendix B contains a preliminary analysis of HITSP constructs as a service hierarchy.
Support both SOA and non-SOA implementations • HITSP is under pressure to support the development of service-oriented architectures (such as by the NHIN) • A new framework has to support the context of a Service-Oriented Architecture (SOA) • BUT, this new framework is not an SOA implementation • It is important to note that HITSP is NOT and CANNOT implement an SOA or an architecture • HITSP can, however, support the implementation of a reference architecture to provide clearer guidance to implementers.
Reduce overall size of HITSP work products • The Framework must at least support the reduction of “boilerplate” where needed and overall document size where appropriate • Concentrate boilerplate in one specific document and provide clear implementation paths (or orchestration) • Reduce the total number of constructs to support and maintain more reusability and extensibility. • However, a framework cannot necessarily change the overall size of work products immediately. A new framework should support a gradual transition to more reusability.
Make the framework more understandable • The framework must be clarified and streamlined to make it more succinct to understand and easy to use for both HITSP and non-HITSP stakeholders • Part of improving the framework will be how it is presented to both HITSP and non-HITSP members • 3 pieces would be needed to make the HITSP Framework complete • A short document that describes the framework – none exists now • A focused visual that clearly outlines how the framework pieces work together – visual is not well received currently • Examples to support how the framework would operate
Technical Committee flexibility and approval is critical • The technical committees must be willing to accept the new framework, so it must have 2 critical aspects to work: • It must be flexible enough to support some discretion by the TC • There is some ongoing perception that HITSP processes and deliverables cannot support SOA implementations • Framework must be flexible enough to support ALL implementations, not just one style. • It must be simple enough to implement AND transition to • Abstract ideas on SOA and services should be avoided. • Simplicity AT ALL COSTS.
Promote reuse wherever possible • Whenever and wherever possible, HITSP must promote reuse of work products through application of rules - • A service catalog where constructs are picked from (like a supermarket) • Common definitions of terms • Traceability to other health IT work products.
Draw on industry-standard terminology and methodologies • Clarification of terms is critical in a new framework as this causes confusion in reading HITSP work products • The words “actor”, “component”, and “transaction” have specific meanings in the system design and development world. HITSP has created definitions around these words that do not fit in an implementation context. • All definitions should be from usable sources in the real world and new terms should only be introduced if they are absolutely necessary. • A move to more common terminology provides better alignment from HITSP work products to other work products produced as part of the National Health IT Agenda
Business Services Inside a Domain Service DATA BUSINESS Common Infrastructure Services Proposed HITSP Framework (Draft) Communication Services Domain Services Emergency Health Plan PHR Medication EHR Laboratory Biosurveillance HITSP REFERENCE ARCHITECTURE Common Messaging Service Media Management Service Document Management Service Privacy Services Security Services HITSP Protocol Services Notify Push/ Pull Subscribe Alert Send/ Receive SERVICE INTERACTION PATTERNS Dynamic Routing One-to-Many Contingent USE CASE PERSPECTIVES Consumer Population Provider Care Management Admin & Finance ACTORS
Conceptual View of the HITSP Framework • Components – what I am exchanging • Transaction – how is it getting exchanged • Transaction Package – what are the steps involved in the exchange
Additional service terms applicable to HITSP • Atomic Service • A service visible to a service consumer via a single interface and described via a single service description that does not use or interact with other services. • Composite Service • A service visible to a service consumer via a single interface and described via a single service description that is the aggregation or composition of one or more other services. These other services can be atomic services, other composite services, or a combination of both
Common Infrastructure Services • Common Infrastructure Services support the low-level communication between use case perspectives and the HITSP Reference Architecture. They support all the common functions shared across use case perspectives. • These services act as a “layer” to isolate the HITSP Reference Architecture from use cases. Its role is to enable a unified gateway for use case perspective that wants access to the HITSP reference architecture. In creating this layer of independence, these common infrastructure services isolate any of the use cases from the intricacies and complexities associated with connectivity and integration
Business Services • Business Services handle the processing of specific transactions that may spread across multiple domains. They establish a context for processing and managing such transactions. Business Services manage orchestration flow, assembly of responses, and application of business rules and data access
Domain Services • Domain Services represent a collection of atomic and composite services (or other non-SOA business components) that encapuslate the shared logic specific to that domain. • For example, a Domain service would capture all the atomic services necessary to support medication management.
Communication Services • These service components deal with the network and application level protocols (transport is considered a common infrastructure service). These services should be able to support various application level protocols such as Web Services (WS-I), ebXML, SOAP, HL7, etc…to allow for both SOA and non-SOA implementations.
Detailed view of HITSP service structure Interoperability Specification 1 or more atomic and/or composite services with orchestration Composite Service Specification (Transaction Package) 1 or more atomic or composite services Atomic Service Specification (Transaction)
Appendix A Transition Plan Overview for new HITSP Framework
Proposed Technical Committee Guidelines • The technical committee focuses on selecting the service interface standards to be followed and selecting the supporting HITSP reference architecture components to be used • The technical committee focuses on defining service interaction patterns and their preferred reference implementations • The technical committee Defining the criteria to be used in determining when standardized data representations (common data models) should be employed in operation interfaces • The technical committee reviews the selection criteria for proposed services and the procedures for validating their appropriateness • The technical committee has discretion to choose a preferred architectural style for implementing services and the criteria to be used in selecting a style. This does not mean the selection of an architecture – it implies the selection of a style (such as SOA and non-SOA, distributed, cloud, etc…) • The technical committee establishes the preferred design patterns for content-based routing and the criteria to be used in selecting a pattern
Rules in the restructured framework • Every information exchange requirement must support a service (consume or provide) • Every Service specification can be mapped to a reference architecture component • Every Interoperability specification would be required to use the HITSP Service Catalog for the selection of services • An interoperability specification can consist of atomic services and/or composite services • HITSP can support multiple contexts by applying varying constraints or interactions in the infrastructure stack without specifying the stack itself
High-Level Process Flow Similar process flow would be used to make the transition to service development and testing easier to achieve.
What would HITSP produce? • RDSS Process becomes 3 distinct parts • RSS Profile (similar to RDSS without the D) • Service Specification (for newly designed constructs) – this is optional depending on context • Information Exchange Package (for newly designed IER or DR) – this is optional depending on context • Interoperability Specification process becomes focused on service orchestration
RSS Profile • The RSS Profile would be contextual and informational • The RSS Profile would describe the end-user functional requirements and assumptions inherent to the AHIC value case (or an outside organization’s standards harmonization request) • The RSS profile would establish when the specific use case perspective is expected to interact with the HITSP Reference Architecture. The profile would document only most common and critical interactions, not every possible interaction • For example, the use case perspective would be expected to use common privacy and security services provided as part of the HITSP Reference Architecture. Each of those services would continue as they are now in terms of standards supported • Scope should be broad enough to cover a large spectrum of healthcare and public health service delivery to achieve representative set of implementations.
Service Specification • Initial drafts are normative; they specify the interfaces between actors, systems, and services • Establishes a language to describe types of service requests made to the HITSP Reference Architecture • Positions which data to be exchanged by referring to information exchange packages • Assumes SOAP-based web services calls where requests and responses are carried between the use case perspective and the HITSP Reference Architecture • HOWEVER, provides support for non-SOA implementations through other application protocol types
Information Exchange Package • Represent what many components currently capture in the Component construct • Must be aligned to one or more IER’s and DR’s • Will use similar rules to components • Typically will use one “primary” standard and may have other “secondary” standards • Expresses constraints on base or composite standards • Terminology standards would be an example of a information exchange package • Messages ARE not information exchange packages – they are a way of transporting information
Interoperability Specification • Interoperability Specification is normative; specify inner workings to orchestrate and process service specifications and information exchange packages • Expresses sequencing of activities to process service interactions from the use case perspective • Expresses expected capabilities of services within the HITSP Reference Architecture to process service interactions
HITSP Service Catalog • The HITSP Service Catalog is the catalog of HITSP specifications and constructs and supporting information used to build them. • Each “Interoperability Specification” picks from the common menu of the HITSP Catalog to build the orchestration of services. • This may also be referred to in its “implementable” form as a HITSP service registry • Supports multiple implementations but becomes less detail-focused • The exposing of the HITSP Reference architecture – maintains complete architectural neutrality but support federation and flexibility that implementers require
HITSP Service Catalog • The service catalog represents the following attributes for HITSP constructs • A description of the HITSP construct • Timeframes or service contract for fulfilling the service • Who should use the service • How to fulfill the service • It would include the following reusable parts of the HITSP Reference Architecture • Actors • Components • Information Exchange Packages (Components) • Service Specifications • Atomic Services • Composite Services • Information Exchange Requirements • Data Requirements
Appendix B Proposed Conversion of Existing HITSP Constructs to HITSP Service Hierarchy
Component Construct Transition Plan Overview • HITSP would maintain existing component definition with some modification to the structure of component construct documents • Components would be renamed to “Information Exchange Packages” • Some effort to consolidate the current number of components would be made, in the context of supporting reusable information exchanges • The key step in transition is to ensure that the number of components is reduced without impacting the quality of any specifications
Transaction Construct Transition Plan Overview • Transactions would be similar in scope and design where appropriate. • Some effort needs to be made to both consolidate the existing number of transactions and add additional transactions to support robustness – transactions in a service “world” would ideally be atomic services. • For those transactions that are not clearly adaptable to becoming an atomic service, consider whether it is an information exchange package or whether it needs to exist. • Goal is to streamline transactions to make them more understandable and easy to implement as services
Transaction Package Transition Plan Overview • Transaction Packages would be similar in scope and design where appropriate. • Ideally would represent the common infrastructure services and business services needed by the use case perspectives (could also be part of domain services)
