2023-03-27 National Directory Meeting

Robert Dieterle

Durwin Day 

Douglas DeShazo 

Matt Elrod 

Rachel E. Foerster 

Scott Fradkin 

Michele Galioto 

Christopher Gracon 

Christol Green 

Gail Hamilton 

Brian D. Handspicker 

Sheljina Ibrahim 

Lenel James 

Crystal Kallem 

Joe Kelly 

Stephen Konya 

Joseph M. Lamy 

Rick Lisseveld 

Tom Loomis 

Nancy Lush 

Dana Marcelonis 

Michael Marchant 

Brett Marquard 

Linda Michaelsen 

Ruby Nash 

Lisa R. Nelson 

Mark Neumuth 

Paul Oates 

Mahesh Patil 

Vassil Peytchev 

Kevin Prince 

Joseph Quinn 

Scott M. Robertson 

Shraddha Sarode 

Bruce Schreiber 

Aaron Seib 

Rosaline Shaw 

Joseph Shook 

Carmen Smiley 

Corey Spears 

Cooper Thompson 

Rita Torkzadeh 

Ron Urwongse 

Serafina Versaggi 

Ronald Wampler 

Abigail Watson 

Thomas Zhou 

Brett Stringham 

Aaron Nusstein 

Picking up from 3/23 call: 

RD: Need to create a base definition of what is attested to, becomes part of nationally attested data. An organization can attest to their data. A payer can attest to an insurance plan. We discussed idea of a network. Networks exist on their own as do practitioner, etc. What else exists on its own? In this case "networks" implies HIE/HIO in the broader definition. 

RD: On the "create" side, when you're attesting in the role, it is expected you will contribute all the information necessary to create that resource. You're responsible for it. 

RD: Base endpoint created by one or more organizations. 

RD: Organizations create endpoints, except Direct/HIE/HIO. Payers are certain part of the organization (except Direct/HIE/HIO).

RD/MD/MB: Healthcare service can be provided by healthcare team.  An organization is typically created for the health care team to exist. May exist across multiple aspects of the organization. 

• RT: From a reimbursement perspective it may be the funder/payer that may defines what could a service.

RD: Practitioner roles get created by? Example: Can a hospital create a valid and visible practitioner role by declaring the following providers have a relationship? 

• MD: Hospital will attest to the hospital, the practitioner and the relationships (for employees)
• RD: What about those who are not employees but have admitting privileges? 
• MD: Hospital can say they have a relationship with the providers
• RD: We agreed that the practitioner declares the role, hospital declares the role. It may not be mutually attested. When the role doesn't exist can either one create the role? 
• MD: if only one attested, need verification to take place
• RD: verification usually occurs against primary source, who is the primary source in this scenario? We used primary source to mean something that is 'fact.' Examples: graduated school, address at this place. Saying it doesn't make it fact. A form of verification may be mutual attestation. 
• MD: Mutual attestation will make the data valid to put into the ND
• RD: Need to make a recommendation. Does attested data become available through the ND whether or not it's been verified. Is attestation sufficient? 
• RL: State or federal or both regulations from a payer perspective re: validating information in the network. Are there similar drivers re: this data? For a provider directory, verification occurs by an individual contacting an organization/provider group/etc. and providing a contact who can speak authoritatively to the scenario. 
• RD: The things you're verifying, would you consider them to be attestation on their part? 
• RD: Practitioner role is a relationship declaration. Do we allow the concept that anyone who declares a relationship (e.g., practitioner role), we create the role and make it available. It's only attested information. Does it have to be mutually attested before it hits downstream directories?
• RL: Attesting doesn't necessarily make it true unless it's attested on the other side. 
• MD: composition is a way to manage data 
• RD: Who submits the composition? How do we know they have the right to attest to the other side of the story? Composition assumes that one entity can do both. Verification resource is about attestation, validation...and can point to any one element/target. Only allow 1 attestor. For mutual attestation do we need to allow more attestors? Attestation is 0..1. Probably should have been 1..2. The base resource is 1..1, Can still represent, need to get the verification result to be sure they've been mutually attested. 
  
  • Either we don't make it available for we tell people to make sure it's been attested to on both sides. Otherwise we need an extension on almost every element. 
  • RL: homework and pick this up on Thursday. 
  • RD: Primary issue may be where and how do we indicate something has been verified? Do we need anything else? A status on the resource itself? 

Future meetings:

• Review HSDS revisions to align with our work