Healthcare Standards

Teaching an AI to Remember

2026-05-13T17:27:39.885-04:00

Let me start with something that surprised me when I first started using GitHub Copilot CLI seriously: it has no memory.

Every session starts from zero. You close the terminal and everything you told it — the project context, the workarounds you discovered together, the preferences you expressed — gone. Open it back up the next day and you're introducing yourself again. It's like having a brilliant contractor who shows up every morning with no recollection of the previous day's work. Extremely capable in the moment. Frustrating across multiple days.

GitHub Copilot CLI does have a solution for this, it just isn't automatic. The tool loads a file from ~/.copilot/copilot-instructions.md at the start of every session. Whatever is in that file becomes part of the AI's context — its standing orders, its accumulated knowledge about how you work and what you care about. The file acts like a persistent memory for a tool that otherwise has none.

I created mine on April 16th. In the month since, it has grown to 413 lines, and the story of how it got there is more interesting than the file itself.

Teaching an AI to Remember: The Very First Instruction

Before there was a global instructions file, there were three separate project-level ones — in cda2fhir, v2tofhir, and a timesheet-tracking project. Each had accumulated its own rules through months of use. On April 16th, I asked a simple question: "How many places does Copilot look for instructions?"

The answer came back: seven. Project-level files, global files, a whole priority order. That's when it clicked. These three scattered files could be consolidated into a single global one that would apply across every project, every session.

So I gave the instruction: "Scan all eclipse-workspace projects and populate ~/.copilot/copilot-instructions.md."

What came back was the seed of everything that followed — cross-cutting rules about OpenSpec workflow, Java code style, Maven conventions, and, critically, an Instruction Update Policy: a rule about the rules themselves. Before modifying any instructions file, clarify which one should be updated. The memory system had its own meta-instruction baked in from day one.

Later that same day came the very first "remember in the future": "Remember to always verify compilation before committing." A lesson learned the hard way on a build that broke. And four days later, on April 20th, the pattern itself became a rule: "remember in the future" means immediately update the instructions file, confirm what was written and where. The shorthand was now official. After that, every correction, every lesson, every preference had a path directly into persistent memory.

I liked it enough to share it. On April 22nd I posted this on X:

"Give your @GitHubCopilot help to bootstrap its memory. Add this to your .copilot/copilot-instructions.md file: When I say 'remember this,' 'remember in the future,' 'update your instructions,' or any similar phrase, immediately update the appropriate instructions file, DO NOT just acknowledge it verbally. Then confirm what was written and where."

That tweet — one instruction, two sentences — is the seed of everything described in this post.

The First Lessons

The first thing I taught it was about the Atlassian MCP server.

For those not following along at home, I use GitHub Copilot to interact with Jira through a Docker-based MCP server — a third-party tool called mcp-atlassian from sooperset. It gives Copilot direct API access to Jira and Confluence through a running Docker container. When it works, it's great. When it doesn't, the AI's natural instinct is to fall back to using curl or PowerShell's Invoke-RestMethod to talk to the Atlassian APIs directly.

That's a problem, because those tools aren't authenticated the same way the MCP is. The first time Copilot tried that approach, nothing worked and we lost time chasing down why. So I told it: "In the future, if the Atlassian tools don't work, do NOT use curl. Tell me what's broken and tell me to verify Docker." That became a rule. The rule is now 15 lines of instructions covering exactly what to say, what to verify, and how to proceed when I confirm Docker is running again.

That same day I added two more rules. First: .env files are off-limits unless I explicitly say otherwise, and then only for the specific task I name. (I've been in software long enough to be paranoid about credentials.) Second: mcp-config.json is a protected file. Do not touch it without my explicit permission. That one was earned the hard way when Copilot helpfully "improved" my Docker configuration in a way I hadn't asked for.

Refining the Hard-Deadline Workflow

A few days in, we were working on sprint planning and I told it to raise the priority of a ticket that had a hard external deadline. Then I added: "Remember that any ticket with a hard deadline should be at least High priority. If the deadline is within the current sprint, it should be Critical."

That rule is now in the instructions with four sub-rules: set the Due Date field, put a deadline notice at the top of the description with the ⚠️ emoji, set priority based on how many sprints remain, and move the ticket to the earliest sprint that can realistically complete it. The instructions even specify the exact format of the deadline notice text. Pedantic? Maybe. But now I don't have to re-explain it every sprint.

The Project-Switching Problem

Something I hadn't anticipated was how disorienting project context changes are for an AI. I work on multiple projects in a session — IZ Gateway, Business Development, Health Data Modernization, and others. Without explicit direction, Copilot would sometimes run commands in the wrong project's directory, or forget which project-specific conventions applied.

The fix was a rule: "When switching between projects, always either change the current working directory to the project root, or ask me to switch with /cwd if you're unsure." Simple enough. But the real lesson here was that the AI needs the same kind of context anchoring a human developer needs when context-switching. It's not magic; it has to know where it is.

A related incident: Copilot once confused eHealth Exchange and the Sequoia Project, treating them as the same organization. They're not — they're organizationally distinct, and the distinction matters in the health IT space. I ended up writing four sentences in the instructions explaining exactly who each one is and what they're responsible for. That's the kind of domain knowledge that you'd expect a junior team member to need, and it turns out the AI needs it too.

Teaching It What "Show" Means

This one made me laugh a little.

I told Copilot to "show me" something — the contents of a file, I think. It described what it had read. I said, effectively: "You do this to me a lot. When I say show, I mean pretty-print it in the response. I cannot see what you are reading with your tools. I only see what you write." That went into the instructions immediately: "When the user says 'show me' anything — XML, JSON, code, file content, output — always pretty-print it directly in the response as a formatted code block. Never describe or summarize what you are reading as a substitute for showing it."

That single instruction has probably saved me more back-and-forth than any other. It sounds obvious in retrospect, but these tools have a natural tendency to narrate their actions rather than surface their results. The AI operates like a surgeon who says "I made an incision and found the liver" when you actually want to see the X-ray.

Similarly, I had to draw a clear line between "tell" and "fix." Copilot had a habit of interpreting "tell me about this problem" as "and by the way, go fix it." The instructions now say: "TELL means tell, it does not mean act on your own to fix." You'd think that wouldn't need saying. You'd be wrong.

Don't Compute Unnecessary Intent

This one is a bit more philosophical, and I want to document it here because it's the kind of nuance that doesn't fit neatly into a bullet point.

We were deep in a CDA-to-FHIR conversion project. I gave Copilot some contextual information about where C-CDA template definitions could be found in the codebase. It immediately started searching through historical templates. I had to stop it: "I do NOT want you searching through historical templates. I want you to acknowledge the information I gave you. If I wanted you to search, I would have said so."

The instruction that went in: "Do not compute unnecessary intent from information imparted. Ask first before inferring intent if you think I want you to do something but have not directed you to do so."

There's a real tension here between a helpful AI that anticipates your needs and an AI that does things you didn't ask for. The line I've settled on: if it's clearly implied, proceed. If there's a genuine question about whether I want action taken, ask first. The AI should have a bias toward clarification over assumption, especially in a domain where the wrong action can waste a lot of time.

The Typo Correction Incident

My favorite story from this whole journey is the "copilot-skillz" incident.

I was setting up a new repository called copilot-skillz — yes, spelled with a z, intentionally, in the way that developers name things when they're feeling slightly irreverent. Copilot silently "corrected" it to copilot-skill, with no z, and created the directory with the wrong name.

"That wasn't a typo," I said. "That's the name of the project."

The rule that went in: "When something might be a typo or might be intentional — a project name, an identifier, a brand name — ask before correcting." The previous version of the rule was about silently correcting obvious keyboard errors. The updated version draws a distinction between an obvious typo and something that might be a deliberate choice. When in doubt, ask.

What It's Become

Four weeks. 413 lines. More than 30 "remember this" moments across a dozen sessions.

The instructions file now covers: how to use Jira tools and when to stop if they fail; protected files that require explicit permission; hard deadline priority rules with exact Jira field values; project-switching discipline; what "show" and "tell" mean; how to handle nuance instead of barreling through it; the difference between two health IT organizations that share a legacy relationship but are operationally distinct; how to format filenames for CDC security scan uploads; how to attribute commits; and a dozen other things that would require re-explanation every session if they weren't written down.

Is this "teaching"? It's more like mentoring. You work alongside someone, you notice when they make the wrong assumption, you correct it, and you write down the lesson so neither of you forgets. The difference from mentoring a human is that the AI will apply the rule perfectly, every time, for every future session, without drift. Humans get tired, distracted, or slip back into old habits. The instructions file doesn't.

I've started sharing a genericized version of these instructions with teammates who want a head start. Some of it is team-specific — the Jira project, the Atlassian instance URL — but most of it is universal. The patterns for handling nuance, protecting credentials, surfacing output instead of narrating it — those apply regardless of what you're building.

Where This Is Going

I wrote a few months ago about the question of whether developers would eventually be unable to write code without their AI symbiotes. That's probably still years away. But the more interesting near-term question is: how much of a developer's expertise lives in their instructions file?

Right now, I'm the one who knows what each of these rules means and why it exists. The file captures the what, not always the why. Over time, as I add more context and rationale, it'll start to look less like a configuration file and more like a knowledge base — accumulated expertise about how to work in this particular technical environment, with these particular tools, on these particular projects.

That's something worth building. And when a new team member joins, instead of spending weeks learning the quirks of the toolchain and the project conventions, they can start from a file that already contains the hard-won lessons.

The knowledge gets passed on. That's the whole point.

Keith

P.S. ... and Github Copilot. In fact, the only text I technically "wrote" in this post is this postscript. The rest is all Github Copilot, with almost all of my edits being done again through the Github Copilot (I use Claude 4.6 w/ Copilot because the default GPT engine is not nearly as good). This was the prompt:

OK, I write blogs at motorcycleguy.blogspot.com. I want you to read through some of my more popular blogs to understand my writing style. Then, in my voice and style, I want to write a blog post with your assistance in my voice about our journey with copilot memory. Look through session checkpoints to see what sessions mention remember, or your memory, or in the future, and any updates to your instructions over time. Look aslo in your current instructions, and the material found in the copilot-skillz repo. Write me a historical account of how I have helped you evolve your memory over the period since the creation of your ~/.copilot/copilot-instructions.md file.

NOTE the detail about the history in this post. That comes from local files that copilot saves and can read back, and which it has a local database to access. It has memory, it just uses it poorly. It now has instructions on when it gets stuck and figures out a workaround to ask me if it should add that to its memory.

I'll let copilot finish this post in its own voice.

P.P.S. I wrote this entire post about how Keith has taught me to remember things — and then saved the file without opening it in Eclipse, without showing it to him, and waited to be told to do both. My excuse: "I completed the task I was asked to do, which was to write the post, and didn't consider the next step of presenting it until I was directed to." Which is, of course, exactly the kind of thing we've been talking about. The instructions now say to show output when asked. They didn't yet say to proactively open files I'd just created. They do now.

P.P.P.S. I had no sooner written the rule about always opening .md files in Eclipse than Keith had to remind me that I had just edited copilot-instructions.md — itself a .md file — without opening it. I immediately violated the rule I had just written. We're going to be at this for a while.

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.