clair054

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 t...

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 se...

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-exam...

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

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: Patient vs 'user' --  Where a scope of 'patient' means all results must be from that one patient Where scope of 'user' means all results are relative to that user rights to data fhir-resource -- Where a FHIR Resource named will limit results to only that Resource type This is a valueset of fixed strings (e.g. "Observation", etc) 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 SM...

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 Ap...