******FYI, raw notes are located at the bottom of the spreadsheet.

Day

Date

Time
RoomEventHostjoiningChairScribeNotes

Saturday

May 4

AM

Q1


Not Meeting






Q2


Not Meeting







PM

Q3


Not Meeting






Q4


Not Meeting






Q5

Co-Chair Meeting

  • Confluence Updates needed:
    • FM main page not updated 
    • eVoting page, see Clinical SD for suggestions
  • Agenda
    • Goals for each quarter
    • documentation needed for each quarter




  • Confluence Updates needed:  Benoit will sit with Josh and do.
DayDateTime
RoomEventHostjoiningChairScribeNotes
SundayMay 5AMQ1
Not Meeting






Q2
Not Meeting






PMQ3
Not Meeting






Q4
Not Meeting






Q5
Not Meeting




DayDateTime
RoomEventHostjoiningChairScribeNotes
MondayMay 6AMQ1Salon A

Agenda/wk overview

Project detailing and alignment - Bob Dieterle  (What do we need to review in this WGM for the DV Project- MK/Paul)

C-CDA Payer Section, Linda M. Need to add to one of the joint session.  See:  Payer Section C-CDA - Wednesday Q1

FM has CRD ballot items that need final resolution, need to add to FM Agenda


GOAL: Finalize Agenda items and required participants for all quarters

Attachments


Linda; 30-45 minutes on FM’s agenda during WGM to continue the discussion on CCDA Payer section.  I am not available

Monday Q1, Q2 or Q4.

I will be there through Q1 Thursday.


Approve 1489, 2 additional FHIR IGs - Drug formulary and Payer Network. 

Bob Dieterle - motion, Laurie Burkhardt 2nd. 23-0-1

Q2 Salon Musset

FM Administration


 Kathleen

 Need to remove ARV segments in body of Chapt 6 .  Reference to Chapt 2 use of ARV manifest needs to be added to both Chapt 6 & 16.  We voted to do this during Jan 2019 ballot reconciliation.  See

Paul:  Motion, add discovered item to the 2.9 to fulfill the disposition item from the January Ballot item.  (technical correction to an item not previously addressed). The CTO will need to approve. 

Beat second.

7-0-1 

 

Bennoit volunteered to be the FM EST Liaison

Andrew Statler 4/26

Hello fellow Co-Chairs.

         I am reaching out to you again to ask that you please identify a Liaison for your Group as a contact point with the Electronic Services and Tools Workgroup. At present, we have Liaisons for the following Workgroups:

  • Structured Documents/CDAMG (Andrew Statler)
  • Imaging Integration (Luiza Kowalczyk)
  • Clinical Information Modeling Initiative (Richard R. Esmond)

The expectations for the liaison are minimal. We are mainly looking for a point of contact to push communications & updates about changes to Tooling and digital Service offerings that groups should be aware of. Not all groups use all tooling, but all groups do tend to leverage a few common tools like HL7.org. In the future, all groups may use JIRA as it may be the tool through which all help desk tickets are routed, so it may be necessary that every group be aware of the tool and how to use it.

There are a variety of tools out there and not every group uses every tool. We would like to establish a list of tools used by each group and so we would like a contact point that can help us discern what each group uses currently. This would help us target communications, help us provide better support for the tools we offer, deprecate tools that are no longer in use and repurpose those dollars to new or better tooling.

You can help in this effort by giving us a primary contact for this effort. It can be changed later, but we really need to make sure we have someone that we can work with at any given time. If they are unable to, they can go back to the group and ask the group to choose a new representative.

Most of the involvement will be push communications from EST to the liaison. From time-to-time we may send short surveys to the liaisons to update our information about your group. We also have a liaison session on Thursday during the WGM.

If you could take a moment to go to our Confluence Liaison Page link below and add a name for your working group, you can help us move tooling forward at HL7.

https://confluence.hl7.org/display/EST/EST+Liaisons

Updated the Mission & Charter. Approve updates made. Motion by:  MaryKay McDaniel, Second Laurie Burckhardt. 6-0-0.

Updated SWOT. Motion to approve updates made:  MaryKay McDaniel, Second Laurie Burckhardt. 7-0-0

PMQ3Salon Musset

FM Working: Dynamic Vocabulary and correct licensed vocab in FHIR

Examples include:

  • Identifiers ("code system". A=NPI, B=Inhouse, etc.)
  • NUBC - TOB, Revenue Codes, Condition Codes; NCPDP - DAW

GOAL: Plan/next steps for how to add the vocabulary to the base resource and/or the US profiles and/or make corrections in V2



MaryKay

***Prior to meeting, MK see HTA

1) V2 walk through the code sets to identify the infringement

2) how to specify vocabulary


**reviewed vocabulary needs for the US Realm work. Need to work with the Da Vinci developers to ask how they are going to be doing the mapping.


Q4Salon A

US Market Needs / Business Level Processing

Eligibility (Coverage Validation, Coverage Discovery, Benefits Determination), Prior Auth).  High level discussion, what are these things - what is the activity? Define the business intention/requirements.

GOAL:  Business level activity name definition and high level content for US provider/payer financial exchanges 

Attachments
MKPaul

Who talks to who, when and why - Not the WHEN, the what

Activity diagram (steps)

See spreadsheet listed in Tuesday Q3.

DayDateTime
RoomEventHostjoiningChairScribeNotes
TuesdayMay 7AMQ1
Not Meeting




Q2
Not Meeting




PMQ3
FHIR - Overview / Financial ResourcesAttachments


Request to FM WG:  ClaimResponse suggested-alternative Extension. Requestors will attend a Pharmacy WG session the WGM to discuss. Coordination may be needed with NCPDP. After meeting with PMG, will check back in with the FMWG.

Using notes from MQ4 (spreadsheet on Documentation page:  Financial Domain Activities 20190507.xlsx)

Paul gave an overview of how to read and understand the FHIR standard, then a walk through of the FM resources. 

Q4

Financial Resources

To address the Eligibility, Coverage Validation, Prior Auth

GOAL: from each US based activity, named and documented FHIR pattern

Attachments


Continuation of Q3. Overview of the business activity and request/response resources.

There is no document that was completed. Attachment WG will complete tomorrow Q1/Q2.


DayDateTime
RoomEventHostjoiningChairScribeNotes
WednesdayMay 8AMQ1

Rm 728

C-CDA Payer Section, Linda M. Need to add to one of the joint session.  See:  Payer Section C-CDA

FM FHIR

***V2 Publishing FM must attend - MK will attend



PaulBenoit

FM Wednesday May 8th, Q1.

Linda presenting.
Lisa presented a PSS to review the Collaborative CDA Template. Linda is presenting this work.
FHIR coverage is where the work is going to start, most of the resources are still at a low maturity level. For FM, even if the level of maturity is high, the level is 2 since the mapping to the RIM hasn't been done. Once done, it will be raised to FMM 3.
In the beginning, FM put the resources in the RIM, from where they got pulled for CCDA. Most of the resources are attached to the payer, which is OK.
-for coverage,
- there is a sequence number and an indication of priority. Coverage is pretty generic, so when localizing to US, not many fields are going to get dropped.
- what do we use for payer type? (usually used for quality => 4 payer types)
- the coverage type could be overridden for the US.
- the payers have been rolled up in a smaller list for reporting (eCQMs)
- the constraints if mapping to X12 may influence the list.
- 5 main elements:
- the payer <=> organization. Questions about the assignedEntity id. The displayed example looks incomplete. 2.16.840.1.113883.19 is specifically for example purpose. In FHIR, ids are identifying the instance, identifiers are identifying the content.
- the guarantor
- the member <=> beneficiary (!! the relationship goes differently in the 2 models: child<->parent, it describes the relationship from the beneficiary to the subscriber for FHIR/V3 might be reversed in CCDA)
- the subscriber (not present if member is the subscriber) is also the policy holder (but what if the subscriber is an employee and the policy holder is the employer?). In CCDA, it is OK not to have the DoB and address of the subscriber, not for the patient.
- entry relationship (if a prior authorization)
- for prior authorization:
- why is it attached here? There is a resource called Planned Coverage, containing AuthorParticipation and Act. the act is supposed to be the prior authorization. Paul suggests the resource to be renamed as it is more a planned treatment not a planned Coverage, the idea is not to change coverage but authorize a treatment.
- in FHIR, the claim resource is used for the pre determination, the pre authorization and the claim. the claim resource links to the coverage and the procedure. Inside the same facility, it could be done to link a pre authorization to a medical procedure in the implementation of the FHIR server.
The template are to be managed in structured definitions. There is a contract to Lisa Nelson to put the tooling in place for Halloween.

Next topic: DRG:
Question: are you aware of somebody sending a claim where some of the items to link to a DRG and some other to another DRG?
The DRG is not really used in the validation of the claim by the payer.
You expect all items in a claim to be associated to one consistent DRG. It could be, that a patient has a chronic and receives emergency treatment. It would be sent as one claim with a grouper. the primary diagnostic points to the DRG. So it needs to move the body of the claim (today it is in diagnostic as the packageCode, the system might be MSDRGs.). The consensus was DRG should be an extension for R4 and an element for R5.

Q2

Salon A


  • Lisa's spreadsheet - Timebox to 30 minutes. 

GOAL: Review the spreadsheet, prioritize and plan for finalization,




*** Were not discussed in Q2.

  • Tracker items and ballot reconciliation
  • Double check CRD outstanding ballot (already in tracker)

GOAL: Plan recon steps





Data Elements from Lisa Nelson's spreadsheet:

The combined workgroups started a review of the following list and made suggestions to where the elements should be mapped into the EOB. Suggested that the requestor gather better descriptions for those that were questioned during the call.
NPI Attending Provider ID
NPI Site Provider ID
NPI Rendering Provider ID
Rendering Provider
Contracting Status Indicator
Claim operating physician NPI
Claim operating physician network status
Claim service location NPI
NPI PCP Provider ID
Allowed Amount
Amount paid by patient
Patient Pay Amount (Pharmacy)
Payment Amount
Non-Covered Reason Code
Non-Covered Amount
Deductible
Coinsurance
Copay
Member Zip Code on Claim
Member's Current County
Member's Current Country
Group id
Group name
Patient account number
Patient.identifier
Medical record number
Patient.identifier
Claim adjusted from identifier
Claim adjusted to identifier
Claim attending physician network status
Claim referring provider NPI
Claim referring provider network status
Claim performing provider NPI
Claim performing provider network status
Claim other physician NPI
Claim other physician network status
Member reimbursement
Claim primary payer code
Claim primary payer paid amount
Claim secondary payer paid amount
Service to date (Line)

 
PMQ3Salon A

Determine time for 2nd FM call to discuss DV projects

Da Vinci Prior Auth Support

Attachments


"final content" FHIR IGs 6/4.

*** The following items were not discussed in Q2, moved to this quarter..

  • Tracker items and ballot reconciliation
  • Double check CRD outstanding ballot (already in tracker)
    • 4 outstanding CRD Tickets were resolved.

20516: Drop supply request from CRD

Motion to find not persuasive. Bob D., Andy S second.  (20, 0, 2  ) yes, no, abstain

20518: Need to address specifications for Hooks. 

Changes need to be reflected in applicable specs.

Motion to find persuasive,  Andy, Benoit second (22, 0, 0)

20519: Need to specify hook version as it could be different than standard version.

Motion to find persuasive,  Benoit, Bob D second Bob D (22, 0, 0)

20520: Style item. Menu only shows limited page should take advantage of  drop downs.

Motion to find persuasive, Bob D, Benoit second ( 22, 0, 0).  Non-substantive change.

  • PDex - NIB approval:

-PA Support

-PDex Directory

Motion to approve the submission of the NIBs for the 3 IGs FM/Attachments are sponsoring

Bob D second Christol (22, 0,0)

Bob Dieterle gave an overview of the Da Vinci Project. 



Q4Salon ADa Vinci PDexAttachments


****NOTE to Co-chairs:  We need to complete the early ballot NIBs

FM call: Tuesday 11-12ET, FM work only

Joint Wednesday: 12-1:30ET for the next 4 weeks.



7-9PM






DayDateTime
RoomEventHostjoiningChairScribeNotes
ThursdayMay 9AMQ1

****Mistakenly added to Agenda. No room for meeting.*****

How to capture the work of other projects.

FM next meeting planning





****NOTE to Co-chairs:  We need to complete the early ballot NIBs

****Note Agendas for after (5/21/2019) what can be deleted as it was completed during WGM? Need to remind folks about Anesthesia billing.*****

Need to set up the following calls: 

FM call: Tuesday 11-12ET, FM work only

Joint Wednesday: 12-1:30ET for the next 4 weeks.

...NEED TO CREATE VOCAB CANONICAL ITEMS....

KNOWN:

OID 2.16.840.1.113883.6.301.7

OID 2.16.840.1.113883.6.301.8

OID 2.16.840.1.113883.6.301.9

OID 2.16.840.1.113883.6.301.10

OID 2.16.840.1.113883.6.301.11

Q2Salon JarryJoint with PAPA



PMQ3

Da Vinci Chronic Illness Risk Assessment, Patient Transparency,

Alerts, Payer Coverage Decision Exchange (SEP 2019 ballot)

Attachments


SEP 2019:  DTR STU, Alerts/Notification STU, Payer Coverage Decision Exchange STU

JAN 2020: Gaps in Care & Information, Health Record Exchange: Patient Data Exchange, Patient Cost Transparency, Risk Based Contract Member ID, Chronic Illness Documentation for Risk Adjustment

Performing Lab reporting - not scheduled at this time

Health Record Exchange: Patient Data Exchange - a way for a patient to provide feedback (I received it, I'm using it, It is working)


Q4
Next meeting, work going forward.Attachments


****NOTE to Co-chairs:  We need to complete the early ballot NIBs

****Note Agendas for after (5/21/2019) what can be deleted as it was completed during WGM? Need to remind folks about Anesthesia billing.*****

FM call: Tuesday 11-12ET, FM work only

Joint Wednesday: 12-1:30ET for the next 4 weeks.

DayDateTime
RoomEventHostjoiningChairScribeNotes
FridayMay 10AMQ1
Not meeting




Q2
Not meeting




PMQ3






Q4








Raw notes:

Monday, May 06, 2019

Attachments/FM

Q1 Monday.

Agenda alignment:

· Finalized the agenda for the week.

· Eligibility discovery:

o Coverage = the insurance card

§ Plan – the financial details: deductibles, co-pays, (bronze, platinum, silver, diamond, etc.)

§ Product – Medical/dental/Benefits, benefit design, limits,

Vocabulary and Glossary are separate concepts within the FHIR Standard

Eligibility – definition from law

noun

the state of having the right to do or obtain something through satisfaction of the appropriate conditions.

Eligibility Date: The date on which a person becomes eligible for insurance benefits. ... A dependent (usually spouse or child) of an insured person who is eligible for insurance coverage. Eligible Employee: An employee who is eligible for insurance coverage based upon the stipulations of the group health insurance plan. Health Insurance Glossary - Health Insurance Definitions and Terms

https://www.ehealthinsurance.com/health-insurance-glossary/terms-e/


FM

Q2 Monday.

Rob McClure Vocabulary:

.name thing for FHIR needs to be a string, human readable. There is a set of requirements that that thing needs to be. The words should be short, typically understood. That becomes the Code system:

Terminology.hl7.org.codesystem/CodeSystem/NUBC_OccuranceCode

Terminology.hly.org.valueset/NUBC_OCCURANCCODE

Content logical definition: “all the codes in the code system”


Mission & Charter review:

Updated the information.


Codeable concept – the code, the system, and MULTIPLE cod sets. i.e, in SNOMED it is this, in HCPCS it is this.



Tuesday, May 07, 2019

Attachments/FM

Q1/Q2 Tuesday.

Mapping the intent and then data

“Exchange standard meets the RESTFUL architecture”

Provider Use cases:

· Initial PA Request

o Endpoint acknowledges (restful response (standard restful acknowledgement) includes a callback id that can be used to retrieve the ‘thing’ later)

o Use a task that

· PA Response – push from Insurer

o **

· Inquiry (is there already a PA? I sent one earlier and need the answer)

o Task was created when I sent the initial PA request

· What was the answer to ‘my’ PA request

o Task was created when I sent the initial PA request

· Update an existing request??

o Or cancel and new?

o “End”?

o

· Cancel (sent something and want to cancel it)


The Prior Authorization Operation endpoint (Insurer, Clearinghouse, UMO) will be managing the round trips

Must define the operations that the end points will use

Map FHIR to 278 and leave everything else as a 275 REST: Representational State Transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services.

FHIR is asynchronous. Request/response is an acknowledgement of receipt

What is asynchronous REST API?

Synchronous/asynchronous APIs are application programming interfaces that return data for requests either immediately or at a later time, respectively. Synchronous/asynchronous APIs provide a way to make immediate or scheduled requests for resources, data or services when available


Q3 Wednesday

RED “S” in FHIR Profile means you MUST send if you have it. And if you receive it you must be able to keep it.





Lisa Nelson – Data Elements that she needs help with.

Data Element concept NPI Attending Provider ID NPI Site Provider ID NPI Rendering Provider ID Rendering Provider Contracting Status Indicator Claim operating physician NPI Claim operating physician network status Claim service location NPI NPI PCP Provider ID Allowed Amount Amount paid by patient Patient Pay Amount (Pharmacy) Payment Amount Non-Covered Reason Code Non-Covered Amount Deductible Coinsurance Copay Member Zip Code on Claim Member's Current County Member's Current Country Group id Group name Patient account number Patient.identifier Medical record number Patient.identifier Claim adjusted from identifier Claim adjusted to identifier Claim attending physician network status Claim referring provider NPI Claim referring provider network status Claim performing provider NPI Claim performing provider network status Claim other physician NPI Claim other physician network status Member reimbursement Claim primary payer code Claim primary payer paid amount Claim secondary payer paid amount Service to date (Line)


FM as sponsor is ‘responsible for’ in an IG.

Resources are used as intended.

No duplication of extensions

Using elements according to definitions.

Styles how implementers want to do things is not in our scope.

FHIR enforces the guide.

Read through all the word material for ‘reasonableness’


Expectations:

Need PDex showing up weekly on one of our calls to review and answer questions.

Give FM WG assignment – read it prior to the joint call with Attachments.

CRD Ballot Reconciliation will be done via Tuesday FM calls.


Katie's NOTES:

Monday: May 6, 2019 WGM Financial Management (FM) Notes:

Q1: Joint meeting with Attachments

  • Reviewed week’s agendas: both FM and Attachments
    • Bob D. will be present for all joint sessions with exception of Q4 on Thursday.
    • Need to ensure content being exchanged is appropriately registered (e.g., ADA, AHA etc). @2 today.
  • Updates made to 1489 (2 additional IGs). 
    • Motion to approve updates
      • Motion by: Bob D.
      • Second by: Laurie B.
      • (Approve, Disapprove, Abstain) 23, 0, 1
  • Began discussions on Q4 topic: US Market Needs / Business Level Processing
    • Eligibility (Coverage Validation, Coverage Discovery, Benefits Determination), Prior Auth).  High level discussion, what are these things - what is the activity? Define the business intention/requirements.
      • Coverage: Paul sees this as the information that is exchanged [used to adjudicate/identify not necessarily the multi-page document detailing coverage (e.g., the drug formulary number, not the formulary itself)].  Plan defines financial responsibilities tied to the coverage. Product defines the benefits. MK points out difference between eligibility vs. enrollment.  Certain criteria must be met, but you must enroll prior to having benefits under a product or plan (e.g., you must be an employee to enroll into employer sponsored coverage, poverty level requirements for Medicaid, age or disability requirements for Medicare etc). Eligibility is contextual. 
        • Coverage is an instantiation of a product/plan.  In terms of benefit, you may have benefits, but there are also conditions that might be tied to that benefit.

Q2:

  • Vocabulary:
    • Rob McClure (sp?) came in and briefly shared some information surrounding expectations:
      • FHIR value code system. Name (human readable, machine processable string). Has specific expectations.  The words should be short and readily understood by those using the code source. 
    • Do you need a separate item for each value system/code system? On the FHIR side they refer to value sets given each field is functioning separate (if they were just getting started they might have considered NUBC as a codessystem).  Information for code system and value set will be similar
    • In cases where NUBC doesn’t host the items.  HL7 will host (not necessarily have the codes)
      • Content logical definition will say all the codes in the code system and , so go get all the codes (latest)


  • Kathleen verified that it was previously agreed to remove the ARV segment from chapter 6 (Jan 2019 ballot reconciliation).  Need to remove it from the body of the chapter 6.
    • There was no ballot comment, but can add as a discovered item, technical correction not previously addressed.  CTO will need to approve it (possibly go to a committee to agree to the change. 
      • Motion to add discovered item to 2.9 to fulfill the disposition of item from January ballot.
        • Motion by: Paul K.
        • Second by: Beat
        • (Approve, Disapprove, Abstain) 7, 0, 1
  • Updates were made to the SWOT
    • Motion to approve updates to SWOT
      • Motion by: MaryKay M.
      • Second by: Laurie B.
      • (Approve, Disapprove, Abstain) 7, 0, 0
  • Request for volunteer liaison from group to electronic services and tools group.  Limited time commitment. 
    • Benoit volunteered to be liaison
  • Mission and Charter revisions.
    • Updates were made to the work group’s Mission and Charter
    • Motion to approve mission and charter
      • Motion by: MaryKay M.
      • Second by: Laurie B.
      • (Approve, Disapprove, Abstain) 6, 0, 0

Q3:

V2.9 Ballot Reconciliation

  • Comment 156 discussed what rule was for removing item after it is deprecated
    • Motion:  To find comment 156 persuasive
      • Motion by: Paul K.
      • Second by: Andy S.
      • (Approve, Disapprove, Abstain) 6, 0, 0
  • Comments 150, 151, 152, 153, 154, 155, 196
    • Motion:  To find comments 150-155 and 196 as persuasive
      • Motion by: Paul K.
      • Second by: Andy S.
      • (Approve, Disapprove, Abstain) 6, 0, 0
  • A-T: Typo comments (misspelling of diagnosis etc.): 194, 191, 189, 271, 205, 270, 204, 203, 268, 267, 266 265, and 263.
    • Motion to let editor fix typos (comments: 194, 191, 189, 271, 205, 270, 204, 203, 268, 267, 266 265, and 263)
      • Motion by: Paul K.
      • Second by: Benoit S.
      • (Approve, Disapprove, Abstain) 7, 0, 0
  • A-C: Comment 269
    • Motion:  To find comment 269 persuasive
      • Motion by: Paul K.
      • Second by: Beat
      • (Approve, Disapprove, Abstain) 7, 0, 0
  • A-Q: Comment 264 - Group that only has a single element.  It is not clear of location/issue. 
    • ACTION: Beat to reach out to the requester for information.
  • Comment 193:
    • Motion:  To identify comment 193 as persuasive with mod
      • Motion by: Paul K.
      • Second by: Benoit S.
      • (Approve, Disapprove, Abstain) 7, 0, 0
  • Comments 190, 192, and 195
    • Motion:  To find comments as persuasive (comments 190, 192, and 195)
      • Motion by: Beat
      • Second by: Benoit S.
      • (Approve, Disapprove, Abstain) 7, 0, 0

Other topics

  • FM Confluence home page was updated, (thank you Benoit).
  • Vocabulary:
    • Next steps and how we move forward, canonical for v2 and v3 plus new stuff for the 278. 
  • MK began identifying where there might be a need for a code set.
    • In an effort to be ahead of their mapping. 
    • Such as transaction request purpose code
      • (X12 has both internal and external codes sets)
    • Don’t want to just recreate the codes
      • at least have a corollary code (guidance) in terms of mapping. 
      • Do we not worry about mapping the header information?  Need to provide guidance on intent where appropriate.
    • Discussed the 278 support of batch (multiple auths in a batch different than how FHIR happens.  This would translate into a bundle in FHIR.
    • FHIR doesn’t have to be real time, but it supports it.
    • FHIR is specifically created as doing it as an instance.
    • As long as in FHIR there is something to indicate what it is…
      • Might add a code for authority to deduct.


  • There was a discussion regarding mapping from the 278 to FHIR.  The BHT is identified and all items are the same in the batch.
    • If might split apart to single FHIR, but this isn’t necessarily true it might be a bundle.
      • Requests will become claims, cancels become a bundle of tasks.
        • High level: need to correlate the concept
        • Guidance of how to correlate a 278 to FHIR (batch to bundle).  Where does this guidance reside? Who develops?
      • Not a mapping, but correlation.  FAQ 1: 
        • Because FHIR is composed of pieces and can stand alone or be bundled together.
        • Authority to deduct:  becomes a claim with funds reserved flag of yes.
        • An order to release unused services.  X12 would get a cancel, but don’t necessarily want to cancel due to partial used
      • Implementation guide version, name drives vocabulary:  There is a version number of FHIR but is specific to FHIR. Wouldn’t you need to store X12 version info and pass it along in FHIR? When converting to the FHIR, there won’t be a way to report in FHIR which is needed for terminology.

Q4: Joint meeting with Attachments

  • Continued discussion surrounding definitions/terminology from Q1 (See table from Paul).
  • Individual professional charges will be on the professional claim and facility charges will be on the institutional.
  • Prior Auth request.
    • Noting something is “limited promise of payment” is misleading.  Payment can be zero.
  • Predetermination provides a reasonable expectation of what will be paid if it was done today all things being equal.
  • Prior Authorization typically goes beyond making assumptions that certain criteria has been met…other items must still be met when submitted as a claim.  
  • Without funds reserved they are still different.
  • What is difference, one is asking permission to perform a service (not actually perform but to have service be reimbursed through the coverage). Predetermination isn’t asking permission
    • In France, there is no predetermination.
  • One issue is that often financial and clinical information are in different systems.
  • Not all payers in the US run their PA s through their adjudication rules.  This doesn’t happen for some until it becomes a claim.
  • MOTION: To update PSS and make Pharmacy the lead on pDEX IG (Motion by Bob Dieterle, MK second.  (11, 0, 8 abstain)

 

Tuesday, May 7, 2019 WGM Financial Management (FM) Notes:

 

Q1 and Q2: (met with MK, Benoit, Bob D)

  • Not a simple mapping exercise of code sets for prior auth


Q3: Joint with Attachments


MISC REQUEST

Matt Bramson (sp) (intermediary in US)

  • They would like to use claim and claim response resources for pre-D.
    • Would like to have it support alternative medication fill suggestions.  Need ability to support sending alternate pricing.
    • Not using FHIR,  but would like to.
  • NCPDP is working on a benefit check.  Voting on a standard in the fall likely to be published early next year. 
  • Locations, generics, alternate fill locations (e.g., mail order)
  • Is this a one off or are they currently using NCPDP standards? MK thinks it is behind the scenes, they want to create the responses to the NCPDP transactions. However, they say they are looking for an alternate path.  This would be a competitive to the NCPDP standard.  MK notes that HL7 doesn’t typically create standards in direct competition with other standards.   This proposal came out their work on the connectithon meeting.  HL7 is willing to work collaboratively with NCPDP.
  • Benoit notes how to use FHIR to propose alternative you might go through suggested-alternative (for treatment). 
  • Concerns
    • The political issue between SDOs is something that needs to be considered. 
    • This potentially creating a second way to do something and would providers to end up supporting both. 
  • This is extension for claim (part of extension would include medication request).  The responder to this is not responding back with a prescription.
  • Next steps need to occur: NCPDP, pharmacy group, Requesters to talk with pharmacy and then come back to groups

Paul provided an overview of FHIR info/and financial domain structure

  • FHIR – (current) is the current development build that will change rapidly and will become the next version.
  • Dated version above the current is the published version.
    • Version matters, need to know what version.
  • Transport specification (not all specifications).   In FHIR it isn’t request/response.  Operations would be request response. 
  • Data types in FHIR are both primitive and complex (date vs date range).
  • Instead of being modeled in transactions it is based on object
  • Resources are the fundamental components and the requirements for each of these is very loose as they support multiple use cases. 
    • In order to put them together you create a profile.  When you create a profile you tighten the cardinality and identify what fields you need.  (required terminologies you have to pick one of those, for flexibility you will have just an example). 
      • Profile keeps the fields you need, addresses the cardinalities, replace the terminologies, extensions (allows you to create an object and place it in the resource. 
      • In FHIR the extension should be registered and you should be using the extension as registered.  (e.g., you can add a religion extension and then be able to use it whenever it is needed). 
        • There is a possibility that an extension might actually be normalized (1st order object) the challenge it is already used in this other way.
        • 80 percent rule for FHIR means that you don’t need to know 100% before you went forward if you knew 80% you could go forward.  That got morphed to be addressing 80% of system requirements and it might have gotten left out if it would be on 80% system used vs 80% of what is known. (example… day supply is not in the claim but it is common just not used in 80% of claims).
          • Bottom line is there is stuff missing.
          • US vocabulary is missing
          • Also need to build a US profile
        • Relative order of use is a treatment story.
      • For each resource (e.g., coverage eligibility request), note the tabs at the top
        • Content: contextual description
        • Examples: (you won’t find the examples of a patient, will only be specific to what resource you are under).
        • Detailed descriptions
        • Mappings
        • Profiles and extensions (this is where you find any extensions.
        • Operations (bags….no one to one relationship
        • R3 conversions
      • Type of field is technically the data type. 
      • A reference will point to typically another resource.
      • Code vs codeable concept (concept allows you to ID the code and the code system or multiple codes so for example you could say in ICD10 it is X in SNOMED it is Y ( you don’t have to have code you can just provide text).  Part of profiling exercise it to limit this.
      • You can also look at the info in a UML diagram.
        • What is Turtle?  It is a form that better supports some analytical efforts.



Q4: Joint with Attachments

  • Bob D. noted permission from X12 to do the 278 and 275 mapping and will be shared with X12 and distributed through X12. Also, there are some operational items that need to be discussed outside the workgroup to better define things.

Back to FHIR Overview:

  • Business models can be used independent of transport.
  • Synchronous (stay on hold) vs. Asynchronous (call back)
  • Claim response can come back with errors, or no errors or totally complete the adjudication could be zero or you aren’t covered. 
  • Map the intent and worry about the data later.  Need to get really really, specific.  Even though we have a specific code that is void and replace, it is really a 2-step process and it results in a void prior and reprocess.  Once US establishes terminology and profiles that is where discussions for possible missing can happen.   Concepts for the US might be done through extensions.
  • No profile to point to that would clearly look like something that claims in the location
  • There is mapping in FM to the HCFA and UB forms. (downloaded to mapping)
  • There are implementation guides
  • Must support = if you have you must send it when it is available and you must be able to return it, so you must save it.  What happens if you have it, but it isn’t available in a particular box?  At that point it wouldn’t necessarily be considered must be supported.  This allows for it to be sent.
  • Bob’s team is identifying existing profiles to potentially be used and if it not there they are creating profiles.  They are also creating IGs