| Management | HL7 Antitrust Policy | 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). |
|
| Ballot Reconciliation |
|
| T
|
Key
|
Summary
|
Assignee
|
Reporter
|
P
|
Status
|
Resolution
|
Created
|
Updated
|
Due
|
FHIR-37957
-
Getting issue details...
STATUS
- JM: thought about how we could adjust the existing weights to arrive at a 10 if we were to have the combination of three items in the 3-5 row of the screen shot (in the Zulip thread). May want to reduce the weight of address so that you have to have first/last name, DoB and two other items from the middle category.
- Will modify to explicitly call out that last four SSN should be included in that category.
- From Julie Maas to Everyone at 13:13: so expand to say "for example, Digital Identifier, last 4 of SSN, OR Insurance..."
- JM: Also discussed combining these values into a level 2 invariant profile totaling 20 (a total of 10 nominally but if doubling, 20 due to attributes being verified).
- Ticket marked ready for vote
Kevin Geminuic and Stephan Baur joined the call to discuss
FHIR-37054
-
Getting issue details...
STATUS
. This ticket was divided into nine different issue tickets to facilitate discussion. Kevin noted that they are also working on CARIN IG implementing some of these components.
FHIR-40347
-
Getting issue details...
STATUS
- AN: Doing some significant updates to Section 1.3 which he displayed.
- KG: Like the expanded narrative. Re: Use cases TEFCA - is this going to be aligned with TEFCA or is this standalone. Understood that TEFCA moving away from CCDAs.
- KG: Is this IG going to be used for TEFCA or is TEFCA going to use their own flavor?
- DP: TEFCA reviews FHIR IGs for consideration and use them where they can.
- KG: Just want to be sure that the TEFCA use case is considered. It sounds like they review it and that's the extent. Now that we understand that, feel it's sufficient.
- SB: Is the Facilitated FHIR IG related here?
- JM: Was derived from Security IG and UDAP dovetails with this work. Our work is not intended to be inconsistent with UDAP Security IG.
- This ticket has been marked duplicate of an existing ticket that addresses the concern.
FHIR-40348
-
Getting issue details...
STATUS
- This ticket has been marked duplicate of an existing ticket that addresses the concern (updates to section 1.3).
FHIR-40349
-
Getting issue details...
STATUS
- KG: The various levels identified in the spec, do you see ONC standardizing on the levels?
- JM: UDAP publishes those levels and live on UDAP.org page. My understanding it would be up to NIST to take up normal levels
- This ticket contains a related question and was addressed through discussion on the call.
FHIR-40350
-
Getting issue details...
STATUS
- AN: The specific terms are not used in the IG. If added, would need to create sections to define the different credential types.
- JM: In this comment, feel we are getting into authentication methods which aren't in our current scope. Where we mention credential, it's a digital identity that is able to be validated but we don't deal with this. Do you think we need more clarification.
- KG: Perhaps in the front matter, what we mean by credential going forward in the document.
- SB: There is often confusion about CSP issues. Might be helpful for these advanced digital identity concepts to define in the text.
- JM: Do you have a working definition.
- SB: If you search for credential and context where it's used, we thought it meant password. Felt it was a bit of inconsistency there.
- From Kevin Geminiuc to Everyone at 13:38: Source(s): NIST SP 1800-17c under Credential. An object or data structure that authoritatively binds an identity, via an identifier or identifiers, and (optionally) additional attributes, to at least one authenticator possessed and controlled by a subscriber.
- From Julie Maas to Everyone at 13:31: That seems fine to me
- KG: Not sure there are inconsistencies with the definition, but would be helpful to include.
- RT: If not specifying authentication, it relies on UDAP and some aspects of those things?
- AN: That was my other question, if we want to reference UDAP IG and/or take this and put into the glossary.
- KG: I'm ok with that.
- JM: If we are able to find a generic definition other than that reference, is that ok?
- KG: Yes, that's fine.
- From Julie Maas to Everyone at 13:46: This is the definition from 63-3 that we should use (please respond if any concerns): An object or data structure that authoritatively binds an identity - via an identifier or identifiers - and (optionally) additional attributes, to at least one authenticator possessed and controlled by a subscriber. While common usage often assumes that the subscriber maintains the credential, these guidelines also use the term to refer to electronic records maintained by the CSP that establish binding between the subscriber’s authenticator(s) and identity. Source(s): NIST SP 800-63-3 under Credential as per: https://csrc.nist.gov/glossary/term/credential#:~:text=NIST%20SP%20800%2D63%2D3,by%20a%20cardholder%20or%20subscriber.
- Ticket marked ready for vote
FHIR-40351
-
Getting issue details...
STATUS
- KG: There was threshold in one of the tables -
- AN: Scoring of the match and weighting of $match submission. The patient weighted input is more aligned with guidelines.
- KG: The TBD reference - these would potentially go into a repository, right? Would this be changed in the future or no weighting on those elements?
- AN: For now, yes. Ultimately hoping to obtain feedback from implementers to create a more useful/enhanced table in the future.
- KG: Is insurance member identifier equivalent to medical record number?
- JM: For your purposes, the numbers may be the same.
- KG: Will there be a weighting threshold recommended for a match. When people pulling records from Kaiser, if they are defining thresholds for us and we know the data quality of ours, it would be hard for us to control if good match or not. Could be implications for us.
- DP: We can't dictate the quality of data points in your implementation.
- KG: Would be helpful to call that out in the spec, that organizations can control that. Would like to see a disposition that enhances the text to say "Organizations would control their data quality matching algorithm."
- JM: I think we have a note above section 4.3 - we have attempted to keep algorithms out of scope. The reasons these scorings some info consideration, we wanted to publish an outwardly way to compute a score so that a score could be passed back.
- KG: This is very helpful for us.
- SB: Didn't other provider organizations request that patient ID numbers be included? In Kaiser's case, I would want to see the patient identifier (e.g., MRN).
- JM: We had some discussion about this; it's not something we can condition return of records.
- From Carmen Smiley to Everyone at 13:51: we have heard that medical record numbers are not often useful between systems
- KG: I think we are good, we can move on.
- JM: I do think identifier you are mention is included in that third line. A medical record number would qualify.
- From Carmen Smiley to Everyone at 13:51: +1 Julie
- This ticket marked as duplicate
FHIR-40353
-
Getting issue details...
STATUS
- KG: Maybe the FHIR spec covers this with FHIR IDs. It's an optimization we typically look for.
- JM: We have discussed this workflow. If you return a resources that includes local identifier and requesting system can kick that up and use it later?
- KG: Yes, just wondering if we could add reference to that result. Sometimes its implied but not called out all the time. If possible to link back to FHIR query spec that there is possibility of probabilistic match for a period of time.
- JM: Is there a specific section you have in mind from FHIR search?
- KG: I would have to go look for it but if there is something there, I would like to refer to it from here.
- Kevin will find the link and send to Aaron after the call.
- Ticket marked ready for vote
FHIR-40354
-
Getting issue details...
STATUS
- There was a comment in the ticket with some starter text from Julie.
- JM: This language aims to capture practices in place where certificates are issued for care quality and direct messaging purposes.
- SB: If there is a reference that can be made to organizational entities and issuing credentials/certificates.
- JM: The items mentioned stem from Direct Trust entities. Is that helpful? The suggested text reiterates the spirit of this. Add to the end "as per" and the reference the Direct Trust Certificate Policy.
- KG: That's acceptable.
Aaron will email Kevin and Stephan to work through final resolution of the last ticket. He will report back to the group during the standing meeting in two weeks.
|
|
