API Security conference -- on #FHIR

Updated April 7, 2022: Here are the slides I presented.

Join me at my presentations at #APISecure2022 where I will be surrounded by far smarter people on API security. This is a virtual event, so you should certainly be able to sign up.

 so, there is going to be just a little bit about #FHIR:

1. On Wednesday I will be on a panel with Alissa and Grahame - The State of FHIR API Security in Healthcare
2. On Thursday Grahame will be speaking - Securing FHIR APIs in Healthcare
3. After Grahame I will be speaking - Designing and Implementing a FHIR API Security Plan

BUT the more important is ALL the other sessions. Protecting a FHIR API starts with fundamentals of protecting an API. So please secure your #FHIR API and Apps. Start with good API Security fundamentals.

Quick video on IHE Privacy and Security

 IHE just published a short video by me on the IHE Privacy and Security solutions.

The key slide page 3

YouTube video hosted on IHE International Channel

Links:

• IHE  IT Infrastructure
• Whitepapers and Handbooks
• Cookbook: Preparing the IHE Profile Security Section 
• De-Identification Handbook 
  • Algorithm Mapping Spreadsheet 
• Document Sharing Metadata Handbook
• Template for XDS Affinity Domain Deployment Planning 
• Access Control 
• Enabling Document Sharing Health Information Exchange Using IHE Profiles 
• Security and Privacy Solutions: Handbooks, Profiles, and Content
• Implementation Guides / Profiles
• Mobile Health Document Sharing (MHDS) TI 
• Consistent Time (CT)
• Audit Trail and Node Authentication (ATNA) Profile
• Cross Enterprise User Assertion (XUA)
• Internet User Authorization (IUA) TI 
• Basic Patient Privacy Consents (BPPC)
• Advanced Patient Privacy Consents (APPC) TI
• Secure Retrieve (SeR) TI 
• Document Digital Signature (DSG)
• Document Encryption (DEN) TI
• Basic Audit TI 

Updated to add key cross-reference matrix slide as image.

Ask, just ask

I am short on ideas of topics that I should elaborate on in a blog article. So, I remind you all that if you thing of a topic that you think I might be able to clarify, please let me know. It costs you nothing. I might not even answer. But I certainly am not going to address the topic if you don't ask.

I look at and respond to Comments anywhere on my blog, but I recognize that some don't like google's requirement for google account. Thus you can also send me a question to my gmail address which simply is my name - JohnMoehrke

The rules are simple:

• Topics I'll cover include anything in my banner specific to Healthcare Interoperability Standards  
• Health Information Exchange, 
• Document Exchange 
• XDS/XCA/MHD, 
• mHealth, 
• Patient Identity, 
• Provider Directories, 
• FHIR, 
• Consent, 
• Access Control, 
• Audit Control, 
• Accounting of Disclosures, 
• User Identity, 
• Authorization, 
• Authentication, 
• Encryption, 
• Digital Signatures, 
• Transport/Media Security, 
• De-Identification, Pseudonymization, Anonymization, and 
• Blockchain.
• All questions and suggestions posted are subject to this Blog's Policies.
• If I don't know or cannot otherwise answer your question, I'll let you know.
• Questions are not necessarily answered or addressed in the order received.

IHE Basic Audit Implementation Guide

Updated May 4th, 2022 -- Trial Implementation released. The Implementation Guide is now named Basic Audit Log Patterns (BALP) Version 1.1.0.

Supporting Privacy Principles to give transparency to how a Patients data are used is one of the goals of a new Implementation Guide from IHE. The AuditEvent profiles in this guide can also be used for Security purposes.

The Basic Audit Log Pattern (BasicAudit) Content Profile defines some basic and reusable AuditEvent patterns. Defining formally an Audit Creator and an Audit Consumer actors (similar to how IHE has Content Creator and Content Consumer in the Document space).

The Audit Log Patterns defined here rely on the ATNA Profile for transport of the AuditEvent and query/retrieval of AuditEvents previously recorded. The patterns defined here may be used as they are, or further refined to specific use-cases. Where a more specific audit event is defined, it should be derived off of these basic patterns. Thus a more specific AuditEvent would be compliant with one or more of the AuditEvent patterns defined here.

This implementation guide is intended to be fully compliant with the HL7

FHIR specification, providing only use-case driven constraints to aid with interoperability, deterministic results, and compatibility with ATNA and other IHE Profiles.

This Implementation Guide is not about the "ANY request/response", this is about what should be put into an AuditEvent record that "auditable event" happened.

Specifically, there are a set of patterns (profiles) defined for the AuditEvent content that should be recorded when any of the following happens:

• RESTful activities 
• Create
• Read
• Update
• Delete
• Search/Query
• SAML Security Token used
• OAuth Security Token used
• Consent Authorized Decision Audit Message
• Privacy Disclosure Audit Message

IHE IT-Infrastructure - March 2022

IHE IT-Infrastructure committee has been very busy this winter quarter. Today we release updates to 9 different publications:

New Publication

•  mCSD 3.5.0 - conversion from PDF to IG Publisher
•  MHDS 2.3.0 - conversion from PDF to IG Publisher
•  Metadata Handbook 2.1 - conversion from PDF to markdown/html

Minor/Patch update publications

•  MHD 4.1.0 - minor updates
•  PDQm 2.4.0 - minor updates to fix bugs, id, and canonical uri
•  PIXm 3.0.2 - patch update to fix id
•  FormatCode 1.1.0 - minor updates to Rad, and canonical URI

Public Comment

•  Basic Audit 1.0.1 
•  mCSD 3.6.1 - updates to support MHD-to-a-Federation work item

Also

• ITI Technical Framework - patch to typos
• addition of above Basic Audit IG
• PCC index fixes
• experimental RSS feed for new FHIR releases

Find all of this at https://profiles.ihe.net

How to comment?

• Each Implementation guide has IG specific links in the footer of each page
• "New Issue" will take you to a github issue entry form, with the proper template for commenting (this requires a github account)
• "Issues" will take you to the known issues, to confirm that the issue you noticed has been reported already.
• "Propose a change" is a web form for those that don't have github accounts