Being worked out in REST API WG
That’s good to hear. Wish I would finally manage to participate more actively
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.
That’s the update for subfolders proposal for the SM / API (it could be PATH for the REST API) Issue navigator - openEHR JIRA
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.
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.
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/) 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/). 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), 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:
- create folder
- create doc
- update folder with doc
Or:
- create doc
- 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.
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
- 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
"links": [{
"meaning": { "value": "LINK-E1i" },
"type": { "value": "administrative_case_number" },
"target": { "value": "ehr:/<ehr_id>/composition/<case_uid>" }
}]
Snippet with HL7 and mapping
"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 (9.7 KB)
In the ISO24305 that relates ISO13606 and ContSys with FHIR we found the valueset Valueset-document-relationship-type - FHIR v5.0.0 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