This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

HL7 FHIR Security 2018-09-04

From HL7Wiki
Revision as of 13:15, 11 September 2018 by JohnMoehrke (talk | contribs) (→‎Security Considerations on each page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Call Logistics

Weekly: Tuesday at 02:00 pm EST

Web conference desktop and VOIP 
Online Meeting ID: security36
Phone: +1 515-604-9567, Participant Code: 880898
 Please be aware that teleconference meetings are recorded to assist with creating the meeting minutes 

Back to HL7 FHIR security topics


Member Name Member Name Member Name
x John Moehrke Security Co-Chair . Kathleen Connor Security Co-Chair . Alexander Mense Security Co-chair
x Suzanne Gonzales-Webb CBCC Co-Chair . Johnathan Coleman CBCC co-chair . Chris Shawn Security co-chair
. Jim Kretz . Kenneth Salyards . Nathan Botts Mobile co-chair
x Diana Proud-Madruga x Joe Lamy AEGIS . Beth Pumo
. Irina Connelly . Matt Blackman Sequoia . Mark Underwood NIST
. Peter Bachman . Grahame Greve FHIR Program Director . Kevin Shekleton (Cerner, CDS Hooks)
. Luis Maas . Julie Maas . Francisco Jauregui
. Gary Dickinson . Dave Silver x Mike Davis



  • John - forward safety checklist updates with explanation to FHIR-I
  • John - propose next steps on "Security Considerations" on each FHIR page
  • John - bring proposal to Grahame to see how the FHIR build tools can aid us

Security Considerations on each page

Classification of the various FHIR Resources according to their intended use-case security/privacy sensitivity. It is inspired by some who have approached me wanting on each page a Security Considerations section, that I think is highly redundant. I am thinking of something similar to how compartment is handled in that a Resource can be multi-classified, but that most of the security considerations are on those classification pages with only resource specifics on the resource pages. Hoping the FHIR build can assist with this automation.

  • General sensitivity:
    • All resources can contain sensitive information, these groups are only general expectations based on the Resource intended use-case
    • Public/Infrastructure, --- Should be Public and not sensitive themselves, but care as inappropriate use might put sensitive information within
      • Bundle, Linage, MessageHeader, OperationOutcome, Parameters, Subscription, CapabilityStatement, StructureDefinition, ImplementationGuide, SearchParameters, MessageDefinition, OperationDefinition, CompartmentDefinition, StrucureMap, GraphDefinition, ExampleScenario, CodeSystem, ValueSet, ConceptMap, NamingSystem, TermininologyCapability, Library, Questioniare, ActivityDefinition, DeviceDefinition, EntryDefinition, EventDefinition, ObservationDefinition, PlanDefinition, SpecimenDefinition, TestScript, TestReport
    • Business-Sensitive, --- Mostly Public and not sensitive, but care as they may contain business sensitive
      • Organization, OrganizationAlliliation, HealthcareServices, Endpoint, Location, Substance, BiologicallyDerivedProduct, Device, DeviceMetric, Task, PractitionerRole, Schedule, Slot, ProcessRequest, ProcessResponse, Measure, MeasureReport
      • all of the Financial ????
      • all of the Medication Definition ???
    • Provider-Sensitive, --- Provider identified data, may be appropriate to release for specific use-cases, but does expose the provider individual
      • Appointment, AppointmentResponse, Practitioner, PractitionerRole, Person, CareTeam
      • all Patient-Sensitive
      • all of the Financial
    • Patient-Sensitive
      • Patient, RelatedPerson, Person, Encounter, EpisodeOfCare, Flag
      • all of the Clinical
      • all of the Financial
    • Unknowable -- Could contain anything, thus might be public or might be highly sensitive
      • Binary, List, Group, QuestionaireResponse



Current Open issues in gForge

  • 9167 AuditEvent+needs+to+make+more+obvious+how+to+record+a+break-glass+event (John Moehrke) Considered for Future Use
  • 10343 Three+additional+Signature.type+codes (Kathleen Connor) Considered for Future Use
  • 11071 Improve+security+label+guidance+-+2016-09+core+%2390 (Kathleen Connor) None
  • 12660 HCS+use+clarification (John Moehrke) None
  • 17192 Verification+of+given+resource+without+changing+the+content (Thomas Johansen) None
  • 17299 enhance+current+disclosure+AuditEvent+so+that+it+explains+what+is+being+recorded+and+why (John Moehrke) None
  • 17300 Break-Glass+description+needs+clarifications (John Moehrke) None
  • 14678 Implementation+guide+for+signatures+-+2018-Jan+Core+%231 (Brian Pech) Not Persuasive


  • John chaired
  • Roll;
  • approval of agenda
  • approval of HL7 FHIR Security 2018-08-28 Minutes -- Diana/Mike Davis: 4-0-0
  • Announcements
    • Mike -- Will be opening up a new project to revise and improve the Privacy and Security DAM.
      • It has been found to be missing ABAC, possibly other
      • Mike will look for old PSS to see if it can be revived or used as a start of a new PSS.
      • Mike to take this to full workgroup
      • Might be FHIR impact for this sub-workgroup to address
  • Process for "Security and Privacy Considerations" section
    • John is behind on writing his introduction to this work
    • Suzanne points out that when we use the term "Public/Infrastructure" that it beggs the question about "Private"?
    • Mike points out that these buckets are already well known, and have well defined guidance
      • Agreed we want to leverage that.
    • The new part here is the assessment of FHIR resources into these buckets
  • Plan for maturing security (and privacy) parts of FHIR -- FMM
    • Reviewed Maturity states in FHIR
    • Doesn't seem like there is much we need to do to prepare for Normative in R5
    • John to add this as a discussion topic at Baltimore
  • All security open
  • New business