Privacy toolkit - W3C Privacy Assessment

This is a short article simply to point toward W3C "Specification Privacy Assessment". I watch many standards bodies, and interact with a few. W3C is most mature "Standards" organization with regards to considering privacy impact that their standards have. Others are working toward having some process for considering privacy while writing a standard specification. But the others are more aspirational, where W3C is 'doing it'.

The best introduction is a presentation. This is fantastic presentation, very detailed. I would love to present these slides as there is so much depth on each page.

They have a set of Questions that each W3C specification writing team must consider. These questions are not intended to short-circuit a real Privacy Impact, but rather to focus on some of the obvious top issues. Here is an excerpt:

• can the information be used (alone or in combination with other APIs / sources of information) to fingerprint a device or user?
• may I access to the information I created?
• may I record it myself (locally)?
• am I able to have actions on this personal record?
• may I block partly or totally the record of the information?
• may I fake it? (think about fuzzy geolocation or voluntary fake location)
• Is the data personally-derived, i.e. derived from the interaction of a single person, or their device or address? (If so, even if anonymous, it might be re-correlated)
• Does the data record contain elements that would enable such re-correlation? (examples include an IP address, and so on)
• What other data could this record be correlated with? (e.g. the ISP)
• If you had large amounts of this data about one person, what conclusions would it enable you to draw? (e.g. maybe you could estimate location from many ambient light events by estimating latitude and longitude from the times of sunrise and sunset)
• Am I likely to know if information is being collected?
• How visible is its collection and or use?
• Do I get feedback on the patterns that the information could reveal (at any instant, over time) so I can adjust behaviors?
• if a background event about the device is fired in all browsing contexts, does it allow correlation of a user across contexts?
• can code on a page send signals that can be received by device sensors on nearby devices?

You can see that W3C considers all of the Privacy Principles, not just confidentiality.

They also have defined some re-usable Privacy Considerations. Such as the "Web Applications Privacy Best Practices"

• Best Practice 1: Follow "Privacy By Design" principles
• Best Practice 2: Enable the user to make informed decisions about sharing their personal information with a service.
• Best Practice 3: Enable the user to make decisions at the appropriate time with the correct contextual information.
• Best Practice 4: When learning user privacy decisions and providing defaults, allow the user to easily view and change their previous decisions.
• Best Practice 5: Focus on usability and avoid needless prompting.
• Best Practice 6: Active consent should be freely given, for specific data, and be informed.
• Best Practice 7: Be clear and transparent to users regarding potential privacy concerns.
• Best Practice 8: Be clear as to whether information is needed on a one-time basis or is necessary for a period of time and for how long.
• Best Practice 9: Request the minimum number of data items at the minimum level of detail needed to provide a service.
• Best Practice 10: Retain the minimum amount of data at the minimum level of detail for the minimum amount of time needed. Consider potential misuses of retained data and possible countermeasures.
• Best Practice 11: Maintain the confidentiality of user data in transmission, for example using HTTPS for transport rather than HTTP.
• Best Practice 12: Maintain the confidentiality of user data in storage.
• Best Practice 13: Control and log access to data.

The "Device API Privacy Considerations". Which includes a nice breakdown of the Privacy Principles to those that impact Device design.

The "Mobile Web Application Best Practices". Which not just itemizes a fantastic set of Best Practices (cookie use, client storage, robustness, informing user, avoid redirects, etc...). But goes into detail on these best practices

    3.1 Application Data 

    3.2 Security and privacy 

    3.3 User Awareness and Control 

    3.4 Conservative use of resources 

    3.5 User Experience 

    3.6 Handling Variations in the Delivery Context 

    3.7 Further Considerations 

see also my articles 

• Security/Privacy Risk Assessment/Management
• Privacy Principles
• Privacy Consent Management

Clarification of Affinity Domains

The Question: I've worked with the XDS.b and XCA profiles for a few years now, but am no means an expert. I've never understood exactly what an affinity domain is. Could someone give an explanation of an affinity domain?

XDS Affinity Domain

Affinity Domain is more properly an "XDS Affinity Domain". The term is specific to XDS. It does not apply to XCA, as XCA uses the term "Community" in a rather similar but more expansive.

an XDS Affinity Domain -- derived from the word "affinity". Which among the many definitions has these -- These from Merriam-Webster definition for "affinity"

• sympathy marked by community of interest : 
• an attraction to or liking for something 
• people with an affinity to darkness — Mark Twain 
• pork and fennel have a natural affinity for each other — Abby Mandel
• an attractive force between substances or particles that causes them to enter into and remain in chemical combination
• a person especially of the opposite sex having a particular attraction for one

In the IHE Glossary

• A group of healthcare enterprises that have agreed to work together using a common set of policies and which share a common infrastructure of repositories and a registry.

Essentially it is a term we use in XDS to encompass all the actors, systems, technology, policy, procedure, people, and ether. A set of XDS Metadata codes that the Registry will enforce. A set of document types that are considered acceptable by the Affinity Domain. Agreement on how Authorization will be done, including Consent, Role-Based-Access-Control, and Break-Glass.

See section 10.4.8 of volume 1 "Concept of an XDS Affinity Domain"

An XDS Affinity Domain is an administrative structure made of a well-defined set of Document Source Actors, set of Document Repositories, set of Document Consumers organized around a single Document Registry Actor that have agreed to share clinical documents.

Note: Document Sources, Repositories and Consumers may belong to more than one XDS Affinity Domain and share the same or different documents. This is an implementation strategy and will not be further described.

Note: The XDS Profile does not support the federation of XDS Affinity Domains directly, but the Cross-Community Access (XCA) Profile addresses the cooperation of multiple Document Registry Actors serving different XDS Affinity Domains.

A number of policies will need to be established in an XDS Affinity Domain in order to ensure effective interoperability between Document Sources and Consumers. Some of the key technical policies include (A more extensive list of policy agreements that need to be made by XDS Affinity Domains is discussed in ITI TF-1: Appendix L):

1. The document formats that will be accepted for registration

2. The various vocabulary value sets and coding schemes to be used for the submission of metadata of document, submission set and folders registration.

3. The Patient Identification Domain (Assigning Authority) used by the Document Registry.

See ITI TF-1: Appendix K for a detailed discussion of the concepts of XDS Affinity Domain.

For which the Handbook on XDS Affinity Domain planning is important.

XCA Community

The difference between "XDS Affinity Domain" and the XCA "Community" is that IHE has much less to say about the requirements of a Community. There are cases where a Community is an XDS Affinity Domain; but XCA allows for many other forms of Community. Common variant of a Community is a large hospital system (like the VA where I now work). In those cases the Community is understood only as the stuff behind the XCA gateways. There is no mandate about code validation by a Registry, no mandate about use of ATNA, no mandate about use of CT, etc. There is no defined way to create registry entries. There is no requirement to support folders, associations, and extensions.

The additional difference is that a Community can contain other Communities. IHE is rather silent on this. This silence was driven more by the desire to get experience with nested communities, routing communities, proxy communities, etc. We have heard of some interest in resolving this, and I would encourage a new work item.

In the IHE Glossary

• A community is defined as a group of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing health information via an established mechanism. Membership of a facility/enterprise in one community does not preclude it from being a member in another community

Some more background articles

• Health Information Exchange: Centralized, Federated, or Distributed
• HIE using IHE
• Understanding XDS metadata - IHE re-documentation effort
• What is the benefit of an HIE
• and other HIE Topics

Consent to deny Sharing for Treatment and Emergency Break-Glass

We have discussed in years past that Australia had a Privacy Consent where break-glass was not allowed. We understand that has changed to allow break-glass. Thus we didn't know of a case where a Consent forbid break-glass... I have been made aware of Utah HIE that has a checkbox on their Consent to forbid break-glass. This is a consent only for HIE, not for within a hospital environment; but it is relevant to our FHIR consent (and CDA consent) work. Thus I think it is useful for us to provide it as an example, and work through how it might be expressed.

The Utah HIE Consent Form is
https://uhin.org/wp-content/uploads/2017/01/cHIE_Patient_Participation_Form.pdf

Note, that in the context of a FHIR consent; this URL could be used as the Policy URI...  It is a general form that the Patient has some check boxes they can choose.

So given that we have an example that forbids Treatment but allows Break-Glass  (Note spell check needed)    http://build.fhir.org/consent-example-Emergency.html

We should likely create an example that forbids both Treatment and Emergency (Break-Glass). Something like this:

<Consent xmlns="http://hl7.org/fhir">  <id value="consent-example-No-Emergency"/> 
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>   Withhold Authorization for Treatment and for Emergency Treatment  </p> <p>     
Patient &quot;P. van de Heuvel&quot; wishes to have no data shared for Treatment or Emergency treatment use.   
An overall consent Directive, with an exception 
&quot;Deny&quot; of purposeOfUse &quot;TREAT&quot; sharing use and
&quot;Deny&quot; of purposeOfUse &quot;ETREAT&quot; sharing use
at &quot;Infoway&quot; HIE.   </p>
</div>
</text> 
<status value="active"/>
<category>
    <coding>
   <system value="http://loinc.org"/>
<code value="57016-8"/>
<display value="Privacy policy acknowledgement Document"/>
</coding>
</category>
<patient>
<reference value="Patient/f001"/>
<display value="P. van de Heuvel"/>
</patient> 
<dateTime value="2017-05-08"/>
<!--   not bound by a timeframe - Consent.period   -->
<!--   I assume the example given is Canada Infoway wide???  AND I assume it is desired to   state that in the Consent.authority element   -->
<organization>
<reference value="Organization/Infoway"/>
<display value="Canada Infoway"/>
</organization>
<!--   the text terms of the consent in lawyer speak   -->
<sourceAttachment>
<title value="The terms of the consent in lawyer speak."/>
<!--   likely use url pointer to common text   -->
</sourceAttachment> 
<!--       this is opt-out - e.g. nothing approved unless otherwise stated.    -->
<policyRule value="https://uhin.org/wp-content/uploads/2017/01/cHIE_Patient_Participation_Form.pdf"/> 
<!-- this policyRule is a multiple use policy. The Patient has expressed       both deny Treatment and deny Emergency  -->
<except>
<type value="deny"/>
<purpose>
<system value="http://hl7.org/fhir/v3/ActReason"/>
<code value="TREAT"/>
</purpose>
</except>
<except>
<type value="deny"/>
<purpose>
<system value="http://hl7.org/fhir/v3/ActReason"/>
<code value="ETREAT"/>
</purpose>
</except>
</Consent> 

I have filed a FHIR Change Request 13420

Other Privacy Consent topics 

Corrected the example to make more clear it is a "Privacy Consent" by specifying the Consent.category.

Two new IHE Profiles on #FHIR - Provider Directory and File Management

Public Comment opens for Provider Directory and File Manager --- both using FHIR STU3

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment The IHE IT Infrastructure Technical Committee has published the following supplements to the IHE IT Infrastructure Technical Framework for public comment in the period from May 17 through June 16, 2017: Mobile Care Services Discovery (mCSD) Non-patient File Sharing (NPFS) The documents are available for download at http://ihe.net/Public_Comment. Comments submitted by June 16, 2017 will be considered by the IHE IT Infrastructure Technical Committee in developing the trial implementation version of the supplements. Comments can be submitted at IT Infrastructure Public Comments.

FHIR OAuth scope proposal using FHIR query parameters

In FHIR STU3 there are now some common query parameters. I propose that these common query parameters can be used to advance the OAuth scopes that are defined today. The current SMART scopes are based on simple vectors:

1. Patient vs 'user' -- 
1. Where a scope of 'patient' means all results must be from that one patient
2. Where scope of 'user' means all results are relative to that user rights to data
2. fhir-resource --
1. Where a FHIR Resource named will limit results to only that Resource type
2. This is a valueset of fixed strings (e.g. "Observation", etc)
3. REST operation

Expressed in EBNF notation, the clinical scope syntax is:

clinical-scope ::= ( 'patient' | 'user' ) '/' ( fhir-resource | '*' ) '.' ( 'read' | 'write' | '*' )

To understand the current OAuth scope see a few other articles:

• SMART specification - Scopes and Launch Context
• David Hay - SMART - Scopes and Profiles
• My - alternatives to SMART scopes - FHIR Scopes
• My - Healthcare access control scope constraints on OAuth tokens

So, if the OAuth authority authorizes the user to access the patient requested, as defined in the launch context, for only Observations, and only read operations. This would be a scope of

patient/Observation.read

A problem with this is that the actual identifier of the "Patient" is undefined. For SMART this is handled by the 'launch context'.

Propose using common "patient" query parameter for patient scope

With the new FHIR STU3 common shared query parameters, we could identify the specific patient within the Scope. There is a common query parameter for "patient" against 35 different Resources. This has an advantage to be specific, but has a disadvantage that the scopes are not made up of static strings. I would like to suggest that this use of shared query parameters would be a replacement form the first part of the SMART scopes.

So, rather than relying on the SMART launch context to hold the patient identifier. The example with a patient of 'http://myserver.example/fhir/Patient/f5c7395'

patient="http://myserver.example/fhir/Patient/f5c7395"/Observation.read

or, we could add it to the end.  I think this more powerful.

Observation.read#patient="http://myserver.example/fhir/Patient/f5c7395"

Which is 

clinical-scope ::= ( fhir-resource | '*' ) '.' ( 'read' | 'write' | '*' ) '#' ( query | '*')

I a proposing this without working out all the issues. I just want the scope to include the patient. 

Scope is Not Query parameters

This is NOT a proposal to force these query parameters and trust server search capability. This might be one thing done to make it efficient, but won't work perfectly as not all. The use of search parameters will just help with positive matches; but will not be perfect against false-positives or false-negatives. It will also fail when the other parts of the query are creatively authored to cause the wrong thing to happen.

The scope does need to be ENFORCED. The Resource server is expected to enforce the scope without fail. This is what I mean by more than just query. Most important is inspecting the resulting Bundle to assure that no content is contained in the Bundle that doesn't fit within the Scope.

More common query parameters

Some of the other common search parameters that might be useful:

• _id -- when the scope is restricted to exactly ONE resource
• _tag -- when the scope is restricted generally to some tag
• _profile -- when the scope is restricted to some specific _profile tag
• _security -- when the scope is restricted to some vocabulary from the HCS (e.g. confidentiality of "N" normal)
• encounter -- when the scope is restricted to a specified encounter

Clearly missing but needed

There are some important vectors in Privacy space that are missing:

• Timeframe for when the data was created - used to hide timeframe or enable a timeframe
• Authored by - used when policy allows only data authored by some org or user

Note, scope is not everything. Where the user is forbidden, they get no authorization at all.

Also, I don't propose how to use negative scopes. Such as this user (Provider) can see any data but not patient Mary.

Not Done Yet

This is not a final solution. I am just putting this out there for discussion. Simply to bring up options for discussion on how to make improvements to Scope. The unfortunate facts of healthcare is that the needs for scope is a complex of multiple vectors; and failure is severe when not appropriately protected or when not appropriately available. Both false positive and false negative can have severe effects.

See my other FHIR articles

IHE ITI on FHIR

IHE ITI has a set of profiles on FHIR existing in Trial Implementation today. These were written against FHIR DSTU2. These have been updated to STU3, now in ballot for members of the ITI Technical Committee to comment and vote on.  Details and access to the ballot drafts of these documents is available from the ballot.

• Mobile access to Health Documents (MHD) 
• DocumentReference, DocumentManifest, List, Patient, Practitioner, Binary, OperationOutcome, Bundle
• Using FHIR FMM 1-5
• Also added some options to recognize XDS-on-FHIR
• Mobile Alert Communication Management (mACM)
• CommunicationRequest, Communication, OperationOutcome, Bundle
• Using FHIR FMM 2-5
• Patient Demographics Query for Mobile (PDQm)
• Patient, OperationOutcome, Bundle
• Using FHIR FMM 5
• Patient Identifier Cross-Reference for Mobile (PIXm)
• operations, Parameters, OperationOutcome, Bundle
• Using FHIR FMM 5
• Add RESTful Query to ATNA
• AuditEvent, OperationOutcome, Bundle
• Using FHIR FMM 3-5
• Appendix Z on HL7 FHIR
• Various reusable guidance and specification
• Mobile Security Considerations

The IHE ITI Technical Committee is also working on new profiles using FHIR. These will be further discussed in later articles.

• Mobile Care Services Discovery (mCSD)
• Including Healthcare Provider Directory (HPD) capability
• Organization, Location, Practitioner, PractitionerRole,  HealthcareServices, Binary, OperationOutcome, Bundle
• Non-Patient File Sharing (NPFS)
• Sharing and Management of Files that are not associated with a patient
• For example: Stylesheets, configuration, policy definitions, workflow definitions
• DocumentReference, Binary, OperationOutcome, Bundle
• Access to Document-extracted Data-elements (ADD) 
• Formerly: Patient Centric Element Location
• This is a profile that combines XDS/MHD and QEDm to describe how a Document Sharing environment can provide more fine grain access (Resource) to data shared as documents. 
• This profile does rely on creative systems engineering to decompose the documents into the FHIR resources. This might leverage CDA-on-FHIR, or some other methodology. This methodology is not specified.
• What is specified is that the fine grain details must have Provenance pointing at the Documents from which the data came. This enables a consumer to retrieve using XDS or MHD the document from which the fine grain details came from.

The IHE ITI and PCC are working jointly on one as well:

• Query or Existing Data for mobile (QEDm)
• supporting Resource level access such as allergies, problems, medications, etc
• Observation;  AllergyIntolerance;  Condition (Problem);  Procedure;  Encounter;  DiagnosticReport;  MedicationRequest;  MedicationStatement;  Medication;  Immunization
• Provenance, OperationOutcome, Bundle

IHE ITI is also working on one non FHIR Profile

• Remove Metadata and Document (RMD)
• This is a profile on XDS for administrative ability to remove metadata entries and remove documents

Lastly IHE Document Digital Signature (DSG) Profile approved for Final Text