HL7 WGs are required to acknowledge the operating under HL7 Code of Conduct & the HL7 Antitrust Statement at the beginning of each meeting.
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).
Security WG calls are recorded per WG approval during 2021-10-27 Security Call unless an objection is sustained.
Approval of 2023-01-30 Security WG Agenda/Minutes
Approval of 2023-02-06 Security WG Agenda/Minutes - Closed early - did not achieve quorum.
|FHIR DS4P IG|
Mohammad: Continue updating progress on publication request and THO ticket UP-370 add a new code (HAS-INLINE-SEC-LABELS) to v3-ActCode to the value set ObligationPolicy
Update from 2023-01-30 Security WG Agenda/Minutes
UP-370 approved and now in the build. Change pushed to rely on the code but error in build because codes are not in build. Can add CI as a dependency. Migrated to Sushi to enable build with CI dependency. John will help with this. CI release end of month?
Add a new code HAS-INLINE-SEC-LABELS to v3-ActCode to the value set ObligationPolicy to indicate that a resource includes in-line security labels that apply to parts of the resource.
- FHIR-40293AuditEvent agent relationship to other agent elements Triaged - John to provide update.
AuditEvent agent relationship to other agent elements
Share this issue
When an AuditEvent is attributed to many .agent values, and there is an obvious relationship (one Practitoner, one Organization) the relationship is implied to be clear. But when there are many this is not as clear. Use-case is where an AuditEvent is by two Practitoners each working on behalf of different Organizations.
2. Could just indicate that PractionerRole should be used (which might be a contained instance when that is appropriate)
3. Could add an agent.agent so that one agent can be related to another agent. (Like AuditEvent has for entity->agent.
4. This could be considered not core, and an extension used. This extension could be created in FHIR core so that it is available consistently.
John walked through options. Favors Option 4 because it is least risky and could be used in R4.
add a core extension allowed in the AuditEvent.agent element
agent-onbehalfOf 0..1 Reference Organization | Practioner | PractitionerRole | CareTeam | Patient
Approve option 4
|Security WG new TSC Representative||TSC Distribution of WGs Amongst TSC WG Representatives||WG doesn't understand why Security is in the TSC grouping or what the role of the representative is.|
|Discussion about how Security WG can best assist with this effort.|
For 3 year plan, we need to do a walk through of HL7 Healthcare Privacy and Security Classification System (HCS), Release 1
Question: Can we simply reaffirm and allow the Security Label vocab to evolve independently?
See instructions J - Reaffirmation Ballot
Unique Ballot ID: REAFF_HL7_PRIVSECCLASSSYS_R1_N1_2019JAN
Reaffirmation of HL7 Healthcare Privacy and Security Classification System, Release 1
International standard document describing the use of a Healthcare Privacy and
Security Classification System (HCS) suitable for automated labeling and
segmentation of protected health care information by access control systems to
enforce privacy and security policies
Reaffirmation of HL7 Healthcare Privacy and Security Classification System, Release 1 (1st Normative Ballot) - REAFF_HL7_PRIVSECCLASSSYS_R1_N1_2019JAN
|Kathleen will review to see if HCS is abstract wrt to binding to vocab so that THO evolution is considered to be aligned to HCS code systems/value sets.|
|DaVinci PoU codes|
Review the codes added to ValueSet: CDex Purpose of Use Value Set
CDEX POU code system and value set Da Vinci PoU codes
Da Vinci CDex IG has defined a number of PoU codes as an extension to the PoU codes in the core.
Suggestion made that the DaVinci POU codes be added to Security WG POU codes in THO.
The concepts are already covered by current PurposeOfUse for DaVinci POUs:
[Healthcare Payment as defined by HIPAA](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/disclosures-treatment-payment-health-care-operations/index.html) and isn't defined further to ascertain a more detailed Purpose of Use concept.
[Healthcare Operations as defined by HIPAA](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/disclosures-treatment-payment-health-care-operations/index.html) and isn't defined further to ascertain a more detailed Purpose of Use concept.
Are these needed at all and should DaVinci value set authors have discuss the reasons they didn’t think the current codes aren’t sufficient with Security WG, steward of the THO POU codes, prior to creating new ones?
To perform one or more operations on information for conducting financial or contractual activities related to payment for provision of health care
To perform one or more operations on information used for conducting administrative and contractual activities related to the provision of health care.
|Need to ask US Realm and FMG to discuss the need to align accelerator IGs with the vocabulary owners rather than creating conflicting/overlapping vocabulary. Concern is that DaVinci and CARIN vocabulary are being referenced in regulation but these IG specific vocabularies are not being reviewed by the owning WGs or THO. Ask Chris Shawn to discuss with US Realm and John Moehrke to discuss with FMG.|
|Notes from CHAT|
Moved FHIR Chats to separate page