Claims Attachments and the Document Rewrite Problem -- 15 years later

In 2005 and 2006, I spent a significant amount of time explaining the "Document Rewrite" problem to the HL7 Claims Attachments (now renamed Payer/Provider Information Exchange) workgroup. 

In short, if you have an existing CDA (or C-CDA) document, and now, for regulatory reasons (for example, to attach a digital signature to it), you must open and rewrite the document, for a subsequent purpose (e.g., to attach an electronic [digital] signature for Claims Attachments), you've introduced a second artifact that must be separately identified, linked to the original, and stored; increasing costs of storage and implementation, and subsequent delays in deployments.  I suspect these additional costs are NOT accounted for in the current proposed rule.

This problem was original introduced in the Attachments AIS back in 2005 in an attempt to insert the attachment linking information into the original artifact, and is now a potential consequence associated with the electronic signature requirements of the currently proposed rule.  At least our institutional memory has had at least one opportunity to notify HHS of this problem again.

Honestly, I'm a supporter of EHRs adding a digital signature to the CDA artifact when the document is SIGNED by the provider creating it, but such technology is NOT readily available in certified EHR technology today. I don't believe that such an imposition should be made for attachments until after such technology is broadly available through certified EHR systems, and then only for documents created after such technology is required for use by healthcare providers under CMS programs.

Using Filebeats on Alpine Linux

One of the critical components for any interoperability component is monitoring.  I've played around with using ElasticSearch with SANER and used it for other projects. One of the important parts of this monitoring component is filebeat, which ships the logs to the Elastic cloud implementation.  Recently, I found that one of my AWS installation scripts stopped working over the April Fool's weekend.  All the more fool I for relying on SBEC (somebody else's code) to keep working.

We use Alpine Linux as the base for many of our Docker image deployments, like many others.  If, like me, you are also using filebeat, and have been relying on the Alpine testing APK repository, you probably noticed it no longer contains filebeat because of this commit.

If you've done as I have, your filebeat installation in your Dockerfile probably looks like this today and isn't working:

RUN echo http://dl-cdn.alpinelinux.org/alpine/edge/testing >> /etc/apk/repositories
RUN apk update
RUN apk add filebeat

To make it work with the penultimate release (using 8.6.2, since 8.7.0 was JUST released a few days ago), you'd replace that with the following.

RUN apk update
RUN apk add curl libc6-compat
ENV FILEBEAT_VERSION=8.6.2
RUN curl https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-${FILEBEAT_VERSION}-linux-x86_64.tar.gz \
  -o /filebeat.tar.gz && \
  tar xzvf filebeat.tar.gz && \
  rm filebeat.tar.gz && \
  mv filebeat-${FILEBEAT_VERSION}-linux-x86_64 filebeat && \
  cd filebeat && \
  cp filebeat /usr/bin

NOTE: If you leave out the libc6-compat, filebeat won't run. That took me a bit to track down

---

This may only be a short-lived problem, as I made a request to find out what it would take to get Filebeats back into the APK repository, and at least one contributed has indicated that they are willing to provide support for it (and possibly other beats applications).