IHE and HL7 are writing and revising Implementation Guides at a fervent rate. There are other organizations also writing and revising Implementation Guide, some are regional IHE or HL7 organizations, and many more.  Everyone that writes an Implementation Guide (IG) desires to create a perfect and fully comprehensive specification on the first try. However, that is simply not realistic, and any IG that has had only one version is most likely one that no one is using. Two very important standards organization mechanisms are critical to the achieving a perfect IG.  Clear indicati ..read more

AI and privacy are hot topics lately. I have effected some changes in HL7 as well as blog articles about those capabilities that exist. I am also a participant in a few AI initiatives in HL7 and within the VHA. These solutions are most well developed in FHIR, but are fundamental provenance, data tagging, and Consent so can work with most standardized data and datasets. The main topic areas in AI: 1) Can data be used to train an AI? Given that there are some data that should be authorized to be used to train an AI, how does one indicate rules that enables some data to be used, whil ..read more

 Updated Releases: PCC Occupational Data for Health (ODH) 1.0.0 Query for Existing Data for Mobile (QEDm) 3.0.0 ITI  normative Technical Framework - updated with approved CPs Add RESTful ATNA (Query and Feed) - updated with approved CPs Mobile Care Services Discovery (mCSD) - updated with approved CPs Scheduling (formerly published by Argonaut in STU3 flavor) - 1.0.0 Document Digital Signature JSON signature option Finance and Insurance Services Public Comment ITI Extensions to Document Metadata Subscription Formal Announcement PCC ITI first and second See all at h ..read more

I have had some conversations lately around a De-Identification Service, specifically if it is possible for a general service that could be used like Actors within IHE. The problem that I have historically came up with is that there is no standard for defining de-identification policy, that set of rules that would drive the de-identification process in a way that (a) protects against re-identification, and (b) provides sufficient detail in the resulting dataset for a (c) given purpose.  There are standards on the concept of De-Identification, and I have written articles on the process. Ke ..read more

As I work hard to enable a patient to express the privacy rules around how their health information can be used and by whom for what reasons; I hear that there is worry that an organization that honors those wishes by blocking the data for a given use, that this Organization may be seen as violating the regulations forbidding Information Blocking. In HTI-2 there is some discussion around some sensitive data that has been expressed as being a special case. However, this is just one kind of data that is or might be considered sensitive by a patient. My concern is wider than just the ONC HTI-2 ..read more

AI is the focus of the HL7 Workgroup Plus meeting this week. As I sit in on the presentations, I find that there are some efforts that the Security WG has already put in place that are not understood. So this article will expose some of the things that Security WG has already put in place to support AI. AI Output ProvenanceFirst up is that there is a concern that any diagnosis, notes, observations, or other content that is created by AI, or assisted by AI, should be tagged as such. With this provenance any downstream use of the data or decisions are informed that the data came from an AI outpu ..read more

Excited to announce that I'll be speaking at the HL7 FHIR Security Education Event on September 4-5! This virtual event is packed with insights and discussions tailored for everyone in the health IT community. Two Tracks to Choose From: General Track: Perfect for those looking to deepen their understanding of FHIR security without getting too technical. Developer Track: Designed for health IT architects, developers and engineers who want to dive into the details. Join me and other experts as we explore the latest in FHIR security. Don’t miss out on this opportunity to enhance your kno ..read more

ABAC: data has "attributes" (elements), that may be summarized into "sensitivity tags" (SLS) that are also attributes. Policies indicate "classifications" of data that indicate how data are to be protected based on some attributes (may be sensitivity tags, but can be any attributes). Policies indicate what "clearance" (aka roles) have access to each data "classification". Users are grouped into "clearances" (aka roles); this might be a FHIR PractitionerRole, CareTeam, RelatedPerson, and Group; but might be something non-FHIR (aka OAuth, LDAP, etc).      Thus:  user have ..read more

I am rather excited that I have been asked about FHIR Security Labels lately by people getting started at implementing. I have tried to find out who has implemented this, but it is a security/privacy topic and thus everyone wants to be covert about it. Thus, I can't tell how widely it has been implemented.  The concept is founded in Attribute Based Access Control (ABAC) that is a common IT access control standard that is especially important in data domains with sensitive information like healthcare, finance, military, etc. I would recommend looking at the generic ABAC details and implem ..read more

There is a FHIR leadership desire to have the FHIR Data Type "Signature" normative in FHIR R6. The ballots leading to FHIR R6 will give us a chance to test with the community their interest in this Data Type being ready to be called Normative. However so far to date it has not received much attention. The FHIR Signature Datatype is less concerning than all of Digital Signatures. That is to say that what would be declared normative in the FHIR Signature Datatype is the FHIR structure. The actual digital signature is a blob, that is ruled by other standards such as XML-Signature and JSON Signat ..read more