Slide 0HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model HITSP Data Architecture Proposed Bottom Up Approach to Constructing

Slide 1HITSP Data Architecture: A Bottom Up Approach to Constructing an Information Model

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 22 Nov 09, Current version available at http://hssp.wikispaces.com/Reference+Architecture

[email protected]@tma.osd.mil


HITSP Data ArchitectureTable of Contents

BACKGROUND: 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 17-20

BACKUP SLIDES

– EXAMPLE: HITSP C154 Data Dictionary entry for Person 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 34

– Six HL7 RIM Foundation Classes 35-38

– Basic UML Legend 38


HITSP Harmonization Framework

AddressingBusiness

Needs

ProvidingInfrastructure,

Security,Privacy

Data Architecture

Available for Independent Implementation

DefiningInformation

Content

IS = Interoperability Specification


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


EXAMPLE: HITSP/CAP141 Communicate Referral Authorization Capability

cmp CAP141 Communicate Referral Authorization - Interfaces

Request AdministrativeTransport to Health Plan

CAP141 Communicate Referral AuthorizationRespond to AdministrativeTransport to Health Plan

Request AdministrativeTransport 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

cmp CAP141 Communicate Referral Authorization - System Roles

Clinical Care Authorization Requestor

Clinical Care Authorization Provider

Pharmacy Authorization Requestor

Pharmacy Authorization Provider


HITSP Capability Conformance• A HITSP Capability addresses a focused business need for secure interoperable Information Exchanges in

support of stakeholder requirements and business processes. A Capability is defined at a level relevant to policy and business decisions. It specifies the use of HITSP constructs to address requirements and options for the information content (e.g., format, structure, vocabulary, and coding) as well as the infrastructure, Security and Privacy for the needed information exchanges. A Capability identifies two or more System Roles to address each information exchange required for the business need.

• A Capability System Role is assigned the responsibility to initiate or respond to one or more information exchanges the Capability supports. System Role is an abstraction defined to enable a Capability to be implemented by many different types of systems. Example System Roles are Order Placer; Order Filler; Specimen Analyzer.

• A HITSP Interoperability Specification (IS) assigns systems to one or more of a Capability’s System Roles. For a System to implement a Capability, it must implement one or more of the Capability’s System Roles.

• Either an IS use or a System implementation is conformant to the Capability if, for each of the assigned Capability System Roles:

• The use or implementation supports the System Role responsibilities, including all interfaces specified by the underlying HITSP constructs according to the conditions specified for the System Role.

• If a Capability option is addressed, the implementation must conform to the Capability’s specifications for that option.


class Data Architecture

EHR System Interoperability Specifications

Capability

Data Architecture

Data Module

Data Element

Value Set

HITSP Constructs

Component (C)

Transaction Package (TP)

Transaction (T)

Service Collaboration (SC)

Selected Standard

HITSP/C83 - CDA Content Modules Component

HITSP/C154 - HITSP Data Dictionary

HITSP/ C80 - Clinical Document and Message Terminology Component

HITSP/TN903 - Data Architecture Technical Note

HITSP/TN904 - Harmonization Framework and Exchange Architecture Technical Note

HITSP/TN901 - Technical Note for Clinical Documents

Data Requirement (DR)

+ Data Module

Capability Requirements

+ Information Exchange+ option+ Scenario+ system role

ARRA Requirement for Certified EHR Systems

Information Exchange Requirement (IER)

+ Systems+ Exchange Content+ Exchange Action+ Exchange Attribute

ARRA Meaningful Use Measures

+ Stakeholder

Regulatory Guidance

Scenario

+ conditions

Certification Criteria

+ Capability

Capability Design

+ conditions+ optionality+ system role

requirementsdesign

Legend

HITSP Data Architecture within HITSP

Harmonization Framework

GREEN indicates reusable elements

HITSP Documents are available at www.HITSP.orgDetailed HITSP Data Architecture is available online at www.USHIK.org


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: 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 (detailed)


HITSP Clinical Document Constructs

HITSP Reuse Paradigm: With the HITSP Communication of

Structured Documents Capability (HITSP/Capability 119), a CDA clinical note can be composed,

from any group of C83 data modules, and then it can be

communicated.

Benefit is agile system interoperability.


HITSP/C83 Data Module CategoriesModule 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


Value Set MetadataElement 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


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


Template MetadataElement 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


Simplified HL7 RIM: Foundation Classes

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

Role link

Act relationship

Participation

The HL7 RIM supports EHR interoperability; an EHR may needs additional foundation classes (e.g., Responsibility)

Language /

communication


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 Reference Information Model (RIM) categorizes and relates Entities (data), Roles and Actions (e.g., Methods, Functions).

The HL7 EHR System Functional Model (EHR-S) categorizes, relates and provides requirements for System Functions (e.g., methods, Actions)

HITSP defines a data architecture to support its Capabilities (e.g., Information Exchanges, System Roles, System Interfaces)

CONCLUSION: We can create an Information Model (IM) using RIM class categorization of the HITSP Data Architecture elements (e.g., RIM Entities), HITSP Capability System Roles (e.g., RIM Roles) and HL7 EHR-S FM System Functions (e.g., RIM Actions).


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.


class EHR Business Architecture Specification

HITSP Constructs

+ Component (C)+ Transaction (T)+ Transaction Package (TP)+ Service Collaboration (SC)




+ Exchange Action+ Exchange Attribute+ Exchange Content+ Systems

Service

Capability Design


Interface

SOA Layers

+ Business Processes+ Composite Services+ Core Business Services+ Component Services+ Operational Services+ Implementation Profiles

requirementsdesign

Legend

EHR Business Architecture

Selected Standard

HL7 Reference Information Model (RIM)

+ Act+ Act relationship+ Entity+ Participation+ Role+ Role relationship

HL7 EHR SD RM

+ EHR-S FM+ FHIMS+ HITSP Capability Design+ SOA Layer

NHIN Connect Service

Behavioral Model

Functional Requirements

EHR-S FM

+ Direct Care+ Information Infrastructure+ Supportive Care

realize

Business ArchitectureSpecification

Using HL7-EHR-S FM, HL7-RIM

and HITSP Capabilities

Slide 19


class EHR Business Architecture Specification with ARRA & FHIMS

HITSP Constructs






Service

Capability Design


Interface

SOA Layers


requirementsdesign

Legend


Selected Standard


+ Capability

Federal Health Informations Model & Standards (FHIMS)

Federal Health Data Model



Clinical Document Architecture (CDA)


+ Stakeholder

Agency Information Model

Agency Data Model

HL7 EHR SD RM



FHIMS is Federal Health Information Model and StandardsEHR-S FM is EHR System Functional-ModelEHR SD RM is EHR System Design Reference-Model

Realize relationship: a source object implements or Realizes its destination object. Realize connectors are used toexpress traceability and completeness in the model.

A HITSP Capability (CAP) specifies interfaces for a set of information exchanges, grouped by system role (e.g., lab order prescriber, lab order filler).A HITSP conformant system implements the specified interfaces for the information exchanges which are required to support the selected system roles of each HITSP capability implemented within the system.

Functions vs. Services differ in that a services enforces encapsulation (e.g., information hiding), have associated governance and Distributed User Resource Sharing Agreements (DURSAs), which defines the business rules for a services' information exchanges.

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 a semantic network of a BA's Capability data models, categorized using the six HL7 RIM foundation classes.

Behavioral Model

Functional Requirements

EHR-S FM


realize

realize

Putting it all togetherFor Project Information, see

http://hssp.wikispaces.com/Reference+Architecture

Slide 20


class EHR-SD RM

FHIMS

HITSP

HL7

HITSP Constructs






Service

Capability Design


Interface

SOA Layers


requirementsdesign

Legend


Selected Standard


+ Capability

Realize relationship: a source object implements or Realizes its destination object. Realize connectors are used to express traceability and completeness in the model.

EHR-S

+ Capability

Partner EHR-S

+ Capability

Federal Health Informations Model & Standards (FHIMS)

Federal Health Data Model

A HITSP Capability (CAP) specifies interfaces for a set of information exchanges, grouped by system role (e.g., lab order prescriber, lab order filler).A HITSP conformant system implements the specified interfaces for the informationexchanges which are required to support the selected system roles of each HITSP capability implemented within the system.

Functions vs. Services differ in that a services enforces encapsulation (e.g., information hiding), have associated governance and Distributed User Resource Sharing Agreements (DURSAs), which defines the business rules for a services' information exchanges.

FHIMS is Federal Health Information Model and StandardsEHR-S FM is EHR System Functional-ModelEHR SD RM is EHR System Design Reference-Model



Clinical Document Architecture (CDA)


+ Stakeholder

Agency Information Model

Agency Data Model

HL7 EHR SD RM



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 a semantic network of a BA's Capability data models, categorized using the six HL7 RIM foundation classes.

EHR-S FM


realize

HITSP Capabilities/NHIN Services

realize

Elements Grouped by Responsible Organization

Slide 21


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 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 Constraints

1.01 Timestamp The date and time that this exchange has been created


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 Constraints

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

C154-[DE-1.03-1] The state part of an address SHALL be recorded using HITSP/C80 Section 2.2.1.1.1 StateC154-[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 CodeC154-[DE-1.03-3] The country part of an address SHALL be recorded using HITSP/C80 Section 2.2.1.1.3 Country

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



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

C154-[DE-1.06-1] Gender SHALL be coded as specified in HITSP/C80 Section 2.2.1.2.1.2 V3 Administrative Gender

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 insurance eligibility and other legal arrangements surrounding care. Marital status often changes during a patient's lifetime so the data should relate to the effective date of the patient data object and not be entered with multiple values like an address or contact number. This element should only have one 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

C154-[DE-1.08-1] Marital Status SHALL be coded as specified in HITSP/C80 Section 2.2.1.2.3.2 Marital Status CDA and HLV3

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



1.12 Mother’s Maiden Name

The family name under which the Mother was born

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



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


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,



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?



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?



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?


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 Component Constructs

C80 - Clinical Document and Message Terminology ComponentThe 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 ComponentThe 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 DictionaryThe 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


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 NoteThe 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 NoteThe 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 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 AuthorizationThis 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 TransactionThe 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 TransactionThe 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. Available at www.HITSP.org


HL7 RIM Foundation Classes: Act-Role-Entity Pattern


Definitions of the Six Core Rim Classes1. 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.


The Rationale Behind the RIM's DesignThe 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.


Linking Acts Together: The Semantics of Act_relationshipAn 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


Basic UML Legend class Basic UML Legend

Book

Preface

Chapter

Publisher

Biography

Author Legend

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

Concept Outline

dependency

aggregate1..*

compose

associate

generalize

realize