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

HL7 FHIR Security 2018-04-10

From HL7Wiki
Revision as of 19:16, 10 April 2018 by JohnMoehrke (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Call Logistics

Weekly: Tuesday at 02:00 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 x Kathleen Connor Security Co-Chair x Alexander Mense Security Co-chair
. Suzanne Gonzales-Webb CBCC Co-Chair x Johnathan Coleman CBCC co-chair . Chris Shawn Security co-chair
. Ali Massihi . Mike Davis x Nathan Botts Mobile co-chair
x Diana Proud-Madruga x Joe Lamy AEGIS x Beth Pumo
. Irina Connelly x Matt Blackman Sequoia . Mark Underwood NIST
. Peter Bachman . Grahame Greve FHIR Program Director x Kevin Shekleton (Cerner, CDS Hooks)
x Luis Maas EMR Direct . Dave Silver x Francisco Jauregui



  • Motion: JC/KC - Where secure http communications are needed, include TLS 1.2 or higher as best-practice in the specification, and consider it as a candidate for being a requirement.
    • Modify first sentence of second paragraph: "TLS 1.2 or higher SHOULD be used for all production data exchange, and disable support for lower versions of TLS."
    • post-paragraph add : "When using TLS use with strong cipher suites (e.g, AES)."
    • References: SMART-on-FHIR, NIST SP 800-52, IETF RFC xxxx on HTTP ......
    • Action: Matt will provide references used in Sequoia
    • Tracker 15907



  • John Chaired
  • agenda approved
  • approved HL7 FHIR Security 2018-04-03 Minutes
  • Discussed Input Validation
    • created and approved CR#15909
    • There was significant discussion around if we should include the second sentence on testing recommendations. The concern that any move into testing might be seen as overly prescriptive or specifically limited. Second concern is that this might lead to a precedent that we include a testing recommendation for every security line item.
  • Likely need overall guidance to use a security framework...