| Management | HL7 Antitrust Statement | Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM). |
|
| HL7 Code of Conduct | https://www.hl7.org/legal/code-of-conduct.cfm |
|
| Meeting Minute Approval | 2023-01-09 National Directory Meeting | Approved by unanimous consent |
| Project Links | Project Page: National Healthcare Directory Project Scope Statement: National Healthcare Directory PSS Implementation Guides: Connectathon: 2023- 01 FAST National Directory of Healthcare & Da Vinci Plan Net Zulip Channel: https://chat.fhir.org/#narrow/stream/283066-united-states.2Fnational.20directory Predecessor work that this effort builds upon: |
|
| Milestones | Sept 2022 Ballot Cycle Milestones | Milestone |
|
|---|
| Ballot Voting | Complete | | Ballot Reconciliation | In Progress |
Tentative: May 2023 Ballot Cycle Milestones | Milestone |
|
|---|
| Notice of Intent to Ballot (NIB) | February 19, 2023 | | Sept 2022 Ballot Reconciliation Complete | March 13, 2023 |
|
|
|
|
| Announcements | January HL7 Working Group Meeting & Connectathon |
|
|
| CMS Advancing Interoperability and Improving Prior Authorization Processes Proposed Rule (CMS-0057-P) This proposed regulation cover areas like Patient Access API, Payer to Payer Exchange, Handling Prior Authorization, etc. Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard Proposed Rule (CMS-0053-P) This is the long awaited attachments rule from the Division of National Standards. It contains follow on requirements in the Accountable Care Act that mandated that CMS establish a standard for exchange of attachments compatible with HIPAA transactions. |
|
| Agenda |
|
|
|
| TIN | Review Evernorth ballot comments - FHIR-38301 – require TIN
- MB - social care providers largely don't have NPIs - would be wise to have identifier like a Tax ID that every org will have
- BD - must support or require?
- Require - you have to have it
- Must support - if you have it, you have to include it in the transaction; have a method for capturing and storing
- KGWEYB - can get contracted TIN but not corporate TIN in some cases; must support makes sense
- From thomas.zhou (AH) to Everyone 11:11 AM - Is the TIN a must to comply with HIPAA?
- BD - HIPAA related transactions may require TIN, but nothing in HIPAA requires TIN
- TZ - if there's no requirement/ policy in HIPAA, there's lack of evidence for must support
- BD - this info probably goes in the base profiles - making it required says every organization that ever participates in the National Directory would have to have a TIN and that's not necessarily true
- TZ - if it's optional, it should stay as optional - must support is attribute level constraint - sometimes confuses implementer downstream
- TL - if organization has that data, your implementation has to save it and retrieve it, but not every org has to have the field/ value
- TZ - mandatory for organization to provide it from business perspective?
- BD - some orgs that participate will not have or provide a TIN, but we have to have ability to capture it and populate the transaction if we have ability to
- TZ - optional is good enough - no need to use must support
- BD - must support says you have to have ability to do that as part of the implementation
- Already have must support requirements as part of US Core
- TZ - must support brings conversation/ debate
- TL - combination of must support and cardinality that turns it from required to optional; maybe share that with your developers - done that way for all FHIR IGs
- MD - if TIN shouldn't be revealed, any capability to constrain it?
- BD - yes, with restriction resource
- MD - use the usage restriction to constrain if TIN shouldn't be shared?
- BD - TINs in NPPES?
- MD - yes - guidance to providers not to enter your TIN - NPPES trying to not reveal to public; but for organizations not sure re: privacy concern
- BD - creating vehicle to restrict if needed, and implementer of directory decides if needs to be restricted or not
- From thomas.zhou (AH) to Everyone 11:27 AM - I second the PIA
- TZ - encourage to provide their TIN; but discretion if privacy issues
- BD - implementer of the directory will make those decisions, not the IG - the IG is about exchange, not policy decisions
- TZ - prefer to start with less constraint, and then down the road can add must support, constraints
- BD - not requiring anyone to have it, but requiring ability to capture it and exchange it
- Proposed Disposition
- Persuasive with mod
- Add slice to base profile for Organization.identifier for TIN and make it 0..1 and must support
- Since OrganizationAffiliation represents relationships between organization modeled after PractitionerRole there is no need to include TIN in OrganizationAffiliation since it will already be associated with the individual organizations
- Enhancement - Substantive, Compatible
- Ready for vote
-
-
- FHIR-38303 – require TIN
- Ticket for Exchange IG
- BD - location address is new piece for this ticket
- BD - we're adopting what US Core has done for addresses for organization; requirements come from USCDI
- Clayton (KGWEYB) - we build tables to map location to US postal service address
- BD- nothing prevents you from having multiple addresses - one that's 123 Main Street and another that says Corner of 4th and Main - we support the capability
- MB - meant as an alias? different way of saying same address?
- KGWEYB - yes
- BD - organization resource and pull back all the addresses are associated with it
- TL - as long as it supports more than one address, we're ok?
- KGWEYB - not a way to necessarily relate them?
- BD - yes could have US postal service address/ everything populated, and then secondary address that has nothing but line populated
- CC - organization in this context can have multiple addresses - clinic with 10 different locations - do we need 2 slices - one that's USPS mailing address - 10 mailing addresses, and then different set of slices to have 10 'vanity' slices?
- Understand need for more human friendly version, but what does that look like?
- BD - we have all the flexibility in the world to have multiple addresses or multiple representations of one address, or within a single address specify a 4 line string
- The only requirement is City, State, Postal Code, Country - the actual street address is not enforced in a way
- TL - could do slicing as well? could we put our own use in there?
- BD - no, it's required you can't - it's not extensible
- Ability to do postal or physical or both
- KGWEYB - enough there to work with
- RL - Plan Net and NDH - address primarily supposed to be in the Location object as opposed to the Organization?
- According to relational structure it looked like Location resource is the expectation for physical address of an organization
- BD - we haven't done anything other than pick up US Core base for that - all the statements would still be true whether you use Organization or Location - could use either
- Practice location would typically use Location
- Organization itself would typically use Organization
- MD - NDH - geolocation is being used but not in US Core
- BD - right, we have some extensions
- RL - are we looking for vanity address for practice location or physical location of the organization
- BD - applies equally to Location and Organization
- KGWEYB - right - across any represntation of address
- From Matt Bishop to Everyone 11:45 AM - (5.0) http://hl7.org/fhir/5.0.0-snapshot3/organization.html and (4.3) http://hl7.org/fhir/2021May/organization.html
- MB - changes for 5.0
- BD - we're buliding on 4.0.1
- MB - want to future-proof or track why this change
- RL - (section 8.6.2) Boundaries and Relationships
- Proposed disposition
- Persuasive with mod
- See FHIR-38301 for disposition regarding TIN
- Current address complex data type has sufficient flexibility to address vanity addresses - no need to modify either Location or Organization resource
- Enhancement - compatible, substantive
- Ready for vote
-
- FHIR-38304 - Examples does not appear to reflect Tiered OAuth
- Redoing all this in the single combined IG
- Changed issue type from a technical correction to a change request
- Proposed Disposition
- Persuasive with mod
- Include brief description and reference to Tiered OAuth in the combined implementation guide
- Clarification - non-substantive
- Ready for vote
-
- FHIR-38305 - Org Type Value Set Flexibility
- TL - discrepancies between 3 IGs
- BD - should have been the one taken out of Plan Net and that had a lot of payer input and terminology group input
- TL - specific value set for the 3 directory IGs and different from base R4 value set
- BD - don't think we have rationale for changing the Plan Net work
- BD - won't have 3 IGs anymore
- Proposed Disposition
- Will verify that value set is the same as used in Plan Net
- If not will change to reference the same value set
- Correction - compatible, substantive
- Ready for vote
|
|
| Management | Next Agenda | No meetings during the week of 1/16 for HL7 WGM Next meeting Monday, 1/23 Future meetings: - Request to revisit discussion, resolution re: endpoint use case topic from a week or so ago - better suited to be called purpose, and needed a separate data element that would reflect the workflow
- Review HSDS revisions to align with our work
- Reference Implementation link
Henderson Meeting Agenda Items: - What will we do with payloadType and payloadMimeType
|
|
| Adjournment |
| Adjourned at 12pm ET |
|
