| | | | | | | |

Healhcare Information Technology Standards Panel

HealthCare Information Technology Standards Panel

Did You Know....

HITSP members work together to define the necessary functional components and standards – as well as gaps in standards – which must be resolved to enable the interoperability of healthcare data.

HITSP Harmonization Framework

The HITSP Harmonization Framework defines a set of artifacts, known as "constructs", that:

specify how to integrate and constrain selected standards to meet the business needs of a Use Case; and
define a Roadmap to use emerging standards and to harmonize overlapping standards when resolved.

HITSP construct types, in decreasing breadth of scope, include:

Interoperability Specifications
Integration of all constructs used to meet the business needs of a Use Case
Transaction packages
Logical grouping of transactions
Transactions
Logical grouping of actions that use components and/or composite standards to realize the actions
Components
Logical grouping of base standards that work together, such as message and terminology

Specific rules exist for each construct type, defining what the construct type can be used for and how the construct types can be nested. 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.

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
Transaction Packages	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
Components	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

HITSP Member Workspace
(password required)

Public Review and Comment

HITSP and its Stakeholders

Learn more about how HITSP interacts with . . .