Stream: Da Vinci
Topic: Payer Data Exchange (PDEx)
Mark Scrimshire (May 04 2019 at 14:27):
This is the channel that is replacing #Da Vinci ePDx
Mark Scrimshire (May 04 2019 at 14:29):
The Reference Implementation is available here: https://github.com/HL7-DaVinci/PDex-Patient-Import-App
Thanks @Taras Vuyiv
Mark Scrimshire (May 04 2019 at 14:34):
The Reference Implementation page background is on Confluence: https://confluence.hl7.org/display/DVP/PDex+Reference+Implementation
Mark Scrimshire (May 04 2019 at 18:12):
The link to the Breakout room schedule is -https://docs.google.com/spreadsheets/d/1oORmFKiKAp3XmqhJ0mvLFcTwsNWgTpEejO-S25GNOAw/edit#gid=407578207
Saturday 2pm in Salon 5 will be a general Da Vinci Standup for all
Mark Scrimshire (May 05 2019 at 15:02):
Summary Report out for PDex Track: https://docs.google.com/document/d/1Zz0CnKID_QteNSVnCDOILS35czILwqOCARtY0vLYX-k/edit?usp=sharing
Mark Scrimshire (May 05 2019 at 15:56):
Copied output into consolidated Report out document: https://docs.google.com/document/d/1uzgofMt_lYhSqTZgv_9QpO4ct6VvtqjubGyBGvG4p1E/edit#
Viet Nguyen (May 05 2019 at 16:07):
Sunday - Da Vinci demos in salon 7 @1pm. Get lunch and join there.
Douglas DeShazo (Aug 14 2019 at 13:53):
@Mark Scrimshire Mark, we (Humana) are in the middle of preparing for PDex in Atlanta and needed clarification on which role (receiving server or source server) should host the SMART on FHIR app? Or should both have the capability?
Mark Scrimshire (Aug 14 2019 at 14:41):
Mark Scrimshire Mark, we (Humana) are in the middle of preparing for PDex in Atlanta and needed clarification on which role (receiving server or source server) should host the SMART on FHIR app? Or should both have the capability?
The Requesting server should host the SMART-on-FHIR app. In the scenario where the SAMRT-on-FHIR app is launched from a CDS-Hooks card the SMART-on-FHIR app is used by a provider and enables them to commit information to their EMR.
In the Payer-to-payer scenario the requesting Payer would host the SMART-on-FHIR compliant application to enable a new member to connect to their old payer and authorize the exchange of information.
I just updated the Connectathon track page this morning to identify three exchange modes:
https://confluence.hl7.org/display/FHIR/2019-09+Da+Vinci+Payer+Data+Exchange
Douglas DeShazo (Aug 14 2019 at 18:49):
Thanks very much Mark.
Sindhu Nallamothu (Aug 27 2019 at 09:11):
In the connectathon 22 page for PDEX (https://confluence.hl7.org/display/FHIR/2019-09+Da+Vinci+Payer+Data+Exchange), all the scenarios mentioned cover the exchange of data from Payer-Payer. Is the Provider-Payer data exchange also included in this connectathon?
Mark Scrimshire (Dec 11 2019 at 02:12):
I will be watching the Da Vinci PDEx /ePDx channel and the PCDE Channel to provide support remotely since I can't attend in person
Mark Scrimshire (Dec 11 2019 at 16:05):
At the Philadelphia Da Vinci Connectathon two questions were raised that each have two parts:
1.1 How does a Health Plan know where to send the communication request and also
1.2 How to identify that a request was from a legitimate sender
2.1 Does the old payer need to provide data they may have received from a previous payer? (In the case where the new payer is the third payer in the 5 year period
2.2 Who is responsible for getting data from the oldest payer?)
I am going to work on a Google Doc that attempts to address these questions and will post it here for comment.
Mark Scrimshire (Dec 11 2019 at 16:05):
Google Doc - still writing it: Da Vinci Payer Discovery and Query Issues - https://docs.google.com/document/d/1yhvT3lAwWTMTKcioTcyizyrqCuZa0BN8mJR7VbJMSE4/edit?usp=sharing
Mark Scrimshire (Jan 08 2020 at 15:03):
The Google doc has been copied to Confluence. It can be found with the Payer Member Discovery Workgroup page here: https://confluence.hl7.org/display/DVP/Payer+Member+Discovery+Workgroup
Mark Scrimshire (Jan 08 2020 at 15:04):
A discussion was held at the CMS Connectathon on the topic of patient matching. The summary of the discussion can be found here: https://confluence.hl7.org/display/DVP/Payer+Member+Discovery+Discussion+at+CMS+Connectathon
Michele Mottini (Jan 24 2020 at 23:23):
The diagram at http://hl7.org/fhir/us/davinci-pdex/2019Jun/6-3_PDex_Hooks.html list the things the CDS server (payer) should return to the client: pasted image
Michele Mottini (Jan 24 2020 at 23:24):
Presumably the access token and FHIR entrypoint can be used by the provider to get the data of interest directly from the payer FHIR end point - correct?
Michele Mottini (Jan 24 2020 at 23:25):
But I cannot find a description on how they are represented in the returned cards
Michele Mottini (Jan 24 2020 at 23:25):
Also: the provider would need the payer's patient ID - and that's not listed
Michele Mottini (Jan 27 2020 at 18:27):
@Mark Scrimshire ^ ?
Melissa Benzie (Aug 11 2020 at 23:09):
Looking at the US Core Patient http://hl7.org/fhir/us/davinci-pdex/2019Jun/3-6-1_US_Core_Patient.html, can someone provide more detail re: the Member Number MB? Does it refer to the unique member health plan number specific to the patient OR the member health plan number which may be the same for a family?
Michael E Campbell (Aug 12 2020 at 19:46):
This is a good question Melissa that will need to be sorted out. The current build http://build.fhir.org/ig/HL7/davinci-epdx/index.html makes the following statement, "member id will be used to express the identifier used by the payer/health plan to identify an individual member. Health Plans may historically have referred to these individual members as:
Member
Subscriber
Beneficiary
Dependent
Group Member
Plan Member
Covered Party
Subject of Care"
However, these IDs are not consistently used across product lines (i.e., Medicaid, Medicare, commercial). For example, Beneficiary usually refers solely to the CMS assigned Medicare ID, and this can be used concurrently with a unique HP member ID. Commercial members usually roll up to subscriber with a dependent ID suffix, and can change if there is a family status change (e.g., divorce) and there is no reference to Medicaid ID, which is commonly used by Medicaid plans as the unique identifier.
Stanley Nachimson (May 18 2021 at 16:06):
Stanley Nachimson12:04 PM
I have created a couple of test patients with UDI resource included. They are at the HAPI R4 server, URL:http://hapi.fhir.org/baseR4/. The Patient IDs are cfsb1621007238203 and cfsb1621344950821. I would love for someone to test their query and see if they can retrieve the UDI information for the patients. The JSON language for the UDI resource is:
{
"resourceType": "Device",
"id": "cfsb1621007158908",
"meta": {
"versionId": "1",
"lastUpdated": "2021-05-18T15:09:33.280+00:00",
"source": "#wYDfpAmpgVz8KuUh"
},
"text": {
"status": "additional",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Knee implant for Bob</div>"
},
"udiCarrier": [
{
"deviceIdentifier": "09504000059316",
"issuer": "09504000059316://hl7.org/fhir/NamingSystem/gs1-di",
"jurisdiction": "hl7.org/fhir/NamingSystem/fda-udi",
"carrierHRF": "(01)09504000059316(17)250101(21)A123999",
"entryType": "manual"
}
],
"status": "active",
"serialNumber": "347a552889",
"deviceName": [
{
"name": "NACH123",
"type": "manufacturer-name"
},
{
"name": "Brand B Implant",
"type": "manufacturer-name"
}
],
"modelNumber": "A12",
"patient": {
"reference": "Patient/cfsb1621007238203"
}
}
Last updated: Apr 12 2022 at 19:14 UTC
