| 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). |
|
| Agenda | Ballot reconciliation | Pick back up on these tickets from last week
FHIR-38163
-
Getting issue details...
STATUS
- BD - endpoint use case was in the previous ticket (FHIR-38164)
- This ticket is pointing to same place - endpoint use case
- MCD - is that where payer endpoints would go?
- BD - questions are about extension to that resource, not the resource itself, but yes, that's where payer endpoints go
- MCD - provider endpoint types and payer endpoint types?
- BD - no, we don't separate them out that way
- MCD - if payer puts in 3-4 endpoints, it will be obvious which is for Price Cost Transparency and which is for Prior Auth?
- BD - endpoint use case
- SI - what is payload type?
- BD - endpoint resource is reasonably genric, e.g., could have endpoints based on Direct and the payload type would tell you what type of payloads that endpoint supports
- JL - is directory only for FHIR endpoints?
- BD - no, that's not the intent
- MB - e.g., TEFCA is mostly IHE profiles at moment with FHIR roadmap
- BD - intent to support what TEFCA does but not be limited by it
- BD - Payload Endpoint Type value set error - Robert Dieterle need to submit a JIRA ticket
- GH - could not find any value set that has PCT, etc. listed
- BD - those are IGs
- GH - orgs tend to segment endpoint by use case
- BD - we already have support for IGs - PCT is an IG
- GH - there are multiple IGs for each use case - sometimes you want to get to the higher use case
- BD - you can have multiple IGs
- GH - users of CAQH endpoint directory are often looking for use case level
- BD - that is supported here already
- MB - dealing with this issue in Direct Trust - because Direct messages are used for many things, this might just be for lab orders, or appointment scheduling or all referrals - that's the kind of granularity where there might not be IG associated with the concept of lab orders for example
- BD - extensible value set
- MB - we should talk to Lisa Nelson - Direct Trust defined sample value set for this (not an HL7 value set) - Matthew Bishop will email Lisa R. Nelson and copy Robert Dieterle and Gail Hamilton
- BD - need an HL7 value set; proprietary value sets can help guide us, but need it to be part of HL7
- BD - reviewed extensions in the IG on top of payload type
- MB - intention for DIrect Trust was that once moved to FHIR directory fully, it would go in the endpoint-use case element
- BD - reviewed endpoint-use case value set
- From josephlamy to Everyone 11:27 AM - What we are calling “usecases" should be called “supported purposes of use"
- MB - need a separate data element? use case seems to describe granularity that GH and MB are speaking to; purpose of use value set
- BD - created extended set for purpose of use value set in CDex which looks like value set for use case except it's extended - it's not lab order - purpose of use is higher level; so is use case higher level
- From Matt Bishop (Open City Labs) to Everyone 11:29 AM - https://terminology.hl7.org/4.0.0/ValueSet-v3-PurposeOfUse.html
- MB - why use case here vs. purpose of use somewhere else?
- Matthew Bishop and Gail Hamilton will share value sets they're using to define functional endpoint capabilities so that we can determine what could be pulled into an HL7 value set
- AK - why does use case extension have an extension inside it for standard and there's also an extension for listing IGs supported? Seems redundant?
- BD - agree, we need to reconcile these 2 extensions
- Proposed disposition: Persuasive with Mod
- Review and reconcile use case extension and the ig-supported extension to accommodate:
- Purpose of use (see CDex value set)
- Specific IGs supported
- Functional endpoint capability (see Direct Trust and CAQH endpoint value sets)
- Create new JIRA ticket to address the above proposal (likely non-compatible)
- Ready for vote
FHIR-38164
-
Getting issue details...
STATUS
- Linked this ticket to FHIR-38163 - resolution will be addressed above
- Ready for vote
FHIR-38357
-
Getting issue details...
STATUS
- Must Support flags in practitionerRole profile
- BD - suggesting we should require the distributed directories to have to support this? Must Support = have to capture it, have to populate it
- AK - in general, yes; these looked like oversights in the process - very specific sub-elements of identifiers
- Query IG does not have the Must Support flags compared to the Exchange IG
- Lack of consistency across profiles
- BD - intent was that profiles are different because of the use
- National directory has the most constraints because expected to have that information and ability to consume it and populate it within an exchange
- Were trying to minimize requirements placed on distributed environments
- If have a practitionerRole at all, then you have to support the identifier of all these elements?
- AK - those three things are equally important to distributed directory as they are to national directory
- RU - agree
- BD - not automating based on the identifier for practitionerRole? what is expected to be in identifier for practitionerRole that you'd use to automate anything?
- RU - differentiating practitioner vs. practitionerRole?
- BD- yes, identifier would be in Practitioner
- AK - what's the value to the national directory?
- BD - to differentiate other than .id, that specific instance of practitionerRole
- AK - that's not true in distributed directory?
- BD - we don't know what they'll have and what they'd use practitionerRole for other than connecting an individual to an organization (e.g., HIE - associate a practitioner with an org)
- AK - have to support identifier, but not any of the elements of the identifier?
- BD - reviewed US Core - doesn't require support for identifier at all
- AK - would be ok with that for Exchange and Query IGs
- BD - we would remove from Query, but not Exchange - expectation that national directory will have identifier for that particular role because it will support many different roles
- MB - why would we want to remove it from Query IG? understand not overdoing requirements, but trying to be certain that we're talking about same practitionerRole, wouldn't you want identifier?
- RU - you have identifier at practitioner level; then you have resource identifiers; don't need identifier in practitionerRole
- BD - Query only applies to queries to distributed environment
- MB - example - trying to identify Dr. Johnson at Hackensack Health System - query practitionerRole at that point - wouldn't we want identifier at that point?
- BD - you query practitionerRole where practitioner is Dr. Johnson and organization is a reference to an organization (whichever one you want) - you wouldn't query on identifier because it doesn't mean anything to the requestor
- MB - is a nurse practitioner in Iowa the same thing as a nurse practitioner in Michigan
- BD - that comes down to value sets; role and specialty would have to be based on national standard; identifier is within context of particular implementation; not sure what you'd do with the national identifier
- AK - identifier is not listed as search parameter in the Exchange IG
- BD - it's supposed to be; may need to fix
- From josephlamy to Everyone 11:58 AM - I think a big use case for business identifier on any resource (in directories) is when the same resource will be mirrored across multiple systems, e.g. mirrored directories, partially overlapping directories, etc.
- From Matt Bishop (Open City Labs) to Everyone 11:59 AM - +1 Josephlamy's comment
- BD - not stopping you from doing that, just saying it's not required for you to do it
- JL - in favor of Must Support
- AK- general recommended approach is that it should be equivalent between the IGs
- BD - will review the original spreadsheet to use as basis for making sure the IG includes what it's supposed to include and the rationale; will bring it back to the call next week
- Pick up this discussion next week
|
|
