Chair: John Moehrke
Scribe: Kathleen Connor
Mondays at 12:00 - 1:00 pm Eastern Time
Closed early - did not achieve quorum.
Agenda Topics
| Management | 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 Moved: Second: Vote: |
| 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? Proposal: 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. See https://bitbucket.hl7.org/projects/UTG/repos/utg/pull-requests/10/overview | |
| FHIR Core |
AuditEvent agent relationship to other agent elements Add comment Share this issue Details
DescriptionWhen 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: 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 Attachments | |
| 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 Last Reaffirmation 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 Instruction Document<http://www.hl7.org/documentcenter/public/ballots/2019JAN/downloads/Reaffirmation%20of%20HL7%20Healthcare%20Privacy%20and%20Security%20Classification%20System%20Release%201%20Instructions.pdf> | |
| 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. http://build.fhir.org/ig/HL7/davinci-ecdx/branches/Sept2022Ballot/ValueSet-cdex-POU.html Suggestion made that the DaVinci POU codes be added to Security WG POU codes in THO. Comments 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. Questions 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 | |
| Resources | ||
| Call Chat | ||
| Adjournment |
