Chair: John Moehrke

Scribe: Kathleen Connor

Mondays at 12:00 - 1:00 pm Eastern Time

Closed early - did not achieve quorum.

Agenda Topics


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.

Agenda Overview

Agenda Approval

Approval of

2023-01-30 Security WG Agenda/Minutes





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.
This is a follow up from this FHIR ticket:
FHIR-33917 - extension-has-inline-sec-label should be a code not extension Resolved - change required



FHIR-40293 - AuditEvent agent relationship to other agent elements Triaged - John to provide update.

  1. FHIR Specification Feedback
  2. FHIR-40293

AuditEvent agent relationship to other agent elements

Add comment
In PersonPropose DispositionWorkflow

Share this issue



  • Change Request

  • Status: Triaged (View Workflow)

  • High

  • Resolution: Unresolved

  • FHIR Core (FHIR)

  • R4

  • Security

  • AuditEvent


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. 

Possible Solutions:
1. Provenance has an agent.onbehalf to address this. Moving to this would make the models similar.

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.

Need discussion


HL7 cyber security event

Discussion about how Security WG can best assist with this effort.
HCS Reaffirmation

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

Security Ballot Tracker

ANSI Standards approaching expiration 

Decide on whether to revise or just point to THO for vocab updates.  NIB must be completed for ballot before expiration on 20240607.

Last Reaffirmation


From <>

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

Instruction Document<>

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]( and isn't defined further to ascertain a more detailed Purpose of Use concept.

[Healthcare Operations as defined by HIPAA]( 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.

Did DaVinci think that they needed US HIPAA specific healthcare payment/operations codes?  Purpose of Use codes are meant to be associated with the prevailing realm privacy policy unless specifically associated with a realm-specific policy, e.g., 42 CFR Part 2 POUs are different from HIPAA POUs?

Notes from CHAT

Moved FHIR Chats to separate page

FHIR Privacy and Security Zulip Chats


Security Project and Ballot Management Resources FAQs

Confluence and JIRA Tutorials

TSC Decisions

Call Chat



  • No labels