Transcript HITSP Data Architecture - HSSP

HITSP Data Architecture
Proposed Bottom Up Approach to Constructing an Information Model
A Health IT Business Architecture can be modeled as clinical stakeholders and their workflow-orchestration of
system-functions, defined by the HL7 EHR System Functional Model. HITSP Capabilities group and specify system
roles, information exchanges and system interfaces to support one-or-more system functions with standards-based
data models and standards-based interface specifications, which may be implemented as services.
An Information Model, for a project or enterprise, can be created from the capability data models of a Business
Architecture, categorized using the HL7 RIM foundation classes.
13 Nov 09 | Version H, last updated 20 Nov 09
[email protected]
[email protected]
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model
Slide 0
HITSP Data Architecture
Table of Contents

HITSP Harmonization Framework Overview
1- 4

HITSP Data Architecture
6-14

HL7 Reference Information Model
15

Summary
16

Building an Information Model for a Business Architecture

BACKUP SLIDES
– EXAMPLE: HITSP C154 Data Dictionary entry for Person
17-20
22-25
– Assumptions: Framing the issue on Data Dictionary
26
– Requirements: Framing the issue on Data Dictionary
27
– Framing the issue on Data Dictionary
28-31
– Key HITSP Reference Documents
32-33
– HITSP Constructs for Eligibility & Authorization
– Six HL7 RIM Foundation Classes
– Basic UML Legend
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model
34
35-38
38
Slide 1
HITSP Harmonization Framework
IS = Interoperability
Specification
Addressing
Business
Needs
Defining
Information
Content
IS
Capability
Service
Collaboration
Transaction,
Transaction Package
Available
for Independent
Implementation
Providing
Infrastructure,
Security,
Privacy
Components
Data Architecture
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model
Slide 2
Observation
 Implementing HITSP Specifications
– ISs typically broad and complex, seldom adopted in entirety.
– Capabilities and Service Collaborations intended to be the “bottom
level” independently implementable constructs.
– Individual Transactions, Transaction Packages, and Components too
narrow.
 Primary organizing logic for capabilities
– Distinct business need, that could be understood by Policy and
Business Analysts
– Should not overlap at the business level.
– To help implementer, business analyst, or policy maker “find” the right
Capabilities that contain things of interest to them
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model
Slide 3
EXAMPLE: HITSP/CAP141
Communicate Referral Authorization Capability
cmp CAP141 Communicate Referral Authorization - System Roles
Clinical Care
Authorization Requestor
Clinical Care
Authorization Provider
Pharmacy Authorization
Requestor
Pharmacy Authorization
Provider
cmp CAP141 Communicate Referral Authorization - Interfaces
Respond to Administrative
Transport to Health Plan
CAP141 Communicate Referral Authorization
Request Administrative
Transport to Health Plan
HITSP/SC114 – Administrative Transport to Health Plan
HITSP/T68 Patient Health Plan Authorization Request and Response
HITSP/T79 Pharmacy to Health Plan Authorization Request and Response
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model
Slide 4
HITSP Conformance

To implement a HITSP Capability, a system must identify one or more
System Roles specified by the Capability that the system will implement.

A system is conformant to that HITSP Capability if, for each of the
Capability’s System Roles that the System is implementing:
– The System supports all interfaces specified by the HITSP Capability
for the underlying HITSP constructs according to the conditions
specified for the System Role.
– For each option offered by the Capability that is stated to be supported
by the system implementation of that capability, the implementation
conforms to the Capability’s specifications for that option.
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model
Slide 5
HITSP Documents are available at www.HITSP.org
Detailed HITSP Data Architecture is available online at www.USHIK.org
HITSP Data
Architecture
within HITSP
Harmonization
Framework
class Data Architecture
ARRA Requirement for
Certified EHR Systems
ARRA Meaningful Use
Measures
Scenario
EHR System Interoperability Specifications
Information Exchange
Requirement (IER)
Data Requirement
(DR)
+
+
+
+
+ Data Module
Legend
requirements
design
+ Stakeholder
+ conditions
Regulatory
Guidance
Systems
Exchange Content
Exchange Action
Exchange Attribute
Certification
Criteria
+ Capability
Capability
GREEN
indicates
reusable
elements
Capability Design
+ conditions
+ optionality
+ system role
Capability Requirements
+
+
+
+
Information Exchange
option
Scenario
system role
Data Architecture
HITSP Constructs
Component (C)
HITSP/TN901 - Technical Note
for Clinical Documents
Data Module
HITSP/C83 - CDA Content
Modules Component
Data Element
HITSP/C154 - HITSP Data
Dictionary
Service Collaboration (SC)
Transaction (T)
Transaction
Package (TP)
HITSP/TN904 - Harmonization Framework and
Exchange Architecture Technical Note
Value Set
Selected Standard
HITSP/ C80 - Clinical
Document and Message
Terminology Component
HITSP/TN903 - Data
Architecture Technical Note
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model
Slide 6
Data Requirements (DRs) and
Exchange Contents (ECs)
 ECs and DRs are unique and numbered globally for
reuse and described in a reference document
 ECs and DRs are Requirements that map to Design
– ECs map to a single HITSP Component. A single Component
may have multiple Exchange Contents mapped to it.
– DRs map to one or more Data Modules defined in C154 - HITSP
Data Dictionary. A Data Module may map to multiple DRs.
 Relationship between ECs, DRs, and Data Elements
– An EC has unique set of DRs, DRs may be used in multiple ECs
– DRs have multiple data elements, data elements may appear in
multiple DRs
 When ECs and DRs used, constraints can be used to eliminate
data elements in a DR or DRs in an EC
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model
Slide 7
HITSP Data
Architecture:
allows HITSP to
identify similar data
elements used in
various relevant
standards and
consistently constrain
its expression across
those standards to
maximize reuse and
interoperability.
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model
Slide 8
HITSP Data Architecture (detailed)
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model
Slide 9
HITSP Clinical Document Constructs
New HITSP reuse Paradigm:
With HITSP/Capability 119
(Communication of Structured
Documents), a CDA clinical
note can be composed, from
any group of C83 data modules,
and then be communicated.
Benefit is agile system
interoperability.
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 10
HITSP/C83 Data Module Categories
Module Category
Description
Personal Information
The personal information includes name, address, contact information, personal identification information, ethnic and racial affiliation and marital status of a person
Support
Support includes the patient's sources of support, such as immediate family, relatives and/or guardians. This includes next of kin, caregivers, support organizations, and
key contacts relative to healthcare decisions. Support providers may include providers of healthcare related services, such as a personally controlled health record, or
registry of emergency contacts
Healthcare Providers
This includes a list of the healthcare providers and organizations that provide or have provided care to the patient
Insurance Providers and
Payers
Insurance providers include data about the organizations or individuals who may pay for a patient's healthcare, and the relationships, demographics and identifiers of those
individuals with respect to the payer. Such organizations or individuals may be health insurance plans, other payers, guarantors, parties with financial responsibility, some
combination of payers or the patient directly
Allergies and Drug
Sensitivities
This includes the allergy or intolerance conditions, severity and associated adverse reactions suffered by the patient
Conditions
This includes relevant clinical problems and conditions for which the patient is receiving care, including information about onset, severity, and providers treating the
condition. Conditions are broader than, but include diagnoses
Medications
This includes the patient's prescription or non-prescription medications and medication history, and may include prescriptions, fulfillments and medication administration
activities
Immunizations
This includes data describing the patient's immunization history
Vital Signs
This includes data about the patient’s vital signs
Test Results
This includes data about current and historical test results from laboratory or other diagnostic testing performed on the patient
Encounter
This includes data describing the interactions between the patient and clinicians. Interaction includes both in-person and non-in-person encounters such as telephone and
email
Procedures
This includes data describing procedures performed on a patient
Family History
Data defining the patient’s genetic relatives in terms of possible or relevant health risk factors that have a potential impact on the patient’s health
Social History
Data defining the patient’s occupational, personal (e.g. lifestyle), social, and environmental history that have a potential impact on the patient’s health
Medical Equipment
Medical Equipment includes implanted and external medical devices and equipment that a patient’s health status depends on, as well as any pertinent equipment or device
history
Functional Status
Data defining the patient’s functional status with respect to, ambulatory ability, mental status or competency, activities of daily living, including bathing, dressing, feeding,
grooming, home/living situation having an effect on the health status of the patient, and ability to care for self
Plan of Care
The plan of care contains data defining prospective or intended orders, interventions, encounters, services, and procedures for the patient
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 11
Value Set Metadata
Element
Description
Identifier
This is the unique identifier of the value set
Name
This is the name of the value set
Source
This is the source of the value set, identifying the originator or publisher of the information
URL
A URL referencing the value set members or its definition at the time of publication
Purpose
Brief description about the general purpose of value set
Definition
A text definition formally describing how concepts in the value set are (intensional) or were (extensional) selected
Version
This row contains a string identifying, where necessary, the specific version of the value set
Type
Extensional (Enumerated) or Intensional (Criteria-based)
Binding
Static or Dynamic
Status
Active (Current) or Inactive (Retired)
Effective Date
The date when the value set is expected to be effective
Expiration Date
The date when the value set is no longer expected to be used
Creation Data
The date of creation of the value set
Revision Date
The date of revision of the value set
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 12
Code System Metadata
Element
Description
Identifier
This is the identifier for a code system from which the value set is drawn
Name
This row provides the name of the code system associated with the value set
Source
This row identifies the source for the code system
URL
This row identifies the URL for the code system
HL7 Identifier
The identifier used to identify this code system in HL7 Version 2.X messages.
Version
This row contains a string identifying, where necessary, the specific version of the code system used
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 13
Template Metadata
Element
Description
HL7Template Metadata
Identifier
This is the identifier of the template
TemplateId
Name
This is the name of the template
templateName
Source
This row identifies the source of the template, the originator or publisher of it.
originatingAuthorEntityID
publisher
URL
A URL pointing to an online resource defining the template
templateRepositoryIdentifier
Purpose
A brief description of the purpose for the template
intention
Definition
Brief description of the template
templateDescription
Inherited Templates
Templates may require the use of other templates for the artifact to which this
template is applied. This entry indicates which templates must be used
Not Available
Templates Used
Templates may require the use of other templates in artifacts that are subordinate
to the artifact to which this template applies. This entry indicates which of these
templates are required or optional
Not Available
Version
This row contains a string identifying, where necessary, the specific version of the
template
version
Effective Date
The date that the template becomes effective
effectiveDate
Expiration Date
The date after which the template should no longer be used
supersededDate
Status
Active (Current) or Inactive (Retired)
publicationStatus
Creation Date
The date of the creation of the template when available
revisionHistory
Revision Date
The date of the revision of the template when available
revisionHistory
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 14
Simplified HL7 RIM: Foundation Classes
Participation
Role link
Act relationship
Language /
communication
The HL7 RIM supports EHR interoperability; an EHR may
needs additional foundation classes (e.g., Responsibility)
The HL7 RIM expresses the data content needed in a specific clinical or administrative context and
provides an explicit representation of the semantic and lexical connections that exist between the information
carried in the fields of HL7 messages [see backup slides 31-34 for details].
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 15
Summary
 Object Oriented Analysis (OOA), Object-Oriented Design (OOD),
Component-based Architectures (CA) and Service Oriented Architecture
(SOA) encapsulate data and bind Methods (e.g., functions, actions) to data.
 The HL7 EHR System Functional Model (EHR-S) categorizes, relates and
provides requirements for System Functions (e.g., methods, Actions)
 The HL7 Reference Information Model (RIM) categorizes and relates Entities
(data), Roles and Actions (e.g., Methods, Functions).
 HITSP defines a data architecture for Capabilities (e.g., Information
Exchanges, System Roles, System Interfaces)
 We can create an Information Model (IM) using the RIM class categorization
of the HITSP Data Architecture elements, HITSP Capability System Roles
and HL7 EHR-S FM System Functions (e.g., Actions).
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 16
Building an Information Model for a Business Architecture
A HITSP Capability (CAP) is an implementable business service that
specifies interoperable Information Exchanges between systems using HITSP
constructs. A Capability supports stakeholder requirements and business
processes, information content, communications and associated secure
infrastructure [HITSP TN904].
A Health IT Business Architecture (BA) can be modeled as clinical
stakeholders and their workflow-orchestration of system-functions, defined by
the HL7 System Functional Model. HITSP Capabilities group and specify system
roles, information exchanges and system interfaces to support one-or-more
system functions with standards-based data models and standards-based
interface specifications, which may be implemented as services.
An Information Model, for a project or enterprise, can be created from the
Capability data models of a Business Architecture, categorized using the HL7
RIM foundation classes.
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 17
Business
Architecture
Specification
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 18
Putting it all together
For Project Information, see
http://hssp.wikispaces.com/Reference+Architecture
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 19
Elements Grouped by Responsible Organization
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 20
Backup
 EXAMPLE: HITSP C154 Data Dictionary entry for Person
 Assumptions: Framing the issue on Data Dictionary
 Requirements: Framing the issue on Data Dictionary
 Framing the issue on Data Dictionary
 Key HITSP Reference Documents
 HITSP Constructs for Eligibility & Authorization
 HL7 RIM 6 Foundation Classes
 Basic UML Legend
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 21
HITSP C154 Data Dictionary Entry for Person (1 of 4)

The personal information module contains the name, address, contact
information, personal identification information, ethnic and racial affiliation
and marital status of the person. See the HL7 Continuity of Care Document
Section 2.5 for constraints applicable to this module.
Table 2-3 Person Information Data Mapping Table – Definitions
Identifier
Name
Definition
1.01
Timestamp The date and time that this
exchange has been created
Constraints
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 22
HITSP C154 Data Dictionary Entry for Person (2 of 4)
Table 2-4 Person Information Data Mapping Table – Definitions Patient Information Event Entry
Identifier
Name
Definition
1.02
Person ID
An identifier that uniquely identifies the individual to which the
exchange refers and connects that document to the individual's
personal health record. Potential security risks associated with use of
SSN or driver's license for this element suggest that these should not
be used routinely
1.03
Person Address
The current address of the individual to which the exchange refers.
Multiple addresses are allowed and the work address may be a
method of disclosing the employer
1.04
Person
Phone/Email/URL
A telephone number (voice or fax), e-mail address or other locator for a
resource mediated by telecommunication equipment. HITSP specifies
just this one data element to describe phone numbers, pagers, e-mail
addresses and URLs, but these may appear in different data elements
in the selected standards. The patient may designate one or more of
these contact numbers as the preferred method of contact and
temporary items can be entered for use on specific effective dates
Constraints
C154-[DE-1.03-1]
The state part of
an address SHALL be recorded using HITSP/C80
Section 2.2.1.1.1 State
C154-[DE-1.03-2]
The postal code
part of an address in the United States SHALL be
recorded using HITSP/C80 Section 2.2.1.1.2
Postal Code
C154-[DE-1.03-3]
The country part
of an address SHALL be recorded using
HITSP/C80 Section 2.2.1.1.3 Country
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 23
HITSP C154 Data Dictionary Entry for Person (3 of 4)
1.05
Person Name The individual to whom the exchange refers. Multiple names are allowed to retain birth name, maiden name, legal
names and aliases as required
1.06
Gender
Gender is used to refer to administrative sex rather than biological sex and therefore should easily be classified into
female and male. It is included in the exchange for purposes of linking to insurance information and other
patient identification linkages and the value chosen by the patient should reflect the information under
which any insurance or financial information will be filed, as well as the same information given to other
healthcare providers, institutions or health data exchange networks
1.07
Person Date
of Birth
The date and time of birth of the individual to which this Exchange refers. The date of birth is typically a key patient
identifier variable and used to enable computation of age at the effective date of any other data element. It
is assumed to be unique and fixed throughout the patient's lifetime
1.08
Marital Status A value representing the domestic partnership status of a person. Marital status is important in determining
C154-[DE-1.08-1] Marital Status SHALL be
insurance eligibility and other legal arrangements surrounding care. Marital status often changes during a
coded as specified in HITSP/C80
patient's lifetime so the data should relate to the effective date of the patient data object and not be
Section 2.2.1.2.3.2 Marital Status
entered with multiple values like an address or contact number. This element should only have one
CDA and HLV3
instance reflecting the current status of the individual at the time the Exchange is produced. Former values
might be part of the personal and social history
1.09
Religious
Affiliation
Religious affiliation is the religious preference of the person
C154-[DE-1.09--1] Religious affiliation SHALL
be coded as specified in HITSP/C80
Section 2.2.1.2.8 Religious Affiliation
1.10
Race
Race is usually a single valued term that may be constant over that patient's lifetime. The coding of race is aligned
with public health and other federal reporting standards of the CDC and the Census Bureau. Typically the
patient is the source of the content of this element. However, the individual may opt to omit race. In this
event, some healthcare organizations that receive the Summary Document may choose to enter an
observed race as their current practice for manual registration. Such organization observed race data
should be differentiated from patient sourced data in the patient's registration summary
C154-[DE-1.10-1] Race SHALL be coded as
specified in HITSP/C80 Section
2.2.1.2.7 Race
1.11
Ethnicity
Ethnicity is a term that extends the concept of race. The coding of ethnicity is aligned with public health and other
federal reporting standards of the CDC and the Census Bureau
C154-[DE-1.11-1] Ethnicity SHALL be coded
as specified in HITSP/C80 Section
2.2.1.2.2 Ethnicity
C154-[DE-1.06-1] Gender SHALL be coded
as specified in HITSP/C80 Section
2.2.1.2.1.2 V3 Administrative Gender
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 24
HITSP C154 Data Dictionary Entry for Person (4 of 4)
1.12 Mother’s
The family name under which the Mother was born
Maiden Name
1.13 Multiple Birth
Indicator
Indicates whether a patient was part of a multiple birth
1.14 Birth Order
The value (number) indicating the patient’s birth order when the
patient was part of a multiple birth.
1.15 Age
The Person’s age. This is normally a value derived, but in some
cases this may be the only information provided (no birth
date)
C154-[DE-1.15-1] ]
The Age SHALL
use UCUM Age Units
1.16 Birth Place
The location of the patient’s birth
C154-[DE-1.16-1]
If born in the United
States, the state part of an address
SHALL be recorded using HITSP/C80
Section 2.2.1.1.1 State
C154-[DE-1.16-2]
If born in the United
States the postal code part of an
address in the United States SHALL be
recorded using HITSP/C80 Section
2.2.1.1.2 Postal Code
C154-[DE-1.16-3]
The country part of
an address SHALL be recorded using
HITSP/C80 Section 2.2.1.1.3 Country
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 25
Framing the issue on Data Dictionary
Assumptions
 Different subject areas (e.g., Population vs Emergency
Responder vs Admin/Finance vs IS01) have need for
differing levels of data elements (e.g., vital signs for
Provider, blood pressure for population, systolic blood
pressure for clinical research).
 Different standards have similar data elements but
– Respond to different requirements (e.g., business, level of
representation, …)
– May have representational or intensional definitions that differ
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 26
Framing the issue on Data Dictionary
- Suggested requirements based on assumptions
 A master dictionary lists all data elements – it is C154
 Subject areas can look at just their subset of the data
elements – more complex issue to be discussed
 Traceability is provided to identify where data elements
are used – more complex issue to be discussed
 Users
– HITSP developers and SDOs
– End-users of HITSP specifications, such as
 Users, implementers, and integrators mof EHRs and other Health
IT Systems
 Developers of clinical practice developing guidelines
 Policy-makers and influencers with respect to interoperable
Information Exchange,
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 27
Framing the issue on Data Dictionary
Questions (1 of 4)
 While different levels of detail should be permitted, are
there levels where vocabulary should take over?
– For example, vital signs is a collection of observations of which
Blood Pressure is one. Vocabulary can deal with some finer
details. We don’t want the HITSP data dictionary to become as
detailed as LOINC (which contains over 30,000 elements).
 HITSP Data Dictionary is a mapping tool meant to
harmonize across standards, not replace the standards.
Should definitions be at a higher level than SDO
definitions to deal with different representational and
detailed definitions?
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 28
Framing the issue on Data Dictionary
Questions (2 of 4)
 Enabling subject areas to look at their subset of Data
Dictionary is inconsistent with current Word approach.
– Each data dictionary element can be classified/categorized in a
number of different ways but current HITSP Data Dictionary is a
Word Document with inherent sequential/hierarchical approach.
– Should we have the HITSP Data Dictionary capitalize on a
registry such as USHIK to enable “slicing and dicing” by various
viewpoints?
 Should we focus on data elements used by HITSP or
look for a harmonized approach across relevant
standards bodies and attempt to involve the SDOs in
supporting that Data Dictionary?
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 29
Framing the issue on Data Dictionary
Questions (3 of 4)
 For traceability between data elements and where used
in HITSP Components:
– Is it sufficient for the Data Dictionary to identify what HITSP data
element is used in what Component, or must it identify which
corresponding standard’s version of that data element?
 Should the Data Dictionary use a coherent standard
(e.g., RIM) as the target for definition across HITSP?
 The Data Dictionary does not use a coherent standard
(e.g., RIM) as the target for definition across HITSP,
it harmonizes 4 key data dictionaries - X12, NCPDP,
HL7 V2 and HL7 RIM. Is this sufficient and appropriate?
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 30
Framing the issue on Data Dictionary
Questions (4 of 4)
 Should we focus on data elements used by HITSP or
look for a harmonized approach across relevant
standards bodies
– Current focus is on data elements identified by Harmonization
Requests, since business requirements necessary to identify the
terms needed in the data dictionary. This is much more
constrained effort in time and resources than the broader
harmonization effort.
– Should the broader harmonization effort should be continued in
discussions between HITSP Foundations and the SCO?
 Should we have a precedence rule to assert where to
look first, second, … in some alternative areas
 Is there a need for exceptions to some of these rules?
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 31
HITSP Data Architecture
Component Constructs
 C80 - Clinical Document and Message Terminology Component
The Clinical Document and Message Terminology Component defines the vocabularies and
terminologies utilized by HITSP specifications for Clinical Documents and Messages used
to support the interoperable transmission of information.
 C83 - CDA Content Modules Component
The CDA Content Modules Component defines the content modules for document based
HITSP constructs utilizing clinical information. These Content modules are based on IHE
PCC Technical Framework Volume II, Release 4. That technical framework contains
specifications for document sections that are consistent with all implementation guides for
clinical documents currently selected for HITSP constructs.
 C154 - HITSP Data Dictionary
The HITSP Data Dictionary defines the library of Data Elements that may be used by
HITSP constructs in standards based exchanges. The Data Elements are organized into
modules to simplify navigation, such as Medications, Advance Directives, Immunizations,
etc.
Available at www.HITSP.org
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 32
Key HITSP Technical Notes
 TN901 - Technical Note for Clinical Documents
The Technical Note for Clinical Documents serves as the top-level reference for the HITSP constructs using the HL7
Clinical Document Architecture (CDA) Release 2.0. It includes a design map of existing standards and specifications
that are used to meet the stated requirements of the AHIC Use Cases. As additional Use Cases are provided to
HITSP, the Technical Note will be updated to address consequent updates to the design and relationship of the
associated HITSP constructs.
 TN903 - Data Architecture Technical Note
The HITSP Technical Note describes the HITSP Data Architecture and the related processes and tools that HITSP
uses to identify the data elements, templates and value sets used in Information Exchanges. It explains how within
HITSP Specifications: base and composite standards are related to the data architecture: data elements are
harmonized across various standards: constraints are applied within HITSP Specifications: and metadata registries
support development and implementation.
 TN904 - Harmonization Framework and Exchange Architecture Technical Note
The Harmonization Framework and Exchange Architecture (HF&EA) Technical Note (TN) defines the terms,
concepts, relationships, and associations that are realized in the artifacts that comprise the primary work product of
the Panel, e.g., an Interoperability Specification (IS), Capability (CAP), Component (C), Transaction (T), Transaction
Package (TP) and Service Collaboration (SC). Further, it organizes the terms and concepts into a HITSP model
based on information exchanges specific to data, context, business process, and workflow. The Exchange
Architecture defines the fundamental topologies that can be used in implementing the HITSP Interoperability
Specifications in configurations such as EHR systems directly connected or connected to Health Information
Exchanges (HIEs).
Available at www.HITSP.org
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 33
HITSP Constructs for Eligibility & Authorization
 CAP140 - Communicate Benefits and Eligibility
This Capability addresses interoperability requirements that support electronic inquiry and response about a patient’s eligibility for health
insurance benefits. The information exchanged includes the following: • A patient’s identification (e.g., name, date of birth, and the health
plan’s member identification number) • Communication of a member’s status of coverage and benefit information and financial liability •
Access to information about types of services, benefits and coverage for various medical care and medications This Capability provides
clinicians and healthcare providers with information about their patient’s health insurance coverage and benefits.
 CAP141 - Communicate Referral Authorization
This Capability addresses interoperability requirements that support electronic inquiry and response to authorizing a patient (health plan
member) to be referred for service by another provider or to receive a type of service or medication under the patient’s health insurance
benefits. The Capability supports the transmittal of a patient’s name and insurance identification number with the request for the type of
service. It also includes the following optional requirements: • Identification of the type of service or medication requested for benefit
coverage (does not guarantee payment by insurance provider) • Communication of a referral notification number or authorization number
from the Payer System to the Provider System It provides clinicians and pharmacists with information about each patient’s medical
insurance coverage and benefits. It may include information on referral or authorization permission.
 T68 - Patient Health Plan Authorization Request and Response Transaction
The Patient Health Plan Authorization Request and Response Transaction provides a mechanism for a healthcare provider (other than a
retail pharmacy) to request approval from a health plan to authorize certain healthcare services, when required by the patient’s health plan
contract. The information exchanged includes, but is not limited to, approval status for coverage, allowed service provider(s), and
certification dates for services that are included in the patient’s health plan benefits. The response from the health plan indicates that the
health plan has determined that the particular service(s) will or will not be covered, and what is the level of coverage if that information is
available from the health plan.
 T79 - Pharmacy to Health Plan Authorization Request and Response Transaction
The Pharmacy to Health Plan Authorization Request and Response Transaction provides a mechanism for a pharmacy to request approval
from a health plan to authorize certain healthcare products and services, as required by the patient’s health plan contract. The health plan
responds to the pharmacy’s request for the approval of products and/or services. The information exchanged includes, but is not limited
to, approval status for coverage of the products and/or services that are included in the patient’s health plan benefits and/or authorization
limitations.
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 34
HL7 RIM Foundation Classes: Act-Role-Entity Pattern
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 35
Definitions of the Six Core Rim Classes
1.
Act - An Act is an action of interest that has happened, can happen, is happening, is intended to happen, or is requested/demanded
to happen. An act is an intentional action in the business domain of HL7. Healthcare (and any profession or business) is constituted of
intentional actions. An Act instance is a record of such an intentional action.
2.
Entity - An Entity is a class or specific instance of a physical thing or an organization/group of physical things capable of participating
in Acts; an artifact. This includes living subjects, organizations, material, and places. The Entity hierarchy encompasses human
beings, organizations, living organisms, devices, pharmaceutical substances, etc. It does not include events/acts/actions, the definition
of things, or the roles that things can play (e.g. patient, provider).
3.
Role - A Role is a categorization of competency of the Entity that plays the Role as defined by the Entity that scopes the Role. An
Entity, in a particular Role, can participate in an Act. Note that a particular entity in a particular role can participate in an act in many
ways. Thus, a Person in the role of a practitioner can participate in a patient encounter as a rounding physician or as an attending
physician. The Role defines the competency of the Entity irrespective of any Act, as opposed to Participation, which is limited to the
scope of an Act. Each role is 'played' by one Entity (the Entity that is in the role) and is usually 'scoped' by another. Thus the Role of
'patient' is played by (usually) a person and scoped by the provider from whom the patient will receive services. Similarly, the
employer scopes an Employee role.
4.
Participation - A Participation is an association between a Role and an Act. The Participation represents the involvement of the Entity
playing the Role with regard to the associated Act. A single Role may participate in multiple Acts and a single Act may have multiple
participating Roles. A single Participation is always an association between a particular Role and a particular Act. Participation is
limited to the scope of the Act, as opposed to Role, which defines the competency of an Entity irrespective of any Act.
5.
Act_relationship - An Act_relationship is an association between a pair of Acts. This includes Act to Act associations such as
collector/component, predecessor/successor, and cause/outcome. The class has two associations to the Act class, one named
"source" the other named "target". .... Since the relationships associated with an Act are considered properties of the source act
object. That means that the originator of the information reported in an act object is not only responsible for the attribute values of that
object, but also for all its outgoing relationships. The rule of attribution is that all act relationships are attributed to the responsible actor
of the Act at the source of the Act_relationship (the "source act".)
6.
Role_link - A Role_link is a connection between two roles expressing a dependency between those roles.
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 36
The Rationale Behind the RIM's Design

The HL7 RIM identifies two major "high-level" concepts that are fundamental to understanding the world of healthcare information: intentional "actions" or
"services" (Acts), and "people, places and things" that are of interest in the world of healthcare (Entities).

The concept "Act" (and its subclasses) represents all of the intentional actions documented by a healthcare professional in either a clinical or
administrative context. The presence of the Act class as one of the core RIM classes is a reflection of HL7's view that "from a messaging/system communication
perspective, healthcare consists of a series of attributed, intentional actions."" Thus, instances of the class/concept Act include both clinical observations (e.g.
patient temperature) and interventions (e.g. administer medication), and administrative actions (e.g. admit patient). Note that in this "act-centered" view of
healthcare, the act of an observation takes on two seemingly contradictory meanings: "the act of recognizing and documenting a particular fact," and "the
description of the thing observed." In other words, an instance of an Observation Act represents both the attributed act of observing and the results of the
observation. Both aspects of this expanded definition of an Observation Act are captured by specific attributes of the class Act or its subclass Observation.

The concept "Entity" (and its subclasses) includes all living subjects (e.g. persons, animals), organizations (e.g. formal and informal), materials (e.g.
durable and non-durable goods, food, tissue, containers,), and places that may be of interest in a healthcare messaging context. It should be noted that the
concept of "collection of information" (e.g. a medical record) is not a instance or subclass of Entity, but is instead considered as a collection of attributed Acts.

The RIM places two additional classes - Role and Participation - between Act and Entity. The Role class models several important concepts that are
prevalent in the healthcare delivery domain. First, Role captures the fact that the various "static" entities may "temporally" assume one or more "roles" (e.g.
patient, primary care physician, responsible party, Registered Nurse etc.) in a particular healthcare context. Second, the concepts of "capability" (e.g. Advanced
Cardiac Life Support) and "certification" (e.g. Licensed Practical Nurse) are also modeled using instances of the Role class. Finally, careful examination of the
multiplicity (0..1) and names (is_scoped_by, is_played_by) of the two associations between Entity and Role reveals that the Role class can be used to "group"
instances of Entity.

It is important to distinguish the concept of Entity-in-a-Role from the Act-specific concept of "the function-based role played by an Entity-in-a-Role in the
context of a specific Act." These semantics are modeled using instances of the Participation class. For example, an Anesthesia Resident (Entity-in-a-Role)
administers anesthesia (Participation as "provider" in the Act "administer anesthesia") to a patient (Participation as a 'recipient" in the Act "administer anesthesia."
Note that the absence of a direct association between the Participation and Entity classes is a manifestation of an underlying HL7 RIM assumption that all
instances of Entity involved in an Act are participating in the Act in a particular Role.

In summary, both the Participation and the Role classes are necessary to fully model the complex semantics that exist between instances of Entity and
Act, and a concise summary of the HL7 RIM's view of healthcare can be stated as follows: At the highest level of abstraction, healthcare consists of a series of
intentional, attributed Acts performed to, by, on behalf of, utilizing or in some way involving one or more instances of a Participating ("as primary provider," etc.)
Entity-in-a-Role ("John Smith in the role of Patient").

The two remaining classes in the RIM - Act_relationship and Role_link - are used to "associate" or "link" instances of the class with which it is associated.
The class Role_link is used to establish a "dependency-based link" (e.g. accountability, chain-of-trust, etc.) between two instances of an Entity-in-a-Role. The
semantics of Act_relationship are explained below.
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 37
Linking Acts Together: The Semantics of Act_relationship
An understanding of the semantics and application of Act_relationship begins with, an understanding of the "fractal" or "robotic arm"
nature of a set of Acts. This perspective is, in turn, best viewed from the overarching framework of the categorization of three
types of "collecting relationships" represented by instances of Act_relationship: whole/part (e.g. lab or test batteries (see the
discussion of the "robotic arm" below); rule-based (e.g. care plans, protocols, etc.); and cognitive actions (e.g. judgment,
renaming, replacement, subsumption, supported by/reason for, etc.).
Regarding the "fractal" or "robotic arm" discussion, As mentioned above, instances of Act_relationship can be used to model the
"fractal" or "robotic arm" notion behind a "whole/part" relationship. Consider a surgical procedure such as a laparoscopic
cholecystectomy. The procedure may be represented as a single instance of Act, or, alternatively, as a "collection" of
(partially ordered) instances of Act each of which is a finer granularity than the entire procedure, e.g. obtain consent,
administer pre-op medication, administer anesthesia (throughout the surgical procedure), make the incision, etc. In turn, for
any of the more finely granulated actions just mentioned, further granulation/decomposition may occur. The degree of
granularity is clearly dependent on the context of the action(s) and the interest level/perspective of the party performing (or
not performing) the decomposition. Figure 1 shows a "surgeon's-eye view" of some of the instances of Act and
Act_relationship for the exemplar cholecystectomy.. [Example of sequential plan construction for laparoscopic
cholecystectomy. Edged boxes are Act instances (all in definition, or 'master' mood.) Rounded boxes are Act_relationship
instances of type: has-component. The sequence_nbr attribute orders the relationships into a sequence. Each act can in turn
be decomposed into plan-components.]
In summary, the classes Act and Act_relationship have been designed to allow for representing the rich semantics of each of three
types of collections mentioned above at whatever coarseness or fineness of granularity is appropriate to the specific
messaging context. In addition, the various of types of collections and levels of granularity represented by instances of
Act_relationship can (and will) be expected to be used to collectively capture the complex semantics of clinical reasoning,
e.g. an instance of Act_relationship (e.g. "supported by") could be used to form a link from an instance of an observation Act
representing a specific lab test (e.g. sedimentation rate = 48 to an instance of an observation Act representing a particular
diagnosis (e.g. DX = Systemic Lupus Erythematosus).
From: Version: V 01-14 (3/9/2002) ModelID: RIM_0114 [ http://www.hl7.org/library/data-model/RIM/C30114\rim.ht
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 38
Basic UML Legend
class Basic UML Legend
Concept Outline
Legend
Author
dependency
realize
Publisher
Book
compose
1..*
aggregate
associate
Chapter
Preface
generalize
Biography
A book realizes an author's concept outline.
A Concept Outline and a Book depends on an Author to be written.
A Book "has-an" index and is composed of one or more chapters.
A Biography "is-a" type of book.
A Book is associated with a publisher.
 Association is a relationship between two classes, that may describes the reasons for the relationship and the rules that govern the relationship.
 Aggregation ("has-a") is a special form of an association that specifies a whole-part relationship between the aggregate (whole) and a component part. The parts
can exist on their own and are therefore shareable among multiple owner classes.
 Composition (a strong type of "uses a" relationship) is a form of aggregation which requires that a part instance be included in at most one composite at a time, and
that the composite object is responsible for the creation and destruction of the parts.
 Realize is a relationship where a source object implements or Realizes its destination object. Realize connectors are used to express traceability and completeness
in the model.
 Generalization ("is-a") is a relationship in which one model element (the child) is based on another model element (the parent).
HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model Slide 39