1 HITSP – enabling healthcare interoperability Current Framework and Fundamental Concepts  For those unfamiliar with the HITSP Harmonization Framework and Fundamental Concepts, these are attached as references. –HITSP Harmonization Framework –HITSP Fundamental Concepts

2 HITSP – enabling healthcare interoperability Healthcare Information Technology Standards Panel HITSP Framework September 15, 2007

3 HITSP – enabling healthcare interoperability HITSP Approach  Use Harmonization process to define a set of artifacts called constructs that –Specifies how to integrate and constrain selected standards to meet the business needs of a Use Case –Defines Roadmap to use emerging standards and to harmonize overlapping standards when resolved  The HITSP Framework describes –Types of constructs that could be used to specify how to meet the needs of a Use Case. –Defines specific rules for each construct type, including: What a construct type can used for. How construct types can be nested.

4 HITSP – enabling healthcare interoperability HITSP Harmonization Framework  HITSP construct types, in decreasing breadth of scope, include: –Interoperability Specification – integrates all constructs used to meet business needs of a Use Case –Transaction packages – Logical group of transactions –Transaction - logical group of actions that use components and/or composite standards to realize the actions –Components - groups of base standards that work together, such as message and terminology  Each construct: –May contain construct types that are less inclusive in scope –May constrain any construct or standard it contains. –May be constrained by any construct that contains it –Is a candidate for reuse and repurposing, if a new set of requirements and context can be fulfilled by the construct without impacting existing uses of the construct –Is uniquely identified and version controlled

5 HITSP – enabling healthcare interoperability HITSP Terminology  HITSP documents are referred to as constructs  There is a hierarchical framework for constructs to facilitate re-use  An Interoperability Specification is a set or collection of constructs of various document types: –ISx: “root” document, sets the context of use for all the constructs in the collection –TPx: a transaction package invoked by the IS, may have additional constraints stated in the IS –Tx: a transaction invoked by the IS, may have additional constraints stated in the IS or TP –Cx: a component invoked by the IS, may have additional constraints stated in the IS, TP, or T  Technical Notes (TNx) provide additional informative content, but are not required for implementation

6 HITSP – enabling healthcare interoperability HITSP Framework Use Case/Modification Request Interoperability Specification (1..m transaction packages, transactions, or components) Transaction Package (1..m transactions or composite standards) Transaction (1..n components or composite standards) Component (1..c base or composite standards) Base Standard #1 Base Standard #4 Base Standard #2 Base Standard #3 Component (Composite) Standard Transaction (Composite) Standard Transaction Package (Composite) Standard Defines and Narrows Context Base Standard #5 Base Standard #6 Base Standard #7 Standard s Organiza tion Potential for Reuse in Other Contexts

7 HITSP – enabling healthcare interoperability LevelDefinitionExampleRules Use Case or Harmonization Request  Defines business and functional requirements Interoperability Specification – to meet use case  Models business, functional, interoperability requirements to meet Use Case  Identifies technical system requirements to meet Use Case  Set context for constructs used  HITSP EHR Interoperability Specification  Identifies technical actors and actions  May include any other HITSP construct - components, transactions or transaction packages  Expresses constraints on HITSP constructs used Definitions and Rules

8 HITSP – enabling healthcare interoperability Definitions and Rules (continued) LevelDefinitionExampleRules Transaction Package  Defines how HITSP constructs are used to support a stand- alone information interchange within a defined context between two or more systems  Record Locator Service  Entity Identificatio n Service  Manage Sharing of Documents  Thin context and interoperability requirements that are testable  Addresses like technical actors, context, and content  May use and constrain two or more transactions and/or one or more composite standards  In special circumstances, may use and constrain infrastructure or security component constructs Transaction  Logical grouping of actions, including necessary content and context, that must all succeed or fail as a group.  Query lab result  Send lab result  Fulfills actions between systems needed to meet one or more interoperability requirements  Testable  May use components or composite standards  Express constraints on composite standards or components used

9 HITSP – enabling healthcare interoperability Definitions and Rules (continued) LevelDefinitionExampleRules Component  An atomic construct used to support an information interchange or to meet an infrastructure requirement (e.g., security, logging/audit)  Lab result message  Lab result context  Typically will use one “primary” standard and may have other “secondary” standards  Expresses constraints on base or composite standards used Technical Note  Used to give additional guidance and direction to HITSP analysis process, as well as background information for implementers  TN900 – Security and Privacy  Does not state any constraints

10 HITSP – enabling healthcare interoperability Composite and Base Standards LevelDefinitionExampleRules Base Standard  A standard capable of fulfilling a discrete function within a single category produced and maintained by a single standards organization.  Messaging standard  Security standard  Code set. HITSP definition of “standard” includes: –Specifications –Implementation Guides –Code Sets –Terminologies –Integration Profiles Composite Standard  Grouping of base standards, often from multiple standards organizations, maintained by single organization. In HITSP, it can fulfill functional requirements for a component, transaction or transaction package.  IHE Integration Profiles  HL7 Implementation Guides  Health transaction services Per Definition above

11 HITSP Fundamental Concepts Internal Review Team (IRT) Report 22 Oct 08 | IRT Meeting TC Members Charles Parisot (co-chair) Steve Hufnagel (co-chair) David Tao Durwin Day IRT Report to TC Leadership Staff Members Bob Yencha Ed Larsen Gene Ginther Jack Corley

12 HITSP – enabling healthcare interoperability Topics Under Review  Definitions of fundamental concepts and their relationships (Done)  Definition and numbering harmonization across documents(In Progress) –Stakeholders, Business Actors, Technical Actors –Information Exchange and Data Requirements (IERs, DRs)  Making HITSP documents easier to use (in Progress) –RDSS a living document; focus on Section 2: Requirements Analysis –IS emphasis on Section 3: Design

13 HITSP – enabling healthcare interoperability Fundamental Concepts  Stakeholder - person, organization or “personified system” that performs actions in a use-case.  Business Actor – an abstraction that is instantiated as an IT system application that a Stakeholder uses in the exchange of data needed to complete use case action(s); a Business Actor is not a Stakeholder.  Technical Actor - the abstraction that is instantiated as an IT system interface that interacts with other Technical Actors. A Technical Actor supports the data exchanges for a Business Actor. The exchanges are defined by HITSP Transaction, Transaction Package, and Component constructs.  Information Exchange Requirement (IER) - describes a requirement for information exchange between HITSP Business Actors. Data contents of such an exchange is defined by associated Data Requirements.  Data Requirement (DR) – defines requirements for part or all of the content for a data exchange for one or more IERs as a set of information attributes with specific details for each attribute.

14 HITSP – enabling healthcare interoperability Fundamental Relationships

15 HITSP – enabling healthcare interoperability Fundamental Relationships Stakeholder IERs & Associated DRs B. Actor T. Actor Transactions & Associated Content Requirements Analysis Specification of Interoperability n Construct IS Supports  Transaction - a logical grouping of data exchanges and data exchange methods that must all succeed or fail as a group. A transaction is specified in a Transaction Construct.  Content – data exchanged among HITSP Technical Actors. When specified separately, content is specified in Component Constructs. Events, Actions & Exchanges B. Actor