1. 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. Healthcare Information Technology Standards Panel
HITSP Framework
September 15, 2007

3. 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 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 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 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

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

8. 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

9. 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

10. 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

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

12. 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. 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. Fundamental Relationships

15. 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.