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.

IHE PCC Bed Management Profile

The IHE PCC Bed Management profile represents a departure from business as usual in the IHE PCC Technical Committee.  It is neither a modern CDA based profile, nor a post-modern FHIR based profile.  Instead, it returns us to working with the twentieth century HL7 Version 2 family of standards.  Why? In this particular case they are widely implemented in the systems where Bed Management is important, they aren't broken, and they are quite sufficient to the use case.  I just uploaded the draft version of the profile for our Volume 1 review next week, where most of the committee will be in Portugal meeting to go over the materials.  I, alas will not be, as I have to be in Orlando suffering (#sarcasm) through a vacation with my family.

The problem this profile attempts to address is to reduce patient wait times for beds when being transferred from the ED to the inpatient setting.  While this profile may use ancient messaging technology, it does provide some support for modern 21st century analytics.  By communicating early in the ED visit, the bed manager can make predictions about resource needs (both beds and staffing), an support appropriate measures in order to provide better care.

In this profile the ADT Patient Registration system communicates patient demographics to the EDIS. The EDIS communicates patient status (potential need for a bed, patient acuity, movement, et cetera) to the bed manager so that it can apply predictive analytics to support resource allocation.  The Order Placer is assumed to be a CPOE component by which the ED physician enters an admission order to the bed manager.  The Bed Manager communicates bed status to the EDIS and ADT Patient Registration system.  Finally, the ADT Tracker support tracking of activity so that facilities can create dashboards, digital bed boards, and capture measures of quality (e.g., time between order to admit and patient transfer from the ED) to support better management of facility resources.

I'll be working in the pre-park (Universal) morning with the IHE PCC Technical Committee whilst on vacation in order to keep up with reviews of this profile.  While I'll miss most of the fun, I'll at least be able to keep up with my work on this particular item.  Unfortunately, I cannot be in two places at once, and as beckoning as a trip to Portugal sounds, a week playing with my family will still win every time.

   Keith