A Moment of Silence

There's no award I could give that would fully recognize the contribution of Bill Majurski to the Cross Enterprise Document Sharing community.  That won't stop me from offering what surely is not enough, but my own recognition none-the-less.

Bill's favorite expression at IHE meetings discussing Cross Enterprise Document Sharing (XDS) was "I'm with the government, and I'm here to help you."  And he was, and he did.

XDS would not be the foundation our US national infrastructure today if it were not for Bill.  But even more so, it would not be the foundation of national and regional infrastructures around the world.  Bill and his team built the first XDS registry/repository system used for testing XDS in the first year, the first open source reference implementation, and for the next 15 years, Bill and his tools and teams were there supporting implementers at every IHE Connectathon to follow.

Sadly, as most of you already know, Bill won't be attending any more Connectathons except via TCP/IP over heavenly ether.  I've been hearing Bill's voice in my head as I have code exchanges using XDS and related specifications ... "That's not going to work...", "What I think we need to do is ...", and "Did you check to see if you ...".  I'll still be hearing it for the next 15 years.

I used to joke about the father and mother of XDS, and Bill was always "the mailman" (i.e., the true father).  But that joke doesn't seem right somehow.  Bill was more like the adoptive father, who nurtured, fertilized, pruned and cared for that initial seed, and let it grow into the mighty tree that it is, and from it which has now grown a tremendous forest enabling interoperability through the original specification, and many revisions and derivative works thereafter.

And forest is an apt description, as Bill was an avid fan of nature, of biking (the pedal kind), of hiking, and camping, and sharing that experience with the scouts he supported.

EVERY, and I mean EVERY interoperable exchange of a CDA document using nationally recognized standards in the US, and in dozens of other countries works in part because of something Bill did, or continued to do for 15 years afterwards.  If there were a national medal of honor for interoperability, it should go to Bill.  If there were an international recognition of the same esteem, it should go to Bill.

I don't have that capacity, I can only make him a Lord of the Ad Hoc Harley, but he always was one, and all I'm doing now is documenting it.  

He is hereby inducted into the 2003 Class of the Lords and Ladies of the Ad Hoc Harley, the year that the XDS Registry was invented by Bill.

Bill Majurski

Semper et semper ascendens deinceps

(ever and ever riding forward)

Data Blocking and Public Health Access through FHIR APIs

 A lot of EHR systems to date have established mechanisms to enable access to patient data via APIs, but there's one challenge that comes to the fore in working through these APIs in the context of accessing data for Public Health.

Many public health operations work with populations ... patients having a reportable condition, patients with COVID, patients with fill in the blank.

And many FHIR connectivity solutions presume that the "App" is going to be integrated via a Provider or Patient directed solution, launched by the EHR or as a standalone application, and will access data ONE patient at a time, and that patient will be known.

This is not so for some public health uses.  For those uses, the app is likely a "Back End Service", the user is likely a system, not a person, and there may not be a provider or patient context to identify what information the system should have access to.  FHIR Bulk data is a pretty good example for this kind of use, where a payer wants to collect information in bulk about patients it is concerned with (their panel of covered lives).  Public health also has such a panel, but not necessarily unique identifiers associated with the populations they are concerned with.  It may instead be a set of characteristics: Patients who are living in, or have been treated in, their jurisdiction.

And so, we see a conflict.  The current APIs attempt to ensure that patient data is not intermingled during API access (hey, this is not just a commonly done thing, it's also a common sense rule to ensure patient safety).  BUT, there needs to be a way to identify and collect data via APIs that allows public health to perform its duties.

Most of the Information Blocking Provisions are written with HIPAA as the context.  HIPAA identifies a few significant organizations: Covered Entities, Individuals (patients), Public Health, the courts and State/Federal government, to grant them specific rights or responsibilities.  Public Health generally isn't a covered Entity (in most cases, we'll leave the specific case of local public health providing treatment services out of this discussion -- which they often do).

And so where does Public Health fit with regard to Information Blocking?  Can a Provider organization, Health information network, or certified developer of Health IT information claim under the exceptions listed in 45 CFR 171 that there's a legitimate patient safety, privacy, security, feasiblility or performancee need to prevent public health access from asking the question in simplest FHIR form: Show me all observations where code is in the list of COVID-19 testing results AND date is today, and result is positive?

I think this question is quite debatable, and I've seen both sides of this coin.  I KNOW what my answer as an EHR Vendor was, is, and ever would be should I find myself in that role again, and that is NO.  EHR systems CAN provide that access, some vendors have done so, and I would do so again. BUT, if an EHR vendor doesn't plan for, design for, and account for this need, public health with have to sit in its usual place at the back of the line, before they can get access to critical data to do their jobs.

   Keith

For what it's worth, I know every EHR has a way to provide access to population data from outside of FHIR APIs.  Arguably, if there is a way to do this safely, feasibly, and securely outside of FHIR, then it can be done using FHIR as well.

Programming Models, Validation and "Continuable" Errors

In writing software, there are two models for validating inputs.

• Fail on First Error
• Report All Errors

The first model assumes that an invalid input should halt processing, and be handled by some sort of error handling routine.  The second model assumes that it's better to continue, finding and reporting as many errors as possible to enable correction of all errors.

The first model is completely applicable in production environments, and is supported in programming language constructs by throwing and catching exceptions.  

The second model is applicable when performing validation testing, and enables reporting of not just the first, but all applicable errors found.  The FHIR OperationOutcome resource supports this model of error reporting.

Ancient software source code compilers USED to work the first way, but modern ones report as many errors as they can to enable software developers to correct as many of these errors as they can before trying again.

It makes me wonder if there shouldn't be a programming language construct to support the queuing of exceptions in some way.  

If I go back to modern compilers, and think about how they are able to continue, there's an error handling component that 

a) flags that an error has occurred to ensure that executable code isn't generated (at least at the location of the error ... the Java debugger can still execute classes and methods that contain compile errors in it), and 

b) "corrects" the input making reasonable assumptions to enable continuation of compilation.

Some things to consider in the construction of a construct to handle continuable errors:

1. What are the boundaries for queuing and reporting of such a "continuable" error and how would these be set in a software application?
2. What should happen if some OTHER error was detected that may have been a result of a continuable error?
3. How would you ensure that software could continue to run after it detected one of these "continuable" errors.

I don't have an idea about how this would look, I'm just thinking about how it would make some jobs easier.

     Keith