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

Healthcare Information Technology Standards Panel HITSP Framework September 15, 2007

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.

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

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

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

Definitions and Rules Level Definition Example Rules 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 (continued) Level Definition Example Rules 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 Identification 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

Definitions and Rules (continued) Level Definition Example Rules 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

Composite and Base Standards Level Definition Example Rules 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

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 Staff Members Bob Yencha Ed Larsen Gene Ginther Jack Corley IRT Report to TC Leadership

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

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.

Fundamental Relationships

Fundamental Relationships Events, Actions & Exchanges Stakeholder Stakeholder Supports Supports Requirements Analysis B. Actor IERs & Associated DRs B. Actor 1-1 1-1 IS B. Actor B. Actor Specification of Interoperability 1-n 1-n Transactions & Associated Content T. Actor T. Actor Construct 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.