Streamlining Health Care Administrative Transactions in Minnesota
Agenda
ACO Data Analytics Technical Advisory Group (TAG)
Thursday, January 14, 2016
8:30 a.m. – 10:30 a.m.
Please note location:
Shoreview Community Center
4580 Victoria St N
Shoreview, MN 55126
In person attendance is preferred. However, teleconference and webex access will be provided
as shown below.
Teleconference line: 605-475-6006 Participant passcode: 337213
Note: If using the teleconference option please put your phone on mute (mute button or
*6) when you do not wish to be heard. Please do not place your phone on hold.
WebEx instructions:
1. To start the WebEx session, go to: https://health-state-mn-ustraining.webex.com
2. Under “Attend a Session,” click “Live Sessions”
3. Click on the session for “ACO Data Analytics TAG”
4. Provide your name, email address, and the following password: Aco2015! (Note: The
exclamation mark at the end is part of the password.)
5. Click “Join now”
Meeting Objectives:
• Review questions/comments regarding recommendations and work products from
December 16, 2015 TAG meeting
• TAG vote on recommended ACO member file data content and format
• Develop plans and next steps for follow-up.
Agenda items
1. Meeting to order – Vicky Swanson, co-chair
2. AUC anti-trust statement: http://www.health.state.mn.us/auc/pdfs/antitrust.pdf
3. Introductions - Please e-mail your attendance to [email protected]
4. Review and discussion of feedback on December 16 meeting products
The TAG met on December 16, 2015 and developed consensus recommendations for the
file structure and data characteristics of ACO member data to be exchanged between
payers and providers. The recommendations included:
Page 1 of 55 total pages in packet
• The file structure should be a pipe-delimited text file;
• A set of data elements listed in a supporting document are to be provided using data
content and format based on HIPAA standard transactions as described in the
supporting document. Elements labeled “situational” should be exchanged whenever
possible.
Following the meeting, the Minnesota Department of Health (MDH) prepared a summary of
the recommendations and related background materials and forwarded them to the TAG
with a request for any questions or comments by January 7. The responses we received are
summarized below.
TAG responses to request for comments or questions regarding work products from 1216-15 meeting:
MDH received a small number of comments/questions with some overlap and
duplicates, as categorized below:
• “Supplemental” data elements: We received questions regarding whether and how
“supplemental” data elements would be permitted and exchanged as part of the
data file. (This was discussed to some degree at the 12/16/15 meeting in the case of
two supplemental data elements, “county” and “clinic name” as displayed in some
of the meeting follow-up materials. The follow-up questions we received were
somewhat general and could pertain to the two supplemental elements discussed at
the meeting, and/or regarding “supplemental” data elements more generally.)
• Frequency and timing of the member file exchanges: We received a question about
how often, and at what intervals, the member files will be exchanged.
• File naming convention: We received a question about whether file naming
conventions should be considered. A related comment suggested the need to also
consider “time stamps” on the files (either as part of the naming convention, or
within the file) to help distinguish among potentially frequent demographic data
feeds.
• Additional clarification of data elements: We received suggestions to clarify data
elements nos. 13, 17 and 18 with additional description as shown in the highlighted
sections below.
Data
Element
Name
(names used
at 12/16
TAG mtg)
[Attributed]
Provider
Name
Element
Order
Data "sub-element"
if applicable
13
Provider Last Name
Format
Usage
Field
length
(min/max)
AN
1/60
Page 2 of 3
Page 2 of 55 total pages in packet
Required
(R ) or
Situational
(aka
Optional)
(S)
S
Notes
Individual last name or
organization name
Data
Element
Name
(names used
at 12/16
TAG mtg)
[Attributed]
Provider ID
[Attributed]
Provider
Clinic
Information
17
National Provider
Identifier (NPI)
AN
10
Required
(R ) or
Situational
(aka
Optional)
(S)
S
18
National Provider
Identifier (NPI)
AN
10
S
Element
Order
Data "sub-element"
if applicable
Format
Usage
Field
length
(min/max)
Notes
Code identifying a party.
Use TYPE 1 NPI. This is
the individual provider
such as a MD, PA, NP.
Code identifying a party.
Use NPI Type 2
Situational Field - This
field represents a single
clinic or in some cases a
grouping of Type 2 NPIs.
In the case of a grouping
of Type 2 NPIs, no single
identifier exists that
reflects this relationship
so field will often be
blank.
• Implementation of recommendations: We received a comment about system
changes that may be needed to implement the TAG’s recommendations, and to
consider such changes when considering the implementation of the
recommendations.
Agenda Items (continued)
5. Clarification and summary of TAG recommendations and TAG vote on recommendations
Following discussion of the responses above, the TAG’s recommendations will be
clarified and summarized for a TAG vote to approve them.
6. Wrap-up and next steps
7. Other Business
Next Meeting:
If needed: 8:30 am – 10:30 am, February 10, 2016, location TBD
Page 3 of 3
Page 3 of 55 total pages in packet
ACO Data Analytics TAG
1-14-16 Meeting Packet
Background – Previously sent to the TAG
Table of Contents
Section
Page
A. Presentation used at 12-16-15 ACO
Data Analytics TAG meeting
4
B. Narrative Meeting Summary:
12-16-15 ACO Data Analytics
Meeting
25
C. 12-16-15 TAG meeting follow-up:
HIPAA standard transactions
formatting of ACO member file data
elements (long version)
30
D. 12-16-15 TAG meeting follow-up:
HIPAA standard transactions
formatting of ACO member file data
elements (short version)
36
E. Meeting summary and follow-up to
ACO Data Analytics TAG 12-16-15
meeting
40
A. Presentation used
at 12-16-15 ACO
Data Analytics TAG
meeting
Page 4 of 55 total pages in packet
ACO Data Analytics TAG
December 16, 2015
Page 5 of 55 total pages in packet
TAG Summary to date
• First meeting November 5
• Overview, discussion
• Project goal/scope
“…a guide [for] the file format and variable names that would be used
to communicate an attributed member list. The elements
preliminarily determined by the subgroup would include the member’s
name, date of birth, gender, address, phone number, primary payer,
and their primary care provider, but may also include other
demographic information such as race, ethnicity, and primary
language.”
Page 6 of 55 total pages in packet
2
First TAG meeting (continued)
• Homework assignment
• Submit to MDH by Nov. 20
• Data dictionaries, record layouts of membership files being exchanged
between payers and providers participating in accountable care
arrangements
• Best practice examples
• 2 MDH reminders; 1 chair reminder
Page 7 of 55 total pages in packet
3
Today – Review, discuss homework responses
• Responses received to date:
•
•
•
•
•
•
•
•
BCBSM
DHS (also submitted information from Colorado and CMS)
HealthPartners
North Memorial (No. Memorial submitted examples from three payers: Medica,
Federated, and PreferredOne)
Mayo/Optum
PreferredOne
Medica (Note: Medica’s information matched what was received from No. Memorial
and is displayed only under No. Memorial to conserve space in the tables later in this
document.)
PrimeWest (received recently, shown in notes section of accompanying tables)
Page 8 of 55 total pages in packet
4
Organization of responses – 3 sets of tables
• Set 1 – Priority data elements to identify patients/members
• Set 2 – Priority data elements to identify providers
• Set 3 – Other patient and provider data elements (less
common among the responses, less immediately relevant to
identifying patients/providers)
Page 9 of 55 total pages in packet
5
“Reference standards”
• HIPAA ASC X12 Benefit Enrollment Maintenance (834) transaction
specifications or other related X12 transactions
• §162.1501 Enrollment and disenrollment in a health plan transaction.
• The enrollment and disenrollment in a health plan transaction is the transmission of
subscriber enrollment information from the sponsor of the insurance coverage, benefits, or
policy, to a health plan to establish or terminate insurance coverage.
• §162.1502 Standards for enrollment and disenrollment in a health plan transaction.
• The Secretary adopts the following standards for enrollment and disenrollment in a health
plan transaction … The ASC X12 Standards for Electronic Data Interchange Technical Report
Type 3—Benefit Enrollment and Maintenance (834), August 2006, ASC X12N/005010X220
(Incorporated by reference in §162.920)
• CMS Medicare Shared Savings Program (MSSP) enrollment file provided to
MDH by DHS
Page 10 of 55 total pages in packet
6
Table Set One: Priority data elements to
identify patients/members
• Data Elements:
• Patient name
• Patient date of birth
• Patient ID
• Patient gender
• Patient address
Page 11 of 55 total pages in packet
7
Data element tables
Yellow banded variation(s) is/are most
common, most frequent
Data element
Variations
(Patient Name)
First name; Middle
initial; Last name
Last name; First Name;
Middle initial
Last name; First Name;
Middle name
First name; Last name
Last name; First name;
Middle name; prefix;
suffix
Response Submissions
BCB DHS HP N. Mem. Mayo/
SM
Optum
X
X
X
X
(Fed, P1)
P1
Reference
HIPAA
CMS
834
(MSSP)
X
Notes
X
X
(Medica)
X
X
Additional information and notes
Types of data
“Alpha” (included terms like text, string, character)
Record lengths
Varied – some had record lengths for each part of the name, others had a
single length for the full name
Availability of data
Varied by payer – weekly, monthly,
“one
timeinload”
Pagequarterly,
12 of 55 total
pages
packet
8
Table Set One: Priority data elements to identify patients/members
Example 1 – Patient Name
Variations
(Patient Name)
First name; Middle
initial; Last name
Last name; First Name;
Middle initial
Last name; First Name;
Middle name
First name; Last name
Last name; First name;
Middle name; prefix;
suffix
Response Submissions
BCB DHS HP N. Mem. Mayo/
SM
Optum
X
X
X
X
(Fed, P1)
P1
Reference
HIPAA
CMS
834
(MSSP)
X
Notes
PrimeWest: Last name, first name only
X
X
(Medica)
X
X
Additional information and notes
Types of data
“Alpha” (included terms like text, string, character)
Record lengths
Varied – some had record lengths for each part of the name, others had a
single length for the full name
Availability of data
Varied by payer – weekly, monthly,
“one
timeinload”
Pagequarterly,
13 of 55 total
pages
packet
9
Table Set One: Priority data elements to identify patients/members
Example 2 – Birth Date
Variations
(Birth Date)
MM/DD/YYYY
01JAN2000
Response Submissions
BCB DHS HP
N.
SM
Mem.
*
X
X
?
X
Mayo/
Optum
?
P1
*
HIPPA
834
CMS
(MSSP)
X
X
Notes
?
?
YYYY-MM-DD
Reference
?
X
?
PrimeWest: ccyy-mm-dd
Suggestion: format all dates the same
HP, BC, DHS, others can comply with this
format (depending on timing)
Additional information and notes
*No. Memorial and PreferredOne indicated that the birth date data element is exchanged, but did not
specify the format.
Type of data:
Alphanumeric, “Date”
Record length:
9, 10 digits
Data availability
Weekly, monthly, quarterly, one time load
Page 14 of 55 total pages in packet
10
Table Set One: Priority data elements to identify patients/members
Example 3 – Patient ID
Variations
(Patient ID)
Member ID Number
Member Subscriber
ID
Recipient ID
Member Number
Alternate ID (Alt ID)
Member ID
Patient Account No.
Subscriber Number
Subscriber ID
Beneficiary HIC No.
Response Submissions
BCB DHS HP N. Mem. Mayo/
SM
Optum
Reference
P1 HIPAA 834 CMS
Notes
(MSSP) Suggestion: Use only a single field rather than
2 (per example)
X
X
HIPAA 834 also has situational “supplemental ID”
X
“Subscriber
ID” – SSN or
other per
contract, up
to 50 char
Patient = subscriber per HIPAA 5010 – use complete defns
from HIPAA guides
DHS shares only record for individual - questions about
subscriber or other relationships not always appropriate in
this case. Discussion is about “patient”
HP also has “person no.” and “patient ID ”
PrimeWest: PMI (numerical MHCP ID)
X
X
X
(Medica)
X (Fed)
X (P1)
X
X
X
X
X
Additional information and notes
Page 15 of 55 total pages in packet
Type of data
Alpha (text, string, character); Number
Record length
8, 9, 11, 50 digits
X
11
Table Set One: Priority data elements to identify patients/members
Example 4 – Patient Gender
Response Submissions
Variations
(Patient
Gender)
Gender
BCBS DHS
M
X
X
HP
N/A
Gender code
N/A
Member gender
N/A
Beneficiary Sex
Code
N/A
Reference
N. Mem. Mayo/
Optum
P1
HIPAA 834
CMS
(MSSP)
X
(Medica,
Fed, P1)
Notes
Note: DHS uses gender to help identify
individuals (some individuals may have several
ID numbers)
X
X
(F, M, or U)
X
PrimeWest also has data element “member gender”
X
(F, M, or U)
Additional information and notes
Type of data
Text, character, string
Record length
1
Page 16 of 55 total pages in packet
12
Table Set One: Priority data elements to identify patients/members
Example 5 – Patient Address
Variations
(Patient Address)
Street_Address_Line_1
Street_Address_Line_2
City
State
Zip_Code
County_of_Residence
Member Zipcode
Beneficiary Zipcode
STREET_ADDRESS_1
STREET_ADDRESS_2
CITY
STATE
ZIP
MEMBER_ZIP_CODE
MEMBER_ADDRESS
MEMBER_CITY
MEMBER_STATE
BCBSM
Response Submissions
DHS HP N. Mem.
Mayo/
Optum
P1
Reference
HIPAA 834
CMS
(MSSP)
Notes
N/A
X
N/A
X
X
N/A
N/A
X
(Medica)
X
(Fed)
X
(P1)
X
X
Addresses difficult because of variability in
writing the address (Street vs. St.); people move
frequently too
From ACO standpoint, important to know where
people live for outreach, follow-up, etc.
X
Additional information and notes:
The BCBSM submission did not include patient address.
Type of data
Alphanumeric, number, character
Record length
2-82 (depending on data element)
Page 17 of 55 total pages in packet
Data availability
Weekly, monthly, quarterly, one time load
13
Table Set Two: Priority data elements to
identify providers
Data elements include:
• Provider name
• Provider ID
• Provider specialty
• Provider clinic information
Page 18 of 55 total pages in packet
14
Table Set Two: Priority data elements to identify providers
Example 1 – Provider name
Response Submissions
BCBS DHS HP
N.
M
Mem.
Mayo/
Optum
Reference
P1
HIPAA
834
Variations
(Provider name)
Attributed Physician
IHP Treating Provider Name
X
X
X
N/A
N/A
Provider Name; Provider First
Name; Provider Last Name
N/A
Attributed Provider; Provider Last
Name; Provider First Name
N/A
Name Last; Name First, Name
Middle, Name Prefix, Name
Suffix
N/A
X
CMS
Notes
(MSSP) Note: Clarity sought regarding terms
like “attributed phys.” vs IHP treating
provider
Need NPI associated with each provider
If NPI available, is name needed? -there are uses for name (perhaps
especially in smaller organizations)
Should format phys name same as
formatting patient name.
N/A Could be other than physician so
perhaps should be named differently
N/A Similar to attributed physician
N/A
X
N/A
X
Page 19 of 55 total pages in packet
N/A
15
Table Set Two: Priority data elements to identify providers
Example 2 – Provider ID
Response Submissions
Variations
(Provider ID)
BCBSM DHS
HP
X
N.
Mem.
Reference
Mayo/
Optum
P1
HIPAA
834
N/A
CMS
Notes
(MSSP) Practice provider vs. treating
provider
N/A
IHP Treating Provider NPI
N/A
Attributed Physician ID
N/A
Provider ID; National Provider
Identifier
PCP NPI
N/A
N/A
X
N/A
N/A
N/A
X
N/A
Provider ID
N/A
N/A
Identification Code Qualifier;
Identification Code
N/A
N/A
X
N/A
N/A
X
N/A
X
(NPI)
HP uses NPI
combined clinic and individual NPI
N/A
Additional information and notes
Type of data
Character, varchar, text, number
Record length
10-60
Data availability
Weekly, monthly, quarterly, one time load
Page 20 of 55 total pages in packet
16
Table Set Two: Priority data elements to identify providers
Example 3 – Provider specialty
Response Submissions
Variations
(Provider specialty)
Attributed Physician
Specialty
BCBS
M
DHS
HP
N.
Mem.
X
N/A
N/A
N/A
Mayo/
Optum
Reference
P1
HIPAA
834
CMS
(MSSP)
N/A
N/A
Notes
BCBSM providing to report
credential of provider
HP - Questions of whether
needed, and if so, how to
standardize
Fairview – reporting specialty
helpful to review, correct errors
Provider Specialty Code
N/A
N/A
N/A
Provider Spclty ID;
Provider Spclty Desc
N/A
N/A
N/A
X
X
N/A
N/A
N/A
N/A
Page 21 of 55 total pages in packet
As long as codes exist to link to
other databases, specialty not
needed
17
Table Set Two: Priority data elements to identify providers
Example 4 – Clinic information
Response Submissions
Variations
Attributed Clinic
BCBS
M
DHS
X
X
X
IHP Clinic NPI; Clinic Name
HP
Attributed Clinic; Attributed
NPI
Reference
N. Mem. Mayo/
Optum
P1
HIPAA
834
CMS
(MSSP)
Notes
Continue to need both clinic name
and NPI
HP uses NPI
Defn of attrib. clinic may vary, some
clinics may not have NPI
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
X
Additional information and notes:
The No. Memorial and Optum submissions did not include clinic.
Type of data
Character, varchar, text, number
Record length
10-60
Data availability
Weekly, monthly, quarterly, one time load
Page 22 of 55 total pages in packet
18
Summary notes
Data Element
Summary
Patient name
Recognition/support of the HIPAA patient name element (not the complete standard), awareness of CMS – possible opportunity for coord with CMS in
future
Patient date of birth
Suggestion: format all dates the same
HP, BC, DHS, others can comply with this format (depending on timing)
Interest in using HIPAA/CMS version
Only a single identifier (all numbers contained in one field)
Unit of interest is the “patient”
Interest in HIPAA data element, with specific 5010 defn.
Gender is needed for ACO individual identification
Interest in HIPAA/CMS defn of gender and field name
Patient ID
Patient gender
Patient address
Interest in address for ACO purposes (individual ID, outreach,etc.)
“County” field important – if that is not part of HIPAA standard, how can it be included? (Are there options in the HIPAA standard for elements like
“county”)
(Above raises general question: if there are “extra” elements, do they also get transmitted in standard format)
Also – generally – review HIPAA standards in more depth
Note: be careful re. county (zipcodes vary across counties)
Provider name
Interest in HIPAA standard
Name of field should reflect that the provider might be other than a physician
Name of field should include the word “attributed”
Interest in HIPAA standard (NPI)
Field name – “provider NPI”
Issue of atypical providers (eg, PCAs) – likely would not be attributed as provider in ACO
Out of scope at this time for the reasons in the slide deck above
Provider ID
Provider specialty
Provider clinic
information
Continue to need both clinic name and NPI
– based
on55
HIPAA
Page
23 of
totalstandard
pages in packet
19
Next steps:
• Preliminary recommendation – use HIPAA standard
• MDH provide additional info re HIPAA standard
• Question: common denominator file format (SAS, text delimited,
etc.)
• LCD – delimited text file (Excel may not have capacity), use pipe as
deliminator
• MDH will send info re HIPAA standard and voting form on two
questions: use of HIPAA standard, and delimited text file as above
• Additional question: frequency of data feeds, and timing for changes;
if supplementary data provided, how format?
Page 24 of 55 total pages in packet
20
B. Meeting Summary:
12-16-15 ACO Data Analytics Meeting
Page 25 of 55 total pages in packet
ACO Data Analytics TAG Meeting Summary
12-16-15
Agenda Item
Notes/follow-up
1. Meeting to order – Vicky
Swanson, co-chair
Vicky Swanson called the meeting to order at approximately 8:30 a.m.
2. AUC anti-trust
statement: http://www.healt
h.state.mn.us/auc/pdfs/antitr
ust.pdf
Vicky briefly summarized and referenced the AUC anti-trust statement.
3. Introductions - Please e-mail
your attendance
to [email protected]
Members introduced themselves.
4. Review and discussion of
responses to information
request from the first meeting
Vicky briefly reviewed the first TAG meeting, held November 5, 2015, and
noted that the TAG’s scope of work focuses on recommending standard
data formats, variable names, and file types for the exchange of attributed
ACO member lists and related providers. She also noted that the
November 5 meeting concluded with a homework request of members to
submit record layouts and data dictionaries for ACO member files to MDH
by November 20.
At the conclusion of the first ACO
Data Analytics TAG meeting on
November 5, 2015, TAG
participants were asked to send to
MDH record layouts of the
membership files being exchanged
between payers and providers
participating in accountable care
arrangements. The TAG will
review and discuss a brief
summary of the responses
received.
Vicky said that the goal of the current meeting was to review and discuss
the homework submissions received, and to determine commonalities,
best practices, and common interests among the submissions. The format
for the meeting was explained as follows: each of several data elements of
interest would be reviewed and discussed individually; a brief summary of
key points or findings from the discussion would be recorded for each
element; and then the summary information would be reviewed for any
possible recommendations and next steps. A slide deck prepared by the
Minnesota Department of Health (MDH) would serve as an outline for the
discussion and as a recording tool for notes and comments. The slide deck
and related rough, unedited notes, are attached with this meeting
summary.
The slide deck used as a discussion guide at the meeting was introduced
with additional background and explanation, including:
•
Responses to the November 5 homework request were received from
the following organizations:
o
Blue Cross and Blue Shield of Minnesota (BCBSM)
o
The Minnesota Department of Human Services (DHS )
o
HealthPartners
o
North Memorial (No. Memorial submitted examples from
three payers: Medica, Federated, and PreferredOne)
o
Mayo/Optum
1
Page 26 of 55 total pages in packet
ACO Data Analytics TAG Meeting Summary
12-16-15
Agenda Item
Notes/follow-up
•
PreferredOne
o
Medica
o
PrimeWest
MDH staff reviewed the responses and identified the data elements
below as most relevant to the TAG’s charge and scope of work at this
time, and for which there was also sufficient information from the
homework responses for discussion:
•
•
•
o
Priority data elements to identify patients/members
o
Patient name
o
Patient date of birth
o
Patient ID
o
Patient gender
o
Patient address
Priority data elements to identify providers
o
Provider name
o
Provider ID
o
Provider specialty
o
Provider clinic information
The slide deck included a table for each of the above data elements.
The tables compared the data characteristics (e.g., variations on the
data element name; record lengths; type of data, such as
alphanumeric or numeric; and other formatting) reported by each
organization responding to the homework request. In addition, each
table included two reference columns, to indicate the data
characteristics reported by two national reference groups: a) the
standards mandated by the federal HIPAA transactions and code sets
rules, and b) data provided by the Centers for Medicare & Medicaid to
providers as part of the Medicare Shared Savings Program (MSSP).
The TAG reviewed and discussed each of the tables in the slide deck. In
discussion several key themes emerged:
•
It is important to consider the HIPAA standards as a basis for a single,
uniform formatting of the data elements of interest because the
standards are federally mandated, and some are also mandated by
state law, and the standards are already widely known and used.
•
The unit of interest in identifying ACO members is the patient. In
considering the HIPAA standards as a basis for single, uniform
formatting, it is important to note that the standards provide a way to
2
Page 27 of 55 total pages in packet
ACO Data Analytics TAG Meeting Summary
12-16-15
Agenda Item
Notes/follow-up
distinguish between the “patient” and other types of individuals (e.g.,
the “subscriber”/insurance policy holder). If the HIPAA standards are
the recommended approach to single, uniform data formatting, the
standards should be used correctly to take advantage of their
capability for distinguishing patients from other individuals.
•
References to “physician” generally should be broader to encompass
other types of health care providers. In addition, when exchanging
provider-related data elements, the data should refer to the attributed
provider as determined by the payer’s algorithms.
Additional discussion and related points can also be found in the attached
slide deck.
Following reviews of the tables in the slide deck, the TAG focused on
summarizing consensus from the meeting and planning next steps as
described below. During this time Dave Haugen of MDH explained that
the AUC recommendation process typically starts with the TAG reaching a
consensus on an issue, followed by a TAG vote to formalize the consensus.
Items that are approved at the TAG level are then forwarded to the “full
AUC” (AUC committee of the whole, the Operations Committee) for a
review and vote before being adopted as an AUC recommendation.
Questions were also raised at this time regarding whether the TAG would
also recommend a single, uniform type of data file to exchange the data
elements discussed at the meeting, and whether the TAG would be
conducting similar work regarding other types of data elements related to
medical costs, utilization, patient risk factors and similar data. The TAG
addressed the first question, as noted below, and Vicky clarified that the
second question was out of scope for the TAG at this time, but that
additional phases of ACO data analytics development were planned as part
of the State Innovation Model (SIM) grant.
Based on the discussion above, the TAG agreed that:
a. With the exception of one data element, all of the other data elements
in the slide deck were consistent with the TAG’s scope. The exception
was the data element “Provider specialty.” In discussion, the TAG
agreed that, because other NPI codes existed to link providers across
databases, reporting of “provider specialty” was not needed as part of
ACO attributed member and provider identification data at this time.
b. The appropriate HIPAA standards should be recommended as the basis
for single, uniform formatting of the data elements being reviewed.
c. Data elements considered “situational” (“optional”) in the HIPAA
standards should be exchanged when the data are available.
3
Page 28 of 55 total pages in packet
ACO Data Analytics TAG Meeting Summary
12-16-15
Agenda Item
Notes/follow-up
d. A “least common denominator” file format should be recommended,
and the file format should be a delimited text file, using the “pipe”
symbol as the delimiter.
e. Any supplementary or additional data elements that might be included
in a data file would be exchanged according to a single, uniform
format, and that these data elements would follow after (so as not to
interfere with, or be mistaken for) the data elements discussed at the
meeting. In particular, the TAG discussed exchanging the patient’s
county of residence and clinic name if available, following the other
data elements noted above.
f.
5. Next steps and wrap up
The TAG will vote on recommending the HIPAA standards as noted in
#2, and the delimited text file as noted in #3, per the AUC process.
The TAG also agreed that prior to its vote, it should receive additional
information and examples regarding the use of the HIPAA standards to
meet the needs being addressed by the TAG.
The following next steps were discussed and agreed to:
1. MDH will provide the TAG with additional information and examples of
the HIPAA transaction record layouts as applied to the data elements
discussed at the meeting.
2. Following dissemination of the HIPAA transaction information, MDH
will send an email voting form to TAG members to vote on two
recommendations:
a. That HIPAA standards be used as the single, uniform basis for
formatting the data elements discussed at the meeting;
b. That data files containing the data elements discussed at the
meeting be exchanged as text delimited files, using the pipe
symbol as the delimiter.
6. Other Business
There being no other business, the chair adjourned the meeting at
approximately 10:25 a.m.
Note: If needed, the next TAG meeting is scheduled for January 14, 2016,
location TBD.
4
Page 29 of 55 total pages in packet
C. 12-16-15 TAG
meeting follow-up:
HIPAA standard
transactions formatting
of ACO member file
data elements (long
version)
Page 30 of 55 total pages in packet
Data Element Name
(names used at
12/16 TAG mtg)
Patient Name
Element
Order
1
2
3
Transaction
Patient ID
6
Field length
(min/max)
Required (R ) or
Situational (aka
Optional) (S)
Notes
Patient Last Name
AN
1/60
R
Individual last name
Patient Last Name
AN
1/60
R
Individual last name
835
Patient Last Name
AN
1/60
S
270-271
Patient Last Name
AN
1/60
S
Individual last name. Required for all
claims that are not retail pharmacy
claims
Individual last name
834
Patient First Name
AN
1/35
S
Individual first name
837P
Patient First Name
AN
1/35
S
Individual first name
835
Patient First Name
AN
1/35
S
Individual first name
270-271
Patient First Name
AN
1/35
S
Individual first name
AN
1/25
S
Individual middle name or initial
AN
1/25
S
Individual middle name or initial
AN
1/25
S
Individual middle name or initial
AN
1/25
S
Individual middle name or initial
834
Patient Middle Name or
Initial
Patient Middle Name or
Initial
Patient Middle Name or
Initial
Patient Middle Name or
Initial
Patient Name Suffix
AN
1/10
S
Suffix to individual name
837P
Patient Name Suffix
AN
1/10
S
Suffix to individual name
834
270-271
5
Usage
834
835
Patient Date of
Birth
Format
837P
837P
4
Data "sub-element"
if applicable
835
Patient Name Suffix
AN
1/10
S
Suffix to individual name
270-271
Patient Name Suffix
AN
1/10
S
Suffix to individual name
834
Patient Date of Birth
CCYYMMDD
AN
1/35
R
Patient's date of birth
837P
Patient Date of Birth
CCYYMMDD
AN
1/35
R
Patient's date of birth
835
Patient Date of Birth
N/A
N/A
N/A
N/A
Patient's date of birth
270-271
Patient Date of Birth
CCYYMMDD
AN
1/35
S
Patient's date of birth
Code identifying a party
834
Patient ID
AN
2/80
S
837P
Patient ID
AN
2/80
S
835
Patient ID
AN
2/80
S
Page 31 of 55 total pages in packet
Data Element Name
(names used at
12/16 TAG mtg)
Element
Order
Transaction
270-271
Patient Gender
Patient Address
7
8
9
10
Data "sub-element"
if applicable
Format
Patient ID
Usage
Field length
(min/max)
Required (R ) or
Situational (aka
Optional) (S)
AN
2/80
S
Notes
This is the unique number that the
payer uses to identify the insured. The
information desired from the payer is
for the patient.
F = Female
M = Male
U = Unknown Unknown is to be used
only when the gender is
unknown or when it can not be sent
due to reporting
restrictions.
834
Patient Gender
F, M, or U
ID
1/1
R
837P
Patient Gender
F, M, or U
ID
1/1
R
835
Patient Gender
N/A
N/A
N/A
N/A
270-271
Patient Gender
F or M
ID
1-Jan
S
Code indicating the sex of the patient
F = Female
M = Male
U = Unknown Unknown is to be used
only when the gender is
unknown or when it can not be sent
due to reporting
restrictions.
834
Patient Street Address 1
AN
1/55
R
Address information
837P
Patient Street Address 1
AN
1/55
R
Address information
835
Patient Street Address 1
N/A
N/A
N/A
270-271
Patient Street Address 1
AN
1/55
S
First line of address information
834
Patient Street Address 2
AN
1/55
S
Address information
837P
Patient Street Address 2
Address information
835
Patient Street Address 2
270-271
Patient Street Address 2
834
Patient City Name
837P
Patient City Name
835
Patient City Name
N/A
N/A
Free form
text
Free form
text
N/A
AN
1/55
S
N/A
N/A
N/A
AN
1/55
S
Second line of address information
AN
2/30
R
Free form text for city name
AN
2/30
R
Free form text for city name
N/A
N/A
N/A
Page 32 of 55 total pages in packet
Data Element Name
(names used at
12/16 TAG mtg)
Element
Order
Transaction
270-271
11
12
Data "sub-element"
if applicable
Patient City Name
Format
Free form
text
Use source
code 22:
States and
Provinces
(from US
Post Office)
Use source
code 22:
States and
Provinces
(from US
Post Office)
N/A
Usage
Field length
(min/max)
Required (R ) or
Situational (aka
Optional) (S)
AN
2/30
S
Free form text for city name
ID
2/2
S
Required when address is in US or
Canada.
ID
2/2
S
Required when address is in US or
Canada.
N/A
N/A
N/A
Notes
834
Patient State
837P
Patient State
835
Patient State
270-271
Patient State
Use source
code 22:
States and
Provinces
(from US
Post Office)
ID
2/2
S
Required when address is in US or
Canada.
834
Patient Postal Code
Exclude
punctuation
and blanks.
Use source
code 51
ID
3/15
S
Code defining international postal zone
code excluding punctuation and blanks
(zip code for United States)
837P
Patient Postal Code
Exclude
punctuation
and blanks.
Use source
code 51
ID
3/15
S
Code defining international postal zone
code excluding punctuation and blanks
(zip code for United States)
835
Patient Postal Code
N/A
N/A
N/A
N/A
Page 33 of 55 total pages in packet
Data Element Name
(names used at
12/16 TAG mtg)
[Attributed]
Provider Name
Element
Order
13
14
15
Transaction
Field length
(min/max)
Required (R ) or
Situational (aka
Optional) (S)
ID
3/15
S
Code defining international postal zone
code excluding punctuation and blanks
(zip code for United States)
Notes
834
Provider Last Name
AN
1/60
S
837P
Provider Last Name
AN
1/60
R
835
Provider Last Name
AN
1/60
R
Individual last name or organization
name
Individual last name or organization
name
Free form text for complete name
270-271
Provider Last Name
AN
1/60
R
Individual last name
AN
1/35
S
Individual first name
AN
1/35
S
Individual first name
N/A
N/A
N/A
See note
834
Provider First Name
837P
Provider First Name
835
Provider First Name
270-271
Provider First Name
AN
1/35
S
Individual first name
AN
1/25
S
Individual middle name or initial
AN
1/25
S
Individual middle name or initial
N/A
AN
N/A
1/25
N/A
S
N/A
Individual middle name or initial
AN
1/10
S
Suffix to individual name
AN
1/10
S
Suffix to individual name
N/A
AN
N/A
1/10
N/A
S
N/A
Suffix to individual name
AN
10
S
Code identifying a party. Use NPI
AN
10
S
Code identifying a party. Use NPI
AN
10
R
Code identifying a party. Use NPI
834
834
Provider Middle Name or
initial
Provider Middle Name or
initial
Provider Middle Name or
initial
Provider Middle Name or
initial
Provider name Suffix
837P
Patient Name Suffix
835
Patient Name Suffix
270-271
Patient Name Suffix
270-271
17
Exclude
punctuation
and blanks.
Use source
code 51
Usage
Patient Postal Code
835
[Attributed]
Provider ID
Format
270-271
837P
16
Data "sub-element"
if applicable
834
837P
835
National Provider
Identifier (NPI)
National Provider
Identifier (NPI)
National Provider
Identifier (NPI)
N/A
N/A
N/A
Page 34 of 55 total pages in packet
N/A
Data Element Name
(names used at
12/16 TAG mtg)
Element
Order
Transaction
270-271
[Attributed]
Provider Clinic
Information
18
834
837P
835
270-271
Data "sub-element"
if applicable
National Provider
Identifier (NPI)
National Provider
Identifier (NPI)
National Provider
Identifier (NPI)
National Provider
Identifier (NPI)
National Provider
Identifier (NPI)
Format
Usage
Field length
(min/max)
Required (R ) or
Situational (aka
Optional) (S)
AN
10
S
AN
10
S
Reference information as defined in
particular transaction set. Use NPI
Code identifying a party. Use NPI
AN
10
S
Code identifying a party. Use NPI
AN
10
R
Code identifying a party. Use NPI
AN
10
S
Reference information as defined in
particular transaction set
Page 35 of 55 total pages in packet
Notes
D. 12-16-15 TAG
meeting follow-up:
HIPAA standard
transactions formatting
of ACO member file
data elements
(short version)
Page 36 of 55 total pages in packet
Working Draft 12-18-15
Not yet approved by TAG or AUC
ACO Data Analytics TAG -- Recommended formats for data elements discussed at 12/16 meeting
Provide the data elements in the order listed below. Provider data is for the attributed provider. Send situational elements that are available.
Data Element
Name
Element
(names used at Order
12/16 TAG mtg)
Usage
Field length
(min/max)
Required (R ) or
Situational (aka
Optional) (S)
Patient Last Name
Patient First Name
Patient Middle Name
or Initial
Patient Name Suffix
Patient Date of Birth CCYYMM
DD
AN
AN
AN
1/60
1/35
1/25
R
S
S
Individual last name
Individual first name
Individual middle name or initial
AN
AN
1/10
1/35
S
R
Suffix to individual name
Patient's date of birth
6
Patient ID
AN
2/80
S
Patient Gender
7
Patient Gender
ID
1/1
R
Patient Address
8
Patient Street
Address 1
Patient Street
Address 2
Patient City Name
AN
1/55
R
This is the unique number that the payer
uses to identify the insured. The
information desired from the payer is for
the patient.
F = Female
M = Male
U = Unknown Unknown is to be used
only when the gender is
unknown or when it can not be sent due
to reporting
restrictions.
Address information
AN
1/55
S
Address information
AN
2/30
R
Free form text for city name
Patient Name
Patient Date of
Birth
Patient ID
1
2
3
4
5
9
10
Data "subelement"
if applicable
Format
F, M, or U
Free form
text
Page 37 of 55 total pages in packet
Notes
Working Draft 12-18-15
Not yet approved by TAG or AUC
ACO Data Analytics TAG -- Recommended formats for data elements discussed at 12/16 meeting
Provide the data elements in the order listed below. Provider data is for the attributed provider. Send situational elements that are available.
Data Element
Name
Element
(names used at Order
12/16 TAG mtg)
[Attributed]
Provider Name
Data "subelement"
if applicable
Required (R ) or
Situational (aka
Optional) (S)
Format
Usage
Field length
(min/max)
Use
source
code 22:
States
and
Provinces
(from US
Post
Office)
Exclude
punctuati
on and
blanks.
Use
source
code 51
ID
2/2
S
Required when address is in US or
Canada.
ID
3/15
S
Code defining international postal zone
code excluding punctuation and blanks
(zip code for United States)
Notes
11
Patient State
12
Patient Postal Code
13
Provider Last Name
AN
1/60
S
14
15
Provider First Name
Provider Middle
Name or initial
Provider name Suffix
AN
AN
1/35
1/25
S
S
Individual last name or organization
name
Individual first name
Individual middle name or initial
AN
1/10
S
Suffix to individual name
16
Page 38 of 55 total pages in packet
Working Draft 12-18-15
Not yet approved by TAG or AUC
ACO Data Analytics TAG -- Recommended formats for data elements discussed at 12/16 meeting
Provide the data elements in the order listed below. Provider data is for the attributed provider. Send situational elements that are available.
Data Element
Name
Element
(names used at Order
12/16 TAG mtg)
[Attributed]
Provider ID
[Attributed]
Provider Clinic
Information
Data "subelement"
if applicable
Format
Usage
Field length
(min/max)
Required (R ) or
Situational (aka
Optional) (S)
Notes
17
National Provider
Identifier (NPI)
AN
10
S
Code identifying a party. Use NPI
18
National Provider
Identifier (NPI)
AN
10
S
Code identifying a party. Use NPI
Supplemental (optional) data elements also discussed at the 12/16/15 meeting (also send if available)
Patient county
of residence*
Clinic name**
Free form
text
19
AN
1/17
Optional
20
AN
1/60
Optional
*We found no particular HIP!! county codes or formatting for “county” and are suggesting “free form text” of up to 17 characters (the longest ounty name, Lake
of the Woods, is 17 characters).
**The closest HIP!! analog for clinic name seemed to be “illing provider name” or Service facility location name,” which were data type !N, field length 1/60.
Page 39 of 55 total pages in packet
E. Meeting summary
and follow-up to ACO Data Analytics TAG
12-16-15 meeting
Page 40 of 55 total pages in packet
ACO Data Analytic TAG
12/16/15 brief meeting summary and follow-up
Page 41 of 55 total pages in packet
1
12/16/15 Meeting summary
• The TAG reviewed responses to a previous request for example data
dictionaries and record layouts
• Outcomes (TAG Consensus)
• 8 data of 9 data elements reviewed were considered in scope.
• The appropriate HIPAA standards should be recommended as the basis for single,
uniform formatting of the data elements being reviewed.
• A “least common denominator” file format should be recommended, and the file
format should be a delimited text file, using the “pipe” symbol as the delimiter.
• Any supplementary or additional data elements that might be included in a data file
would be exchanged according to a single, uniform format, and that these data
elements would follow after (so as not to interfere with, or be mistaken for) the data
elements discussed at the meeting.
Page 42 of 55 total pages in packet
2
Meeting summary
• MDH is to provide the TAG with additional information and examples
of the HIPAA transaction record layouts as applied to the data
elements discussed at the meeting.
• Following dissemination of the HIPAA transaction information, MDH
will send an email voting form to TAG members to vote on two
recommendations:
• That HIPAA standards be used as the single, uniform basis for formatting the
data elements discussed at the meeting;
• That data files containing the data elements discussed at the meeting be
exchanged as text delimited files, using the pipe symbol as the delimiter.
Page 43 of 55 total pages in packet
3
Follow-up from 12/16/15 meeting:
In scope data elements
The following data elements were determined to be in-scope for the TAG at
this time:
Priority data elements to identify patients/members
•
•
•
•
•
Patient name
Patient date of birth
Patient ID
Patient gender
Patient address
Priority data elements to identify providers
• Provider name
• Provider ID
• Provider clinic information
Page 44 of 55 total pages in packet
4
Follow-up from 12/15/16 meeting:
Delimited text file (conceptually)
• The record for each individual will be one continuous line of text, with each data
element separated from the next by the delimiter.
• Remember – the illustration below is conceptual (e.g., “Patient name” will
actually be further divided with delimiters to “last name”, “first name”, “middle
name/initial”, etc.)
Patient
name
Patient
date of
birth
Patient
ID
Patient
gender
Provider
Patient Provider Provider clinic
address name
ID
informat
ion
“Pipe” delimiters
Page 45 of 55 total pages in packet
5
Follow-up from 12/15/16 meeting:
Review of HIPPA transactions
• MDH staff reviewed four widely used HIPAA transactions across the
revenue cycle for their applicability to the data elements of interest
• Reviewed: Enrollment (834); eligibility inquiries and responses (270-271);
claims (837P); and remittance advices (835)
• Formats for the data elements were compared across the four
transactions
• Data elements of interest at the 12/16 meeting were further clarified with
descriptions of component “sub-elements”
• e.g., “Patient address” is comprised of Street name 1, Street name 2, City name, etc.
• Found very high levels of consistency and uniformity across the 4 transactions
Page 46 of 55 total pages in packet
6
Follow-up from 12/16/15 meeting:
Data elements of interest expanded per HIPAA transactions
Data Elements found to be in-scope at 12/16 meeting
Priority data elements to identify patients/members
Patient name
Patient date of birth
Patient ID
Patient gender
Patient address
Priority data elements to identify providers
Provider name
Provider ID
Provider clinic information
Data Elements expanded
Priority data elements to identify patients/members
Patient name
•
Last name
•
First name
•
Middle name/initial
•
Name suffix
Patient date of birth
Patient ID
Patient gender
Patient address
•
Street 1
•
Street 2
•
City
•
State
•
Zipcode
Priority data elements to identify providers
Provider name
• As above for name (last, first, etc.)
Provider ID
Provider clinic information
Page 47 of 55 total pages in packet
7
Follow-up from 12/16/15 meeting:
Data elements of interest expanded per HIPAA transactions (cont.)
• The following tables display 18 priority expanded data elements.
Whenever these data exist, they should be transmitted in the HIPAA
formats shown in the tables.
• Two additional data elements (“county”, “clinic name”) were identified as also
of interest and were described as “supplemental.” If these data are available,
they should also be sent.
• We found no particular HIPAA county codes or formatting for “county” and are suggesting
“free form text” of up to 17 characters (the longest County name, Lake of the Woods, is
17 characters).
• The closest HIPAA analog for clinic name seemed to be “Billing provider name” or Service
facility location name,” which were data type AN, field length 1/60.
Page 48 of 55 total pages in packet
8
Follow-up from 12/16/15 meeting:
A word about HIPAA formats that follow
• The tables below show key attributes of HIPAA formatted data elements
• “Format” includes occasional formatting notes (e.g., use “free form text”)
• “Data type”: type of data (AN = string) (ID = identifier)
• “Field length”: minimum and maximum number of characters allowed in a field
• “Required” or “situational”: this is a specialized term may be a little confusing.
Some HIPAA data elements are required “no matter what,” others are required only
if some situations are met. For the TAG’s purposes, if data is available for the
elements in the following tables, the data should be sent in the HIPAA format shown.
Page 49 of 55 total pages in packet
9
Follow-up from 12/16/16 meeting:
Data elements and HIPAA standard transaction formats
• Data should be provided in the following formats, based on HIPAA standard transactions, in the
order shown in the following tables
• Send situational (optional) data when available
Data Element
Name
Required (R ) or
Element Data "sub-element"
(names used
Format Data Type Field length (min/max) Situational (aka
Notes
Order
if applicable
Optional) (S)
at 12/16 TAG
mtg)
Patient Name
1
Patient Last Name
AN
1/60
R
Individual last name
2
Patient First Name
AN
1/35
S
Individual first name
3
Patient Middle Name
AN
1/25
S
Individual middle name or initial
or Initial
4
Patient Name Suffix
AN
1/10
S
Suffix to individual name
Patient Date
5
Patient Date of Birth CCYYM
AN
1/35
R
Patient's date of birth
of Birth
MDD
Patient ID
AN
2/80
S
This is the unique number to identify the
Patient ID
6
patient. It is a single field (if there is a
separate number denoting the patient as a
“dependent”, that number is included in this
Page 50 of 55 total pages in packet
10
single field with no spaces).
Follow-up from 12/16/15 meeting:
Data elements and HIPAA standard transaction formats
Data Element
Name
Element
(names used at Order
12/16 TAG mtg)
Data "sub-element"
if applicable
Patient Gender
7
Patient Gender
Patient Address
8
Required (R ) or
Data Field length
Situational (aka
Format
Type (min/max)
Optional) (S)
F, M, or
U
Notes
ID
1/1
R
F = Female
M = Male
U = Unknown Unknown is to be used only when the gender is
unknown or when it can not be sent due to reporting
restrictions.
Patient Street Address 1
AN
1/55
R
Address information
9
Patient Street Address 2
AN
1/55
S
Address information
10
Patient City Name
AN
2/30
R
Free form text for city name
11
Patient State
ID
2/2
S
Required when address is in US or Canada. Use source code
22: States and Provinces (from US Post Office)
12
Patient Postal Code
ID
3/15
S
Code defining international postal zone code excluding
punctuation and blanks (zip code for United States). Use
source code 51
Free
form
text
Page 51 of 55 total pages in packet
11
Follow-up from 12/16/15 meeting:
Data elements and HIPAA standard transaction formats
Data Element
Name
Element
(names used at Order
12/16 TAG mtg)
Provider Name
Data "subelement"
if applicable
Field length
Format Data Type
(min/max)
Required (R ) or
Situational (aka
Optional) (S)
Notes
13
Provider Last Name
AN
1/60
S
Individual last name or organization
name
14
15
Provider First Name
Provider Middle
Name or initial
AN
AN
1/35
1/25
S
S
Individual first name
Individual middle name or initial
16
Provider name
Suffix
AN
1/10
S
Suffix to individual name
Provider ID
17
National Provider
Identifier (NPI)
AN
10
S
Code identifying a party. Use NPI
Provider Clinic
Information
18
National Provider
Identifier (NPI)
AN
10
S
Code identifying a party. Use NPI
Page 52 of 55 total pages in packet
12
Follow-up from 12/16/15 meeting:
Supplemental (optional) data elements
Data Element
Name
(names used at
12/16 TAG mtg)
Data "subElement element"
Order
if
applicable
Format
Data
Type
Field length
(min/max)
Required (R )
or Situational
(aka Optional)
(S)
County
19
Free form text AN
1/17
Optional
Clinic name
20
AN
1/60
Optional
Notes
Page 53 of 55 total pages in packet
13
Follow-up from 12/16/15 meeting:
Putting it all together in a scenario
• John Jacob Schmidt was born December 17, 1982.
• His patient ID is 2345678 and he is male.
• He lives at 222 22nd Avenue W., Apr. 318, Wonderfulville, MN 559089876.
• His primary care clinic is the Pretty Good Clinic, NPI 1000000001,
where his primary care physician is Jane Amazing, NPI.
Page 54 of 55 total pages in packet
14
Follow-up from 12/16/15 meeting:
Putting it all together in a scenario
Schmidt│John│Jacob││19821217│2345678│M│222 22 Avenue West│Apartment 318│Wonderfulville│MN│559089876│Amazing│Jane│││1111111111│1000000001│││
Note: Provider data is for attributed provider per payer algorithm.
Page 55 of 55 total pages in packet
15