Jekyll2025-04-20T11:17:27+00:00/feed.xmlPavel RozhkovFHIRPath UI v1.1.0 (FHIRPathME)2025-04-20T11:12:00+00:002025-04-20T11:12:00+00:00/blog/2025/04/20/fhirpath-110Every time when I need to use the FHIRPath UI I faced with repeated problem - I don’t have the history of the requests and expression executions.

Now this problem is fixed in the 1.1.0 version of the application. The history of the requests and executions is available. The list of features:

  1. The history of requests with ability to check resulted resource, use this resource and use the URL;
  2. The history of expression with ability to reuse them.

This update gives me an understanding of new features. Hope to provide new features soon.

https://projkov.github.io/fhirpath-ui/

Best regards,

Pavel Rozhkov from beda.software

]]>FHIRPath UI v1.0.0 (FHIRPathME)2025-04-05T04:56:00+00:002025-04-05T04:56:00+00:00/blog/2025/04/05/fhirpathreleaseI’ve decided to release version 1.0.0 of the FHIRPath UI. This app has stood the test of time—I still use it daily for anything related to FHIR resources. It’s fast, simple, and does exactly what it’s supposed to do.

However, there were a few things that used to be annoying: layout issues, the inability to use the Authorization header, and bad error handling. Those problems are now fixed, and I think it’s time to say: okay, it’s 1.0.0.

After this release, I have a few ideas for version 1.1.0, like a history of FHIRPath expressions and request history. I plan to add those features soon.

Hope you enjoy using this tool!

https://projkov.github.io/fhirpath-ui/

Cheers,

Pavel Rozhkov from beda.software

]]>What about the FHIRPath VSCode extension?2024-09-30T16:35:00+00:002024-09-30T16:35:00+00:00/blog/2024/09/30/fhirpath-vscodeToday, I have a lot of work to do in “offline” mode with Implementation Guide files. When I say “offline”, I mean that the files are stored locally on my computer, and I am reading them directly from there.

I’ve been working with a profile-resources.json file. If you’re familiar with it, you know it’s a huge file. Naturally, I don’t want to read it as-is. I need a way to manipulate the data using FHIRPath. Currently, I select all the lines in my editor, copy them, and paste them into fhirpath.me to run queries. I don’t like doing it this way.

Perhaps I should create a VSCode extension that acts as a wrapper for fhirpath.js. This could be a useful tool for developers.

]]>My thoughts about FHIRPath.me (day 2)2024-09-29T07:40:00+00:002024-09-29T07:40:00+00:00/blog/2024/09/29/fhirpathme-day-2When I finished the first note with my thoughts on FHIRPath.me, I found myself reflecting on how new changes could turn a lightweight service into something much larger.

I believe you don’t need a complex tool to solve a simple problem. For instance, you don’t need IDE-like functionality just to check FHIR resource data or to validate the structure of a resource in a StructureDefinition file. If you need help with an incorrect FHIRPath expression applied to a specific resource and want to share it with colleagues, you don’t need a lot of extra features for that either.

What I’m trying to say is, that I think the current state of FHIRPath.me is ideal for handling simple tasks. It’s fast, simple, and ready to use without any changes. Maybe I should keep the current app as a “light” version and continue developing a separate branch (or version) with more advanced functionality.

Best regards,

Pavel Rozhkov

]]>My thoughts about FHIRPath.me2024-09-28T04:29:00+00:002024-09-28T04:29:00+00:00/blog/2024/09/28/fhirpathmeIt’s been a long time since the last version of [FHIRPath.me]: https://fhirpath.me was released. I’ve used this app many times in my work, and I find it convenient, especially because of its speed and sharing feature. However, I have also identified several areas for improvement. Below are my thoughts on the functionality I’d like to see in the app:

  1. Expand workspace: I suggest removing the button that triggers the information modal window to free up more space for displaying information.
  2. Add output format selection: Currently, there’s no option to select the output format, and the result is shown as a list of text blocks. It would be great to allow users to choose an output format where the result is displayed as a regular string, with the option to separate values using a specified delimiter—such as a period or a comma.
  3. Support multiple queries simultaneously: At the moment, users need to open a new browser tab for each query, which can lead to losing track of the task’s context. It would be more convenient if users could make multiple queries in the same window.
  4. Save expressions for reuse: Often, expressions are repeated with slight variations in context, for example, when a user is studying the CapabilityStatement resource and wants to see different “searchParams” elements for various resource types. Adding the ability to save expressions for later reuse would enhance productivity.
  5. Enable multiple workspaces: Users should be able to work with multiple workspaces simultaneously and store references and expressions as formalized collections that they can revisit when needed.

To implement features 3-5, backend support and user authentication will likely be required. This means expanding the tech stack to include a backend language such as Python or TypeScript, along with a database like PostgreSQL. Initially, it might be sufficient to use local storage with import/export capabilities for collections.

These suggestions will soon be turned into GitHub issues, and I hope to find time to work on them.

Best regards,

Pavel Rozhkov

]]>