Friday, April 3, 2020

What is 6000 * 5 * 4 * 7 * 52 / 60 / 24?

To damn much if you ask me.

6000 hospitals.
x    5 minutes / form reported
x    4 forms reported / day
x    7 days / week
x   52 weeks / year
= 30333.333 hospital minutes

How fast could a computer report that if we but had the right infrastructure?  Surely 0.333 minutes would be enough.

I do NOT want to hear someone's brilliant idea about how to use the web to solve the COVID surveillance problem one more time if all they can do is implement <FORM>.  Sure, it's FORM on top of a Bootstrap/React UI with Node.js and NOSQL backend, but the front end input is still a human at a keyboard, the same as it was when Tim Berners Lee invented HTML in the mid-90's.

I do NOT want to hear about one more front-line medical profession typing in stuff into a form.


Use a camera, a sensor + arduino, an ultrasonic tag, or spare printer parts.  Do whatever it takes to enable people in a crisis to operate at the top of their license, not the bottom.

If "all you need is a phone", understand that in that phone is a supercomputer that is 100,000 times more powerful than necessary to land on the moon.  Use it the damn thing.


Tuesday, March 31, 2020

Classifying Strata for Beds and Ventilators for The SANER Project

I'm presently working on terminology to help classify what is being counted in various measures for Beds, Ventilators and other equipment for The SANER Project.

As I look at the classifications that others are using:

Physical Capacity: Total number of beds (or other things being counted)

This breaks down in two different ways, by licensure and staffing.
Licensed Capacity: Number licensed (interesting but not important in emergency cases)
Surge Capacity: Number of additional that can be added in overflow situations.

Staffed Capacity: What has staff to support treatment.
Unstaffed Capacity: What does not have staff to support treatment.

Type of location:
A Bed is located in a part of a hospital (or similar facility) and is intended to support:
Inpatient care - Beds meant for patients with acute disease, but not needing emergency treatment.  Inpatient care includes patients admitted for "Observation".  They aren't well enough to return home, but they aren't sick enough to require a higher degree of attention.  The distinction between Inpatient and Observation is generally a billing distinction, not one that truly addresses other characteristics of location.

Acute care: A subtype of inpatient care that provides for treatment of patients with care, but not intensive.
Intensive care: A subtype of inpatient care, providing a higher level of care, treatment and staffing than acute care.
Critical care: Some institutions have a level of care between Acute and Intensive which has higher staffing levels and treatment needs that normal acute, but lower than "Intensive".  Cardiac care units and critical care units fit into this category.  For the current situation, we think that CCU (whether cardiac or critical care) should fit into the Intensive care category when counting.

Burn Units: A burn unit is a specialization of an ICU that supports those needing treatment for burns (heat or chemical).  These have additional equipment needed to treat patients who have significant loss of skin due to burns (e.g., cooling baths, higher temperature controls, and additional treatment resources).  Such units might be used to treat patients who need ICU for which a normal ICU is not available, but this is not ideal use of resources.  There's some question about whether these should be counted the same as ICU beds or differently from ICU beds.  For the current crisis, this question may not be able to be answered.  There will be crises in the future where this distinction is critically important.

Emergency care - Emergency beds are those meant to treat patients who have urgent or emergent
care needs which must be addressed before admission (or discharge to home or another location for treatment.

Post-Acute care - Other facilities also provide spaces for treatment of non-acute disease, which I would describe as care needed to support rehabilitation and recovery, or long-term care.

Outpatient care - Outpatient care beds include those meant for patients who are recovering from a procedure, or in other similar situations.  See rooms below.

Other hospital facility space includes:
Operating rooms - facilities for performing surgical procedures.
Procedure rooms - facilities for performing other procedures (usually diagnostic).
Recovery rooms - facilities for treating patients recovering from surgery or other procedures that do not need post-procedure acute care.

These spaces may be reconfigured in emergency to support other uses.

Beds may be designated to treat patients within a certain age group:
Neonatal care beds (Nursery, NICU) are designed to support newborns and infants.  They cannot be readily used to treat older children or adults, simply due to size limitations.

Pediatric care beds are designed to address the needs of children.  They might be used to treat adults in cases of emergency.

Adult care beds are designated to address the needs of adults.  They can be used to treat children in cases of emergency.

Many reasons for the distinctions between adult and pediatric beds are to address the different needs of these two populations when staffing and resourcing and planning the facility, rather than physical capacity restrictions (unlike the situation for neonatal care).

In Use/Available/Unavailable
Beds and other assets are either available or in-use or otherwise not available (broken, missing, on loan, et cetera).  When being counted according to current guidelines, nobody seems to have addressed the "not available yet not-in-use" state.

Supplies (test kits, masks) are either on-hand (available for use), consumed (used for their intended purpose), disposed of (e.g., due to contamination, transfer to another location, or otherwise).  For test kits, we need to distinguish between "test kits" which do the actual diagnostic test, and "specimen collection kits" which are used to collect and safely transport the specimen from the collection location to the testing facility.  A shortage of either can cause problems.  We also need to clarify the type of specimen used (blood vs. nasal or other swab) b/c sending a blood sample to a site that can only test via swab isn't going to help.

For equipment, we see discussion around ventilators and ventilator slots.  We should be counting both in some way if both are in use.  Adding slots to a ventilator (treating two or four patients with one ventilator) is being done today.  It's a modification of a medical device that should only be done under specialized scruitiny and only in emergencies, but it is being done in New York at this stage.

There should be some clarity around how these are counted, because if people start thinking about how to redeploy ventilators to support patients, and one facility is counting slots and another counting ventilators, that's a problem.  I'd suggest to "count ventilators" when talking about equipment, and count slots when talking about patients.

There's also the distinction between invasive ventilator (those requiring a tracheal tube), an non-invasive ventilation (CPAP and BiPAP), and also between those that are designed for long-term use and solutions that are coming out of the maker/innovator community which are specifically designed as "surge capacity devices."

Sunday, March 29, 2020

Printing a FHIR IG

panicking leslie nielsen GIF For folks who are used to working in Microsoft Word or with PDF documents, trying to review a FHIR Implementation Guide on the web can be a little bit daunting for the first time.  A colleague of mine tediously copied all the pages for a guide that we had produced for the Mobile Health workgroup so that others could do corrections in line.

It's really not that hard to do, just a tedious way to spend 15 minutes to an hour (depending on page count).

I've turned other highly linked web formats into single page HTML specs in the past ... it really isn't all that hard to do.  You need a scraping tool, HTML Tidy (jtidy won't cut it any more, it just hasn't gotten the love), and a very little bit of XSLT.  If the specification already has a table of contents page, it's even easier because then you don't have to worry about how to order the material.

Just about every FHIR IG now produces a ZIP file with the entire specification.  So, download the zip file, unzip it to a folder, and run the this XSLT against it (after you clean up the html).  I threw this together in like 10 minutes between five other things I'm trying to get done, but it worked.

If you are using a spec I worked on, there's a "download this specification" somewhere on the home page.  Otherwise, just replace index.html with if the person who wrote the spec is using the FHIR IG Builder or older tools.  That will get you the full data.

  1. for %f in (*.html) do c:\util\tidy -utf8 -asxhtml -n -m %f
  2. java -cp c:\saxon9h2\saxon9he.jar net.sf.saxon.Transform -s:toc.html -xsl:gen_single.xsl  -o:single.html
  3. single.html

After you've launched the output, you can:

  1. Print to PDF
  2. Copy and paste everything on the single page to a Word document and distribute it.
  3. Turn on your printer and spend a ton of money printing something out.
There are a lot of places this could go.  I would love to see this little gist turned into something that would turn a FHIR IG not just into a PDF, but rather into an e-book.  It's not that difficult to do.  But, maybe I'll get back to it when the crazyness settles.

Meanwhile, stay sane, stay safe, and stay home.


Playing with Control Charts for COVID19

I've been playing with Excel and control charts over the last week to get an understanding of where things are headed.  I get the human difficulties with understanding exponential growth, so I wanted to look at the data in a different way.  The italic text is my commentary on the blog.  The normal faced text is what I've been tweeting, the bold text is when.

If it looks to you like the exponent on infection growth rate is increasing, you are probably right. I just looked at the 5-day LOGEST values (estimate the exponential growth based on last 5 days activity), and the rate has risen 4 out of the last 5 days. Testing just started...

So, this isn't scary to me YET. What it means is not that the real exponential growth rate of infection is increasing, but rather that the rate of our knowledge of exponential rate is increasing. But more testing is still needed to get the numbers to settle down ...

There's gonna be lots of numbers for the epidemiologists and hyper-mathy folks to study RE impact of testing volumes (see ) on estimates of real growth rate when this is over. I don't recall signing up for that clinical trial though.

I suspect there they may even be some new hyper-mathy stuff that addresses statistical process controls applied to exponential growth curves. I kinda faked a control chart with my 5-day moving estimator for the growth rate. There should be some useful signal there ...

I know enough math to know that something should work, maybe even already exists (but maybe and even possibly not yet). I also have enough math to know it's not going to be me who actually proves it.

I've seen enough in that one graph to tell me what I already knew, the real rate is worse than a lot of people thought, or the current graphs show. The good news is that we are seeing a correction now. The bad news may be that it will take a longer time than we want to adjust.

But I'm still not panicking yet.
And neither should you.

3/27 (early morning) 
I just updated my spreadsheet. The good news is that the infection rate is declining, and has been for eight days in a row. However, it's also stabilized, which means it might be getting ready to inflect the other way.

If you look at the graph above, you see eight points in a row declining.  That's enough to trigger an alert in a statistical process control environment (actually 6 or 7 depending on whose set of controls you use).

3/27 (later in the day)
OK, my chart gets better. I can compute New Cases / Total Cases, which should be a constant for an exponential function. In fact 1/(1-New/Total Cases) recovers the base of it. Here's the new control chart on the base value, I find it more helpful.

This above graph was inspired by this great video on plotting exponential data.  It is worth including in this post, just so you can see what I'm doing is valid.  I still like the orientation of my approach better because you don't have the overwhelming sense associated with a graph plotted on logarithmic axes gives you.  It's just a little number bouncing around telling us how fast cases are growing, without really making it apparent how fast an exponential works.  Since I'm looking at that growth everyday, and listening to my family's response to it, I get the impact of it.

Today's update is promising. The downward trend in growth shows we are making progress. Note that it took two weeks to get farther than 1 standard deviation in the right direction. Maybe by tomorrow we'll be at 2.

Several additional notes here:
  1. Remember that set of 8 control points going down?  How come I don't have that once I switched to this format?  That's because I'm no longer reporting the 5 day average, just the current days rate.  See that dip on 3/21?  It gets included in the 5 day average in the previous format, which hides the current day's signal.  I kept the 5 day deviation because it tells me something about how the rate is settling in, or not.  So, now we have 6 on the same side of the average line, that's another kind of signal in statistical process controls (or 7 or 8, again, rules vary).
  2. Statistical process controls are for managing stable processes.  When the process is changed, you have to adjust the controls your are using.  I'm thinking that I should be marking the graphs above on a weekly basis with the per week mean and standard deviation lines so we can see HOW the process is changing over time.
  3. There's no API to work with the data I'm using, but I there's a way to scrape it from the page I'm recording numbers from.  I haven't bothered because it's licensed data.  What I've done above falls (as best I can tell) under fair use.  Scraping their page dynamically isn't what I'd call fair use.  If they do publish an API for this data set, well then I might take a crack at doing something with this little gem of a gist.
  4. There IS a source of publicly available data  from John's Hopkins that does work via APIs.  The API is simply:{date}.csv

Saturday, March 28, 2020

Technical Environment for The SANER Project

This started out as a page describing the technical environment for the SANER Project, but I'm busy reintegrating some of my development tool set back into the build, and so have not been able to push a new build.

Resource utilization data can be provided from a number of sources:

  • Systems Having Clinical Data
    •   Electronic Health Record (EHR) systems
    •   Emergency Department systems
    •   Labor and Delivery systems
    •   ICU and/or Nursing Central Monitoring systems (or stations)
    •   Laboratory Information Systems (LIS)
    •   Clinical Data Repository (CDR)
  • Systems not having Clinical Data
    •   + Bed Management (a.k.a., Housekeeping) systems
    •   + Asset Management systems
    •   + Surgery/Operating Room Scheduling systems
    •   + Staff Scheduling systems
    •   + Inventory Control systems

Systems Having Clinical Data

Systems in this category have access to some or all of the health records for a patient,
and so can often provide information indicating COVID-19 positive or suspected patients, as
well as associated problems, patient demographics, and patient acuity (severity of
illness) data.

These systems are often used to place or discontinue orders that involve medical
equipment (ventilators, viral tests), and so may be used to determine in use (in
the case of ventilators) or consumed (in the case of test kits) equipment or
supplies.  Some orders might also indicate use of special equipment (e.g., isolation

EHR Systems

Comprehensive Hospital EHR solutions may include the capabilities of the other systems
listed above, or may be integrated with other systems but not have direct access
to all data available to the other systems. Even when those capabilities are available
in the comprehensive EHR solution, other solutions may still be chosen by the facility
for a variety of reasons (features, cost, legacy, et cetera).

An EHR may have access to beds in use (because it has access to the active patient
census), but may not be able to report status of beds as known by the bed management
or housekeeping system (e.g., beds available for use, beds needing cleaning, beds
taken out of or added into service, et cetera).

An EHR may also be able to make an educated guess about number of ventilators in use
based on the number of orders for ventilation on the patients it knows about, and the
current status of the order.

Emergency Department Systems

Emergency department systems are simply specialized EHR systems that facilitate patient
care in an emergency room setting.  They may also support or be integrated with central
monitoring solutions enabling ED staff to monitor the status of patients on monitoring

Labor and Delivery Systems

Labor and Delivery systems are another form of specialized EHR system that facilitate
treatment of mothers about to give birth in the hospital.  They generally support the
ongoing monitoring of the pregnant mother, and integrate with specialized equipment
used to support newborn delivery (e.g., fetal heart rate monitors, infusion pumps used
for anesthesia, et cetera), as well as routine charting while a mother is still in labor
but not yet ready to deliver.

ICU/Central Monitoring Systems

These systems bring real-time data from the EHR together with a variety of monitoring
and treatment equipment, often to provide clinical decision support for patients
needing intensive ongoing treatment and monitoring.  As a result, these systems have
awareness of the use of medical equipment, patient acuity, disease progression, as well
as the in-use status of ICU beds, and perhaps the total bed capacity of an ICU (but
not necessarily the availability).

Laboratory Information Systems (LIS)

These systems are used to track and control incoming laboratory orders, to manage
laboratory automation equipment, and to manage outgoing reports on orders.  They have
some access to patient clinical and demographic data, usually enough to facilitate the
interpretation of the laboratory test, but may not have access to more data.  Some
data available in an LIS might be used to assess patient acuity, but the EHR would
be a better source of this assessment.

An LIS may also be connected to external public health reporting systems to support
biosurveillance efforts (tracking of disease in populations).  Just the placement of
certain kinds of laboratory orders may be used as a trigger to initiate alerting to
public health (e.g., highly contagious disease such as Ebola or Zika, or a condition
which may indicate a high risk situation in the community such as food poisoning).

Past biosurveillance efforts have not generally considered the impact of disease (such
as COVID) on available beds, but the impact of COVID on hospital bed capacity has now
made this a significant consideration.  Some organizations do use data from internal
laboratory information systems to track the prevalence, type and locations associated
healthcare acquired infections (HAI) (e.g., due to antibiotic resistant strains of
bacteria), in order to provide appropriate treatment and infection mitigation precautions.

Clinical Data Repository (CDR)

Hospitals (especially those affiliated with academic medical centers) utilized CDRs
for long term storage of clinical data to support analysis, research, measurement and
quality improvement efforts.

CDRs may have information about the long term impacts of disease, treatment procedures
and other factors on hospital operations might be used to aid research, but do not
generally have real-time data that could support utilization reporting.  Some of the
data in a CDR might show impacts of high utilization on hospital operations, which could
aid in identifying and addressing long term monitoring efforts.

Systems Not Having Clinical Data

Systems in this category do not generally have access to health records for a patient,
but may have information about the status of hospital equipment and supplies.

Bed Management (a.k.a Housekeeping) systems

Bed Management systems are designed specifically to keep track of the status of beds
as it impacts the operations of the housekeeping in a facility.  After a patient is
discharged, the bed and room in which they resided need to be cleaned, special precautions
may be needed when rooms have been contaminated (exposed to blood, or infectious organism),
et cetera. These systems may also have operational data about ongoing bed turnaround
time (e.g., from unoccupied to available for use) which can also impact availability.

In smaller hospitals, the classic method of bed management is a bed board, which can
be as simple as a whiteboard with a table drawn on it, with room numbers, more complex
systems might use a magnetic board with pretty colored magnets. Modern bed boards get
really fancy, with ward layouts and color codes, and all sorts of bells and whistles
and reports and graphs.

Asset Management systems

Asset management systems usually involve solutions that enable a facility to manage
equipment inventory, tags that can be attached to equipment for tracking, and sensors
that can detect nearby tags deployed in the hospital environment.  Sensors typically
need to be connected in some way to the hospital network, and the tags need to be able
to operate in a radio-frequency and sound and barrier rich environment.  This is combined
with mapping software which can plot the location of a device in a facility (in 3

A typical small hospital might have 10 ICU beds.  With an average ventilator utilization
ranging somewhere between 15-45% (see,
a facility could reasonably get by with a half dozen or so ventilators for the ICU.
Under normal circumstances, such a small number would be reasonably managed with manual
processes, and for that reason, many facilities may not use asset management systems
to track ventilator locations.

Surgery/Operating Room Scheduling systems

In certain crises, the availability of an open OR for a patient needing immediate emergency
surgery would be a critical piece of facility resource utilization data.  Operating
rooms use a variety of complex, expensive medical equipment and resources.  Hospitals
that want to optimize use of these spaces and equipment will use information systems designed to
ensure greater utilization of available capacity.  These systems will be aware of the
availability of operating room schedules and equipment needs.

Staff Scheduling systems

Staff scheduling in a hospital is an ongoing effort of looking at the current patient
load, forecast patient load, existing staff schedules and available surge staffing resources.
Again, in smaller facilities, much of the essential management might be done through
human effort, and on a whiteboard. In larger facilities, software might be used to address
optimization of schedules, improving staff utilization.

Inventory Control systems

Inventory control systems are used to track expendable supplies, and manage replenishment
and distribution across the facility.  These systems may have information about available
supplies such as surgical and N95 masks and personal protective equipment (PPE) that is
frequently replaced.  But these systems don't always automate the counting process that is
often needed to track current inventory levels for this kind of equipment.

Friday, March 27, 2020

What will The SANER Project Produce

It's a great question, and one I have in my head conceptually, but it's time to start writing this down:
  1. A specification for how some things are going to work (basically a FHIR IG).
  2. Two or more deployable FHIR Server images (1 .NET and 1 Java based) that can be used to support reporting of utilization data from hospitals, and viewing of that data by public health.
  3. Interfaces delivered by major EHR, Health IT and Medical Device vendors that can populate the server above.
  4. One or more components that can take data from that server and produce visualizations including:
    1. Maps of facilities or regions that depict information about utilization
    2. Graphs of trends over time for a specific facility or region that shows resource utilization and/or capacity.
  5. One or more components that can consume data from that server and provide alerts about facilities or regions having (or no longer) being challenged.
  6. One or more components that can consume data from that server and provide measure reports based on the available data.
  7. Components that can bridge between what is delivered and existing solutions:
    1. A way to quickly classify beds in an institution.
    2. A way to transform the resulting data into  
  8. A classification system for beds that allows systems to participate with some minimal level of supporting information and evolve to providing more granular data without disruption.
  9. A classification system for reporting about mission critical equipment and supplies, and perhaps even a process or set of principles to use for establishing such classifications for future crises.
  10. A virtual testing event where these materials can be tested safely, with simulated data.
  11. A real world pilot where some of the components are deployed in secure environment and used with real world data.
  12. A directory of endpoints where data can be sent to, or consumed from.
Components should be able to deploy with commonly available components on multiple platforms, including open-source database servers (SQL or NoSQL), and where cloud is available, to work with readily available cloud components (including both Windows and Linux servers).

No single organization will deliver all of these components.  Instead, members of The SANER Project will produce individual components that they can make readily available and easily installed for their customers, with minimal disruption.

Wednesday, March 25, 2020

The SANER Project

I don't usually talk about "work" that isn't part of my volunteer standards activities here.  What I do in standards is public information, and I can have my own opinions about it, so that's safe. The rest of my work is really between me and my employer, and when I blog for them, I do it on their site as I've done for the past decade and a half.  But there are times to break the rules, even my own.

The SANER Project is called that because if I couldn't do something about COVID-19, I would go crazy.  At lot of my colleagues at Audacious Inquiry feel that same way.  That's why we've started a project to work on this.  There's an implementation guide, and people, and meetings.  If you are in the same boat, become one of the people, join the meetings, and help us develop the implementation guide, test it, and even pilot it.  So, how am I breaking my rules?  This isn't a Standards project.  It WILL become one, it is using standards, but first and foremost, it's about how to rapidly deploy a solution that can become the way to address our needs in the US.

I grew up outside Philadelphia during the gratefully brief Legionnaire's disease crisis, and I remember the trauma, and the daily news cycles as a child, and my a) inability to escape the constant barrage of information, and b) complete inability to do anything about it.  It must have had an impact on me, I can still recall it vividly today as we enter the same sort of barrage around COVID.

I've been thinking about what the Health IT Community could do about COVID-19 for weeks, I listened to what people were saying, and where the attention was (or wasn't). Discussions around situational awareness have been getting louder again as this crisis began (as is usual for Public Health in the ongoing approximately triennial cycle of novel fill-in-the-blank).  Six new diseases SARS, Bird Flu (H5N1), Swine Flu, MERS, Bird Flu (H7N9), and now COVID-19 (SAR-Cov-2) in the last 17 years.

Situation awareness is something I first heard about in standards circles with the introduction of what many of us called the "Bird Flu" Use Case in ANSI/HITSP.  HITSP adopted OASIS HAVE and some HL7 V2 messages in C47 Resource Utilization Component.  HL7 and OASIS worked on a Cross-Paradigm specification.  And AHRQ took up the ball with HAvBED2.  It didn't work because it involved manual entry of data for the most part. 

The big ask from Public health are very much the same now as they have been over the past decade an a half: How are hospitals doing?  Break that down, and it's Beds (by type), Equipment and Supplies, and Staff.

The challenges our healthcare providers are having now is dealing with a crisis, and not having resources to get public health the information they need because we failed to automate it when we had the time.  And if the situation keeps repeating itself the way it has over the last decade an a half, they won't be able to address it the next time either, because nothing can be done in the middle of a crisis, and real efforts to resolve it after haven't considered the real challenges of automating the process, because once the crisis is over, public health doesn't get to take center stage (if there's ever a group of under-recognized people, it's those who work in public health... it's somewhat like what I've heard others say about the military 98% waiting, 2% sheer panic).

Bed Availability is a math problem.  Most think about it as:

Bed Availability = Total Beds - Beds In Use

But that's half the story because a bed cannot be used if the people needed aren't available to staff it.  A bed is a location of care... if the staff cannot provide the care, an empty bed is not going to help.  The real math is closer to:

Available Capacity = Total Beds - Beds in Use
Usable Capacity = f(Available Capacity, Available Staff)

And f() varies by type of bed and so many other things.

And there are other challenges.  Total Beds is not a constant for a facility, it's a fungible figure, because someone can roll out overflow beds into the ER in minutes, reconfigure an OR as a temporary ICU in hours, crank up a temporary treatment center in hours, build hospitals in days, or field treatment centers, activate resources, and people and even Health IT systems (my employer developed PULSE for this -- That came out of the "Katrina" use case).

Equipment is fungible too, ventilators have been modified in real treatment (NOTE: This is off-label use, and not a recommendation from me, just a note that it's been done by experts), and there are makers building them.

But situation awareness isn't about exact numbers, it's about close enough to make plans (kind of like software project management).  And there's an incremental path to getting there, because we can track the outputs needed (Bed Availability) back through it's dependent inputs Available Capacity, Total Beds and Beds in Use, and start generating those numbers, and eventually, as we track it, we start to derive the f() based on what we learn.  But before we get to point C, we have to go through A and B first.

There's value in reporting available capacity and beds in use, even if that doesn't get to usable capacity immediately, because someone who works in this space can take what else they know about staffing shortages and compute an approximation of f() in their head.  And Beds in Use is an important signal alone. It can be used to alert public health to changing trends.

And tracking those two and applying analytics can eventually get us to a data driven value for f(), and other analytics can improve the performance of f() even further.

And yes, I know, there's International value in what we are doing, and I certainly welcome International contributions, but for now, this project is going to focus on the US; others are welcome to contribute and use the materials it produces, but for now, it's going to be hard enough to manage 56 or so jurisdictions and public health agencies in my own country, so it's going to be focused at least for now, on US efforts.  After all, there's only so many cats one can possibly herd.  Thankfully, I'm not trying to do this alone.


Thursday, March 12, 2020

Oh, for a Muse of FHIR

A prologue for the oncoming storm, with apologies to William Shakespeare:

O for a Muse of FHIR, that would transcend
The brightest HL7 of invention,
A country for a stage, CEOs to act
And patients to behold the swelling scene!
 Then should the humble Posnack, like himself,
Assume the port of Mars; and at his heels,
Leash'd in like hounds, should famine, sword and FHIR
Crouch for employment.
 But pardon, and gentles all,
The flat unraised spirits that have dared
On this unworthy parchment to bring forth
So great an object: can this cockpit hold
 The vasty tombs of Regs? or may we cram
Within this short time O the very reams
That did affright the air at the Register?
 O, pardon! since a crooked figure may
Attest in little place 5 megabytes;
And let us, ciphers to this great accompt,
On your portable documents work.
Suppose within the girdle of this time
 Are now confined these mighty industries,
Whose high portals and abutting interface
The perilous narrow ocean parts asunder:
Piece out our uninteroperability with your thoughts;
Let a thousand flowers bloom upon man,
And make imaginary puissance;
 Think when we talk of servers, that you auth them
Sending their resource in the receiving net;
For 'tis your data that now must deck your apps,
 Carry them here and there; jumping o'er times,
Turning the accomplishment of many years
Into an hour-glass: for the which supply,
 Admit me Chorus to this history;
Who prologue-like your humble patience pray,
Gently to hear, kindly to judge, our reading.

Wednesday, March 11, 2020

Tweaking the FHIR IG Spreadsheets

Sometimes boundaries are good, and other times, they are limits meant to be broken.  I'm usually breaking boundaries.  One of the boundaries imposed by the FHIR IG Builder is it's use of templates.

And, unless you know what you are doing, breaking away from that is challenging, or even just making minor adjustments to make your life easier is a PITA.  But after you have the secret sauce, it's very simple.

The IG Builder runs off a configuration file called ig.ini.

Your's probably looks something like this:
ig = input/ImplementationGuide-hl7.fhir.uv.mhealth-framework.json
template = hl7.fhir.template
usage-stats-opt-out = false
copyrightyear = 2020+
license = CC0-1.0
version = 0.1.0
ballotstatus = CI Build
fhirspec =

Mine looks like this:
ig = input/ImplementationGuide-hl7.fhir.uv.mhealth-framework.json
template = #ig-template
usage-stats-opt-out = false
copyrightyear = 2020+
license = CC0-1.0
version = 0.1.0
ballotstatus = CI Build
fhirspec =

The hash-mark (#) means in this local folder (and yes, you can nest it away in another folder).

I have a folder in my build called ig-template, living right alongside my ig-data folder (yeah, I use SUSHI, you should too).  It is organized this way:


The CSS file contains some CSS classes I wanted to make my IG development easier to work with, because I can say in one class what takes about 10 lines of HTML to do otherwise.  You'll get a view of that in the appendix of the Mobile Health IG I'm working on.

The /includes/_append.fragment-css.html file works with the existing template infrastructure.
<link href="{{}}assets/css/bootstrap-glyphicons.css" rel="stylesheet"/>
<link href="{{}}assets/css/assess.css" rel="stylesheet"/>

It's an included fragment that the existing templates incorporate into the part of your html page where additional stylesheets can be added.  The {{ and }} stuff is Jekyll related gunge* that basically inserts the value of a specified variable passed to it during the IG Building process.  You don't need to worry about it for the most part, and if you do, you'll figure it out (or perhaps not).

Finally, you need to tell the IG Builder what this package is, what else it needs.  That's what package/package.json does.  Mine looks like this:
  "name": "hl7.mhealth.template",
  "version": "0.0.1",
  "type": "fhir.template",
  "license": "CC0-1.0",
  "description": "HL7 Mobile Template - for use with Mobile Health Framework",
  "author": "",
  "canonical": "",
  "base": "hl7.fhir.template",
  "dependencies": {
    "hl7.fhir.template": "current"

The critical pieces are the values you set for "base", and "dependencies", which tells the IG Builder that your local template is BASED on the hl7.fhir.template.  You could also base it on the IHE FHIR template, or the HL7 base template, or the CDA template.

Essentially, by doing this, you are inheriting ALL of the behavior of the previously existing templates, and the world (headers, footers, all the rest of the gunge), is essentially your oyster (to eat raw or cooked as you desire).

So, now you have in a page a description of how to tweak your FHIR IG Builder templates.

For what it's worth, I'm going to be working on another tweak which will enable readers to comment on the page by creating a JIRA ticket (I already have DISCUS working in prototype form for the V2 to FHIR project).


* Gunge is a technical term meaning stuff one developer thinks deeply about that another really just is going to ignore.

Monday, March 9, 2020

Where's the Tweet Storm on the Cures and PatientAccess Rules?

Those of you who know me, know to expect a tweet storm when I start reading through a rule, and might be wondering where it is, and why it hasn't started yet.

This week, I'll be starting my Storm on Wednesday around 3:15-ish, because I'll be starting it live on a Virtual Health Conference session being supported by 1up Health.  They are in the process of finalizing the schedule, so check back in a few hours or so.

So, I won't be actually be reading through it and tweeting about it until I start live on that Virtual session (though I'm doing SOME practice run-throughs on both rules today and tomorrow -- though not all of it as I want my reactions to be real).


Time changed due to working around various schedules.

Wednesday, March 4, 2020

Using the FHIR ConceptMap for mapping between Information Models

One of the notions that the V2 to FHIR project has adopted in development of a representation is the use of  ConceptMap to represent information mapping models between different representations.  Key to this is the notion that there is an identifier for each concept in an information model that can uniquely identify the data element being mapped.

If you've got XML, there's a pretty ubiquitous way to address that, using an XPath.  If there's the JSON representation, one can also use a JavaScript notation to identify the item.  Another representation that's format independent is FHIR Path, and there can be (and usually is) more than one way to represent a path using FHIR Path (as there is for XPath and do some degree also JavaScript notation.  And as I mentioned in a previous post, there's a way to represent just about any structured content in a FHIR StructureDefinition resource.  So, assuming a StructureDefinition exists, there's also a representation based on StructureDefinition that could be used.

The point is, these are unique identifiers for a concept in an information model.  If you've taken a CDA data types class from me, you know I teach identifiers first, and concept descriptors (coded data) second, and that I basically say "a code is an identifier for a concept in a coding system, just like an ID is an identifier for something in a naming system".

So, given that we have unique identifiers for the concepts in the model, otherwise the same as a code in a coding system, we have a tool to use.  The FHIR ConceptMap resource provides a way to map from one code to another.  So, we can now map between information models using the FHIR ConceptMap resource.

We do need to address a few more things about mapping before this is fully resolved.
  1. When mapping concepts, there may be preconditions that have to be true before the mapping is invoked.  This is supported by the ConceptMap.dependsOn property associated with a mapping target.
  2. When a mapping is invoked, there may be additional information products produced by the mapping.  This is supported by the ConceptMap.product property associated with a mapping target.
  3. When a mapping is invoked, translation may be needed by mapping coded values from one value set to another.  This means that the mapping depends on yet another ConceptMap that specifies how to go from one value set to another.  That's effectively another precondition on the mapping (or at least how I interpret it).
There's other data that's used in the V2 to FHIR Project that we are planning to include in the ConceptMap.  Some have suggested use of extension for this, but frankly, I think this can be addressed through the product property, since these are simply additional "outputs" of the mapping.

For additional inputs, that's really reference to a model, and for that, I think extensions might be appropriate.


Tuesday, March 3, 2020

Risk Analysis: My Thought Processes on HIMSS Attendance in light of COVID-19

I’ve been monitoring the details daily from authoritative sources on COVID-19.  I’ve been watching outbreaks and alerts, recent activity in Boston an RI, recent events in the northwest (e.g.Portland OR, and Washington state), California, Atlanta and Florida...

I’m not, at present, concerned for my own health at this time in attending HIMSS 20, though I will miss my annual spate of hugs at this event, I expect.  I’m healthy, if I get it, I will likely survive.  Others in Florida I might want to see are more vulnerable, I have to consider the advisability of family visits.

What does concerns me most is the impact on my household and community should I get infected.  My wife works in the town library, which serves a lot of vulnerable populations.  I live in a very small town, 300+ homes, 3000+ people.  I’m probably one of the most frequent travelers in contact with thousands of people on a monthly basis in this town, I could be the key link.  There are people living in my home, and with whom my adult children have contact with who are quite vulnerable.

Orlando is a huge tourism vector.  Not just at HIMSS where I will be in contact with 60 thousand of my closest friends, but the airport, the hotel, the venues that I will be at with hundreds of thousands of people from everywhere in the country, many from outside the US.

Risk of exposure: Moderate - we don’t know the risk yet, but I have to put it at possible, though not yet at likely.  More on that in a moment.
Impact of exposure: slight to moderate,  but certainly livable and tolerable for most but not all in my home (one has asthma among other things, but age is a mitigating factor).

If I get ill, the impact on me personally is likely to be slight, my family slight to moderate (it’s harder to go to work/school if you have to go to the library/kennel/community college and can’t b/c you are under quarantine), some of that can be worked out/mitigated.  For others I could be in contact with, the risk is high.

Clearly I have to talk to others in my home about this, continue to monitor, and investigate other mitigations available.

Ok, further evaluating risk of exposure after more research... number of known cases in the US is very small, < 100 (but barely, and not likely to stay that way for much longer I think).  Number of actual cases is likely larger b/c the time between onset and being contagious is around a week maybe less, and there’s some issues with how many can be adequately tested. Call it less than a thousand.  Transmission around health workers is lower than in average populations, likely due to paying attention to infection control.

Chance of exposure, very slight YET,  but this is an ongoing situation and that could change between now and departure in a less than week.

So at present:

  • Chance of exposure: very slight
  • Additional mitigations: Infection control, contact reduction, reducing to minimal
  • Impact of exposure: none to moderate
  • If impacted: Mitigations are limited.

I’m far more likely to suffer adverse effects by listening to the recently announced keynote speaker, than COVID 19.  So far, I’m still planning on attending, but that could change if the situation worsens.

  — Keith

The decision has been made elsewhere.  I will not be attending HIMSS this year.  I'm frankly grateful for that. While I did evaluate the risk to be minimal, and was willing to attend based on that assessment, it's now a risk I simply don't need to worry about.

Thursday, February 27, 2020

Using the HL7 FHIR IG Builder for other Standards

As I mentioned earlier this week, there's a way that one can use the IG Builder to profile other content.  It all depends on having a FHIR Structure Definition for that content, as exists for CDA 2.1 and HL7 Version 2 Messages.  These two examples demonstrate that other structured content (such as that used for XDS-b, or NCPDP and X12) can also be documented using the StructuredDefinition resource.  This was one of Grahame's desiderata for constructing that resource, not that it was a requirement at all for FHIR, just a generally good idea he implemented because it was the right thing to do.

Using this structure definitions as the foundation, one can apply other FHIR tools, such as Sushi, or the IG Builder to create an implementation guide.  Sushi would need some work to create example instances using features of the StructureDefinition resource it probably doesn't deal well with right now (e.g., using XML attributes to describe output).

And IG Builder right now defaults to using a set of canonical StructureDefinitions for different versions of FHIR, although I'm sure there's a way to get it to look at others, although it might require additional work to expose that as an option.

Even so, imagine if everyone in healthcare could use the same set of tools to build an IG using standards from multiple SDOs.  It's a nice pipe dream.

Wednesday, February 26, 2020

Thoughts on a canonical FHIR Implementation Guide Outline

I've been working on implementation guides for decades, first in CDA and then in FHIR, in HL7, IHE and other SDOs.  Everyone has  a slightly different approach, but there's also a lot of commonality.

Assuming a web publication format with highly linkable output, this is how I would put the outline together today:


The home page orients you towards the entire specification.  It contains a short (no more than a paragraph) description of the problem it solves, and allows you to navigate through the main components of the specification. It includes at the end a link to download the specification or subcomponents of it used for implementation, a link to any source code or other materials, et cetera.


The introduction section describes the content of the IG in more detail.  This includes the audience for the material, the scope of work explicitly included and excluded, describes the conventions used in the document (e.g., key words such as SHALL/SHOULD/MAY, other conventions), describes the organization of the document in detail, and acknowledges contibutors and/or sponsors of the work.  If there's a short glossary, it can go in this section as well, a longer glossary goes at the end in an appendix.


The overview section gives a clear and detailed statement of the problem that the IG is trying to solve.  It includes an explanatory description of key concepts and terms which may not be familiar to all readers, but these are short (more detailed material can be included as references).  It can also provide a description of the technical environment in which the IG is expected to be used (e.g., what systems, networks, et cetera, are available/used).

Use Cases

The use cases section lists each high level use case (these are user oriented), provides a short description of each one, and then launches into a detailed description of each of the use cases.  The detailed descriptions include sequence diagrams associated with the steps of the use case, along with a narrative description of what happens in each step.


The actors section lists each technical (e.g., non-human or system) actor identified in the use cases, and specifically identifies the requirements of each of these.  If there's optional behavior for the actors, it can be described in this section.  I'd recommend identifying options by name, and giving requirements for each named option (this is how IHE handles options), as it makes addressing verifying implementations do what they say they will do (a.k.a., Conformity Assessment) a lot easier.


There should be a security considerations section that addresses security concerns.  This section should identify all the security concerns, and may reference more detailed content elsewhere in the IG.  The security concerns section may identify specific actor requirements, but these should be detailed in the requirements for individual actors.  This is so that all requirements are present in one place, not spread throughout the IG.


There should be a section to describe all the interactions the IG has between the technical actors it defined (IHE identifies these as transactions).  In a RESTful environment, these are the GET/PUT/POST/DELETE operations that it supports.  In FHIR, these are the operations that the IG describes.  This includes the standard ones such as read, vread, search, create and update, and others such as $expand, but also includes any custom operations described by the IG.

Detailed Interaction Descriptions

Each interaction should describe the requirements of the actors participating in the interaction, and should also include a security considerations section, which should indicate specific security requirements that can be tested during the execution of the interaction (e.g., audit logging, encryption, et cetera).  When the interactions work with profiled content, the requirements should indicate that the interaction shall operate on content that conforms to the specific profile.  That profile should be described in more detail in a separate section.  There are some occasions where a FHIR Resource profile is described in general form (e.g., uses this content), but have specific constraints in the content of some interaction (for example, when a resource is sent via create, it shall not have an id, but when sent for an update, it shall).  In this case, make these specific requirements of the interaction.  One can also create profiles specific to each interaction, but this should only be done when warranted by complexity.

Content Profiles

There should be a section that provides a high level description of each content profile (e.g., resources, extensions, value sets, coding systems, capability statements et cetera).  These should be organized in some way (e.g., by type), and described individually.  Best practice indicates that the resource or extension profile content should include at least some sort of introductory section describing the purpose and rationale.

Detailed Content Profile Descriptions

Each content profile (e.g., Resource, Extension, Value Set) should have not just the requirements, but also an explanation of why they exist (the rationale).  This will help to explain to readers why this item is required and what the purpose is behind its inclusion.


The examples section (or appendix) provides examples of conforming interactions and content.  One include examples with each interaction and content.  The examples section simply aggregates these these and provides a high level description of each example.

I've been working on a few examples of this.  You can see what I did for the IHE ACDC Profile and the HL7 mHealth App Data Exchange IG on the web.

I'm not perfect, and I haven't managed to hit on all of the above in either profile.  You can also see I have experimented with slightly different organizations of each as well.  I'm working towards the idea that there should be one generalized approach though, and I can see where I might be able to put together a pretty decent outline for use by either IHE or HL7 for use with the FHIR IG Builder.


P.S.  While the work I'm doing here is strictly related to FHIR, there's a notion that this could be applied more broadly that would enable this and my earlier post this week for other structured formats such as CDA, HL7 Version 2, even X12 and NCPDP wire formats.  I'll talk about this a little bit later.

Tuesday, February 25, 2020

Leading the Ride at MITRE is the first FHIR Lord

There's the people that do the work, and then there's the people who make doing the work possible.  Sometimes that means going out and blazing the trail, and at other times, that means giving the team the needed bulldozers so that they can just mow it down themselves.  Dr. Mark Kramer of MITRE is just that kind of person.

Mark is one of those rare technical leads who retains his technical acumen even after being promoted to two orders of magnitude greater responsibility.  In fact, if there's anything that's the opposite of the Peter Principle, it's what I'm going to start calling the Mark Principle, which is that there are some people which really can do it all more than competently.

Mark's been involved in many technical projects which perhaps should have earned him an Ad Hoc Harley long before, including hData, CQL, Synthea, and is leader behind Sushi which recently earned one of his teams the Ad Hoc Bike Week, and the lead contributor to that project also earned a Serious Chrome upgrade to a prior Ad Hoc Harley

That should tell you something about the quality of work that Mitre and Mark's teams do.  In fact, Mitre is one of only two organizations* that can claim more than one honoree among Ad Hoc awardees.

Mark now joins a very elite club, as the 2019 inductee to the Ladies and Lords of the Ad Hoc Harley.  In fact, with his accomplishments and this award, he's the first person who could accurately claim to be a FHIR Lord.

Mark Kramer

Semper et semper ascendens deinceps
(ever and ever riding forward)

Monday, February 24, 2020

My Favorite Tools for Building FHIR Implementation Guides for IHE and HL7

I've been doing a lot of implementation guide development lately, and have some favorite tools that I'm starting to work with.  Here's a look at what I've been using.

Source Code

The first of these is a source code repository.  I've been using GIT for source control, and as a free repository for IG development.  You can look at two of the guides I've developed at and to see two of the projects I've built using this toolset.

Editing Content

I like writing content in something simple.  A long time ago I prototyped a process for IHE whereby we created IHE Profile content on the IHE Wiki.  Wikitext in MediaWiki is nearly the same as Markdown.  The value of using something like this is that it allows contributors to focus more on content and less on formatting or making things pretty.  Pretty is good, but that should be the purview of a single person with appropriate design skills rather than a dozen volunteer editors.

Text Content

So, these days, I'm using a the fairly simple Markdown editor provided in Eclipse (more on that later).  There are plenty of Markdown editors you can use, many which work in Eclipse.  I also use FluentMark from time to time.  My favorite XML Editor also supports JSon and Markdown content.

One of the challenges that contributors often have with Markdown is that it's really not very user friendly for editing and creating content pages.  Confluence or other Wiki style pages are a good place to enable not technical users to create content.  Unfortunately, they don't integrate well with source code control systems.  I'm going to look into some solutions whereby we can get some good content editing that integrates into git-based solutions.

Image Content

My biggest used for image content is with structured images, for example UML Use Case, Sequence and Class diagrams.  My goto editor for this material is PlantUML.  PlantUml has an Eclipse plugin that allows you to view UML diagrams within Eclipse while you edit the diagram in a text editor.  You can also run PlantUml from the command line to automate the process of image conversion.  This makes it really useful in automated builds.

XML and JSon Content

I'm really happy with Oxygen XML Editor for editing structured content like XML and JSON documents.  Happily, it also supports Markdown so I can use it for that too.  It has some features that are helpful for finding invalid Unicode characters, something that shows up frequently when you copy and paste text from Word into your markdown documents.

Converting from Microsoft Word or Other Formats

For those that have a lot of content already in Microsoft Word or PDF or other formats, PanDoc is an excellent open source tool for converting content between these formats and Markdown.  PanDoc supports a number of flavors of Markdown, including CommonMark which is the format used by the HL7 Implementation Guide Builder.

FHIR Profiles and Instances

There are a number of different tools that support building FHIR Profiles and instances.  The original FHIR specification build tools allow you to specify profile content in Microsoft Excel, but that's pretty complex tool chain for most user's.  Today, I'm using SUSHI which compiles FHIR Shorthand into Profiles and example instances.  This is an open source tool developed by an award winning team of people over at Mitre.  While still very much a work in progress, it's already saved me a tremendous amount of time, and the Mitre team has been very responsive.

Build Environment

Integrated Development Environment

These days I use Eclipse as my integrated development environment.  I'd love to figure out a way to make of the editing capabilities available using something like Confluence and provide some automated conversions so that when you create or update a content page, you have an easy way to edit the sub-components it requires (e.g., other content pages in links, or images or example content).

Build Automation

Right now my build environment is very much command line and batch file driven.  What I'd like to do is turn it into a Maven project with dependencies on the various editing and other tools described above.  That way I could build a template project which would automate the build of the IG Content.

IG Builder

I use HL7's IG Builder tool to generate an implementation guide.  Between that and github, it automatically deploys my draft IG to whenever I commit something.  However, I like to do a local build to confirm that I'm going to get what I want, and it takes less time to test things out that way.

To perform a local build, I also need to install Jekyll, and to use that I need Ruby.

Putting it All Together

To put this all together, what I'd love to see is an installer that would:
  1. Install or use an existing Java VM
  2. Install or use an existing set of Git Tools
  3. Install or use an existing set of Maven Tools
  4. Install or use an existing Eclipse installation
  5. Install PlantUML with Eclipse
  6. Install or use an Node.js installation (required for Sushi)
  7. Install or update the current version of Sushi
  8. Install or use an existing Ruby installation.
  9. Install or use the existing Ruby Dev Tools.
  10. Install or use an existing Jekyll installation.
  11. Provide an example projects with pre-constructed outlines following best practices for
    1. HL7 FHIR Implementation Guides
    2. IHE FHIR Implementation Guides / Profiles
    3. IHE non-FHIR Profiles (to demonstrate that IG Builder can be used for these).
  12. Provide example plantuml files for use cases, sequence diagrams, and actor / transaction diagrams that are often used in IHE profiles and could be used in other Implementation Guides.
  13. Provide documentation for the whole package on how to use the various parts of it.

Monday, February 17, 2020

It's that time again, but what? AGAIN!?!

One of the many unwritten rules of the Ad Hoc Harley award is that you can't earn it more than once.  I'm not going to change that now, but one of the previous recipients has done it again.  And for that, I'm awarding the rare (and heretofore never previous awarded) serious chrome upgrade for this contributors latest piece of work.

If you haven't heard about SUSHI (and no, I'm not talking about what I eat when I travel to standards meetings), and you build FHIR implementation guides, or implement FHIR resources, you NEED to learn about it, and the FHIR Shorthand language for creating FHIR Implementation Guide Resources.

Here's why:  Starting at 10:30 on Saturday, and working about 16 hours straight, I was able to do with SUSHI what in the past would have taken me 5 to 10 days of implementation effort.  As a result, I managed to put together an IHE Profile implementation guide from scratch in record time.

The ability to create implementation guides, value sets, capability statements, coding systems, any sample resource you might ever want in this simple language is simply fantastic.

So, here goes:

This certifies that
Chris Moesel of MITRE

has hereby been recognized AGAIN for awesome work with the rarely awarded and highly coveted Serious Chrome Upgrade.

And furthermore, no man is an island, and no open source project like this can possibly be done alone. So I get to repeat the Bike Week award (originally awarded to the Redoc Dozen).

Chris is working with a team of developers at MITRE that includes:

ngfreiter (Nicolas Freiter)

mint-thompson (Mint Thompson)

kjmahalingam (Dylan Mahalingam)

jafeltra (Julia Afeltra)

Let's give them all, and MITRE a round of applause.

Ad Hoc Bike Week Award

Wednesday, February 12, 2020

Bending the Healthcare Cost Curve means Cutting Jobs

You've all probably seen the charts. We spend far more in the US than other countries for healthcare.

It's been heading in the wrong direction for decades, and is getting worse.

It also isn't the best care in the world.  Other countries do better measured in many ways.  Lifespan is one of them.

And then finally, there's the growth of administrative costs in the US.

If you look at data from this Robert Wood Johnson study, you can see that Canada's administrative costs are about 15% of the US.

If we are to significantly bend the cost curve, the obvious place to go is after administrative expense.  If you consider the attention that the HL7 Da Vinci project has been getting on Prior Auth, you can see that this is definitely a pain point (even for payers).

And what does that mean?  I'm thinking it means that administrative jobs would disappear from the healthcare marketplace if done right, not providers.  Is this a bad thing?  Frankly, I don't think so.  But for those companies who primarily exist in the healthcare market to facilitate healthcare administration might have a different opinion.  After all, nobody who goes into business ever plans to get out of it.

But, that is the bottom line.  There's stuff we are spending money on in healthcare we don't need, and those who provide it will fight to keep it.