esMD PPA Use Case 2  WG Meeting

Wednesday, April 18th, 2012

2

Meeting Etiquette

• Remember: If you are not speaking keep your phone on mute

• Do not put your phone on hold – if you need to take a call, hang up and dial in again when finished with your other call – Hold = Elevator Music = very frustrated speakers and

participants• This meeting, like all of our meetings, is being recorded

– Another reason to keep your phone on mute when not speaking!

• Feel free to use the “Chat” or “Q&A” feature for questions or comments

NOTE: This meeting is being recorded and will be posted on the esMD Wiki page after the

meeting

From S&I Framework to Participants:Hi everyone: remember to keep your phone on mute

Agenda

Item Presenter Time frame

Overview of Face-to-Face discussions Sweta 1:30 – 1:40

Beginnings of Author of Record brainstorming and Pre-Discovery work

Sweta/Presha / Bob

1:40 – 1:45

Review of Parking lot and follow up items from the Face to Face

Presha / Bob 1:45– 2:15

Review of Changes made to Use Case 2 sections and Structured Content

Presha / Bob 2:15 – 3:00

3

Recap of Last Week (S&I F2F)

• THANK YOU to all who attended the S&I F2F!• Reviewed and completed development of the

remaining Use Case 2 (eMDR and Structured Content) sections– Risks, Issues, Obstacles– Communities of Interest– Glossary of terms– Use Case Diagram– User Stories - Commercial and CMS specific

S&I Face-to-Face Meeting

• Meeting Agenda, Minutes, Relevant Presentation materials posted– http://wiki.siframework.org/S%26I+2012+Face+to+Face+%28F2

F%29+Meeting+-+esMD+Meetings

5

Author of RecordInitial Discussions at the F2F

• AoR is the 3rd and last work stream within the S&I esMD Initiative• During F2F meeting Dr. Doug Fridsma charged the esMD group to

work with the other S&I Initiatives on Author of Record and Digital Signature needs

• F2F agenda was modified on 4/12 from 4-6pm for this initial brainstorming discussion which was led by Bob Dieterle. – Reed Gelzer also presented real world examples for Authorship

and EMR documentation issues.• Presentation materials from this brainstorming session can be found

on the esMD F2F page (previous slide). • Pre-discovery will start next week, consisting of an environmental

scan of the current state of digital signatures (next couple weeks). – Use Case 3 development for this workgroup will commence after

the pre-discovery phase. This will give us time to work with other S&I Initiatives and identify their needs as well.

6

esMD Follow Up Items from April 2012 Face to Face

7

S&I Framework F2F: esMD Parking Lot and Action Items

Action Item / Parking Lot Support Team Comments Status Due Date, if needed

Fee/Cost Risks in S&I Use Cases - Determine if including cost-based risks is acceptable within S&I Use Cases.

LRI UC has included cost related risksFees charged by Agents or HIHs may increase costs for adopters of esMD and therefore hinder adoption.

Closed

“eMDR Consumer” is the terminology we used within the UC for the Provider/Provider Organization that receives eMDR and incorporates /consumes this into their system

Are there any concerns with leaving “eMDR Consumer “ as an actor and the “eMDR Consuming System” as the System ?

Open

Determine what terminology to be used for the basis of the information requested – claim, encounter, episode?

We will ensure that theMDR Covers Claim level requests for documentation for fee for service. We do not have a need in this UC to define “episode” or “encounter”

Open

Distinction between a Generic Gateway and an esMD Gateway

Definitions are appropriately reflected in both user stories and diagramsLink - http://wiki.siframework.org/PPA+UC+2+-+Context+Diagrams

NA

Distinction between Claim Date and Dates of Service. Claim Date vs. Date of Service was discussed; the Date of Service has many policy impacts (esp. in relation to insurance policy coverage/activation).

Claim Date is the Date of SubmissionDates of services is when the services were performed

Both data elements will be kept on the eMDR for now.

Open

8

S&I Framework F2F: esMD Parking Lot and Action Items (Cont.)

Action Item / Parking Lot Support Team Comments Status Due Date, if needed

Added a category for “Processor Information” within the eMDR. Data element is Claim Processor Identifier. Further describe the intent & role of the Claim Processor Identifier and capture within the Data Element Description.

Draft definition – “The entity that processes the claim submission”

Open

External & Internal Unique Case Reference Identifiers. See suggested comments

Within the Audit Specific Information Section within eMDR1. “Unique Claim Reference Identifier” - This serves

as only an internal identifier that ties to a claim. 2. “Unique Case Reference Identifier” - This links to

one or more claims for the same beneficiary. Serve as a unique external ID.

Open

Linkage between multiple transactions within Cover Letter. Is there a link (and should there be a link) between multiple related transactions if a provider wants to aggregate claims?

The Unique Case Reference Identifier (see above) addresses this issue

NA

Determine which line-item information on an eMDR is necessary to clarify the referenced line and necessary supporting information.

It is the intent to include all line item information but consider optionality as part of harmonization

NA

9

S&I Framework F2F: esMD Parking Lot and Action Items (Cont.)

Action Item / Parking Lot Support Team Comments Status Due Date, if needed

Referencing the “patient” for which a claim was submitted.

For purposes of requesting information on a claim, the subscriber, member, and beneficiary and are the same. It is the individual on which the service was performed. The difference is who holds the policy.

Suggested word to reference the patient is – “Beneficiary”

Open

For eMDR of Structured Content – Broke data elements into various sections – Line level data, Claim level data, Beneficiary Information, Documentation Requested,

Mark Pilley and Dan Kalwa following up on items within these sections

Open

Audit Specific Information on the eMDR (Scope or Type of Audit) – What is this information used for?

Added the following in the Additional Notes column - It is a codified field that determines the type of request including Pre certification, Claim Payment Documentation, Audit, Payment Recovery etc.

Closed

Terms identified to add to Glossary in Use Case Define: Query, Account #, Medical Record #, Provider Directory, Dates of Service, Bill Type, Claim Date, Address ID (if we decide to keep Address ID as a data element)

Open

10

Agenda Today

• Share updates to sections reviewed for UC 2– Definitions of eMDR Consumer and eMDR Consuming Information System within

Glossary– Review Use Case Diagram– Information Interchange Table– Issues, Risks, Obstacles– Generic User Story & CMS User Story– Introduction sections including Background, Scope, Value statement etc

(should be similar to UC 1)

• Review Changes at a high level to Structured Content of eMDR Data Elements– Just a quick review of the realignment of data element sections within the eMDR– We will go into more detail during Friday’s SC call, or later today if there is

additional time

–

11