1

AHIMA Standards Task Force

HIM Practice Standards Project

Specification of Use Cases for

Information Management Practices in Healthcare:

Patient Registration Use Case

Chicago, Illinois, USA

2016
 2

Table of Contents
Synopsis.......................................................................................................................................................5
Overview.................................................................................................................................................5
Target Audience......................................................................................................................................5
Scope.......................................................................................................................................................6
Development Process..............................................................................................................................6
References...............................................................................................................................................7
Use Case Specification Format................................................................................................................7
Patient Registration Use Case......................................................................................................................9
Overview.................................................................................................................................................9
Problem Description..............................................................................................................................11
Solutions: Use Case Scenarios...............................................................................................................12
Scope.....................................................................................................................................................12
Actors (Business and Technical).............................................................................................................13
Use Case Description.............................................................................................................................14
UML Workflow and Dataflow Diagram..................................................................................................14
Data Specifications for Information Items.............................................................................................14
Patient Registration Information.......................................................................................................14
Insurance Information.......................................................................................................................14
Payment Information.........................................................................................................................14
Chief Complaint, Reason for Visit, ABN.............................................................................................14
Consent for Visit................................................................................................................................14
Consent for Information Sharing.......................................................................................................14
Wristband (patient ID bracelet with barcodes).................................................................................14
Notification of Record Availability.....................................................................................................14
Acknowledgement of Receipt............................................................................................................14
Audit Record......................................................................................................................................14
 3

AHIMA Standards Task Force Members 2016 – To Be Updated

Name Affiliation
Kathleen Addison Alberta Health Services
Linda Bailey-Woods Plante Moran
DeShawna Hill-Burns Advocate Trinity Hospital
Carlyn Doyle Multnomah County Department of Assets
Susan Clark eHealthcare Consulting
Alane Combs Coastal Healthcare
Vicki Delgado Kindred Hospital Albuquerque
Robert Giannini ECRI Institute PSO
Elisa Gorton St. Vincent's Medical Center
Darice Grzybowski H.I. Mentors, LLC
Aaron Haskett Sutter Health
Beth Horn Chapa-De Indian Health Services
Sandra Huyck Beaumont Health System
Theresa Jones Resurrection University
Satyendra Kaith Kaplan Higher Education Group
Robin Keeney VHC, Inc.
Katherine Lusk Dallas Children’s Medical Center
Susan Lucci Just Associates
Jennifer Manahan Via Christi Clinic, PA
Marcia Matthias Southern Illinois Healthcare
Tabitha McDaniel Nuance Communications
Lori McNeil Tolley Boston Children's Hospital
Sharon Meyer Ministry Health Care
Nicole Miller Miller And Miller Associates
Neysa Noreen Children's Hospitals and Clinics of Minnesota
Sandra Nunn KAMC Consulting
Michael Nusbaum M.H. Nusbaum & Associates Ltd.
Teri Phillips HSHS St Anthony’s Memorial Hospital
William Reisbick William B Reisbick, Esq
Deana Stillar Alberta Health Services
Christine Taylor University of Washington Medicine
DeAnn Tucker Owensboro Health
Christine Watts University of Chicago Medicine
Traci Waugh North Valley Hospital
Valerie Wilson HCA Information Technology Services
Lee Wise Summit Medical Center
Donna Young Memorial Hospital of Carbondale
AHIMA Staff
Dr. Anna Orlova Senior Director, Standards
 4

Name Affiliation
Harry Rhodes Director, National Standards
Diana Warner Director, HIM Practice Excellence
 5

Synopsis
Overview
This document specifies the AHIMA Use Case for Patient Registration in Healthcare Organizations
(Patient Registration Use Case, Use Case). The Use Case is developed as a continuation of the AHIMA
efforts for specifying health information management (HIM) practices to guide the development of
health information technology (HIT) standards for information sharing in healthcare. The AHIMA effort
of standardization of information management in healthcare started in 2015 as described in the White
Paper entitled HIT Standards for HIM Practices.1 The White Paper was developed by AHIMA in
collaboration with the Integrating the Healthcare Enterprise (IHE) - a collaborative of HIT vendors and
professional associations aimed to developed interoperability standards.

The AHIMA Patient Registration Use Case is one of the series AHIMA use cases developed to guide
standardization of both HIM practices and HIT products in healthcare. Table 1 presents the list of the
current and future AHIMA Use Cases. Please note that 2015-2016 lists do not reflect all possible HIM
practice use cases. The use cases listed in Table 1 were selected as examples by the AHIMA Standards
Task Force. The Task Force has been working on identifying a comprehensive list of HIM practice use
cases in the context of clinical care workflow depicted on Figure 1. In addition, the Task Force has been
also working on developing the methodology to prioritize the use cases for the development of HIT
standards supporting HIM practices.

Table 1. HIM Checklists and Use Cases for HIT Standards

Use Cases for HIT Standards
2015 AHIMA-IHE White Paper 2016 AHIMA Specifications
1. All documents in the episode of care record are 6. Patient registration
accounted for 7. Record and data quality
2. Episode of care record is complete and closed 8. Copy and paste
3. Release of Information (ROI) to external 9. Patient matching
requestor 10. Transition of care
4. Audit for the episode of care record
5. Audit for the ROI

Specifications of Use Cases is a part of the collaborative informatics-based approach for translating HIM
practices into HIT standards that was deployed in the 2015 AHIMA-IHE White Paper.

Target Audience
This specification is targeted to
1. Organizations (e.g. healthcare organizations, public health agencies, payers/insurance
companies, academia) involved in origination, management, and use of healthcare data
2. Health professionals that originate, manage, and use healthcare data
3. Implementers - organization’s staff involved in implementation of HIT Systems
4. HIT vendors and consultants involved in the design, development and implementation of HIT
systems
5. Health information exchange (HIE) entities that collect, manage, and exchange data
1
Integrating the Healthcare Enterprise (IHE). Information Technology Infrastructure (ITI) Technical Framework (TF) Supplement.
Health IT Standards for HIM Practices. White Paper. 2015. URL: http://qrs.ly/lb4vec0
 6

6. Standards developers at various standards development organizations (SDOs)

7. Consumers (e.g. patients, care givers, employees, employers) involved in creation, management,
and use of healthcare data and
8. Educators involved in HIT, HIM and informatics training.

In 2016, we are focusing on target audiences #1 through #6.

b
Figure 1. Clinical Workflow - Episode of Care (EOC) Functions and Records:
a-high level view; b-detailed view of the record life cycle with examples of EOC Components 2

Scope
This AHIMA Use Case specification standards cover all health information (clinical, financial and
operational), on all media and formats, created by a healthcare organization in its enterprise
information management system. This includes legal health records and information contributed by
patients.

2
Integrating the Healthcare Enterprise (IHE). Information Technology Infrastructure (ITI) Technical Framework (TF) Supplement.
Health IT Standards for HIM Practices. White Paper. 2015. URL: http://qrs.ly/lb4vec0
 7

Development Process
The Patient Registration Use Case has been developed based on the functional requirement analysis 3 as
well as literature review of the best HIM practices related to documentation management.

First, we developed a Use Case description specifying

(a) actors - business (personas, people) and technical (information systems) - and their roles in the
use case
(b) actions (functional requirements) - workflow steps, documents/records/data types by each step
(data flow), and the role of actors in each step
(c) the boundaries of the use case (start-end) by specifying entry and exit conditions, and
(d) non-functional requirements (quality, etc.)

Use Cases were presented in the tabular format 4 and accompanied by the Unified Modeling Language
(UML) sequence diagram.5

Please note that we used two terms for the actors in the Use Cases:
 Business actors (people: HIM professionals, clinicians, patients, and other) and
 Technical actors (information systems: EHR, PHR, mHealth, and other).

This separation between business and technical actors is important to align the roles of HIM
professionals (business actors) specified in the Use Cases with the information system functions (collect,
manage, integrate, analyze data and generate reports) performed by technical actors. Specification of
activities performed by the business actors (HIM professionals) and technical actors (information
systems) in the same use case allows aligning the business needs with the applicable technical actors
from the IHE interoperability standards, e.g., Content Creator (information systems that acts as
information creator and sender) and Content Consumer (information systems that acts as information
receiver) and others.

The AHIMA Use Case serves as a foundation for the IHE Patient Registration Content Profile (to be
developed in the IHE 2017 development cycle).

References
References to the HIM and other materials used in the specification are presented in the footnotes.
They include examples of HIM practice documentation (operational procedures) and samples of
respective documents/records/data types from healthcare organizations, published sources, and other.

Use Case Specification Format

The AHIMA Use Case and Practice Checklist specification consists of the following sub-sections:

Use Case: <Name>

Overview
Problem Description

3
Bruegge B. and Dutoit AH. Object-Oriented Software Engineering. Pearson Prentice Hall. Upper Saddle River, NJ. 3rd Edition.
pp.121-170.
4
Bruegge B. and Dutoit AH. Object-Oriented Software Engineering. Pearson Prentice Hall. Upper Saddle River, NJ. 3rd Edition.
p.50.
5
Ibid. p.30-74.
 8

Solutions: Use Case Scenario(s)

Scope
Actors (Business, Technical)
Use Case Description
 Name
 List of Actors
 List of Workflow Steps
 Information Items (Documents/Records/Data) by Actor, by Workflow Step
 Entry and Exit Conditions
 Non-functional Requirements
UML Workflow and Dataflow Diagram (Sequence Diagram)
Data Specifications
 9

Patient Registration Use Case

Overview
Patient Registration is the process of checking-in a person to initiate the episode of care. Patient
registration takes place in various healthcare settings and at the various functions of the episode of care
(Figure 1). Patient registration can be done by patient and/or by the designated (authorized, legal)
patient’s representative (guardian) (parent, caregiver, decision-maker, etc.). In some cases pre-
registration may take place prior to the actual registration process at the healthcare organization. This
may happen as a part of scheduling a procedure during the episode of care, a follow-up visit, etc..

Registration department (or Patient Access or Admitting departments, or Call Centers, or Online
Scheduling Services) is responsible for management of patient registration activities. In some situations
for an unknown patient [e.g., trauma unknown patient, unconscious patient, patient with acute
condition (stroke, heart attack), child who was brought up to the emergency department without a
representative], patient registration can be conducted by other authorized staff, e.g., clinicians. During
the patient registration, insurance verification and pre-authorization may take place. In this case,
insurance verifier is involved in verifying payment information as a part of the patient registration
process. Please see Business Actor list below.

The patient or patient’s representative (guardian) provides registration information to the registration staff
verbally, via facility registration portal/kiosk, or phone interview. Data collected during the registration
process include those provided by the patient or patient’s representative (guardian) as well as
received/uploaded from the various data sources, e.g., Electronic Health Record (EHR) systems, payor
systems, Health Information Exchanges (HIE) and other (please see Technical Actor list below).

Information collected at the registration initiates the creation of a new episode of care record. This
information will be further used at the next functions of the episode of care (triage/assessment, testing,
treatment, medication management and discharge/transfer). Figure 2 presents Patient Registration Use
Case in the overall context of Episode of Care’s functions and record components generated at a specific
function in the process of care. 6

Specific information collected during registration includes:

Generated by Business Actors
1. Demographics (Patient, Facility, Provider, Payor/Guarantor and Episode of Care)
2. Chief complaint/reason for visit (medical necessity)
3. Insurance information including billing data from the payors and remittance, as appropriate
4. Payment information (charge capture)
5. Physician order (for in-inpatient registration scenarios)
6. Consents
Generated by Technical Actors
7. Notification of document svailability
8. Acknowledgement of receipt
9. Audit record (Who, When, Why, How information was obtained and released) created in the
information systems

6
Integrating the Healthcare Enterprise (IHE). Information Technology Infrastructure (ITI) Technical Framework (TF) Supplement.
Health IT Standards for HIM Practices. White Paper. 2015. URL: http://qrs.ly/lb4vec0
 10

This information is to be input into the Registration–Admission, Discharge, and Transfer (R-ADT) System
as well as other health information systems (HIS) as appropriate (please see Technical Actor list below).
Use Case description below shows how specific information from the list above is generated by the
workflow step. Detail list of data elements by information category is provided in Data Specification
section below.

Fi
gure 2. Patient Registration in the Episode of Care

Specific actions conducted by the registration and insurance verification staff include:
1. Activation or the Episode of Care (EOC) record
2. Demographic information collection, verification and correction as needed
3. Data capture (input) and information retrieval (access) from various sources
4. Information reconciliation, validation and verification including patient identity matching
(master patient index (MPI) management, census reconciliation)
5. Concurrent analysis, queries and responses to ensure record correctness and completeness
including final scrubbing, editing, cleansing, and adjustments
6. Preparation for the coding and abstracting
7. Preparation for record archival
8. Establishing of the audit trail record for the episode of care
9. Electronic signing/authentication of registration record and
10. Release (or transfer) of information (output) to the next function of the episode of care, e.g.
triage/assessment
 11

Problem Description
Problems with Patient Registration can be classified into two categories: 1- Record/Data Quality and 2-
Information Access as described below.

Record/Data Quality
1. Insufficient information accuracy to support other functions in the episode of care
a. Inaccurate patient ID information
b. Error in data entered7
c. Redundant information, which causes the inability to determine current information, i.e. “field of
noise”8 (see “redundant information” also below).
2. Lack of clinical documentation, e.g.
a. Missing medical records from the previous encounters
b. Refusal to sign consent
c. Inability to obtain advanced beneficiary notice (ABN)
d. Inability to obtain prior authorization from payer
e. Missing orders for encounter/procedure/test/treatment
f. Missing adequate content in the physician’s order (e.g., admitting diagnosis, reason for visit
on the orders)
3. Lack of provider identification or contact information
a. Patient does not remember his provider
b. Patient does not have contact information for his provider
Information Access
4. Inability to get information about the unknown patient (e.g., trauma unknown patient, unconscious
patient, patient with acute condition (stroke, heart attack), child who was brought up to the
emergency department without a representative)
5. Lack of information access from various sources to support patient registration
6. Redundant information may restrict efficient access to critically need clinical information

7
ECRI. Recommendations for Health IT Patient Safety. Webinar: July 19th Quarterly Conference Call of the Partnership for
Health IT Patient Safety 2016.
8
Kuhn T, Basch P, Barr M, etal. Clinical Documentation in the 21 st Century. An Executive Summary of a Position Paper from The
American College of Physicians. Annals of Internal Medicine. 2015. 162(4): 301-314. URL:
http://annals.org/aim/article/2089368/clinical-documentation-21st-century-executive-summary-policy-position-paper-from
 12

Solutions: Use Case Scenarios

The following is the list of scenarios that involve patient registration:
A. Emergency department visit:
1. Registration of walk-in/patient presentation in ED
2. Registration initiated/conducted by clinicians
3. Registration for diagnostic testing during ED stay
4. Registration for medication administration
5. Registration for pre-admission of patients into the hospital
6. Registration for follow-up care
B. In-patient setting visit (hospitals, clinics and other):
1. Registration for planned admission
2. Registration for diagnostic testing during hospital stay
3. Registration for medication administration
4. Registration for treatment during hospital stay
5. Registration/Scheduling for post acute care follow-up
C. Out-patient setting visit:
1. Registration for walk-in/patient presentation
2. Registration/Scheduling for planned visit
3. Registration/Scheduling for diagnostic testing
a. during the visit
b. after the visit
4. Registration/Scheduling for treatment
a. during the visit
b. after the visit
5. Registration for medication administration
6. Registration for post-visit follow-up

Scope
In 2016, we will focus on the following Patient registration scenarios:

A. Emergency department visit:

1. Registration of walk-in/patient presentation in ED
2. Registration initiated/conducted by clinicians

These two scenarios were selected from the 17 Patient Registration scenarios above because of the
following reasons:
Scenario 1 represents the generic example of patient registration/checking-in across various settings.
Scenario 2 describes the life-threatening situation that often occurs in the ED.

Use cases for the remaining 15 scenarios will be developed in the future.
 13

Actors (Business and Technical)

The following are the actors involved in the Patient Registration Use Case
Actors Description of the Role in the Use Case
Business Actors
Patient or guardian (patient’s Individual and/or his legal representative who are seeking healthcare
representative)
Registration staff Staff responsible for registering patients 9
Billing staff Staff responsible for generating a bill for healthcare services performed. This
includes Insurance Verifier Registrar, who verifies patient insurance information
and communicates with the payor
Payor Entities involved in paying for medical care
Clinician10 Clinician who receives patient registration information to conduct assessment
Technical Actors
Registration–Admission, An administrative information system that stores demographic information and
Discharge, and Transfer (R- performs functions related to registration, admission, discharge, and transfer of
ADT) System patients within the organization11
Electronic Health Record An information system that ensures the longitudinal collection of electronic
(EHR) System health information for and about persons; enables immediate electronic access
to person- and population-level information by authorized users; provides
knowledge and decision support that enhances the quality, safety, and efficiency
of patient care; and supports efficient processes for healthcare deliver. 12 These
include EMR, EPR, CPR systems (see Glossary section for the definitions).
Health Information System Information system that supports healthcare delivery within a healthcare
(HIS) organization. It includes R-ADT, EHR, laboratory, radiology, pharmacy, financial,
administrative and other information systems.
Electronic Document Software consisting of many component technologies that enable healthcare
Management System (EDMS) businesses to use documents to achieve significant improvements in work
processes13
Financial System Information system used by a healthcare organization to perform administrative
and financial transactions associated with healthcare delivery
Payor System Information system used by health plans to manage administrative and financial
functions associated with the coverage and financing of healthcare for individuals
enrolled in the health plan (health plan members). These functions manage
information regarding the individual’s enrollment, eligibility, coverage and
benefits, authorizations, claims, care coordination and other information related
to the member
Personal Health Record (PHR) Information system used to create, review, annotate and maintain records by the
System patient or the caregiver for a patient. The PHR may include medications, medical
problems, allergies, vaccination history, test results, visit history or
communications with healthcare providers
Health Information Exchange An infrastructure to support information exchange between information
(HIE) exchange participants
Mobile Health (mHealth) mHealth application (apps), i.e. portable device including but not limited to
Application mobile phones, Personal Digital Assistants (PDAs) and other, that enables access

9
AHIMA, Pocket Glossary of Health Information Management and Technology. Chicago, IL. 2014, p. 127.
10
Ibid, p. 29.
11
Ibid, p. 127.
12
Ibid, p. 53.
13
Grzybowski D. Strategies for electronic document and health record management. AHIMA. Chicago, IL. 2014. pp. 31,40,47,159.
 14

to patient information across various information systems

Use Case Description

Use Case Name: Registration of Walk-in/Patient Presentation in ED
Italic font and grey highlights indicate steps performed/data created by Technical Actors
Business Actors: Patient (or Guardian/patient’s representative), Registration staff, Billing
staff (Insurance verifier registrar), Payor, Clinician
Actors
Technical Actors: R-ADT System, HIS, Financial System, Payor System, EHR, EDMS, HIE,
PHR, mHealth app
# of Step Workflow Steps Information Items
(Documents/Records/Data)
1 Patient enters into ED and presents to the Registration Patient Registration Record
staff 1. Patient/guardian demographics
2 Registration staff identifies patient, asks patient to (e.g.,name, DoB, address)
complete necessary forms (paper or electronic), and 2. Visit demographics (e.g., enterprise
checks in/register the visit in R-ADT System. In the case medical record number, date/time
of “trauma/unidentified patient”, registration staff of encounter, reason for visit, list of
assigns a tag with the ID number to be used in the barcodes, etc.),
episode of care. 3. Physician demographics (name,
3 HIS creates an audit record of the encounter PID, department/service
4 R-ADT System searches and obtains patient and visit- 4. Reason for visit
relevant information from various systems (HIS, EHR, 5. Consent for visit
Financial Systems, EDMS, HIE, PHR, mHealth app) 6. Consent for information sharing
5 Registration staff validates patient information, prints ID 7. eSignature for Registration Staff
bracelet and correspondent labels with barcodes for the 8. Wristband (patient ID bracelet)
patient, and signs the record with e-signature. Risk Management (RM)/Infection
Control (IC)/ Public Health/ Population
Health (PH) information
Audit record: Who, When, Why, What
6 Registration staff sends patient to Insurance verifier Insurance information:
registrar. Insurance verification may be done by the 1. Payor demographic
Registration staff. 2. Insurance ID
7 Insurance verifier registrar verifies patient insurance 3. Coverage
information; contacts payor, if needed; and 4. Co-pay
requests/collects co-pay or makes payment 5. eSignature for Insurance Verifier
arrangements – Need to be developed at more granular Payment information:
lavel 1. Invoice for service
8 R-ADT System communicates with the payor system 2. Payment receipt
directly or via HIE to obtain patient insurance 3. Payment plan, if needed
information. Patient information is updated in the 4. eSignature for Billing Staff
Financial System Audit record: Who, When, Why, What
9 R-ADT System updates patient information in PHR via Updated Patient Registration Record
mHealth app Audit record: Who, When, Why, What
10 Registration staff assembles all documents necessary for Updated Patient Registration Record
the episode of care and completes the registration by eSignature for Registration Staff
signing the Episode of Care Record with e-Signature in Notification of Record Availability
 15

EHR. This may be done automatically when the staff including notification to Care Team
completes the record (all data are entered and verified) Acknowledgement of Receipt
and closes the registration record for this patient. Staff
sends patient to clinician for assessment. Clinician opens
patient record to begin assessment and sends the
acknowledgement of receipt.
11 Registration information is uploaded into EHR. EHR Updated Patient Registration Record
sends Notification of Record Availability to clinician. Notification of Record Availability
12 EHR sends back to the R-ADT the Acknowledgement of Acknowledgement of Receipt
Receipt.
13 Audit trail for the personnel and systems involved in Audit Record: Who, When, Why, What
patient registration is completed in HIS
Entry Condition R-ADT System
Exit Condition HIS with record for assessment function and with audit trail record
Quality Real time patient information verification
Requirements

UML Workflow and Dataflow Diagram

Figure 2 presents the Unified Modeling Language (UML) sequence diagram to demonstrate roles and
relationship of the actors (business and technical), workflow and data flow associated with the use case.
 16

Figure 2: UML Sequence Diagram: Use Case A1 - Registration of Walk-in/Patient Presentation in ED.
Numbers 1-13 indicate the workflow steps. Update to add new steps and actor (clinician.)
 17

Data Specifications for Information Items

The following information items (documents/records/data) were identified in the Patient Registration
Use Case:

Patient Registration Information Insurance information

2. Patient/guardian demographics (e.g., name, 1. Payor demographic
DoB, address) 2. Insurance ID
3. Visit demographics (enterprise medical record 3. Coverage
number, date/time of encounter, reason for 4. Co-pay
visit, list of barcodes, etc.), 5. eSignature for Insurance Verifier
4. Physician demographics (name, PID, Payment information
department/service) 1. Invoice for service
5. Chief complaint, Reason for visit, ABN 2. Payment receipt
6. Consent for visit 3. Payment plan, if needed
7. Consent for information sharing 4. eSignature for Billing Staff
8. eSignature for Registration Staff
9. Wristband (patient ID bracelet with barcodes)
Risk Management/Infection Control/Public Health/ Notification of Record Availability
Population Health Information Acknowledgement of Receipt
1. Have you been out of the country in the last Audit Record: Who, When, Why, What
three weeks?

Please note that during patient registration, clinical information may be collected, however this information is out
of scope for the Patient Registration Use Case.

Tables below provide list of data elements by information item for the Patient Registration Record. Each
data element contains the description of its attributes: sequence (SEQ, based on Health level Seven
(HL7) version 2.x (v2.x) sequence), data element name, optionality (OPT), format, length of the field
(Len, based on HL7v2.x length), HL7 data types and IHE data element names.

For Optionality (OPT) 14 we used the following legend:

Option Symbol Definition
SHALL R - Required Field must be populated with a valid value.
SHOULD C - Conditional Field will be populated if value does exist depending on the specific
condition. For example, US Passport may be available only from the US
citizens; Non-US citizens will have their green cards or visas, instead.
MAY O - Optional Field may be populated at the discretion of organization.

14
Health Level Seven (HL7). Conformance Implementation Manual. 2.B.7.2 Usage in v2.x Standard. 2006. URL:
http://wiki.hl7.org/index.php?title=Conformance_Implementation_Manual . Please note that HL7 optionality codes include R, C
and O. In some cases, when in the HL7 standard the data field was listed as optional or otherwise not required , IHE further
constrains the HL7 optionality as follows:
R - sending application shall provide a valid value for all “R” fields.  The value shall be of the specified type and within the range
specified for the field; R2 - an IHE extension - if the sending application has data for the field, it is required to populate the
field. If the value is not known, the field may not be sent; R+ - an IHE extension - in the context of a specific transaction, IHE
requires that this field be present and populated with data.” (IHE Terminology. URL:) IHE uses R+ to help call out to the
reader that the baseline standard does not require this attribute, but the IHE transaction does make this mandatory.
 18

Patient Registration Information

Based on HL7 Patient Identity (PID) and IHE PID Segments 15
* asterisk in SEQ column means that this data element is not available in the HL7 PID segment. It is available in the
HL7 PV1 (Patient Visit) segment. This data element is included in the AHIMA data set for completeness of patient
registration information from the user perspectives.
NNN –Bold, italic font, shaded row indicates the data element that contains additional data element components.
Blank SEQ cell indicates that the data element components carry the same SEQ number as the main data element.
SEQ Data Element Opt Format Len HL7 IHE Data Element
Data Name
Type
Visit/Encounter Identification
1 Enterprise Master Patient Index R Alphanumeric 20 SI Set-ID - Patient ID
(EMPI)
2 Medical Record Number (MRN) R Alphanumeric 250 CX
* Episode of Care Number16 R Alphanumeric 250 CX
* Visit/Encounter Number (account C Alphanumeric 250 CX Patient Account
number)17 Number
318 Forms of Patient Identification 250 CX Patient Identifier
List
Photo O Image
19
19 Social Security Number C Numeric 16 ST SSN Number-
Patient
2020 Driver’s License Number C Alphanumeric 25 DLN Driver License-
Patient
State ID Card C Alphanumeric 25
Military ID C Alphanumeric 25
Passport Number C Alphanumeric 25
Green Card Number C Alphanumeric 25
Visa Number C Alphanumeric 25
Student ID C Alphanumeric 25
Insurance Card C Alphanumeric 25
5 Patient Name R Alphanumeri 250 XPN Patient Name
c
Name, Prefix O Text 20 ST Prefix
Name, Last R Text 194 FN Family Name
Name, Suffix C Alphanumeric 20 ST Suffix
Name, First R Alphanumeric 30 ST Given Name

15
Integrating Healthcare Enterprise (IHE). Information Technology Infrastructure (ITI) Committee. Technical Framework (TF).
Patient Identity Segment. Volume 2a. p.40-42. URL: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2a.pdf
16
NOTE: Episode of care may have multiple visits to different departments, or series of visits under an account number. Some
systems call this an encounter number; CSN – Contact Serial Number – in EPIC
17
NOTE: Encounter Number is an individual visit number with unique start and end time under a series of visits in the episode
of care.
18
HL7 SEQ Number 4 represents Alternate Patient ID. It is retained for back compatibility with HL7v2.3 where this code was
used. It is not used in the newer versions of HL7 standards where Alternate Patient ID is a part of Forms of Patient Identification
(SEQ 3).
19
This data element is available in the Hl7 SEQ Number 19 in the HL7v2.x PID segment.
20
This data element is available in the HL7 SEQ Number 20 in the HL7v2.x PID segment.
 19

SEQ Data Element Opt Format Len HL7 IHE Data Element
Data Name
Type
Name, Middle C Text 30 ST Second and Further
Given Names or
Initials Thereof
6 Mother’s Maiden Name O Text 250 XPN Mother’s Maiden
Name
7 Date of Birth R 26 TS Date/Time of Birth
Time of Birth (e.g., newborn) C 5 DTM Date/Time
8 Administrative Gender R 1 IS Administrative Sex21
(F/M/U)22,23
9 Patient Alias 250 XPN Patient Alias
Alias, Last O Text 194 FN Family Name
Alias, First O Text 30 ST Given Name
Alias, Middle O Text 30 ST Second and Further
Given Names or
Initials Thereof
10 Race24 R Text 250 CE Race
11 Primary Address R 250 XAD Patient Address
Building Number R Alphanumeric 12 SAD Dwelling Number
Line 1 (Street Name) R Alphanumeric 184 SAD Street Address
Line 2 (Apt. No or Unit No) O Alphanumeric 120 ST Street Address
City R Text 50 ST City
County25 R Text 20 IS County
State/Province R Text 50 ST State or Province
Zip Code R Alphanumeric 12 ST Zip or Postal Code
Country Name R Text 3 ID Country
13 Phone Number Home 250 XTN
Phone Number – Home R Numeric 199 ST Telephone Number
Phone Number – Cell C Numeric 199 ST Telephone Number
Email Address – Business O Alphanumeric 199 ST Email Address
14 Phone Number Business 250 XTN
Phone Number – Business R Numeric 199 ST Telephone Number
Phone Number – Fax C Numeric 199 ST Telephone Number
Email Address – Business O Alphanumeric 199 ST Email Address
11 Alternate Address O 250 XAD Patient Address

21
Trans-gender is not recognized at this time in IHE.
22
HL7 v3: Female/Male/Undifferentiated (F/M/U) format. This format is also used by the Centers for Disease Control and
Prevention (CDC). Public Health Information Network (PHIN) Vocabulary Access and Distribution System (VADS). PHIN-VADS
Administrative Gender. URL: https://phinvads.cdc.gov/vads/ViewValueSet.action?id=8DE75E17-176B-DE11-9B52-
0015173D1785
23
In Meaningful Use: Female/Male/Unknown (F/M/UNK). Common Clinical Data Set (CCDS) for Meaning Use. Birth Sex Codes.
URL: https://www.healthit.gov/sites/default/files/2015Ed_CCG_a5-Demographics.pdf.
24
FIND REFERENCE - Race Table in US Census (X options) and /or CDC (3000 options)
25
HL7 SEQ Number 12 represents County Code. It is retained for back compatibility with HL7 v2.3 where this code was used. It
is not used in newer versions of HL7 where county is a part of address (SEQ 11).
 20

SEQ Data Element Opt Format Len HL7 IHE Data Element
Data Name
Type
Building Number R Alphanumeric 12 SAD Dwelling Number
Line 1 (Street Name) R Alphanumeric 184 SAD Street Address
Line 2 (Apt. No or Unit No) O Alphanumeric 120 ST Street Address
City R Text 50 ST City
County R Text 20 IS County
State/Province R Text 50 ST State or Province
Zip Code R Alphanumeric 12 ST Zip or Postal Code
Country Name R Text 3 ID Country
13 Phone Number Home 250 XTN
Phone Number – Home R Numeric 199 ST Telephone Number
Phone Number – Cell C Numeric 199 ST Telephone Number
Email Address – Home O Alphanumeric 199 ST Email Address
14 Phone Number Business 250 XTN
Phone Number – Business R Numeric 199 ST Telephone Number
Phone Number – Fax C Numeric 199 ST Telephone Number
Email Address – Business O Alphanumeric 199 ST Email Address
15 Primary(Preferred) Language R Text 250 CE Primary Language
16 Marital Status O Text 250 CE Marital Status
17 Religion O Text 250 CE Religion
21 Mother’s Identifier C Alphanumeric 250 CX Mother’s Identifier
22 Ethnic Group26 R Text 250 CE Ethnic Group
23 Place of Birth O 250 ST Birth Place
11 City O Text 50 ST City
11 State/Province O Text 50 ST State
11 Country O Text 3 ST Country
24 Multiple Birth Indicator C Numeric 1 ID Multiple Birth
Indicator
25 Birth Order C Numeric 2 NM Birth Order
Other Information
26 Citizenship O Country 250 CE Citizenship
27 Veterans Military Status O Text 250 CE Veterans Military
Status
Occupational Information27
Employment Status O Text 250 CE Insured's
Employment Status
Employer O Text 250 XAD Insured’s Employer
Address
Occupation O Text 250
Industry O Text 250

26
Race Table in US Census (X options) and /or CDC (3000 options)
27
Occupational Information is not collected in HL7 PID. It is collected in insurance section HL7 IN1. AHIMA NEEDS TO DECIDE –
where to have Occupational Information ( in Pt Registration Information or Insurance information)
21
 22

Patient Registration Associated Parties Information (Based on HL7 NK1 Segment)

SEQ Data Element Opt Format Len HL7 HL7 Data Element
Data Name
Type
2 Emergency Contact Name O 250 XPN Name
Name, Prefix O Text 20 ST Prefix
Name, Last R Text 194 FN Family Name
Name, Suffix C Alphanumeric 20 ST Suffix
Name, First R Alphanumeric 30 ST Given Name
Name, Middle C Text 30 ST Second And Further
Given Names Or
Initials Thereof
3 Relationship O Alphanumeric 250 CE Relationship
5 Phone Number Home 250 XTN
Phone Number – Home R Numeric 199 ST Telephone Number
Phone Number – Cell C Numeric 199 ST Telephone Number
Email Address – Home O Alphanumeric 199 ST Email Address
6 Phone Number Business 250 XTN
Phone Number – Business R Numeric 199 ST Telephone Number
Phone Number – Fax C Numeric 199 ST Telephone Number
Email Address – Business O Alphanumeric 199 ST Email Address

2 Legal Healthcare O 250 XPN Name

Representative/Guardian of the
Person (Surrogate Decision
Maker) Name
Name, Prefix O Text 20 ST Prefix
Name, Last R Text 194 FN Family Name
Name, Suffix C Alphanumeric 20 ST Suffix
Name, First R Alphanumeric 30 ST Given Name
Name, Middle C Text 30 ST Second And Further
Given Names Or
Initials Thereof
3 Type of Legal Representative C Alphanumeric 250 CE Relationship
(Surrogate Decision Maker,
Guardian, Conservator, Durable
Power of Attorney HC)28,29,30
28
State of Connecticut. Probate Court User Guide for Conservators. 2016. URL: ctprobate.gov.
29
FindLaw. Web Resource. Definition of Guardian. 2016. URL: http://family.findlaw.com/guardianship/how-to-establish-
guardianship-of-a-child-faqs.html
30
Reisbick B. Personal Communication, September 20, 2016
Surrogate Healthcare Decision-Makers are advocates for incompetent patients due to: Immaturity; Mental Incapacity
(Temporary or Permanent); Cognitive Impairment; Nearing End of Life; or otherwise unable/unwilling to make decisions
regarding their personal healthcare. There is high variability under various state laws. Often, where there is no designated
Surrogate for Healthcare Decisions, the Healthcare Surrogate may be selected in a descending order of priority from: (a)
Patient’s Guardian (or Conservator) of the Person; (b) Patient’s Spouse; (c) Either Parent; (d) Adult Son or Daughter. Terms in
use: Guardian of the Person with Authority makes healthcare (not business) decisions; Designee of a Durable Power of
Attorney for Healthcare (not business) decisions. Surrogate healthcare decision-making guiding factors: (a) the Patient’s prior
 23

4 Legal Healthcare 250 XAD Address

Representative/Guardian of the
Person (Surrogate Decision
Maker) Address
Building Number R Alphanumeric 12 SAD Dwelling Number
Line 1 (Street Name) R Alphanumeric 184 SAD Street Address
Line 2 (Apt. No or Unit No) O Alphanumeric 120 ST Street Address
City R Text 50 ST City
County R Text 20 IS County
State/Province R Text 50 ST State or Province
Zip Code R Alphanumeric 12 ST Zip or Postal Code
Country Name R Text 3 ID Country
5 Phone Number Home 250 XTN
Phone Number – Home R Numeric 199 ST Telephone Number
Phone Number – Cell C Numeric 199 ST Telephone Number
Email Address – Home O Alphanumeric 199 ST Email Address
6 Phone Number Business 250 XTN
Phone Number – Business R Numeric 199 ST Telephone Number
Phone Number – Fax C Numeric 199 ST Telephone Number
Email Address – Business O Alphanumeric 199 ST Email Address

stated wishes or preferences; (b) the Patient’s personal values, religious preference, beliefs about life and death, dignity, etc; or
(c) the Patient’s best Interests.
 24

To Be Developed for the 12/19 Call

Insurance Information

Payment Information

Chief Complaint, Reason for Visit, ABN

1. Chief complaint
2. Reason for visit
3. Advance Beneficiary Notice (ABN)

Consent for Visit

(BCCP/ APPC)
1. Conditions of Admission and Treatment (Consent form)
2. Guardianship/Power of attorney
3. Personal Representative Authorization
4. Consent for surgical procedure
5. Advance directives (Living will)
6. Do not resuscitate
7. EBOLA & MERS screening

Consent for Information Sharing

Wristband (patient ID bracelet with barcodes)

Notification of Record Availability

Get from IHE NAV Profile

Acknowledgement of Receipt
Get from IHE NAV Profile

Audit Record
WHO, WHEN, WHY, WHAT
Get from S&I Data Provenance or HL7
1. Patient’s Full Name
2. Medical Record Number
3. Date of birth
4. Address
5. Date(s) of Service Accessed
6. Information Accessed
7. Name of person accessing record
8. Date Record Accessed
9. Access Purpose (treatment, payment, operations [TPO])