clair054

I blogged half as many articles as last year, and yet my readership only dropped by 16%. I am amazed at all you loyal readers. I wish I had more than 28 blog articles this year to give you. Falling mostly in the category of FHIR, Consent/AccessControl, or De-Identification. I hope that they were useful. Thanks. FHIR Break-Glass on FHIR solution Break-Glass on FHIR HEART profiles for review, comment, and approval Building a MHD Client before MHD is DSTU2 aligned IHE updating FHIR Profiles to align with DSTU2 FHIR Security initiatives FHIR does not need a deidentify=true parameter What is MHD beyond XDS-on-FHIR? Searching for an ATNA Audit Record Repository MHD Connectathon Results FHIR Security: Do (Not) Worry FYI: Update on the creation of Joint workgroup between #IHE and #HL7 including #FHIR topics IHE MHD and DSG now open for Public Comment Consent & Access Control Guest Post: Use-Case - Security Audit Prompts Investigation Don't disassemble ATNA, what you are lo...

I explain the use-case and environment behind Break-Glass on FHIR. In there I explain that it is unusual to need Break-Glass, but that it is still an important capability in healthcare.  In this article I will outline a few solutions that exist, and hint at some other solutions. This solution is based on a Client/Server relationship where the security subsystem is managing Access Control between the Client and the Server.. This diagram and definitions from the FHIR specification  Where: The consumer that is using a healthcare related system The client application the user is using (application, mobile app, website, etc.) The security system (authentication and access control) The clinical/healthcare repository Notify that Break-Glass 'could' be used. This is not specifically necessary, as a user/system could always indicate that Break-Glass is being invoked. If it is not authorized, then this request would be rejected. If it is authorized by no new information then nothing mo...

Break-Glass is the term used for an exceptional case where a treating clinician is allowed to see information that the patient has asked be blinded. Recognize that break-glass is not an universally accepted use-case. Break-glass is specific to protecting safety of the patient or care-giver during treatment. The first condition that leads to break-glass is that the Patient is given the ability to restrict access to some or all of their data for ‘treatment’ use-cases (PurposeOfUse==Treatment), and that patient has authorized ‘break-glass’. We clearly want to enable this use-case, and it is part of our current Privacy Consent Directive IG. http://hl7-fhir.github.io/pcd/pcd.html (A work in progress, http://wiki.hl7.org/index.php?title=HL7_FHIR_Consent_Directive_Project . Note we are not limiting ourselves to treatment Privacy Consent, just haven’t gotten that far yet). The patient might have included in their “Consent” clauses that restrict this authorization (only specific individuals...

 A project I participated in inside IHE applying the de-Identification handbook I helped create. Very important prototyping of this concept to an important topic. Many lessons learned and need to be learned wider. Checkout other blog posts I have on De-Identification 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  December 14, 2015 through February 5, 2016 : De-Identification for Family Planning (De-ID for FP) Re-documentation Document Sharing Profiles Edition The documents are available for download at  http://www.ihe.net/Public_Comment/ . Comments submitted by  February 5, 2016 will be considered by the IHE IT Infrastructure Technical Committee in developing the trial implementation versions of the supplements. Comments can be submit...