Minutes Approved as Presented
This is to approve minutes via general consent. "You have received the minutes. Are there any corrections to the minutes? (pause) Hearing none, if there are no objections, the minutes are approved as printed."
Meeting Minutes from Discussion
|Decision Link(if not child)|
|Management||Review ANSI Anti-Trust Policy|
|May Terry and Joe Minieri||Reference Implementation Update|
- Updating Reference Implementation Server to be able to handle CommunicationRequest and respond with Communication containing the PCDE bundle
- RI demo
- Current version relies on user having the Member ID or being able to retrieve the Member ID
- If there are multiple IDs there's not currently a way to handle that
- Currently no way to gather all the initial coverage information and storage in a bundle - using a pre-made bundle at the moment
- Concern re: getting the right Member ID - how do we ensure RI doesn't allow people to fish for the right ID/information
- RI assumes that authorization has already taken place
- Member ID can be active/inactive if the member moves to a different plan
- Member ID issue is not unique to PCDE
- Patient demographics and plan descriptors (payer, subscriber, member ID, plan/group numbers, etc.) are what uniquely identifies the individual - a single identifier may not be enough
- Need some guidance re: whether PCDE IG should define an approach, or should we bubble it up to HRex to guide other IGs
- PCDE could propose a strawman to propose to payers and get feedback
- May Terryto schedule a session next week (Tuesday-Thursday) to put it together
- Paul Knapp and Michael Cabral volunteered to participate
- Michael Gouldvolunteered to review materials
- Could distribute to BCBSA for feedback
- AHIP feedback?
- WEDI feedback?
- Provider feedback may help - they have to deal with the diversity that exists now
|Lloyd||Update on terminology issues|
- Structured Docs discussion re: Condition and Procedure terminology bindings
- Agreement and approved by sponsoring workgroup to add support for ICD-10 (and maybe ICD-9) as well as HCPCS level 2 codes
- Will be included in US Core release coming out in 2 weeks
- Medication bindings
- Expectation is to continue expressing medications as RxNorm due to standard conversions already existing
- Are there standard conversions from HPCS for medications to RxNorm?
- Medication itself or administration of medications?
- HPCS medication codes are usually given in context of administration of the medication, not necessarily for the order itself
- We would need to identify where we'd expect payer systems to be mapping HCPCS codes into FHIR (MedicationRequest)
- US Core timeline probably won't accommodate this at this point
- PCDE payer to payer implications
- Send HCPCS codes and provide the best RxNorm translation that you can (even if you lose granularity)
- If that's not feasible, we'd have to create our own profile
- Translation is challenging due to loss of granularity
- HCPCS code is by unit dose and there may not be an equivalent (more administrative data than clinical data)
- RxNorm is more clinical - concentration/dose/form/ingredients
- Financial Management, Payer/Provider Information Exchange (PPIE) workgroups may need to consider these types of codes that are needed for payers and make recommendations
- This was brought up in CQI workgroup today (10/11) - voted to support ICD-9, ICD-10, HCPCS on 2 GForge Tracker items
- If there are other places where there are terminology challenges, we should identify those as well - if there are further proposed changes to US Core for another release, we'd want to address all at once
- Is there a US Core Device profile?
- Implantable Devices - extensible binding for Device Type which leverages SNOMED
- Prosthetics are typically done using L codes - obscure, but reality of legacy
- Prosthetics are not implantable
- Review of US Core Profiles against commonly-used payer terminologies
- Doesn't make sense to do in individual Da Vinci IG calls
- Financial Management will review jointly with PPIE workgroup
|Lloyd and Julia||Ballot Comment Review|
- CertificationType in Prior Auth Support extension
- Question came up in Virtual Connectathon
- In this case there's no binding yet because value set is supposed to come from X12
- Relevance to PCDE use case?
- Do we want to create PCDE-specific profiles on Claim for Prior Authorization?
- If we define multiple profiles, it's additional work for payers - one interface for Prior Auth Support and a different one for PCDE
- How important is it for us to standardize this in PCDE?
- Past profiles might mark something mandatory that's not mandatory in PCDE, so we'd have to create our own profile to relax our expectations
- Would also need to keep Prior Auth Support and PCDE in sync
- No need to constrain the use of this or any other Prior Auth Support elements in PCDE
- Update on terminology discussions
- Ballot comment review continued
Create Decision from template