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

HL7 FHIR Security 2018-10-23

From HL7Wiki
Revision as of 13:11, 23 October 2018 by JohnMoehrke (talk | contribs)
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

see gForge


  • John chaired