Skip to end of metadata
Go to start of metadata

Chair: @Chris Shawn

Scribe: @Suzanne Gonzales-Webb 

Weekly calls Tuesdays 3PM ET

FreeConferenceCall Online Meeting Link

Dial-in Number (United States): (515) 604-9567 Access Code: 880898#

Agenda Topics 

 Minutes Approval


2019-10-15 Security WG Agenda/Minutes

Motion to Approve with amendment to update # of approval 10/15 Minutes

Moved: Beth Pumo Second: Matt Blackmon

Carrie Hammond abstained


PSAF Provenance NIB

Kathleen - Review and request approval for PSAF Vol 3 Provenance to proceed to next ballot opening 20191227, closing 20200127. Normative 3. Project 914

Description of Proposed Document: The Privacy and Security Architecture Framework (PSAF) Provenance Volume 3 is the remaining PSAF volume to be balloted as normative. This ballot rectifies approved disposition changes from the September 2019 ballot including clarification that scope includes both enterprise and federated architectures, the normative vs. informative portions, and various simplifications and corrections noted by commenters. It does not extend the substantive content beyond responding to September ballot comments.

Summary of changes of material interest since last ballot: Changes include clarification that scope includes both enterprise and federated architectures, the normative vs. informative portions, relationship to other Provenance standards, and various simplifications and corrections noted by commenters.

Motion to Approve submission of PSAF Provenance Volume 3 NIB

Moved: Beth Pumo Second: Matt Blackmon

Carrie Hammond abstained


Share with Protections

Mike Davis

Update on SwP Part 1 and Part 2 (to be presented Drafts).  Recommend FHIR IG PSS for SwP. 

No Update
Slide decks and Sharing with Protections paper are available on Security WG Confluence site

DaVinci IG Privacy and Security Considerations

Continue discussion 10/29 because DaVinci team has conflicts

Mohammad Jafari and Kathleen offer additional Privacy and Security Considerations for

PDex US Drug Forumlary

DaVinci PDex Plan Net IG

John suggested possible additions to Security Module AnonymousRead, or BusinessSensitive classifications as well.

Proposed Privacy Considerations:

The following privacy risks should be considered and addressed by both the formulary mobile application and the formulary service developers. Note that this IG is focused on the specification of the formulary service and does not discuss details of the formulary mobile application implementations, therefore, this is not a comprehensive list of privacy risks and considerations for the formulary mobile applications; mobile app developers must seek other resources to ensure the protection of consumer’s privacy.

- The formulary mobile app SHALL NOT send any information which can directly identify the consumer (e.g., consumer identifier or name) when querying a formulary service, including in the HTTP headers. A conformant payer formulary service SHALL NOT require formulary mobile applications to send any consumer-identifying information in order to query for the list of health plans provided by that payer and the medication costs for each plan, specific to the consumer's set of medications.

- Any information that can identify the mobile app (e.g. OAuth client ID ), even if it does not directly connect the app ID to a consumer, can be used to correlate and cross references the pattern of requests from the mobile app. This can significantly increase the risk of compromising consumer's privacy by inference, including by cross-referencing with other information such as public databases. Even more general identifiers such as the request IP address of the formulary mobile app, when paired with the details of the queries (especially in the case of uncommon drugs) can lead to statistical inferences about the consumer and can lead to compromising consumer’s privacy.

- While API client authentication is often necessary for business reasons (e.g., protecting access to the service, billing, and rate-limiting), access to the formulary service SHALL NOT require any authentication which ties the mobile app to a consumer identity and the server SHALL NOT maintain any records that could associate the consumer with the medication list that was queried.

- Any information uniquely identifying the formulary mobile app (e.g. OAuth client ID) SHALL be subject to privacy-protective measures if recorded for audit or quality assurance purposes on the service side, since it can potentially lead to divulging or narrowing down the identity of the consumer.

- Formulary mobile applications SHALL use the POST (as defined by the [FHIR REST API specifications]( method and only include the parameters in the body of the request.  This is especially important for for queries that include formulary drugs codes, to ensure that the drug codes are in the body of the HTTP request and do not appear in the HTTP request URL, which are prone to being logged by intermediaries (e.g., proxies, reverse proxies, load balancers, and TLS terminators) together with the IP address of the client. This mitigates the risk of leaking query details in logs.

-Because  patient information shared between the Client and the Formulary Service is released under HIPAA Individual Right of Access directive, and is thereafter offered little protection beyond Consumer protection laws, a Formulary Service SHALL only accept POST queries that only pass sensitive search parameters in the HTTP body.  For detailed guidance, see the Security and Privacy Module sections...(hoping John Moehrke can provide the correct references.)

Data sharing practices of medicines related apps and the mobile ecosystem: traffic, content, and network analysis BMJ 2019; 364 doi: (Published 20 March 2019)

Conversation continued @

Grahame Grieve: It's been brought to my attention that some members of the community are seeking to prohibit the use of GET for search requests in particular IGs, and possibly more broadly.

I think we should have a clear view on this across the community. Some background:

  • mostly, this is a question of logging - HTTP logs offer an access route to PHI through whatever PHI the URLs contain
  • in general, HTTP logs do not log the body. At least, not by default. But they can, and sometimes do. There is (and never will be) any normative rule that they can't
  • any organization collecting logs of FHIR RESTful calls is a party to PHI and needs to manage their logs accordingly. Given a secure connection to the app server, only the organisation should have access to the call to log it
  • I think we should assume that if the logging agent is malicious (MITM etc) they'll be logging the body as well
  • other arguments for not using GET relate to web pages, not web applications (referrer, visible in the address bar for other users)

For these reasons, the specification has never made any rule about this not using GET, but it does say that servers SHALL accept POST searches, mainly for this reason, so that clients can use POST instead of GET if they want.

Individual IGs are welcome to make their own rules, but in general, I would recommend against hard SHALL NOT use GET, since this is actually based on bad threat analysis (as outlined above). I would recommend that
- we explain this a little better in the specification
- IGs repeat the guidance in the specification

John Moehrke: I think it is appropriate for us to state that there exists a risk of un-managed audit logging (managed is by definition managed). I do not see that this risk of un-managed audit logs is a rational to forbid the use of GET and mandate of use of POST. (especially as Grahame points out there is nothing stopping an un-managed audit log from logging POST body).

Matt Blackmon: I would agree with the above.

I agree in that there is a risk of propagating the "misunderstanding" of "SHALL NOT use GET mitigates" a certain risk.

It also eliminates a potentially useful action (namely, GET) that may not have been fully explored or utilized. I don't have anything particularly in mind for this, but it seems dreadfully overly restrictive for what such a prohibition would actually deliver.

Finally, the existing recommendation to utilize https/secure transport mitigates much of this concern while addressing security in turn by measures at the proper layers of the OSI model.

Jenni Syed: Do we have anything about this in a security guide? It's such a common misunderstanding, I'm curious if we have a similar list of bullets and considerations for reference

Jenni Syed: I know we've talked about this quite a bit over the years

Lloyd McKenzie: We could also add guidance in the IG- guidance IG.

Mohammad Jafari: Adding my comment for the Security WG RE this:

There's also some draft language if we want to address and mention this in the security/privacy page.

I also think that instead of a SHALL NOT, we should suggest this as a possible design choice which mitigates some risks.

Jenni Syed: Interesting on assumption of TLS terminating. In public clouds, we've been given guidance that TLS in transit is recommended for all sensitive health data (which would matter depending on how deep the stack/logging goes)

Jenni Syed: I know of a few frameworks that default to logging bodies on POSTs for failure

Jenni Syed: And a few reverse proxies that parse bodies for similar TLS or URL manipulation issues for architectures referenced there

Jenni Syed: (to make sure the URL going outbound matches what the caller used inbound when behind a termination or proxy of some sort)

Jenni Syed: Essentially: everything your data transits through unencrypted has to be considered part of the model to protect data

Grahame Grieve:

Do we have anything about this in a security guide?

No. Hence my proposal above to say something explicitly

k connor: RE • GG "any organization collecting logs of FHIR RESTful calls is a party to PHI and needs to manage their logs accordingly. Given a secure connection to the app server, only the organisation should have access to the call to log it"

Unfortunately, it doesn't matter that the organization has access to the logs in scenarios where the entities accessing the PHI in logs have no laws restricting how they use PHI, in particular, where a US consumer releases PHI to entities not governed by HIPAA (and now no longer PHI and perhaps vaguely governed by Consumer Protection laws), perhaps it makes sense for IG authors to restrict queries to POST especially when their IGs are about "Consumer-centric control of their information.

Thankfully, some are developing API consumer privacy protective guidelines such as Xcertia Guidelines and CARIN Alliance Code of Conduct, which may decide that restrictive conformance requirements are appropriate for the policy context in which they operate. Providing approaches to Sharing Consumer Information with Protections would be a useful FHIR P&S, to which IGs wishing to distinguish their Consumer Centric Capabilities could assert conformance.

Grahame Grieve:

in scenarios where the entities accessing the PHI in logs have no laws restricting how they use PHI, in particular, where a US consumer releases PHI to entities not governed by HIPAA (and now no longer PHI and perhaps vaguely governed by Consumer Protection laws), perhaps it makes sense for IG authors to restrict queries to POST

That's the core confusion here: if the organization is collecting logs, it doesn't matter whether you use a post or a get since they may collect the bodies.

k connor: Those able to log PHI because they're the end point is one problem that can't be solved with POST vs GET. It's the intermediaries logging the GET HTTP headers, who aren't even covered by the Consumer Protection Laws that are the other issue.

    Grahame Grieve:
  1. There should be no intermediaries not covered by consumer protection laws. How would that happen?

  2. If there are such intermediaries, they can log the POST bodies too, and sometimes do.

The whole idea that intermediaries only log the URL is bad security analysis that we shouldn't allow

k connor: The US FTC has some consumer protection laws if the terms of agreement in Apps are not followed. No protections against intermediaries for the most part. Even HIPAA X12 transactions have to be opened beyond the envelope by whatever Clearinghouse among any number of Clearinghouses (and not necessarily with Business Associate Agreements with the Source/Recipient Covered Entity) happens to need to find out the transaction end points. Likely there needs to be more analysis/research on existing analysis about the lack of protections by intermediaries. I don't think any of us has enough research to make any assertions about what intermediaries are doing with GET Header or POST Header/Body. Doesn't hurt to try to minimize damage. Suggest that a more comprehensive review of the literature/practices be done so that we can give appropriately tuned guidance about the risks HL7 implementers should be considering/mitigating against.

k connor: May want to check out Data sharing practices of medicines related apps and the mobile ecosystem: traffic, content, and network analysis BMJ 2019; 364 doi: (Published 20 March 2019)

k connor: Here's FTC Medical App guidance

Laura Hoffman: The ONC and CMS interoperability rules are going to require providers to push health information to consumers via apps at a pace never before seen. There are no substantive privacy protections for consumers using apps and since the information is leaving the covered entity space, HIPAA obviously won't apply. Certified APIs should need to check for app attestation to whether they adhere to industry guidelines around app development and data use (Xcertia Guidelines, CARIN Code of Conduct, FTC Best Practices), as well as whether they provide consumers with easy-to-understand, model privacy notices (e.g., ONC's Model Privacy Notice). Otherwise apps are free to do what they want with health information on patients and their families.

Grahame Grieve: right. So obviously there are concerns here, and only using POST is a mitigation.. but my point is - it's a very minor mitigation, far less than people think. Doing your client crypto good is a far better protection, to reduce the prospect of accidental leakage - you will be connected directly to the source, who can log whatever they want

Mohammad Jafari: Intermediaries can indeed log POST bodies but in most cases they don't because that will lead to large volume of log data. It's much more likely for intermediaries to log URLs than full HTTP bodies. Note that this is about the customery configurations rather than what each entity can technically see and log.
As I mentioned in the writeup for the security WG, we can't deny that URLs are usually more exposed in logs compared to POST bodies.
I copy the example from a heroku default router log which is created after TLS termination. We see the URL parameters and the source IP which is very common to log.

2019-10-21T14:20:41-07:00 test heroku/router at=info method=GET path="/endpoint?parameter1=value1" request_id=87eef4da-3eb2-4cdc-a9ee-914607fbbaa9 fwd="" dyno=web.1 connect=0ms service=42ms status=200 bytes=515 protocol=https

Once again, people can configure things to cease generating these logs or filter them. What we are saying is that using POST is also an additional mechanism to subject sensitive parameters to less exposure and mitigate the risk of exposure via logs due to possible misconfiguration. This is not about a definitive prescription; it's just bringing to attention a possible mitigating measure.

Grahame Grieve: so I agree to bring it people's attention as a mitigating factor. But not to support that by bad analysis.

PSAF Provenance Volume 3 Ballot Reconciliation

Kathleen - Discuss proposed resolutions for block vote 10/22 call.

Jonathan Coleman comments 67 - 74

Also request a block vote on Beth Pumo's comments 58-66.

Next week, we plan on block votes for Bernd Blobel, and votes from Netherland Affiliates.


Reviewed dispositions. Block vote for 58 - 74 approved.

Moved: Mike Davis Seconded: Beth Pumo. Carrie Hammod abstrained



Comply with Policy Obligation Codes Proposal

Create a new Specializable parent [CPLYPOL in the ObligationPolicy ActCode system under which the various policies requiring compliance can be nested.  Add a new ObligationPolicy_CPLYPOL_CPLYCUI to support emerging US realm need to inform recipients of Federal Agency source Controlled Unclassified Information (CUI) that they must comply with the applicable laws, regulations, executive orders, and other guidances, such as included in DURSAs, to persist, mark, and enforce required CUI controls.  Add a Comply with Jurisdictional Security Policy.

Update current CPLYPOL to be a Specializable parent of









CPLYJSP (comply with jurisdictional security policy)


Custodian security system must retrieve, evaluate, and comply with applicable jurisdictional security policies associated with the target information.


CPLYCUI (comply with controlled unclassified information policy)


Custodian security system must retrieve, evaluate, and comply with applicable US Controlled Unclassified Information (CUI) policies associated with the target information.

Change Leaf Concept PRIVMARK to Specializable with a CUIMark child concept Proposal.

Create Leaf Concept

CUIMark (display CUI Mark)


CUI Custodians must create, persist, display, and convey computable and human readable security label CUI tags as required by CUI Marking policies including US 32 CFR Part 2002 and US Executive Order 13556 "Controlled Unclassified Information . CUI Custodians must enforce CUI Security Controls per applicable CUI policies.

Custodians include a CUI classifier of original CUI content; or a CUI derivative classifier, which reclassifies CUI content that has been aggregated with other CUI or Unclassified Uncontrolled Information (U) or dissembled from a larger CUI content

Recipients of CUI tagged content, CUIMark Obligation security labels must consume, persist, display, and enforce CUI controls per applicable CUI policies.

Usage Note:   Applicable CUI policies include:

Add Upgrader Role Code Proposal

Add UPGRDER as a child of RoleCode_AffiliationRoleType_AgentRoleType


UPGRDER (upgrader)


An individual authorized to raise the classification level of labeled content and provide rationale for doing so as directed by a classification guide.

Reviewed several substantively complete proposals and put on notice that several additional technical corrections/specializations of current codes will be submitted by initial deadline for subsequent review.

Approval of Initial submission of Harmonization Proposals

Moved: Kathleen Seconded: Beth

Carrie Hammond abstained


FHIR Security

John Moehrke

Note the call time has moved to 1PM ET, which is the hour after the CBCP calls.

John reported out on discussions related to proposed Change Requests for 3 Security Label extensions on codings with the following DataTypes:

Annotation: To support CUI display requirements and the Designator's Agency name/contact information

RelatedArtifact : To support references to specific Policy or Consent Directive governing the Security Labels assigned to FHIR Resources

Contributor: To support indicating the role of an entity that orginates or reclassifies a Security Label

Kathleen to submit Change Requests for these items.

Discussion thread on Zulip @

WGM Report out

Kathleen - Draft WGM Minutes - in process. 

16 SEP 2019 SEC WGM Minutes

17 SEP 2019 SEC WGM Minutes

18 SEP 2019 SEC WGM Minutes


Kathleen has not had time to complete these WGMs to date.

(SP) 800-207, Zero Trust Architecture

Mike Davis: Should HL7  Sec WG provide comments on NIST Zero Trust Architecture relevant to standards work?  Reference HL7’s PSAF Vol 1 with links to relevant sections such as Fig 7, 9, 12, 18 etc.

Mike will continue his review and report to WG about any healthcare specific use cases about which the WG would like to recommend that HL7 PAC develop/submit comments. Due date is11/22.  To review NIST SP 800-207 and provide input please check (SP) 800-207, Zero Trust Architecture

Federal Health IT Strategic Plan

Mike Davis Should HL7 security comment on Federal Health IT Strategic Plan –

    • Individuals perform on their own some of the activities that traditionally occur only in formal health care settings (e.g., monitoring blood pressure, tracking body mass index). An increasing number of individuals want the ability to use technology to track and improve upon their health goals, and want technology to be helpful and easy to use.
    • How does HL7 support objective 4b?
Mike will provide links to this document once it is publicly available.

AdjournmentMeeting adjourned at 4PM ET

Temporary Meeting Recording:



John Moehrke Co-Chair

HL7 Austria

Kathleen Connor  Co-Chair

VA (Book Zurman)
@Trish Williams Co-ChairFlinders University

Chris Shawn, Co-Chair


John Davis (Mike)


Julie Chan jchan@cwglobalconsult.comHL7 FHIR
VA (Book Zurman)
VA (Book Zurman)
@Adam Wong adam.wong@hhs.govHHS

@Ricky Sahu,  

1up Health
Wave One

EMR Direct
Laura Bright
Jim KamperAltarum
 PJM Consulting
 @David Staggs drs@securityrs.comSRS 
 Ready Computing
Terence Cunningham (Terry) AMA
Trustworthy EHR 
Laura Hoffman laura.hoffman@ama-assn.orgAMA
Heather McComas AMA 
Matthrew Reid matt.reid@ama-assn.orgAMA
Stephen MacVicar smacvicar@mitre.orgMITRE
Saul Kravitz saul@mitre.orgMITRE

Robert Dieterle

David Staggs drs@securityrs.comSRS
Carie Hammond carie.hammond@aegis.netAegis

  • No labels