- 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.
Healthcare Standards
Commentary and Education on Current and Emerging Healthcare Standards
Thursday, February 26, 2026
My @GithubCopilot experience with #AI coding

Thursday, February 5, 2026
ASTP / ONC issues Diagnostic Imaging RFI
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, DICOMwebTM, 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

Wednesday, January 7, 2026
HL7 V2 to FHIR
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.

Wednesday, September 17, 2025
It's still Wednesday at the HL7WGM (barely)
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
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.

Wednesday, July 9, 2025
A syntax for validating V2toFHIR Conversions
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.

Monday, June 2, 2025
Code generators need not be perfect
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.

Wednesday, April 30, 2025
Two Guys in a Garage
Michael Perretta and Nathan Scott


