# Is it possible to follow a link in AQL?

**URL:** <https://discourse.openehr.org/t/is-it-possible-to-follow-a-link-in-aql/6994>\
**Category:** AQL\
**Tags:** aql, links\
**Created:** [17 July 2025 16:44 UTC](https://discourse.openehr.org/t/is-it-possible-to-follow-a-link-in-aql/6994 "2025-07-17T16:44:07Z")\
**Posts on this page:** 6\
**Page:** 2

<div class="post-metadata">

**Author:** ![yampeku](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yampeku/32/25_2.png) [@yampeku](https://discourse.openehr.org/u/yampeku)\
**Post date:** [25 July 2025 16:02 UTC](https://discourse.openehr.org/t/is-it-possible-to-follow-a-link-in-aql/6994/21 "2025-07-25T16:02:33Z")

</div>

> [@birger.haarbrandt](#):
>
> Edit: We also should consider adding Patch to add uids to the folder. Always fetching the whole thing is inefficient. I think @pablo raised this quite a while ago.

Being worked out in REST API WG 😃

---

<div class="post-metadata">

**Author:** ![birger.haarbrandt](https://discourse.openehr.org/user_avatar/discourse.openehr.org/birger.haarbrandt/32/24_2.png) [@birger.haarbrandt](https://discourse.openehr.org/u/birger.haarbrandt)\
**Post date:** [25 July 2025 16:04 UTC](https://discourse.openehr.org/t/is-it-possible-to-follow-a-link-in-aql/6994/22 "2025-07-25T16:04:41Z")

</div>

That’s good to hear. Wish I would finally manage to participate more actively 😒

---

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [25 July 2025 20:00 UTC](https://discourse.openehr.org/t/is-it-possible-to-follow-a-link-in-aql/6994/23 "2025-07-25T20:00:36Z")

</div>

> [@birger.haarbrandt](#):
>
> Edit: We also should consider adding Patch to add uids to the folder. Always fetching the whole thing is inefficient. I think @pablo raised this quite a while ago.

Yes! the idea was to allow commits to sub-structures in the main EHR.directory without the need to committing the whole directory each time, though I’m not sure what’s the current status.

---

<div class="post-metadata">

**Author:** ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)\
**Post date:** [25 July 2025 20:33 UTC](https://discourse.openehr.org/t/is-it-possible-to-follow-a-link-in-aql/6994/24 "2025-07-25T20:33:07Z")

</div>

> [@JPMesserli](#):
>
> Is it possible to load and update only a subfolder, e.g. only the ‘Administrative Cases’ folder without always loading all folders?

That’s the update for subfolders proposal for the SM / API (it could be PATH for the REST API) [Issue navigator - openEHR JIRA](https://openehr.atlassian.net/issues/?jql=textfields%20~%20%22subfolder%2A%22&selectedIssue=SPECPR-338)

> [@JPMesserli](#):
>
> Is it advisable to create a separate folder with subfolders for each case to map the administrative cases?

I don’t think there is a best practice that applies to every case, I would suggest to adopt/adapt folders in the way you need to structure them.

> [@JPMesserli](#):
>
> An archetype is used to store the attributes for a case, by default ‘openEHR-EHR-FOLDER.generic.v1’. Is it permissible and better to use other archetypes for a folder, e.g. ‘openEHR-EHR-FOLDER.administrative\_case.v1’?

I would say the generic one is kind of a place holder, you might need to create your own archetype for the folder details if the current ones don’t adapt exactly to your requirements. Then, you can share it with the community in the CKM if you want.

> [@JPMesserli](#):
>
> How can I load my FOLDER archetypes into the CDR so that they are available for validating the details when saving?

I think most CDRs work with Operational Templates (OPT), not with archetypes directly, though there are exceptional cases depending on the implementation. In our implementation ([https://atomik.app/](https://atomik.app/)) we have OPTs for everything: EHR\_STATUS, COMPOSITION, FOLDER, PERSON, PARTY\_RELATIONSHIP, ROLE, ORGANISATION, etc. For testing, we upload the OPTs on the openEHR Toolkit to generate instances that comply with the OPTs ([https://toolkit.cabolabs.com/](https://toolkit.cabolabs.com/)). So the data validation happens always against the OPTs.

Depending on the modeling tool you use, some might not support exporting the FOLDER archetype as a template. We have a tool in the openEHR SDK to do that ([GitHub - CaboLabs/openEHR-SDK: Java/Groovy Support of openEHR Operational Templates, Reference Model, Data Generators and other tools for www.CaboLabs.com projects](https://github.com/CaboLabs/openEHR-SDK)), which will be added to the Toolkit soon.

About managing stuff in the FOLDER, I’m assuming you can control the client side. So you can create the episode folder in the same “transaction” as the first document you want to include in the folder, and you can do it in any way:

1. create folder
2. create doc
3. update folder with doc

Or:

1. create doc
2. create folder with doc

Of course if there is a workflow that happens way before the first document is available but the episode itself needs to be created, you need to create the folder with its details previously, in a different transaction, then add the document later in another transaction, and that’s normally how you add the rest of the documents to the episode.

Best,  
Pablo.

---

<div class="post-metadata">

**Author:** ![JPMesserli](https://discourse.openehr.org/user_avatar/discourse.openehr.org/jpmesserli/32/5054_2.png) [@JPMesserli](https://discourse.openehr.org/u/JPMesserli)\
**Post date:** [26 July 2025 13:39 UTC](https://discourse.openehr.org/t/is-it-possible-to-follow-a-link-in-aql/6994/25 "2025-07-26T13:39:46Z")

</div>

Thanks a lot again to everyone!

I still have a few questions about RM links. The links consist of ‘meaning’, ‘type’ and ‘target’

- meaning = contains the semantic relationship – here only the code (e.g. LINK-E1i) from ISO 13606-3:2019
- type = domain category of the link (e.g. ‘episode\_of\_care’, ‘administrative\_case\_number’) for classification/filtering based on meaning

Questions about LINK.Meaning:

- ISO 13606-3:2019 is not accessible. Is it possible to use an HL7/FHIR value set e.g. [Codesystem-related-artifact-type - FHIR v6.0.0-ballot2](https://build.fhir.org/codesystem-related-artifact-type.html)
- If yes, can the terminology used be stored in LINK with ‘mappings’, as sketched below?

Questions about LINK.type:

- There is no official, global value list in openEHR für ‘type’. Is that correct?
- According to my research, there are frequently used terms. I have tried to list them in an Excel file with their meanings and also tried to map them to HL7 (attached below). What is your opinion on this? Or are there best practices or official lists?

Snippet with ISO 13606-3:2019 Code for meaning

```auto
"links": [{
  "meaning": { "value": "LINK-E1i" },
  "type": { "value": "administrative_case_number" },
  "target": { "value": "ehr:/<ehr_id>/composition/<case_uid>" }
}]

```

Snippet with HL7 and mapping

```auto
"links": [{
  "meaning": {
    "value": "part-of",
    "mappings": [{
      "match": "=",
      "target": {
        "terminology_id": { "value": "http://hl7.org/fhir/related-artifact-type" },
        "code_string": "part-of"
      }
    }]
  },
  "type": { "value": "administrative_case_number" },
  "target": { "value": "ehr:/<ehr_id>/composition/<case_uid>" }
}]

```

[openEHR\_LINK\_type\_governance.xlsx](https://discourse.openehr.org/uploads/short-url/18gJElA3zzXWWbetKxcd7lui5AK.xlsx) (9.7 KB)

---

<div class="post-metadata">

**Author:** ![yampeku](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yampeku/32/25_2.png) [@yampeku](https://discourse.openehr.org/u/yampeku)\
**Post date:** [26 July 2025 15:20 UTC](https://discourse.openehr.org/t/is-it-possible-to-follow-a-link-in-aql/6994/26 "2025-07-26T15:20:32Z")

</div>

> [@JPMesserli](#):
>
> ISO 13606-3:2019 is not accessible. Is it possible to use an HL7/FHIR value set e.g. [Codesystem-related-artifact-type - FHIR v6.0.0-ballot2](https://build.fhir.org/codesystem-related-artifact-type.html)

In the ISO24305 that relates ISO13606 and ContSys with FHIR we found the valueset [Valueset-document-relationship-type - FHIR v5.0.0](http://hl7.org/fhir/ValueSet/document-relationship-type) as the closest valueset (pretty sure this did not make the cut onto the final norm text)  
Notably this FHIR valueset is a subset of the ISO13606 Link codes

[Previous page](https://discourse.openehr.org/t/is-it-possible-to-follow-a-link-in-aql/6994.md?page=1)