New post

Find

Article
· Dec 28, 2025 6m read

2025.1 FHIR Search Highlight - Lists-related Search Support (_List, $find, Functional/"Current" Lists)

Sometimes it is more convenient, more efficient, and more secure, to limit FHIR Searches per pre-defined "Lists" of Resources.

Since v2025.1 we support several List-related features in our FHIR Server.

I will highlight these here, and provide some samples.

In general you can see details about the List Resource from the official FHIR documentation.

But here is a short description based on the above:

The FHIR List Resource represents a flat (optionally ordered) collection of records used for clinical lists (e.g., allergies, meds, alerts, histories) and workflow management (e.g., tracking patients, teaching cases).
Lists may be homogeneous (single resource type) or heterogeneous (mixed types, e.g., a problem list spanning Conditions, AllergyIntolerances, Procedures).
Use List when you need a curated/filtered set that cannot be obtained via a simple query (e.g., “current” allergies vs all recorded allergies).
Querying a List yields a human-curated point-in-time snapshot, whereas querying the resource endpoint usually returns a broader, non-curated, “as of now” dataset.

In our latest versions (2025.1+) you can find new support for working with Lists:

  • The _list Search Parameter 

See the related FHIR docs for a full description. See our related Docs for details about the support available (specifically around Type-level vs. System-level searches).

Using this feature you can define for example a List of certain Resources, for example Encounters or Patients, etc. which you might want to Search according to them, without having to detail all of them as multiple Search Parameters.

For example I could define a List of Patients:

 
PUT /List cURL snippet

And then Search for them like this:

 
GET /Patient?_list cURL snippet

And get back a curated list of the Patients I wanted, instead of having to "mention" all of them in some multiple Search Parameters.

And of course there are many other use-cases.

  • Functional Lists (including the Custom Operation $update-functional)

A special kind of lists are Functional Lists (or "Current Resource" Lists).

See the related FHIR docs for a full description.

For your convenience here is a short description based on the above:

Many clinical systems maintain “current” patient lists (for example, a current problem list and a current medication list), but FHIR cannot reliably infer “current-ness” by inspecting a single resource instance.
Using Condition as an example, the same resource type may be posted for multiple legitimate purposes (curated problem list entry, encounter complaint/diagnosis, diagnostic workflow context, or inbound referral data), and Condition has no element that cleanly distinguishes these usages.
Because distinguishing current vs. past would require retrospective alteration (creating integrity and digital-signature concerns), a normal search on Condition for a patient will return more than just the curated “current problems,” and limiting it to “current only” would hide other important Condition records.
Therefore, whether a Condition (or similar record) is on a patient’s “current list” could determined by whether it is referenced from the appropriate List.
Via the REST API, this is expressed via the list search mechanism using _list with standard functional list names (e.g., GET [base]/AllergyIntolerance?patient=42&_list=$current-allergies), and the server may support this without necessarily exposing a standalone List instance.
There are several "common" functional list names such as $current-problems, $current-medications, $current-allergies, and $current-drug-allergies (a subset of allergies).

In order to allow maintaining these Functional Lists, we defined a Custom Operation, called $update-functional, which allows for creating and updated these kinds of lists. See more details in our Docs.

You can define a list of current allergies for example like this:

 
POST /List/$update-functional?for=...&name=\$current-allergies cURL snippet

This will create/update the $current-allergies List, for a specific Patient (ID 34 in the example above).

Note I include the 'for=' in the URL pointing to the Patient ID, and in the List I have 'subject' referencing the Patient.

(Note also that for the dollar sign ($) I used a slash (\) before it, i.e.: \$)

And now, I can ask for AllergyIntolerance Resource of this Patient, and instead of getting all of them, I can ask for just the "current" ones, as defined in the List above.

This would look like this:

 
GET /AllergyIntolerance?patient=...&_list=\$current-allergies cURL snippet

And this would return a subset of this Patient's allergies, per the current allergies list.

Note we're using the same _list Search Parameter mentioned previously, just this time instead of with a "Custom List", with a "Functional List".

Note you can control the names of the functional list names (and for each list, it's subject Search Parameter, and subject Resource Type; for example in the sample above the subject Search parameter was patient and the subject Resource Type was Patient), via the FHIR Endpoint configuration, specifically the "Interactions Strategy Settings", see related Docs here. This looks like this:

  • $find Operation

In addition, if you simply want to get the Functional List itself (for a particular subject, and of a particular type), you can use the $find operation.

See the related FHIR docs for a full description. And see also our related Docs.

Here's an example, per the previous one:

 
/List/$find?patient=...&name=\$current-allergies cURL snippet

This will return the related $current-allergies list for this Patient, as defined above via the $update-functional function.

 

See the related Open Exchange app which includes a Postman Collection with the samples above (plus a little more) and instructions re running this against @Evgeny.Shvarov's FHIR server template docker container (indeed the sample above was created around this sample; with a slight change... see details in my app usage instructions).

A general note - all this functionality assumes you are using the, relatively newer, and current default, JsonAdvSQL Storage Strategy for your Endpoint. (If relevant see here regarding migrating from a legacy Strategy)
2 Comments
Discussion (2)1
Log in or sign up to continue
Article
· Dec 27, 2025 1m read

关于导出映射Global

InterSystems 常见问题

使用 %Library.Global 类的 Export() 方法导出时,如果导出格式(第四个参数:OutputFormat)设置为 7,即 "块格式(Block format)/Caché 块格式 (%GOF)",则无法导出映射的Global项(只能导出命名空间默认Global数据库中的Global项)。要导出 "块格式/Caché 块格式 (%GOF) "的映射Global项,请在 %Library.Global.Export() 的第一个参数中指定要映射Global项的数据库目录。

执行示例如下。

set DB = "^^c:\InterSystems\Cache\Mgr\Test\" ; "^^\<path to database folder>\"
set sc = ##class(%Library.Global).Export(DB, "TESTGBL.gbl",FULLPATH,7,,")

如果将导出格式指定为 5(默认),即 "ISM/ObjectScript 格式(ISM/缓存格式)(*)",则也可以导出映射Global,但输出文件会比将导出格式(第四个参数:OutputFormat)设置为 7(即 "块格式/Caché 块格式(%GOF)")时大。

此外,如果在Global中记录了二进制数据,也无法正确输出。

更多信息,请参阅以下文档。
类参考:%Library.Global.Export() [IRIS]
类参考:%Library.Global.Export()

[注意]
默认导出格式为 5(ISM/ObjectScript 格式(ISM/Cache 格式)(*))时,包含 $LIST 格式或控制字符的Global文件无法正确导出。 在这种情况下,必须将导出格式(第四个参数:OutputFormat)设置为 7(块格式/Caché 块格式 (%GOF)),按数据库逐个导出。

* 顺序文件格式

Discussion (0)1
Log in or sign up to continue
Article
· Dec 27, 2025 2m read

"Os Erros HTTP Ocultos" (Por trás do IIS)

Você envia uma requisição HTTP e recebe de volta um erro HTTP, mas com uma página de erro HTML que você não esperava... o que está acontecendo? 🤔

Especificamente, por exemplo: talvez você tenha tentado ler um recurso FHIR (ex: /Patient/123) e recebeu uma página de erro 404, embora com outros IDs de pacientes você receba o payload do recurso normalmente — então "a página" definitivamente existe... por que você estaria recebendo uma página de erro 404? 🙄

A resposta para essas perguntas está relacionada ao comportamento do servidor web IIS na forma como ele lida com erros.

O IIS possui 3 opções para exibir erros:

  • Sempre mostrar apenas páginas de erro personalizadas
  • Sempre mostrar erros detalhados do servido
  • Para requisições locais, mostrar erros detalhados; mas para requisições remotas, mostrar páginas de erro personalizadas.

Esta última opção é mais segura (do que sempre mostrar erros detalhados) porque, às vezes, os detalhes do erro podem expor informações internas que você não deseja que usuários externos visualizem. Por isso, este é o padrão do IIS.

No entanto, isso significa que, se você estiver testando contra um servidor remoto, os erros reais estarão ocultos para você. Portanto, você precisaria alterar essa configuração para "Erros detalhados" (pelo menos durante as fases de depuração e assumindo que você está considerando o acesso externo e, talvez, limitando-o).

Veja mais detalhes sobre essa configuração em um artigo IIS relacionado (e você pode consultar esta seção relacionada em nossa documentação que discute o assunto).

O exemplo específico de FHIR que mencionei é um caso interessante, pois um erro 404 poderia significar simplesmente que um recurso FHIR específico não foi encontrado (o ID que você tentou ler não está no repositório), e não que você tem algum problema no servidor ("página não encontrada").

Por exemplo, se você conseguir visualizar o erro detalhado, verá algo assim:

Mas, sem o erro detalhado, você receberia apenas uma página de erro personalizada, como esta:

E isso pode ser enganoso, portanto, mantenha essa configuração do IIS em mente.

1 Comment
Discussion (1)1
Log in or sign up to continue
Question
· Dec 27, 2025

How the installed IPM package can know where it was installed?

Hi developers!

There is a very neat variable in IPM ${ipmdir} that lets packages be installed on a particular IRIS server and ensures that the data and resources they bring don't mess around as ${ipmdir} variable during the installation transforms into:

iris installation dir/ipm/package_name/version/whatever_you_install_here

It is very convenient, e.g., to bring some data and resource files that can be useful during the installation setup, e.g., via FILECOPY. Indeed, suppose you bring some csv_file, e.g. titanic.csv via FILECOPY as:

<FileCopy Name="data/titanic.csv" Target="${ipmdir}data/titanic.csv"/>

or even the whole folder of data in the source code repo into the package:

<FileCopy Name="data/" Target="${ipmdir}data/"/>

And in the case of Iris in Docker it resides in:

/usr/irissys/ipm/package_name/1.0.0/data/titanic.csv

This is all great, but is there any way for the installed code to determine the location of the data files? It'd be neat to let the installed app know somehow where is the data that came with it? Could it be the method in the IPM client that will resolve ${ipmdir} for the app? 

Or at least, it'd be great to let it be used on module.xml level where ${ipmdir} is supposed to be used, e.g., to be passed to an invoke method as an argument. But the issue is that it looks like <Arg></Arg> element expects literals only, but not parameters? Filed the issue already.

2 Comments
Discussion (2)2
Log in or sign up to continue
Discussion (0)1
Log in or sign up to continue