Digital Transformation is not computerizing paper forms

This is very related to what we are trying to accomplish with CREDS, and so is sort of a followup to my previous post on CREDS, but is more broadly scoped.

It starts here with this tweet, but not really.  It actually starts with all of the work that people have had to do to mediate between the data in the EHR, and measurement of what that data actually means.

It boils down simply to how one asks questions in order to perform a measurement.

In the early days of quality measurement and/or registry reporting, it was not uncommon to see questions like this:

• Does this patient qualify for XYZ treatment?
• Has the patient been prescribed/given XYZ treatment?
• Is XYZ treatment contraindicated and/or refused?

And, the reporting formats be structured in Yes/No form in some sort of XML or other format.

It's gotten to the point that some of these questions and their possible answers have been encoded in LOINC.  Now, when used for a survey or assessment instrument, that use is fine.  

But for most registry reporting or quality measurement activities, this should really be handled in a different fashion.  This is a start, and can be written in Clinical Quality Language format, or even more simply in a FHIRPath Expression.

• Does this patient have any of the [XYZ Indications ValueSet]?
• Has this patient been prescribed/given [XYZ Treatment ValueSet]?
• Does this patient have [XYZ Treatment Contraindications ValueSet]?

The theme in this restructuring is: Ask the provider what they know and did, and define the logic to compute it.  But even better is to ask the provider what they know and did (and recorded), and have the quality measure reviewer actually do the compute on the quality measure.

Apply normal workflows to keep track of what is learned and done; these shouldn't be interrupted.  I can recall a case where normal workflow added a checkbox to an EHR screen just to get a clinician to acknowledge that they had reviewed and/or reconciled the medication list.

Building these value sets and the logic to evaluate them is hard.  Doing it so that it is interoperable across systems is also hard.  But honestly, the cost per provider to do this is so much less to do it once and do it well, than it is to have hundreds or thousands of systems all need to do this is much more costly, and likely to introduce differences in the compute, and variability in the reported values.

Stop asking for the answers, start asking for the existing evidence to get the answers you need consistently.  And if you cannot get the existing evidence, ask yourself why before asking that it be added to the normal workflow.

   Keith

How Does CREDS work?

I'm getting back to some standards writing, this time on the CREDS project.  In case you haven't heard of this one, the (b)acronym decodes to Clinical Registry Extraction and Data Submission.  The challenge that CREDS is looking to solve for Clinical Registries is a very common one.  Data needs to be collected from clinical records, packaged up, and then be sent somewhere.

There are three key questions that any implementer has to answer in this kind of effort.

1. What data?
2. Where is it sent?
3. How is it formatted?

In this post, I'm going to be focused on the first question.  The next two will vary by registry, but we can generally express the answers to 2 as "To the registry that is asking for it", and in this case, CREDS is a FHIR IG, so the answer to 3 is FHIR, but it's also a little bit more complicated than that.

What Data?

The what question comes in several parts:

1. Who has it?
2. In what (standardized we hope) form or forms can it be found?
3. How do we find it?

Answers to the first question for clinical registry reporters include:

• My EHR System
• My Old EHR System
• My Laboratory Information System
• My Radiology or Imaging information system (RIS or PACS)
• An ambulance (not ambulatory) information system.  Yes, you might have to dig through transport records in a standardized format.
• The patient's primary care or specialty provider (in their EHR, RIS, or PACS)
• In a third party's information system
• Through an HIE
• Through some form of national data exchange network
• The patient's payer (typically an insurer, or a state or nationally funded program).

The second question can varyingly be answered as:

• FHIR, and if so, problem solved
                                          ^ (nearly, more on this later)
• CDA
• HL7 Version 2
• DICOM
• NCPDP
• X12
• or various others, and finally
• the worst case Digital paper ... e-mail, pdf, printed text reports -- which I'm going to take a hard pass on for this blog post.

The third question (how do we find it in the data) is not quite so simple, and yet has one answer, at least for CREDS, and is the key to how CREDS works.  You see, CREDS relies not just on FHIR, but also FHIRPath.  FHIRPath is a declarative programming language that allows one to express a pointer to one or more pieces of data in a data model, or perform a computation based that data, or answer a yes or no question about it. It originated as a way to point into FHIR Resources to express things like the location of search parameters, or constraints on a refined model (a profile of a FHIR Resource) that must be met for a resource to comply with the profile.  For those that have been around for a while, you can see that FHIRPath looks very much like XPath, and for some constrained versions of FHIRPath, there are some very simple transformations from FHIRPath to XPath expressions.

I've been working with XPath (and XSLT which relies very heavily on it as a transformation language) before it was a W3C Standard, while it was being invented, with the inventors working in cubicles or offices right next to my own.  You can do just about anything with XPath that you can in any other programming language, though I'm not quite sure you'd necessarily want to. It takes a twisted brain to think in declarative form.  It takes a bit less twisting in FHIRPath because the creators of that language had similar experiences and already had some ideas about what worked and what doesn't.

But declarative has its own value.  The point of a declarative program is not in specifying how to get the answer in stepwise form, but rather to define what you want the outcome to be, and let the system decide how to get there.  The value add of the system is in defining how how to perform these operations efficiently.  Programmers use systems like this all of the time.  Consider SQL (also primarily a declarative language, though it has some procedural elements).

CREDS says that a registry defines a logical model describing its data, and that logical model is made available to users of the CREDS IG via an information system.  This may be nothing more than an excel spreadsheet with element names and data types, or it might be an entity relationship model expressed in a variety of standard forms.  Since CREDS is using FHIR, CREDS requires that these logical models be expressed in a FHIR format.  For that, we have the FHIR StructureDefinition.  Yes, the same creature that defines the logical model for FHIR Resources and extensions and FHIR Datatypes is also used to define logical models.  If you want to find a logical model for a registry, you have more than 2 dozen search parameters on StructureDefinition you can use to find it.

FHIRPath, interestingly enough, also is designed to work with logical models, although it is principally intended for use with FHIR, it is NOT limited to that model.  I'll show why that's important in just a bit.

Each element in a FHIR logical model (StructureDefinition resource) can be mapped to one or more other standard formats. The language in which this mapping is expressed is left unrestricted in the base FHIR Standard, though it should have a mime type (which is defined by FHIR to be text/fhirpath [and is recognized by IANA as such).  CREDS says that you must use FHIRPath in your mappings.  Why?  Because with those mappings, you can now locate the actual data element in the mapped to standard that reflects the intent of the author of the definition for the registry data model ... in a computable manner.

Furthermore, to successfully use CREDS, the mapping identifiers used in the StructureDefinition resource for the logical model must also be bound to a separate logical model that describes the mapped-to standard.  And that logical must be defined using StructureDefinition resources.  This is important because it makes it possible to automate queries to extract the necessary data from the larger assets that contain them (CDA Documents, V2 messages, et cetera).

So, now to the meet of how CREDS actually works:

1. Download the Registry's logical model from a FHIR Server by querying for the StructureDefinition resource(s) you need.
2. For an identified patient, and for each system that might have data, collect the relevant data for that patient from the system.
1. By first mapping the patient identity you know to the patient identity in the system that you are going to query.
2. And then query for and extract the relevant data assets (FHIR Resources, CDA documents, or V2 messages).
1. To query for FHIR Resources in this example, it is enough to request Patient/$everything, and let the FHIRPath mapping perform filtering.  This is a naive implementation, you could be smarter, and CREDS will have some guidance both about writing mappings and how to use those mappings to get to the document you need.  A key assumption in CREDS is that the mapping is explicit, it does not assume that anything other than patient identity and date are available as pre-established contextual cues to extract the data.
2. To query for CDA documents, well, you have a couple of options, but the one I'd start with is already FHIR enabled, and is basically the equivalent MHD query for all patient documents for a given time range for the patient.  And if you happen to need to query to an XDS/XCA based registry / repository (as might be the case for QHINs under TEFCA, or most national networks already today), there's a way to bridge from MHD to XDS/XCA queries. I built one in personally in 2016, I worked with a team that shipped another one to production a few years later.  It's baked into the design.  After all, MHD started out with the XDSEntry resource.  Others have done the same, including Grahame Grieve.
3. V2?  CDA showed the way.  While there is NO "standard" way to do the same for V2 messages, I've also built (and shipped) a FHIR based query modeled after MHD to an HL7 V2 message repository.  This is not rocket surgery, it's more like brain candy.
4. Got another format (e.g., NCPDP, X12)?  Same thing, different format.
5. Finally, for each element in the Registry's logical model, apply the appropriate FHIRPath expressions over the extracted resources to collect the information in the logical model.
3. Having collected the data to populate the registry's logical model, you could just send it in logical model form and let the registry take it, but that's no longer FHIR, it's just FHIR-like, or perhaps even FHIR-lite.  So ...
4. A smart registry will define their logical model in (as close to as possible) a FHIR format.  That's a small lift, but certainly worthwhile.  Registries which define their submission models in FHIR format don't need the final CREDS step of transforming the data.
5. We sort of cheat on the very last step for registries which don't do that work, and say, the submission to the registry goes only so far as FHIR as a standard, so if the registry logical model isn't already written in FHIR (and the various regional standards such as the HL7 FHIR US-Core or USCDI (or USCDI+), then they must also supply a computable transformation using the FHIR StructureMap to convert information structured in their logical model format to the FHIR Bundle.  CREDS won't go into much detail there, and it really need not do so.  There are implementations that can apply a structure map to perform transformations from one logical model to another.

That's enough on CREDS for tonight and it's NOT what my project manager wanted me to do, but it's really about getting my thoughts down in pencil before I whip out my pen.  

Surely there's more to be written, I have a list.  Here's a few of the topics I plan on taking up shortly:

1. How to go from a mapping to a queryable repository in FHIR.  In this, I'll answer the question about how a registry can specify mappings in a way that makes it possible for different institutions to query different repositories or networks for assets to collect.
2. Optimizing queries. The principles of writing FHIRPath expressions in a format that enables users to distinguish between the initial query to send to an external part and the filter to apply after asset retrieval to collect the data, and some thoughts on how to merge queries for the same kind of asset (e.g., a FHIR Resource type, a CDA document or a V2 message).  I suspect that the first implementation I work on in any way will be naive (Patient/$everything), but I'm certain I can do better.  FluentQuery would be a big help here, but at the moment, I've got the only implementation I know of from the SANER Project.
3. FHIRPath for CDA. If I get to this one in 2022, I will declare the year a grand success, because it means I will be writing an implementation or better yet, that someone else beat me to it.

Personally, I think CREDS project will result in a visionary IG, but it's goal is NOT to boil the Atlantic Ocean, or even Lake Ontario.  I'll settle for Lake Kerr* for now, understanding that if I but turn up the FHIR, I could use it take on anything.

For those that don't know, the main inspiration for how we are doing things in CREDS is based on the work I did over the last two years with the SANER Project.  For that project, we needed to do two things:

1. Extract data from patient medical record in various places, and
2. Count the things that we extracted.

CREDS is just refining how to do the first part, and not just for data that exists in FHIR.  Because lord knows, it's not all in FHIR yet, and it will probably remain that way through my lifetime.

     Keith

*  Lake Kerr is within sight of where I wrote Happy Tears, and I walked by it with my mother last week a few days after her successful cancer surgery.

Happy Tears

This stream blew up on twitter, so I thought I'd share it here as well (with edits since I don't have to worry about length limits).

Spoiled Rotten and Not Knowing It

When I was young and naive (about 20 years or so ago), I was responsible for leading up part of a development team who worked on a XML database product that ran on the early web and which could serve up XML content or HTML pages in response to requests.  One of the people on our staff had a masters (in mathematics or computer science, I cannot recall which), and was also working on his doctorate in the same.

Every Monday I would get a report about the product performance he wrote, and the changes in performance between this week and the last.  It was filled with estimates on the number N of requests needed of each type to verify performance improvements, and mathematics behind it, and then the design of the performance tests ... experiments he called them.  And they were carried out with that kind of experimental accuracy you'd expect from a scientist.  The results, the relative improvements (or dis-improvements), error bars, and the expected P values and all the rest the rest were in the summary report, about 10 pages, every week for weeks in a row, on my desk, Monday morning from the past week's performance run.

He set my expectations for performance testing in a way that would leave me almost forever disappointed for the rest of my career.  I was spoiled rotten for months and never knew it.  I miss him, and I wonder where he went.  He was only with us for a short period of time, I think on an internship.  If I was team captain, he was my Scotty, not just an engineer, but a true scientist.

That company was my introduction to standards development (in W3C), and gracefully self-disrupted at the outset of the .com bust in 2001, which led me to my career in healthcare, and eventually Health IT standards.

SMEs know the right Keywords

Somewhere in the course of my career, I spent a good bit of time working on "Information Retrieval" projects.  I think my first one was a search enhancer while working for a linguistic software company, but in reality, much of my earlier work experience was also related to building searchable repositories for information.  My Capstone project was also an Information Retrieval project.

And even before that, I was an expert at finding things in books because I could remember WHICH book had the answer, and how to find the right page using the index.

A recent Facebook post I ran across asks: "Badly explain your day job".  I should have responded with the image above.

I suppose part of it is translating questions into Google and Stacktrace queries, but it's not just "JFGI".  A lot of the time it's translating the querant's request into terms that Subject Matter Experts (SMEs) in a particular art would use to answer the question.  I'm not an expert so much of in terms of what I know, so much as in what I know how to find out.  Yes, I have encyclopedic memory of the CDA R-MIM, and a few other things, but I don't keep that on the top of my memory, instead, I know where to find what I need.

The CDA Book came about so that I'd have a list of those things that I need for my work in print form by my desk (and yours).  This blog came about for some of the same reasons.  I know I wrote something about that, where the heck did I put it.

If Web 2.0 is the Semantic web, and Web 3.0 is some Block chain related thing, Web 4.0 should be the translator of simple questions into expert answers, and if we get there, we will also have solved the Touring problem.  Because to do what I do as a significant part of my day job, is to get INSIDE the head of the querent, figure out what they are really trying to do or understand, and then, get the expert answer and translate it back into something that they'll understand ... the Freshman lecture version if possible.

Debugging Network Communications - For the Rest of the World

In one of my very early forays into IHE standards implementation, I had to implement TLS version 1.0 shortly after it became an IETF RFC, in Java, using Tomcat.  Thus began the ATNA FAQ.  Thiat document is now 15 years old, and is still being used (at least by me).  I started writing these kinds of things down so I don't forget them, which eventually resulted in this blog.

I'm still debugging TLS connections, and I have to admit that it's become a particular art form, but not so much as in finding out what when wrong, and figuring out the solution, but rather in explaining it to someone who is NOT versed in the ingredients of TLS connection sausages so that can a) find the right person to fix it, and b) communicate what needs to be fixed without c) further intervention from me.  That's high art.

I have a highly evolved tool set including:

• DNS, Ping and TraceRt
• WireShark
• OpenSsl
• JVM debugging arguments

Here's the problems these tools help me identify.  Each requires appropriate communication..

1. My computer cannot get a good TCP/IP address for the supplied hostname.
1. Either DNS is down somewhere, or the new DNS record is still propagating, or it simply does not exist.
2. My computer cannot connect to the TCP/IP address that DNS gave it.
1. The DNS change for your server may still be propagating
2. That IP address is not connected to the Internet, is not within my reachable networks
1. The sending computer sends a SYN, but no ACK is ever returned.
1. Ping returns no response to that IP (may be blocked by a firewall).
3. The firewall doesn't like the computer it is coming from.
   
1. Same symptoms as above.  Firewalls and application gateways (Firewalls on steroids) and other interfacing technologies (e.g., AWS Lambdas or Azure Functions, gateways that have been weaned from Steroids) can mimic just about anything, but most often, they just hide your computer from mine.
4. The computer is actively NOT listening to connections from that address.
1. SYN goes out, but a RST comes back.  In other words, I'm listening to communications, just not to THAT port.
3. The computers can connect (three way TCP SYN, ACK, SYN-ACK completed), but we cannot make a TLS connection.
1. My client sent your computer a TLS version it didn't like. You server needs to enable support for TLS Version (1.2 or higher).
2. My client sent your computer a set of encryption protocols it really doesn't care for.  Your server needs to enable the following encryption protocols ...  (RSA or DCHE Galois Cipher Mode[GCM]).  Cyclic block cyphers (CBC) are no longer considered to be secure.
3. Your server sent my system a certificate it didn't like, it was:
1. Expired, please renew it
2. Revoked,  please replace it with a new certificate
3. Not secure enough ... please use a certificate supporting at cipher strength of at least (2048 bits).
4. Not signed by an entity trusted on my end
1. Our system doesn't accept self-signed certificates, please get your certificate signed by (a commonly trusted CA, or a CA of my choosing)
5. Prepared using an algorithm my server doesn't support.  Please use an certificate signed using (the RSA algorithm).
6. For a server going by a different name (this one is rare.  Hostname matching is important in many circumstances, but in cases where the server that is supplying the certificate is three layers deep behind other network infrastructure, it has no clue, and so is often disabled.
4. Your server required a client certificate from my system that it doesn't have.
1. Here's our certificate chain, please trust someone in this chain - OR -
2. Please supply me with the necessary client certificate and the instructions for the obtaining one (the administrative hoops that I have to jump through to get them).

The problem with this are:

1. The tools are complicated and require either good training or documentation for folks who haven't needed to learn to use them.
2. You actually have to understand how the Internet standards work to determine what tool to use and when.
3. I don't scale.  We need me in a box (or more specifically, in a service).

So, I've resolved to work on a tool to do this sort of testing for me, with the details about what is wrong written in very user friendly language about what it finds about the problem.  It's an interesting bit of interface engineering.

Automating FHIR IG Generation from Non-FHIR Sources by cloning myself

An awesome lot of my FHIR IG development involves taking data in one structure and converting it to other structured formats required by the FHIR IG Development process.

That includes creating .fsh and .md files from structured data.

I do most of my FHIR IG development in Eclipse (because if it involves code or transforms, that's where my XML Editors plug in, or my Java transform code for other formats).  I've narrowed down my processes so that I can run Sushi, the FHIR Build or my "custom build script" from within eclipse with one of three external tool configuration scripts:

Here's my normal "Build" script, which just launches build.bat in the project root folder:

<launchConfiguration type="org.eclipse.ui.externaltools.ProgramLaunchConfigurationType">
    <stringAttribute key="org.eclipse.debug.ui.ATTR_CONSOLE_ENCODING" value="UTF-8"/>
    <stringAttribute key="org.eclipse.ui.externaltools.ATTR_LAUNCH_CONFIGURATION_BUILD_SCOPE" value="${project}"/>
    <stringAttribute key="org.eclipse.ui.externaltools.ATTR_LOCATION" value="C:\Windows\System32\cmd.exe"/>
    <stringAttribute key="org.eclipse.ui.externaltools.ATTR_TOOL_ARGUMENTS" value="/c build.bat"/>
    <stringAttribute key="org.eclipse.ui.externaltools.ATTR_WORKING_DIRECTORY" value="${project_loc}"/></launchConfiguration>

Sometimes I just want to rebuild the IG, for that I can just call the IG Publisher:

<launchConfiguration type="org.eclipse.ui.externaltools.ProgramLaunchConfigurationType">
    <stringAttribute key="org.eclipse.debug.ui.ATTR_CONSOLE_ENCODING" value="UTF-8"/>
    <stringAttribute key="org.eclipse.ui.externaltools.ATTR_LAUNCH_CONFIGURATION_BUILD_SCOPE" value="${project}"/>
    <stringAttribute key="org.eclipse.ui.externaltools.ATTR_LOCATION" value="C:\jdk-11.0.2\bin\java.exe"/>
    <stringAttribute key="org.eclipse.ui.externaltools.ATTR_TOOL_ARGUMENTS" value="-Xmx2G -jar ../publisher.jar -ig ig.ini -tx n/a"/>
    <stringAttribute key="org.eclipse.ui.externaltools.ATTR_WORKING_DIRECTORY" value="${project_loc}"/>
</launchConfiguration>

And sometimes I just want to rerun Sushi alone, without running FHIR:

<launchConfiguration type="org.eclipse.ui.externaltools.ProgramLaunchConfigurationType">
    <stringAttribute key="org.eclipse.debug.ui.ATTR_CONSOLE_ENCODING" value="UTF-8"/>
    <stringAttribute key="org.eclipse.ui.externaltools.ATTR_LOCATION" value="C:\Program Files\nodejs\node.exe"/>
    <stringAttribute key="org.eclipse.ui.externaltools.ATTR_TOOL_ARGUMENTS" value="C:\Users\kboone\AppData\Roaming\npm\node_modules\fsh-sushi\dist\app.js fsh -o ."/>
    <stringAttribute key="org.eclipse.ui.externaltools.ATTR_WORKING_DIRECTORY" value="${project_loc}"/>
</launchConfiguration>

Save any of these snipped to a file named your-file-name.launch and you should be able to import it as an external tool configuration.

I've even gone so far (finally) as to make this build process an automated part of my check-ins to the FHIR Repository (that way I don't need to be present to run the scripts when source material changes).  What I usually do is take the command line (Windows) script and convert it to Unix and run it in GitHub CI/CD.  For V2-to-FHIR, I just recently created a CI/CD workflow that updates the Sushi from CSV files downloaded from Google Sheets.  This is all for publication purposes.  For SANER, I had other tools to create the SANER IG from an XML file I've been using for IG creation for IHE profiles.  Effectively what I'm doing is cloning myself using GitHub CICD.  I'm not even the first person in the community to do this.  It's basically how build.fhir.org runs, essentially as Grahame in-a-box, but it scales and neither I nor Grahame do.

We were running that up until a few weeks before final publication, after which we did all edits to the files created by the automated process, and removed all the code that supported that process.  That's because the FSH and FHIR IG content in GitHub are the official sources for the IG, not the process inputs used to generate them, and I don't want to be on the hook for maintenance for life for my own tooling that I'm using MOSTLY to make my life easier.

I've build now about 5 different guides using automated FHIR IG (and FSH generation tools).  It's the only way to fly when you have to turn dozens of structured inputs into FHIR IG outputs.