Transparent Health Blog

Conveying Identity and Authenticator Assurance Levels in OpenID Connect and Beyond in Healthcare 1. Standards and the Proposed Rule NIST's Special Publication 800-63-3 Digital Identity Guidelines outlines 3 identity assurance levels, "1", "2", and "3" to codify how well a person is or isn't, with 1 being a low confidence a person is who they say they are.  Similarly, Authentication Assurance Levels (AALs) of "1", "2", and 3" are also defined in NIST guidelines.  IAL details the  "login" or Authentication event. In ONC's proposed rule, " 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program ", OpenID Connect is proposed in the following passage:   To enable and support persistent user authentication and app authorization processes, we propose to adopt a standards and additional implementation specification for the FHIR standard. First, w

Fun Fact:  Did you know that congress actually has a gag order preventing Health and Human Services(HHS) from even discussing the idea of a national health identifier?  Well fear no more... word on the street is that this might finally change . America's multi-payer system is already complex enough. We also have to contend with a lack of a national health identifier?  Certainly national health identifiers have issues, but it is still a monumental step in the right direction.  While a national patient identifier will not fully solve the patient linking and matching problem, it will go quite a long way in improving the status quo.  I've spent way too much time thinking about how such an identifier should be constructed and issued.  Here are some main points: It should be numeric so it is easy to enter via a number pad/telephone. It should, in-part, be defined by the end user.  For example the first 10 digits could be someone's phone number It should contain a check d

HealthCa.mp/dev   Location:   AcademyHealth (1666 K Street NW, Ste. 1100, Washington, D.C.)   Dare and Time:  March 26  9:00 a.m. – 5:00 p.m. ET Cost:   $50 As Application Programming Interfaces proliferate across the industry, we still face challenges for consumers, data holders and application developers. How can API endpoints be discovered? How can consumers have confidence in applications that are receiving their health data? How can data holders know which applications to trust? How can we address all of these challenges without limiting choice for consumers?   HealthCa.mp/dev is hosting a pre-Palooza un-conference that will examine and brainstorm these issues and discuss standard approaches to addressing the challenges in a way that can unleash innovation that will enable an accelerated adoption and use of APIs for health data. If you are an application developer producing consumer-facing health apps, or if you are a data holder needing to provide an API for con

Naming things is hard.  Sometimes technologies are given more than one name.  Such is the case with FHIR Bulk Data.  This article is written to explain FHIR Bulk Data at a high level and why it is sometimes called "Flat FHIR". The FHIR Bulk Data is a draft specification for accessing (you guessed it) FHIR data in bulk.  Unlike regular FHIR, Bulk Data is an asynchronous exchange built atop HTTP.  Some situations where this paradigm may be useful include: When results are very large such as population-level queries. When results are not immediately available and need to be compiled.  HTTP servers and clients usually time out in a minute or two, so any query taking longer than thirty seconds should consider this asynchronous approach. FHIR Bulk Data responses can represent a population and can therefore be very large. After the initial request is made, an immediate response is returned to the client including the target URL in the response body. The target URL is where

Over the past few years, I've begun or contributed to a number of open source projects.  These have mostly been centered around health technology while supporting the Unites States federal government agencies such as CMS ,  HHS , and NIST . TransparentHealth.org and https://github.com/TransparentHealth were first created as a place to consolidate these open source projects into one place.  Other people seemed to like the idea.  Not only is open source software a good idea, but so is the adoption of open standards.  We made facilitating the adoption of standards a priority as well. To ensure the long term maintenance of these projects and goals it became increasingly apparent that software foundation was needed. Hence Transparent Health was created. In April of 2018, Transparent health became a non-profit organization.  The directors of the organization are Mark Scrimshire , and myself .  Other people are helping out too. We are just getting started! We encourage your cod

Transparent Health received tax exempt status from the IRS making it a 501(c)3 non-profit organization. We look forward to expanding our role as custodians of open source projects that benefit health care consumers.