Healthcare Standards

How AI is going to change the way we code and teach coding

2026-03-23T12:25:00.001-04:00

AI is already changing the way developers are approaching the development of code. I already spend a good bit of time directing AI in the features I'm building. Many schools have already added classes to incorporate the use of AI into development, and there's also classes being provided by AI developers to train people how to use the tools. But here's the rub, how does one gain the expertise I have without having had to do the work that I've done that makes able to correctly guide the AI in the first place?

With training changing, and development approaches also changing, will we reach the stage of Roman Concrete, in which up until recently, we couldn't do that anymore because the knowledge was not passed on?

Think about your development infrastructure, Maven, MySql, DynamoDB, Node, NextJS, AWS S3, SQS, SNS, Azure Blob Storage, SQL, et cetera? How will AI influence changes in that infrastructure and the APIs to manage it to make it easier to AI to develop applications for it. Will there be a new "REST" approach that incorporates what we've learned about using AI in development that makes AI assisted development better? Will we stop writing our APIs using Swagger or OpenDoc and start writing Markdown documents that help AI build an appropriate MCP or a skill instead? With spring-boot go away or be replaced by an AI-oriented substitute? Will our CLIs become AI advisors? Will we have to tell it three time to "sudo rm -r *"?

Will we be stop being able to write code without our AI symbiotes?

These are NOT things that keep me awake at night, but they do deserve some consideration.

Keith

Some thoughts while working with HAPI FHIR

2026-03-08T04:40:00.001-04:00

As far as I'm concerned, HAPI on FHIR is THE way to go when working with FHIR Resources in Java. However, one of challenges I've had with HAPI is having to write conditional code based on the type of resource I'm working with when I'm handling similar fields, for example setPatient/getPatient/hasPatient or setSubject/getSubject/hasSubject. A number of FHIR Resources have these common setter/getter patterns, and not just with references. Another example is for primitive fields, such as dateTime.

This makes writing automation code somewhat difficult.

I'd love to see some interfaces defined for common 5W patterns that are commonly used on FHIR Resources be introduced that encapsulate the set/get/has methods. These interfaces could be named using the pattern: HasX or HasXList, where X is the field name. Some examples of these follow:

public interface HasSubject {
HasSubject setSubject(Reference subject);
Reference getSubject();
boolean hasSubject();
}

public interface HasOrganizationList {
HasOrganizationList addOrganization(Reference);
Reference addOrganization();
List<Reference> getOrganization();
HasOrganizationList setOrganization(List<Reference> orgList);
Reference getOrganizationFirstRep();
}

This would mean that I could use:

if (x instanceof HasSubject hs) {
hs.setSubject(patient);
} else if (x instanceof HasPatient hp) {
hp.setPatient(patient);
}

Which would make certain automation related code a lot easier.

You might need to make the interfaces use a template parameter for the type to address certain differences in name use, e.g., HasEffectiveTime<DateTimeType> or HasEffectiveTime<InstantType>.

My @GithubCopilot experience with #AI coding

2026-02-26T09:20:00.004-05:00

I've been using Github Copilot for a few months now and thought I would share some of my experiences with it. Overall, I would say my experience with Copilot is good, and it's enabled me to do some things that I would have taken much longer to do by myself. It hasn't stretched beyond my personal reach but would certainly do so for some junior engineers.

I have multiple GitHub accounts. I like the fact that I can use my corporate GitHub account to cover my charges on it, even though to do work I am checking in via a different account.
With respect to Ask vs. Agent modes, I generally like to work in Agent mode unless I want Copilot to just answer a question without making code changes. Ask is show, Agent is do.
I've experimented with a few agents:

The default, ChatGPT 4.5 is decent, but pretty much at the Junior engineer level.
ChatGPT Codex Max is more senior, but also very slow. It's like the old fart of the agents. I can't wait areound for Codex Max to get off it's duffer.
Claude seems to be young, eager and a lot more skilled and detail oriented. I'll probably stick with Claude for a while.
Claude can stumble down a rat hole and go pretty deep. Cancel intermediate actions or press the stop button if you want to interrupt its thought processes and redirect it.

The Eclipse (yeah, I'm definitely an Old Fart as far as that goes) GitHub Copilot integration is more limited in what it can do as compared to Copilot in IntelliJ or VS-Code. It may be enough to finally make me make the switch to IntelliJ, but that is several decades of muscle memory I am loathe to give up.
OpenSpec is truly awesome for organizing and documenting work with AI. So far, I've only used it with Claude, am I'm very happy with the results. I've used it to add a feature to my CDA to FHIR Parser, and it came up with a very complete set of requirements, design, and implementation plan. Yes, I DID have to add some detail but not really correct anything. As an adjunct to AI development, it is very helpful.

ASTP / ONC issues Diagnostic Imaging RFI

2026-02-05T13:25:00.002-05:00

ASTP/ONC recently issued a Diagnostic Imaging Request for Information. Here are the questions, and my (personal) responses to them:

I'll start off by saying we are well beyond the time where this capability needs to be available to patients and providers in the national Health IT Infrastructure.

PM-1. What barriers do patients experience with electronic access to diagnostic images? Are there examples today where patients can successfully access, exchange, and use diagnostic images outside of a particular hospital or network system without use of physical media?

My son's partner had to travel an extra 20 minutes each way for imaging instead of going to the closed imaging center associated with a hospital from the same system (UMASS). More than a year after UMASS acquired this facility, there still was not imaging interoperability between the related facilities. It simply wasn't a priority b/c only the patient is inconvenienced. That's within the SAME hospital system. It's even worse between different systems.

I'm still in the habit of getting CDs (physical media) from imaging providers b/c of the lack of interop between facilities. I don't have this problem with my present provider network b/c they do focus on access between providers, but I've seen that even they have challenges when trying to get images from hospital imaging centers they work with.

PM-2. What existing policies do you believe limit or interfere with diagnostic image access, exchange, and use? What policies would you introduce to accelerate the transition to electronic, standards-based diagnostic image access and exchange and to reduce the practice of imaging silos that impede electronic access, exchange, or use of diagnostic images

PM-2A. What other policy or financial barriers do providers face in accessing diagnostic images from outside facilities? For example, are there concerns about compliance with health care facility policies or procedures (e.g., security or overall policies on data sharing outside the facility), state laws, or malpractice liability?

Accessing prior imaging results reduces the financial compensation provided to specialty providers with their own imaging centers, by reducing the need for subsequent imaging, as several studies have shown (e.g., Outside imaging in emergency department transfer patients: CD import reduces rates of subsequent imaging utilization - PubMed)

PM-2B. What technical/interoperability concerns exist, such as compatibility between systems, authorization issues from external sources, or issues with the provenance of diagnostic images?

The same study listed above indicates that 78% of images were able to be imported. I wrote in 2012 about Medical Imaging Exchange and referenced a study (no longer available on the web) that cited 80% import success. David Clunie (the acknowledged Father of DICOM) presented at RSNA in 2010 on the key reasons for import failures, failure to follow the DICOM standard, and presented a number of recommendations. While this report applied to images on media, the import failures over the internet will use the same standards in that report. The standards are available; they simply need to be followed.

PM-3. What technical, operational, and policy approaches can best support health care providers in transitioning from physical media ( e.g., CDs and DVDs) to secure, electronic exchange-based methods for sharing diagnostic images outside of their operating environment/health care organization system? If possible, please be detailed in your response.

The technical approaches should focus on XCA-I, which builds on the existing XCA standards used for National Networks and TEFCA today, DICOM for imaging, including some of the requirements about use of DICOM in the IHE Portable Data for Imaging and other related image sharing profiles, and commonly used metadata standards, with the incorporation of RADLEX for certain imaging metadata. The application of these technical and to some degree operational approaches (e.g., for metadata) build incrementally from already existing, widely support standards available for sharing of health information over the internet.

One key policy to consider is that image sharing challenges occur not just across health systems, but even within health systems. For a provider to be considered compliant (from a CMS rather than an ASTP/ONC perspective), imaging should be available electronically WITHIN and ACROSS the entire health system as well as from outside the system.

PM-4. Do health care providers and/or patients (including patient-facing apps) need access to the full resolution diagnostic images stored in PACS or is a reference image ( e.g., a DICOM image rendered as a JPEG) sufficient for clinical decision-making and use by health care providers and patients? Does this vary by clinician specialty or by type(s) of care provided to the patient? Please feel free to elaborate with rationale.

For the most part, for personal use, patients typically only need a reference image ... UNTIL they need to provide imaging access to another provider. At that point, the full resolution diagnostic image will be needed so that the consulting provider (e.g., for a follow-up or second opinion) may want access to the full resolution image.

Many ambulatory primary care providers likely only need access to a reference image, but specialty providers will definitely want full resolution diagnostic images so that they can use the imaging tools they have at hand to manipulate and view the image data.

Image exchange should enable both reference image access, and full resolution access to the imaging study to enable all use cases.

PM-5. Do health care providers and/or patients need access to quantitative parameters derived from images for clinical decision-making and use by providers and patients? Please feel free to elaborate with rationale.

Numerous quantitive parameters are useful for clinical decision support, and many also have specific places in the provider chart that enable provider workflows (e.g., in flowsheets and diagnostic results such as Cardiac ECHO and Stress Test).

SC-1. What technical approaches are currently in use to enable access and/or exchange of diagnostic images between health care systems and health information networks? To what extent are these methods based on standards ( e.g., DICOM, DICOMweb^TM, FHIR®, IHE® XDS-I, IHE® XCA-I) versus proprietary or custom integrations?

XDS-I.b is readily supported by 7 out of 8 vendors listed in Definitive Healthcare's "Top 13 PACS by Number of Installs" report. I determined this by downloading data from the IHE Connectathon Global Results page selecting the Cross Enterprise Document Sharing for Imaging (XDS-I.b) profile and comparing the listed companies against the companies listed in the Definitive Healthcare Report. There are 126 companies that have demonstrated support for XDS-I at IHE Connectathons.

XCA-I is readily supported by 5 out of 8 vendors listed in that report. XCA-I is simply the cross-community version of XDS-I and requires modest technical changes for implementation over the XDS-I implementation. I implemented a simple Web Viewer imaging application in 2010 using widely available open-source software while at RSNA on a system that already supported XDS and XCA in about 3 days, as I mentioned in "The Right Tools". It is a very modest lift from the existing XDS/XCA based national networking protocols.

SC-2. What metadata and other information is currently associated with diagnostic images for purposes of access and exchange, including images exchanged using different standards and custom integrations? Please feel free to elaborate on the use of artificial intelligence tools in adding metadata to images and additional information to accompany an image.

Key metadata for imaging that needs standardization are the codes used to describe the imaging procedure. Arguably, SNOMED CT and CPT could be used here but also consider RADLEX for the imaging procedure. Other metadata (e.g., reason for procedure, diagnosis) would also be useful for searching for imaging results. The modality (X-RAY, CT, MRI, SPECT, Ultrasound) is another key piece of metadata.

SC-3. What technical barriers, such as proprietary interfaces or ambiguous standards, limit the access, exchange, and use of diagnostic images across health IT systems (including by patient-facing apps), and should existing technical standards be further modified (please identify the standard)?

Assuming conformance to XDS-I.b or XCA-I, the real technical barriers are related to custom DICOM data supported and used by imaging modalities and/or generated by imaging workstations. Even so, several reports indicate 80% success rate importing DICOM images from media or networks. The failures are most often attributable to failure to follow the DICOM standard.

SC-4. How do certified health IT and/or EHRs enable or facilitate access, exchange, and use of diagnostic images today? Specifically, do EHRs play an active role in diagnostic image exchange, or is the functionality primarily driven by imaging systems such as PACS and VNAs?

While I'm told that you can get access to imaging studies through MyChart, my own experience with my provider is that such access is not available to patients. I have had in the past similar experience with EHR and PHR systems from vendors who have shown the capability to enable imaging access (in other words, the product supposedly supports image links, but the provider doesn't enable it), but that experience is somewhat dated.

Most imaging exchange systems that I have had experience with rely on PACS or VNAs, which makes this another reason to keep imaging exchange a separate criterion (see below).

SC-5. Should ASTP/ONC update the Certification Program to support the access, exchange, and use of diagnostic images? For example, an image access requirement could be added to the existing VDT certification criterion or additional imaging data elements could be included in the United States Core Data for Interoperability (USCDI).

ASTP should update the certification program. Additional data elements supporting imaging specific metadata should be included in USCDI, including imaging procedure and modality (see RADLEX). LOINC and SNOMED CT should be the vocabular used for other imaging metadata.

I'm not certain whether it would be more appropriate to create a separate certification criterion to support imaging data exchange, or if it would be better to combine this with the existing VDT criterion. I think generally, the long-term goal is that VDT should support both documents and images. Creating a separate criterion for it reduced vendor and provider burden by allowing for certification to the separate imaging access criteria, which would make it possible for it to be phased in over a longer period of time.

Because imaging data exchange is more usually handled by PACS or VNA, it's likely better kept as a separate criterion.

SC-6. Should there be a focus on particular, individual diagnosis and treatment use cases (e.g., ocular imaging)? Are there specific requirements that need to be considered for use cases in other fields?

I do not think imaging should NOT focus on a singular use case, modality or specialty. Instead, it should focus on imaging studies in general, perhaps with a specific minimum set of common modalities, including X-RAY, CT, MRI and Ultrasound.

I've had my eye doctor routinely text or otherwise send me my retina images (which I store on my phone), and the quality of that JPEG image is more than sufficient for retinopathy investigations, so would completely rule out the most common ocular imaging use case.

SC-7. Could image management systems, such as PACS and VNAs, be certified to specific certification criteria that would improve interoperability between these systems and EHRs and make access to diagnostic images available to “outside” providers and patients (including patient-facing apps)? What standards and capabilities should these certification criteria include?

IHE XCA-I, and DICOM provide sufficient criteria to support reliable imaging exchange.

SC-8. Beyond or absent the certification of health IT to specific technical standards, what diagnostic image-related standards should ASTP/ONC adopt on behalf of HHS to improve interoperability and health IT alignment?

Strict DICOM compliance is critical to ensure images can be used by the receiving system.

SC-9. Are there unique privacy and security concerns related to the access, exchange, and use of diagnostic images that may not exist with other types of health information?

Anyone who's watched any TV show that stars a medical examiner likely understands that imaging data IS PHI. The particular shape, placement, or measurement of internal organ characteristics is often sufficient to identify an individual, beyond just basic dental X-rays. It is simply NOT possible to deidentify such data.

SC-10. Would further development and adoption of the SMART® Imaging Access draft specification help address the access, exchange, and use of diagnostic images, as well as any specific privacy and security concerns related to such access, exchange, and use?

SMART Imaging Access relies on DICOM WADO, which is a later specification than XCA-I, and may be a more viable long-term approach. RSNA strongly supports the use of WADO-RS, which also has better integration than FHIR. I'm somewhat out of the loop on imaging systems these days, so cannot adequately speak to the support for WADO-RS in the imaging space, but it definitely seems like the appropriate long-term approach.

As to whether it would be better to adopt XCA-sooner I due to the light adaption necessary in existing national network specifications or focus more on WADO-RS and FHIR with SMART depends on timing and industry readiness. The lack of "hype" about SMART Imaging Access leads me to believe that it and possibly WADO-RS are not really ready for adoption yet.

References:

Top 13 PACS by Number of Installs, Definitive Healthcare, 2024, https://www.definitivehc.com/resources/healthcare-insights/top-PACS-number-installs

IHE Connectathon Global Results, Integrating the Healthcare Enterprise, 2025, https://connectathon-results.ihe.net/custom-search/

Outside imaging in emergency department transfer patients: CD import reduces rates of subsequent imaging utilization, PubMed, https://pubmed.ncbi.nlm.nih.gov/21507903/

The Right Tools, Healthcare Standards, Keith W. Boone, 2010, https://motorcycleguy.blogspot.com/2008/12/right-tools-make-any-job-easy.html

Medical Imaging Exchange, Healthcare Standards, Keith W. Boone, 2012, https://motorcycleguy.blogspot.com/2012/01/medical-imaging-exchange.html

Sharing Images on CD, DVD & USB: Standards, Tools & IHE PDI, IRWF and BIR Profiles, RSNAN, David Clunie, 2010, https://www.dclunie.com/papers/rsna2010_pdi_clunie.pdf

HL7 V2 to FHIR

2026-01-07T09:51:00.003-05:00

You may have seen my guest post on Healthcare IT Today about Why Public Health Data needs to Modernize a few months back. I've been working to support this for years, and in October 2025, HL7 achieved a pretty significant goal supporting that. The HL7 Version 2 to FHIR Standard for Trial Use was finally published.

I have been working on the HL7 Version 2 to FHIR project since the initial inception in late 2018, almost at the same time as I started at Audacious Inquiry. My first project at Audacious was to create a V2 to FHIR Converter, which we did build and provide to some of our customers. Audacious contributed the mappings our team developed (mostly through efforts of our product owner and me, with some help from our HL7 V2 interface developers) to the project in early 2019, and they became the initial spreadsheets that were used to create the HL7 V2 to FHIR guide.

I now have the somewhat dubious attribute as having be an editor working on one of the longest running projects from inception to STU publication in HL7 history (7 years). Yes, I am certain some have run longer, but none that I can think of off the top of my head. Part of my editorial role in the early days was to have evolved the effort to represent the content in spreadsheets, and then to translate (in code), those nearly 400 spreadsheets into over 250 FHIR ConceptMap resources. More recently, it has been maintenance of the V2 to FHIR IG generator code base, and detailed technical review of the content produced in the guide to verify that it can be accessed in computable form, not just via spreadsheets but through the FHIR Resources, and ensuring that all content is consistently handled and can be used to automatically generate a V2 to FHIR converter.

I'm thrilled to see this finally published, and our team has been working on turning the output of this guide into a Data Modernization offering for public health that will enable them to turn legacy data into FHIR resources that can be accessed through modern APIs. We are working on a completely new software base to support V2 and CDA to FHIR conversions we'll be talking more about at HIMSS 26.

It's still Wednesday at the HL7WGM (barely)

2025-09-17T23:02:00.002-04:00

It's been too long since I've written an HL7 Plenary Wednesday post, but if you understand the history of this blog, you know what is coming. For rather understandable reasons, I have shifted a great deal of my focus towards implementations and standards supporting Public Health, rather than the EHR space. Some of that has to do with what my employer Audacious Inquiry does, but other parts of that stem from seeing an unmet need that can impact people around my country, and even more so, the public health people working very hard, and on very limited budgets to keep us all healthy. That unmet need became even more apparent as we went through COVID-19 and are still in many ways recovering from it.

Significant effort is underway even now to connect public health to the health information eco-system that we in HL7, IHE and other organizations have been creating for patients. One of those efforts is to enable public health agencies to connect to that eco-system through TEFCA and national networks to make it easier, cheaper and faster to do the jobs that need to be done, and to improve the infrastructure that is long overdue for a major upgrade.

Over the last couple of years, I met a young leader whose team is developing tools to enable public health agencies connect to the Health Information Superhighway we have been trying to create for the past two decades. Over the past year, I worked closely with him and his team at two different FHIR Connectathon events to better enable agencies to build on-ramps to that expressway. Through his work, I've been able to make some on-ramps of my own that should enable public health agencies better access to their own data using a more modern infrastructure and achieve a five-year goal I set for myself back in early 2021.

This next recipient is someone I've not had a chance to watch over a long period of time, nor see him grow (though I know he has even in the short time I've known him). He does what all good leaders do, which is to enable others to succeed, and by others, in this case, I mean me. We have infrequent contact, we don't really work on the same project, but where our roles intercept, he's made it possible for me achieve a significant goal. Without further ado, here's the next Ad Hoc Harley.

For Daniel Paseltiner, of Skylight

For leadership that enabled me an opportunity to nail a 5-year goal

P.S. I know this post was more about me than Dan, and for that, I'm sorry. I do wish Dan and I had more opportunities to work more closely together on a project. To see some of the work of Dan and his team, check out the DIBBS Query Connector project on GitHub.

A syntax for validating V2toFHIR Conversions

2025-07-09T09:30:00.006-04:00

I've been working on V2toFHIR since its inception. A month ago, and back in January I participated in two Connectathons that are using that capability from this code. In building that engine, I needed a way to test a conversion of an HL7 message in a way that would make it easier for me to write detailed tests.

The input to a test is an HL7 V2 message with segments. A very long time ago, I resolved to use plain-text files containing messages and divide them with a blank line. Here's an example below of a file with two messages I've previously used for other purposes at IHE Connectathons (I have several years of IHE Connectathon test data lying about):

# Outbound ack:

MSH|^~\&|PAT_IDENTITY_X_REF_MGR_MISYS_TLS|ALLSCRIPTS|OTHER_IBM_BRIDGE_TLS|IBM|20090224114149-0500||ACK^A04|OpenPIXPDQ10.243.0.65.19767899354465|P|2.3.1

MSA|AA|0851077658473390286

# PIX Feed (ADT^A01)

# Inbound feed:

MSH|^~\&|OTHER_IBM_BRIDGE_TLS|IBM|PAT_IDENTITY_X_REF_MGR_MISYS|ALLSCRIPTS|20090224104152-0600||ADT^A01^ADT_A01|8686183982575368499|P|2.3.1

EVN||20090224104152-0600

PID|||102^^^IBOT&1.3.6.1.4.1.21367.2009.1.2.370&ISO||SINGLETON^MARION||19661109|F

PV1||I

You might also note that I allow for comment characters at the start of the line. My test framework simply ignores those lines while reading the test data, and if gives me a way to identify the test case. For testing V2 to FHIR Conversions, I needed a way to create assertions that would be used to verify the assertion. Of course, FHIRPath comes to mind because it's already an expression language widely used in FHIR itself for assertions and other manipulations of FHIR Resources. That's ideal language for my use case.

So, I added a capability in my test case reader to add assertions to the test case. Here's an example for the first test case above. The @ sign introduces an assertion.

@MessageHeader.source.name = "PAT_IDENTIFY_X_REF_MGR_MISYS_TLS"

@MessageHeader.source.endpoint = "ALLSCRIPTS"

@MessageHeader.destination.name = "OTHER_IBM_BRIDGE_TLS"

@MessageHeader.destination.endpoint = "IBM"

I'm actually checking a bundle but use a little string substitution hackery to replace MessageHeader with %context.entry.resource.ofType(MessageHeader) at the head of the expression to save me about 31 characters of typing each time.

The next bit of fun is enabling the assertions to come close to where they are useful in the message. It should be obvious that each test case has two streams of data, the message, and the assertions. They can easily be interwoven. So, assertions can easily follow the segment, but I also wanted more, because some segments can be very long. Borrowing from other scripting languages (e.g., bash), I allow the introduction of the \ character at the end of the line to allow lines to be continued. I realized that it would be important to visually see the start an end of a segment in the file, so I ignore leading whitespace at the beginning of continuation lines. So now I can write:

# Outbound ack:

MSH|^~\&|\

PAT_IDENTITY_X_REF_MGR_MISYS_TLS|\

@MessageHeader.source.name = "PAT_IDENTIFY_X_REF_MGR_MISYS_TLS"

ALLSCRIPTS|\

@MessageHeader.source.endpoint = "ALLSCRIPTS"

OTHER_IBM_BRIDGE_TLS|\

@MessageHeader.destination.name = "OTHER_IBM_BRIDGE_TLS"

IBM|20090224114149-0500|\

@MessageHeader.destination.endpoint = "IBM"

|ACK^A04|OpenPIXPDQ10.243.0.65.19767899354465|P|2.3.1

MSA|AA|0851077658473390286

And so forth. In this way, I now have a test case where I can start with the message in my usual form (simple text with a blank line between cases). From there I can augment the test case with assertions that I feel are important. Following that, I can also break things up, even just long lines of V2 messages to make the test files more readable.

The final piece of this was to allow long assertions to be broken up the same way messages are, and to steal the final comment in the assertion expression (comments are part of FHIRPath syntax) to use for my assertion message in my testing framework. That's also just simple string substitution as well.

You can find all of the code for this in V2toFHIR, the open-source converter my team and I created for some of our ongoing work. The two key files of interest are MessageParserTests.java and TestData.java. The method TestData.load() is where all the test input parsing magic happens. It's not really that complicated.

Code generators need not be perfect

2025-06-02T09:07:00.001-04:00

Le mieux est le mortel
ennemi du bien. -- Voltaire

I've been working on expanding the v2tofhir code that Audacious Inquiry developed for one of our projects into a broader offering for public health that handles more than just Immunization messages. That's not going back into the original open-source work, as it is not within the scope of that program. But it is going to become an application available to our customers. Contact me if you want to learn more.

One thing I relearned from my vibe coding session with Copilot is that code generators don't have to be perfect -- although it certainly helps if they are. I already know from years of experience working with natural language processing is that heuristics can often get you most of the way there, and specialized exception handling can handle what the heuristic doesn't.

By putting these two ideas together I can successfully generate code for the 2700+ mapping rules in the current HL7 V2 to FHIR specification in just minutes. This makes my code generator immediately effective to support the 75 or so segment mapping tables supported by that specification. With a few minutes, I can generate code to support every segment, and within a few hours more, can correct all of the missing bits.

The compiler is a perfect tool for detecting the exception cases. Like a canary in a coal mine, it is especially sensitive to danger. The code generator I'm still developing has been an excellent QA resource for the HL7 V2 to FHIR spec, as it enables me to verify content in the spec. Some errors in the generated output are actually caused by typos in the over 10000 lines of CSV data that is used to generate the HL7 standard.

This is a tremendous lift for development, and as we figure out the patterns of errors, we can easily augment the code generator to fix them. While that's being done, we still have code that we can tweak to perfection in much less time than it takes to generate it manually. It also reduces the amount of SME expertise needed to create the application.

The original open-source code took a more manual approach to automation (I was actually trying to figure out the process in using spreadsheets). It took about 3 months of work to handle about 20 segments. Easily half of that was putting together the surrounding infrastructure rather than parsing individual segments. The code generator took about a week to build. It gets very close to final code for 75 segments. These leave me about 40-50 errors to resolve, most of which are simple. I'm expecting another week or two will be needed to handle those issues in the generated code. This is easily an order of magnitude improvement. It can be repeated on new editions of the V2 to FHIR outputs much faster than fixing the code by hand, which also speeds up maintenance.

Two Guys in a Garage

2025-04-30T17:53:00.005-04:00

COVID-19 impacted many things in a bad way but also had some beneficial impacts on Public Health infrastructure and adjoining technologies. This long overdue post recognizes a small team whose impact on Public Health data has been tremendous. In my work on IZ Gateway, I was first introduced to these two entrepreneurs, almost literally two guys in a garage, who had developed a wicked cool application. While I cannot personally benefit from this application today, my brother and his family live in a state where, because of this application, they can access their immunization data directly from the New Jersey IIS.

I got to work with this team a couple of years ago at a demonstration of the IZ Gateway and their application, and on the last day of the Interoperability Showcase, I got to be the demonstrator pitching what this application does to the showcase audience. The application they have built is truly an engine for change. This Ad Hoc Harley goes to two guys, Michael Perretta and Nathan Scott, founders of Docket, who have truly shown what can be done with the right vision and skills.

This Certifies that

Michael Perretta and Nathan Scott

Have been hereby recognized for being engines of change in Public Health

Imagine riding with this engine under your seat.

HIPAA Security Section 312 Changes

2025-02-07T13:09:00.005-05:00

Earlier this week I provided a side-by-side comparison of the HIPAA section 308 changes. Today I have a similar sheet for Section 312. Next week I should have a summary prepared of what this comparison tells you.

Once again, green background is new content. Yellow background is mostly unchanged, and red background is stuff that has been removed from the rule (there's not much that was removed).

New Section #	New Text	Old Section #	Old Text
312	§ 164.312 Technical safeguards.	312	§ 164.312 Technical safeguards.
	Each covered entity or business associate must, in accordance with §§ 164.306 and 164.316, implement all of the following technical safeguards, including technical controls, to protect the confidentiality, integrity, and availability of all electronic protected health information that it creates, receives, maintains, or transmits:		A covered entity or business associate must, in accordance with § 164.306:
312(a)	(a) Standard: Access control	312(a)(1)	(a) (1) Standard: Access control.
312(a)(1)	—(1) General.
	Deploy technical controls in relevant electronic information systems to allow access only to users and technology assets that have been granted access rights.		Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4).
312(a)(2)	(2) Implementation specifications	312(a)(2)	(2) Implementation specifications:
312(a)(2)(i)	—(i) Unique identification.	312(a)(2)(i)	(i) Unique user identification (Required).
	Assign a unique name, number, and/or other identifier for tracking each user and technology asset in the covered entity or business associate's relevant electronic information systems.		Assign a unique name and/or number for identifying and tracking user identity.
312(a)(2)(ii)	(ii) Administrative and increased access privileges.
	Separate user identities from identities used for administrative and other increased access privileges.
312(a)(2)(iii)	(iii) Emergency access procedure.	312(a)(2)(ii)	(ii) Emergency access procedure (Required).
	Establish (and implement as needed) written and technical procedures for obtaining necessary electronic protected health information during an emergency.		Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.
312(a)(2)(iv)	(iv) Automatic logoff.	312(a)(2)(iii)	(iii) Automatic logoff (Addressable).
	Deploy technical controls that terminate an electronic session after a predetermined time of inactivity that is reasonable and appropriate.		Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.
312(a)(2)(v)	(v) Log-in attempts.
	Deploy technical controls that disable or suspend the access of a user or technology asset to relevant electronic information systems after a reasonable and appropriate predetermined number of unsuccessful authentication attempts.
312(a)(2)(vi)	(vi) Network segmentation.
	Deploy technical controls to ensure that the covered entity's or business associate's relevant electronic information systems are segmented in a reasonable and appropriate manner.
312(a)(2)(vii)	(vii) Data controls.
	Deploy technical controls to allow access to electronic protected health information only to those users and technology assets that have been granted access rights to the covered entity's or business associate's relevant electronic information systems as specified in § 164.308(a)(10).
312(a)(2)(viii)	(viii) Maintenance.
	Review and test the effectiveness of the procedures and technical controls required by this paragraph (a)(2) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
312(b)	(b) Standard: Encryption and decryption
312(b)(1)	—(1) General.
	Deploy technical controls to encrypt and decrypt electronic protected health information using encryption that meets prevailing cryptographic standards.	312(a)(2)(iv)	(iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.
312(b)(2)	(2) Implementation specification.
	Encrypt all electronic protected health information at rest and in transit, except to the extent that an exception at paragraph (b)(3) of this section applies.	312(e)(2)(ii)	(ii) Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.
312(b)(3)	(3) Exceptions.
	This paragraph (b)(3) applies only to the electronic protected health information directly affected by one or more of the following exceptions and only to the extent that the covered entity or business associate documents that an exception applies and that all other applicable conditions are met.
	(i) The technology asset in use does not support encryption of the electronic protected health information consistent with prevailing cryptographic standards, and the covered entity or business associate establishes and implements a written plan to migrate electronic protected health information to a technology asset that supports encryption consistent with prevailing cryptographic standards within a reasonable and appropriate period of time.
	(ii) An individual requests pursuant to § 164.524 to receive their electronic protected health information in an unencrypted manner and has been informed of the risks associated with the transmission, receipt, and storage of unencrypted electronic protected health information. This exception does not apply where such individual will receive their electronic protected health information pursuant to § 164.524 and the technology used by the individual to receive the electronic protected health information is controlled by the covered entity or its business associate.
	(iii) During an emergency or other occurrence that adversely affects the covered entity's or business associate's relevant electronic information systems in which encryption is infeasible, and the covered entity or business associate implements reasonable and appropriate compensating controls in accordance with and determined by the covered entity's or business associate's contingency plan under § 164.308(a)(13).
	(iv) The technology asset in use is a device under section 201(h) of the Food, Drug, and Cosmetic Act, 21 U.S.C. 321(h) that has been authorized for marketing by the Food and Drug Administration, as follows:
	(A) Pursuant to a submission received before March 29, 2023, provided that the covered entity or business associate deploys in a timely manner any updates or patches required or recommended by the manufacturer of the device.
	(B) Pursuant to a submission received on or after March 29, 2023, where the device is no longer supported by its manufacturer, provided that the covered entity or business associate has deployed any updates or patches required or recommended by the manufacturer of the device.
	(C) Pursuant to a submission received on or after March 29, 2023, where the device is supported by its manufacturer.
	(4) Alternative measures
	—(i) Alternative measures.
	Where an exception at paragraph (b)(3) of this section applies, a covered entity or business associate must document in real-time the existence of an applicable exception and implement reasonable and appropriate compensating controls in accordance with paragraph (b)(4)(ii) of this section.
	(ii) Compensating controls.
	(A) To the extent that a covered entity or business associate determines that an exception at paragraph (b)(3)(i), (ii), or (iii) or (b)(3)(iv)(A) or (B) of this section applies, the covered entity or business associate must secure such electronic protected health information by implementing reasonable and appropriate compensating controls reviewed and approved by the covered entity's or business associate's designated Security Official.
	(B) To the extent that a covered entity or business associate determines that an exception at paragraph (b)(3)(iv)(C) of this section applies, the covered entity or business associate shall be presumed to have implemented reasonable and appropriate compensating controls where the covered entity or business associate has deployed the security measures prescribed and as instructed by the authorized label for the device, including any updates or patches recommended or required by the manufacturer of the device.
	(C) To the extent that a covered entity or business associate is implementing compensating controls under this paragraph (b)(4)(ii), the implementation and effectiveness of compensating controls must be reviewed, documented, and signed by the designated Security Official at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, to continue securing electronic protected health information and relevant electronic information systems.
	(5) Maintenance.
	Review and test the effectiveness of the technical controls required by this paragraph (b) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

312(c)	(c) Standard: Configuration management
	—(1) General.
	Establish and deploy technical controls for securing the covered entity's or business associate's relevant electronic information systems and technology assets in its relevant electronic information systems, including workstations, in a consistent manner, and maintain such electronic information systems and technology assets according to the covered entity's or business associate's established secure baselines.
	(2) Implementation specifications
	—(i) Anti-malware protection.
	Deploy technology assets and/or technical controls that protect all of the covered entity's or business associate's technology assets in its relevant electronic information systems against malicious software, including but not limited to viruses and ransomware.
	(ii) Software removal.
	Remove extraneous software from the covered entity's or business associate's relevant electronic information systems.
	(iii) Configuration.
	Configure and secure operating system(s) and software consistent with the covered entity's or business associate's risk analysis under § 164.308(a)(2).
	(iv) Network ports.
	Disable network ports in accordance with the covered entity's or business associate's risk analysis under § 164.308(a)(2).
	(v) Maintenance.
	Review and test the effectiveness of the technical controls required by this paragraph (c) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
312(d)	(d) Standard: Audit trail and system log controls	312(b)	(b) Standard: Audit controls.
312(d)(1)	—(1) General.
	Deploy technology assets and/or technical controls that record and identify activity in the covered entity's or business associate's relevant electronic information systems.		Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.
312(d)(2)	(2) Implementation specifications
	—(i) Monitor and identify.
	The covered entity or business associate must deploy technology assets and/or technical controls that monitor in real-time all activity in its relevant electronic information systems, identify indications of unauthorized persons or unauthorized activity as determined by the covered entity's or business associate's risk analysis under § 164.308(a)(2), and alert workforce members of such indications in accordance with the policies and procedures required by § 164.308(a)(7).
	(ii) Record.
	The covered entity or business associate must deploy technology assets and/or technical controls that record in real-time all activity in its relevant electronic information systems.
	(iii) Retain.
	The covered entity or business associate must deploy technology assets and/or technical controls to retain records of all activity in its relevant electronic information systems as determined by the covered entity's or business associate's policies and procedures for information system activity review at § 164.308(a)(7)(ii)(A).
	(iv) Scope.
	Activity includes creating, accessing, receiving, transmitting, modifying, copying, or deleting any of the following:
	(A) Electronic protected health information.
	(B) Relevant electronic information systems and the information therein.
	(v) Maintenance.
	Review and test the effectiveness of the technology assets and/or technical controls required by this paragraph (d) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
	(e) Standard: Integrity.	312(c)(1)	(c)(1) Standard: Integrity.
	Deploy technical controls to protect electronic protected health information from improper alteration or destruction, both at rest and in transit;		Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.
	and review and test the effectiveness of such technical controls at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
		312(c)(2)	(2) Implementation specification: Mechanism to authenticate electronic protected health information (Addressable). Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.
		312(e)(2)(i)	(i) Integrity controls (Addressable). Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.
312(f)	(f) Standard: Authentication	312(d)	(d) Standard: Person or entity authentication.
	—(1) General.
	Deploy technical controls to verify that a person or technology asset seeking access to electronic protected health information and/or the covered entity's or business associate's relevant electronic information systems is the one claimed.		Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.
	(2) Implementation specifications
	—(i) Information access management policies.
	Deploy technical controls in accordance with the covered entity's or business associate's information access management policies and procedures under § 164.308(a)(10), including technical controls that require users to adopt unique passwords that are consistent with the current recommendations of authoritative sources.
	(ii) Multi-factor authentication.
	(A) Deploy multi-factor authentication to all technology assets in the covered entity's or business associate's relevant electronic information systems to verify that a person seeking access to the relevant electronic information system(s) is the user that the person claims to be.
	(B) Deploy multi-factor authentication for any action that would change a user's privileges to the covered entity's or business associate's relevant electronic information systems in a manner that would alter the user's ability to affect the confidentiality, integrity, or availability of electronic protected health information.
	(iii) Exceptions.
	Deployment of multi-factor authentication is not required in any of the following circumstances.
	(A) The technology asset in use does not support multi-factor authentication, and the covered entity or business associate establishes and implements a written plan to migrate electronic protected health information to a technology asset that supports multi-factor authentication within a reasonable and appropriate period of time.
	(B) During an emergency or other occurrence that adversely affects the covered entity's or business associate's relevant electronic information systems or the confidentiality, integrity, or availability of electronic protected health information in which multi-factor authentication is infeasible and the covered entity or business associate implements reasonable and appropriate compensating controls in accordance with its emergency access procedures under paragraph (a)(2)(iii) of this section and the covered entity's or business associate's contingency plan under § 164.308(a)(13).
	(C) The technology asset in use is a device under section 201(h) of the Food, Drug, and Cosmetic Act, 21 U.S.C. 321(h) that has been authorized for marketing by the Food and Drug Administration, as follows:
	(1) Pursuant to a submission received before March 29, 2023, provided that the covered entity or business associate has deployed any updates or patches required or recommended by the manufacturer of the device.
	(2) Pursuant to a submission received on or after March 29, 2023, where the device is no longer supported by its manufacturer, provided that the covered entity or business associate has deployed any updates or patches required or recommended by the manufacturer of the device.
	(3) Pursuant to a submission received on or after March 29, 2023, where the device is supported by its manufacturer.
	(iv) Alternative measures
	—(A) Alternative measures.
	Where an exception at paragraph (f)(2)(iii) of this section applies, a covered entity or business associate must document in real-time the existence of an applicable exception and implement reasonable and appropriate compensating controls as required by paragraph (f)(2)(iv)(B) of this section.
	(B) Compensating controls.
	(1) To the extent that a covered entity or business associate determines that an exception at paragraph (f)(2)(iii)(A) or (B) or (f)(2)(iii)(C)(1) or (2) of this section applies, the covered entity or business associate must secure its relevant electronic information systems by implementing reasonable and appropriate compensating controls reviewed, approved, and signed by the covered entity's or business associate's designated Security Official.
	(2) To the extent that a covered entity or business associate determines that an exception at paragraph (f)(2)(iii)(C)(3) of this section applies, the covered entity or business associate shall be presumed to have implemented reasonable and appropriate compensating controls where the covered entity or business associate has deployed the security measures prescribed and as instructed by the authorized label for the device, including any updates or patches recommended or required by the manufacturer of the device.
	(3) To the extent that a covered entity or business associate is implementing compensating controls under this paragraph (f)(2)(iv)(B), the effectiveness of compensating controls must be reviewed and documented by the designated Security Official at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, to continue securing electronic protected health information and its relevant electronic information systems.
	(v) Maintenance.
	Review and test the effectiveness of the technical controls required by this paragraph (f) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
312(g)	(g) Standard: Transmission security.	312(e)	(e)(1) Standard: Transmission security.
	Deploy technical controls to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network;		Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.
	and review and test the effectiveness of such technical controls at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
			(2) Implementation specifications:
312(h)	(h) Standard: Vulnerability management
	—(1) General.
	Deploy technical controls in accordance with the covered entity's or business associate's patch management policies and procedures required by § 164.308(a)(4)(ii)(A) to identify and address technical vulnerabilities in the covered entity's or business associate's relevant electronic information systems.
	(2) Implementation specifications
	—(i) Vulnerability scanning.
	(A) Conduct automated vulnerability scans to identify technical vulnerabilities in the covered entity's or business associate's relevant electronic information systems in accordance with the covered entity's or business associate's risk analysis required by § 164.308(a)(2) or at least once every six months, whichever is more frequent.
	(B) Review and test the effectiveness of the technology asset(s) that conducts the automated vulnerability scans required by paragraph (h)(2)(i)(A) of this section at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
	(ii) Monitoring.
	Monitor authoritative sources for known vulnerabilities on an ongoing basis and remediate such vulnerabilities in accordance with the covered entity's or business associate's patch management program under § 164.308(a)(4).
	(iii) Penetration testing.
	Perform penetration testing of the covered entity's or business associate's relevant electronic information systems by a qualified person.
	(A) A qualified person is a person with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for ensuring the confidentiality, integrity, and availability of electronic protected health information.
	(B) Penetration testing must be performed at least once every 12 months or in accordance with the covered entity's or business associate's risk analysis required by § 164.308(a)(2), whichever is more frequent.
	(iv) Patch and update installation.
	Deploy technical controls in accordance with the covered entity's or business associate's patch management program under § 164.308(a)(4) to ensure timely installation of software patches and critical updates as reasonable and appropriate.
	(i) Standard: Data backup and recovery
	—(1) General.
	Deploy technical controls to create and maintain exact retrievable copies of electronic protected health information.
	(2) Implementation specifications
	—(i) Data backup.
	Create backups of electronic protected health information in accordance with the policies and procedures required by § 164.308(a)(13)(ii)(B) and with such frequency to ensure retrievable copies of electronic protected health information are no more than 48 hours older than the electronic protected health information maintained in the covered entity or business associate's relevant electronic information systems.
	(ii) Monitor and identify.
	Deploy technical controls that, in real-time, monitor, and alert workforce members about, any failures and error conditions of the backups required by paragraph (i)(2)(i) of this section.
	(iii) Record.
	Deploy technical controls that record the success, failure, and any error conditions of backups required by paragraph (i)(2)(i) of this section.
	(iv) Testing.
	Restore a representative sample of electronic protected health information backed up as required by paragraph (i)(2)(i) of this section, and document the results of such test restorations at least monthly.
	(j) Standard: Information systems backup and recovery.
	Deploy technical controls to create and maintain backups of relevant electronic information systems; and review and test the effectiveness of such technical controls at least once every six months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.