<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.0 20040830//EN" "journalpublishing.dtd"><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" dtd-version="2.0" xml:lang="en" article-type="research-article"><front><journal-meta><journal-id journal-id-type="nlm-ta">JMIR Med Inform</journal-id><journal-id journal-id-type="publisher-id">medinform</journal-id><journal-id journal-id-type="index">7</journal-id><journal-title>JMIR Medical Informatics</journal-title><abbrev-journal-title>JMIR Med Inform</abbrev-journal-title><issn pub-type="epub">2291-9694</issn><publisher><publisher-name>JMIR Publications</publisher-name><publisher-loc>Toronto, Canada</publisher-loc></publisher></journal-meta><article-meta><article-id pub-id-type="publisher-id">v13i1e67984</article-id><article-id pub-id-type="doi">10.2196/67984</article-id><article-categories><subj-group subj-group-type="heading"><subject>Original Paper</subject></subj-group></article-categories><title-group><article-title>A Validation Tool (VaPCE) for Postcoordinated SNOMED CT Expressions: Development and Usability Study</article-title></title-group><contrib-group><contrib contrib-type="author" corresp="yes"><name name-style="western"><surname>Ohlsen</surname><given-names>Tessa</given-names></name><degrees>MSc</degrees><xref ref-type="aff" rid="aff1">1</xref><xref ref-type="aff" rid="aff2">2</xref></contrib><contrib contrib-type="author"><name name-style="western"><surname>Hofer</surname><given-names>Viola</given-names></name><degrees>Dr rer nat</degrees><xref ref-type="aff" rid="aff3">3</xref></contrib><contrib contrib-type="author"><name name-style="western"><surname>Ingenerf</surname><given-names>Josef</given-names></name><degrees>Prof Dr, Dr rer nat</degrees><xref ref-type="aff" rid="aff1">1</xref></contrib></contrib-group><aff id="aff1"><institution>Section for Clinical Research IT, Institute of Medical Biometry and Statistics, University of Luebeck and University Hospital Schleswig-Holstein</institution><addr-line>Luebeck</addr-line><country>Germany</country></aff><aff id="aff2"><institution>Institute of Medical Informatics, University of Luebeck</institution><addr-line>L&#x00FC;beck</addr-line><country>Germany</country></aff><aff id="aff3"><institution>Thieme Compliance GmbH</institution><addr-line>Erlangen</addr-line><country>Germany</country></aff><contrib-group><contrib contrib-type="editor"><name name-style="western"><surname>Lovis</surname><given-names>Christian</given-names></name></contrib></contrib-group><contrib-group><contrib contrib-type="reviewer"><name name-style="western"><surname>Ehrsam</surname><given-names>Julien</given-names></name></contrib><contrib contrib-type="reviewer"><name name-style="western"><surname>Karen</surname><given-names>Triep</given-names></name></contrib></contrib-group><author-notes><corresp>Correspondence to Tessa Ohlsen, MSc, Section for Clinical Research IT, Institute of Medical Biometry and Statistics, University of Luebeck and University Hospital Schleswig-Holstein, Ratzeburger Allee 160, Luebeck, 23562, Germany, 49 45131015623; <email>t.ohlsen@uni-luebeck.de</email></corresp></author-notes><pub-date pub-type="collection"><year>2025</year></pub-date><pub-date pub-type="epub"><day>28</day><month>2</month><year>2025</year></pub-date><volume>13</volume><elocation-id>e67984</elocation-id><history><date date-type="received"><day>25</day><month>10</month><year>2024</year></date><date date-type="rev-recd"><day>11</day><month>12</month><year>2024</year></date><date date-type="accepted"><day>25</day><month>12</month><year>2024</year></date></history><copyright-statement>&#x00A9; Tessa Ohlsen, Viola Hofer, Josef Ingenerf. Originally published in JMIR Medical Informatics (<ext-link ext-link-type="uri" xlink:href="https://medinform.jmir.org">https://medinform.jmir.org</ext-link>), 28.2.2025. </copyright-statement><copyright-year>2025</copyright-year><license license-type="open-access" xlink:href="https://creativecommons.org/licenses/by/4.0/"><p>This is an open-access article distributed under the terms of the Creative Commons Attribution License (<ext-link ext-link-type="uri" xlink:href="https://creativecommons.org/licenses/by/4.0/">https://creativecommons.org/licenses/by/4.0/</ext-link>), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR Medical Informatics, is properly cited. The complete bibliographic information, a link to the original publication on <ext-link ext-link-type="uri" xlink:href="https://medinform.jmir.org/">https://medinform.jmir.org/</ext-link>, as well as this copyright and license information must be included.</p></license><self-uri xlink:type="simple" xlink:href="https://medinform.jmir.org/2025/1/e67984"/><abstract><sec><title>Background</title><p>The digitalization of health care has increased the demand for efficient data exchange, emphasizing semantic interoperability. SNOMED Clinical Terms (SNOMED CT), a comprehensive terminology with over 360,000 medical concepts, supports this need. However, it cannot cover all medical scenarios, particularly in complex cases. To address this, SNOMED CT allows postcoordination, where users combine precoordinated concepts with new expressions. Despite SNOMED CT&#x2019;s potential, the creation and validation of postcoordinated expressions (PCEs) remain challenging due to complex syntactic and semantic rules.</p></sec><sec><title>Objective</title><p>This work aims to develop a tool that validates postcoordinated SNOMED CT expressions, focusing on providing users with detailed, automated correction instructions for syntactic and semantic errors. The goal is not just validation, but also offering user-friendly, actionable suggestions for improving PCEs.</p></sec><sec sec-type="methods"><title>Methods</title><p>A tool was created using the Fast Healthcare Interoperability Resource (FHIR) service $validate-code and the terminology server Ontoserver to check the correctness of PCEs. When errors are detected, the tool processes the SNOMED CT Concept Model in JSON format and applies predefined error categories. For each error type, specific correction suggestions are generated and displayed to users. The key added value of the tool is in generating specific correction suggestions for each identified error, which are displayed to the users. The tool was integrated into a web application, where users can validate individual PCEs or bulk-upload files. The tool was tested with real existing PCEs, which were used as input and validated. In the event of errors, appropriate error messages were generated as output.</p></sec><sec sec-type="results"><title>Results</title><p>In the validation of 136 PCEs from 304 FHIR Questionnaires, 18 (13.2%) PCEs were invalid, with the most common errors being invalid attribute values. Additionally, 868 OncoTree codes were evaluated, resulting in 161 (20.9%) PCEs containing inactive concepts, which were successfully replaced with valid alternatives. A user survey reflects a favorable evaluation of the tool&#x2019;s functionality. Participants found the error categorization and correction suggestions to be precise, offering clear guidance for addressing issues. However, there is potential for enhancement, particularly regarding the level of detail in the error messages.</p></sec><sec sec-type="conclusions"><title>Conclusions</title><p>The validation tool significantly improves the accuracy of postcoordinated SNOMED CT expressions by not only identifying errors but also offering detailed correction instructions. This approach supports health care professionals in ensuring that their PCEs are syntactically and semantically valid, enhancing data quality and interoperability across systems.</p></sec></abstract><kwd-group><kwd>SNOMED CT</kwd><kwd>PCE</kwd><kwd>postcoordination</kwd><kwd>FHIR</kwd><kwd>validation</kwd><kwd>postcoordinated expression</kwd><kwd>Fast Healthcare Interoperability Resource</kwd></kwd-group></article-meta></front><body><sec id="s1" sec-type="intro"><title>Introduction</title><sec id="s1-1"><title>Background</title><p>The ongoing digitalization in medicine has significantly increased the amount of available medical data in the health care sector. To optimize medical care, it is crucial to use this data efficiently. For this, it is essential that the data can be exchanged and processed automatically across different systems. This requires not only technical compatibility but also semantic interoperability. Semantic interoperability ensures that the meaning of the data is maintained when it is transferred to another system. A key aspect of semantic interoperability is the sophisticated use of suitable coding systems and medical standards for medical terms [<xref ref-type="bibr" rid="ref1">1</xref>]. One example is the terminology SNOMED Clinical Terms (SNOMED CT). With over 360,000 concepts, SNOMED CT is considered the most comprehensive terminology in medicine. SNOMED CT facilitates machine-readable data exchange and reduces issues related to country-specific and domain-specific coding, as well as difficult versioning issues. However, despite its comprehensiveness, SNOMED CT cannot cover every possible medical circumstance by precoordinated concepts alone due to the complexity of natural language [<xref ref-type="bibr" rid="ref2">2</xref>]. For instance, an allergy to metals: The SNOMED CT International Edition, version 2024-09-01, lists a total of 1575 different metals. However, only 43 specific allergies to metals are included in this edition and version of SNOMED CT. This indicates that not every allergy-relevant metal or substance can be expressed through a precoordinated concept, such as an allergy to Cobalt-chromium alloy. To address such gaps, SNOMED CT offers postcoordination in contrast to many other vocabularies. Here, existing precoordinated concepts are combined into new expressions using formal grammar. This avoids the well-known problem of combinatorial explosion [<xref ref-type="bibr" rid="ref2">2</xref>]. An example postcoordinated expression (PCE) for an allergy to a Cobalt-chromium alloy based on Compositional Grammar [<xref ref-type="bibr" rid="ref3">3</xref>] is as follows:</p><p>1155942004 |Allergy to metal and/or metal compound|:</p><p>{719722006 |Has realization| = 472964009 |Allergic process|,</p><p>246075003 |Causative agent| = 256526003 |Cobalt-chromium alloy|}.</p><p>Here, the focus concept Allergy to metal and/or metal compound is refined by combining attributes (eg, Causative agent) with corresponding attribute values (eg, Cobalt-chromium alloy) as attribute relations.</p><p>Creating PCEs improves the detailed recording of medical facts and enhances patient record quality and automated processing. PCEs are complex due to the syntactic requirements of the Compositional Grammar [<xref ref-type="bibr" rid="ref3">3</xref>] and the semantic rules of the Concept Model [<xref ref-type="bibr" rid="ref4">4</xref>]. The syntactic requirements ensure that PCEs are correctly structured, while the semantic rules ensure that they accurately represent medical concepts and their relationships. This complexity makes it challenging to create valid accurate PCEs [<xref ref-type="bibr" rid="ref2">2</xref>].</p><p>Since Germany acquired a license for SNOMED CT in January 2021, the interest in using SNOMED CT has grown. SNOMED CT is increasingly being used in various national projects [<xref ref-type="bibr" rid="ref5">5</xref>,<xref ref-type="bibr" rid="ref6">6</xref>]. Despite this, postcoordinated SNOMED CT expressions are still used hesitantly. Nevertheless, PCEs are used in the Medical Information Objects of the National Association of Statutory Health Insurance Physicians [<xref ref-type="bibr" rid="ref7">7</xref>] or in anamnesis forms from Thieme Compliance [<xref ref-type="bibr" rid="ref8">8</xref>]. Nonetheless, some do not fully comply with the rules of the Compositional Grammar or the Concept Model. To address these issues, this work aims to develop a tool for the validation of PCEs. The focus is not only on determining whether a PCE is correct but also on providing detailed information and concrete suggestions for correcting a PCE (<xref ref-type="fig" rid="figure1">Figure 1</xref>). These suggestions are based on the analyzed errors and provide targeted recommendations for correcting specific PCEs.</p><fig position="float" id="figure1"><label>Figure 1.</label><caption><p>For every invalid PCE, a correction suggestion should be made automatically using the developed tool. PCE: postcoordinated expression.</p></caption><graphic alt-version="no" mimetype="image" position="float" xlink:type="simple" xlink:href="medinform_v13i1e67984_fig01.png"/></fig></sec><sec id="s1-2"><title>Related Work</title><p>Currently, SNOMED International provides a tool called &#x201C;SNOMED International APG Parser: SNOMED CT Compositional Grammar&#x201D; which validates PCEs based on syntactic rules of Compositional Grammar [<xref ref-type="bibr" rid="ref9">9</xref>]. Nevertheless, this tool only assesses syntactic correctness and does not consider the semantic rules of the Concept Model, which are essential for ensuring contextually accurate PCEs. This work aims to supplement this by adding semantic validation, which should provide better feedback for the user.</p><p>An alternative method for the syntactic and semantic validation of PCEs is using the commercial terminology server Ontoserver [<xref ref-type="bibr" rid="ref10">10</xref>] of Commonwealth Scientific and Industrial Research Organization. Ontoserver is currently the only Fast Healthcare Interoperability Resource (FHIR) terminology server that supports postcoordination at all. Ontoserver is used to validate the PCEs in combination with the FHIR service $validate-code [<xref ref-type="bibr" rid="ref11">11</xref>]. This checks a PCE against specific coding systems, such as SNOMED CT. This method provides a validation result through a Representational State Transfer (REST) request that returns a JSON object [<xref ref-type="bibr" rid="ref11">11</xref>]. Although this service indicates errors, it presents them in a technical manner that requires a solid understanding of SNOMED CT. This work&#x2019;s tool will build upon the FHIR service $validate-code based on Ontoserver to offer more comprehensive validation and suggestions. Hence, the difference between this work and the Ontoserver is that the focus is on the individual correction instructions for each PCE.</p></sec></sec><sec id="s2" sec-type="methods"><title>Methods</title><sec id="s2-1"><title>Overview</title><p>This work aims to develop a user-friendly tool for validating postcoordinated SNOMED CT expressions. The focus is on the automated provision of detailed correction instructions if a PCE contains syntactic or semantic errors. The tool&#x2019;s pipeline is illustrated in <xref ref-type="fig" rid="figure2">Figure 2</xref>. First, a PCE is validated using the FHIR service $validate-code [<xref ref-type="bibr" rid="ref11">11</xref>] and the terminology server Ontoserver [<xref ref-type="bibr" rid="ref10">10</xref>]. If the entered PCE is correct, this is communicated to the user, and the algorithm terminates. For incorrect PCEs, the tool generates detailed correction instructions in the next step, based on the results of the FHIR service. A processed Concept Model in JSON format and custom error categories are also used for this purpose. The correction instructions are presented to the user. The individual components of the pipeline are explained in more detail below.</p><fig position="float" id="figure2"><label>Figure 2.</label><caption><p>Pipeline for the validation of a PCE. PCE: postcoordinated expression.</p></caption><graphic alt-version="no" mimetype="image" position="float" xlink:type="simple" xlink:href="medinform_v13i1e67984_fig02.png"/></fig></sec><sec id="s2-2"><title>Initial Validation</title><p>FHIR, an interoperable data standard developed by Health Level 7 [<xref ref-type="bibr" rid="ref1">1</xref>], is gaining increasing importance both nationally [<xref ref-type="bibr" rid="ref12">12</xref>] and internationally [<xref ref-type="bibr" rid="ref13">13</xref>,<xref ref-type="bibr" rid="ref14">14</xref>]. In addition to the exchange of patient-related health information, FHIR also offers a terminology module with various services [<xref ref-type="bibr" rid="ref1">1</xref>]. In this project, the FHIR service $validate-code [<xref ref-type="bibr" rid="ref11">11</xref>] combined with Ontoserver [<xref ref-type="bibr" rid="ref10">10</xref>] plays a central role. This is used to verify the syntactic and semantic correctness of a postcoordinated SNOMED CT expression, in combination with a terminology server. The $validate-code service operates via an HTTP POST request. The response is a JSON object that contains the results of the validation. <xref ref-type="fig" rid="figure3">Figure 3</xref> shows an excerpt from this JSON object for an invalid PCE. The error messages indicate that the concept 472964009 |Allergic process| is not a valid attribute. This detailed output is attributed to the commercial Ontoserver, which possesses extensive knowledge of SNOMED CT, enabling precise analysis of PCEs.</p><p>Although the output is focused on automatic processing rather than human readability, it remains particularly valuable due to this specialization. This output provides a crucial basis for the next stages of the tool&#x2019;s pipeline.</p><fig position="float" id="figure3"><label>Figure 3.</label><caption><p>Domain and range example for the SNOMED CT attribute Causative agent.</p></caption><graphic alt-version="no" mimetype="image" position="float" xlink:type="simple" xlink:href="medinform_v13i1e67984_fig03.png"/></fig></sec><sec id="s2-3"><title>Determination of Detailed Instructions for Correction</title><sec id="s2-3-1"><title>Processed Concept Model</title><p>The Concept Model defines rules for how SNOMED CT concepts and PCEs are structured using formal logic and specific guidelines. These rules ensure that medical expressions are meaningful and consistent. For each SNOMED CT attribute, the Concept Model specifies a domain and a range (<xref ref-type="fig" rid="figure4">Figure 4</xref>):</p><list list-type="bullet"><list-item><p>Domain: This includes concepts (eg, Allergy to metal and/or metal compound) from at least one of the 19 Top-Level Hierarchies (eg, Clinical finding).</p></list-item><list-item><p>Range: This specifies a subset of SNOMED CT concepts that are valid values for an attribute. For the attribute Causative agent, for instance, only certain substances, such as Cobalt-chromium alloy, are included in the range.</p></list-item></list><fig position="float" id="figure4"><label>Figure 4.</label><caption><p>Extract of an error message for an invalid PCE based on an Ontoserver request. PCE: postcoordinated expression.</p></caption><graphic alt-version="no" mimetype="image" position="float" xlink:type="simple" xlink:href="medinform_v13i1e67984_fig04.png"/></fig><p>Additionally, the Concept Model specifies the cardinality of the attributes and whether attributes must be grouped [<xref ref-type="bibr" rid="ref2">2</xref>,<xref ref-type="bibr" rid="ref4">4</xref>].</p><p>To facilitate the tool, a machine-readable Concept Model (MRCM) is included in the RF2 files for each SNOMED CT edition and version [<xref ref-type="bibr" rid="ref15">15</xref>]. For our purposes, the MRCM Domain Reference Set (International Edition, 2024-05-01) is used. The MRCM Domain Reference Set is provided as a text file, with each domain represented by a detailed entry. Each entry includes all essential information about the respective domain, including a so-called template that is particularly significant for this work [<xref ref-type="bibr" rid="ref15">15</xref>,<xref ref-type="bibr" rid="ref16">16</xref>]. An excerpt from one of these templates is shown on the left side of <xref ref-type="fig" rid="figure5">Figure 5</xref>. The syntax of the templates is based on Compositional Grammar and includes the relevant attributes, as well as the cardinalities and value ranges for each domain. To further enhance usability, we developed an algorithm that decomposes the template into its individual components and presents this information in JSON format. This allows for a structured and efficient processing of the template components in the next step. All relevant information is already available in the appropriate format, enabling subsequent processes to use it directly without any further conversions. An extract of the JSON is displayed on the right side of <xref ref-type="fig" rid="figure5">Figure 5</xref>. The JSON is available on GitHub [<xref ref-type="bibr" rid="ref17">17</xref>].</p><fig position="float" id="figure5"><label>Figure 5.</label><caption><p>Extract from the processed machine-readable Concept Model in JSON format which proves to be advantageous for further processing.</p></caption><graphic alt-version="no" mimetype="image" position="float" xlink:type="simple" xlink:href="medinform_v13i1e67984_fig05.png"/></fig></sec><sec id="s2-3-2"><title>Error Categories</title><sec id="s2-3-2-1"><title>Overview</title><p>Based on the authors&#x2019; expertise in SNOMED CT postcoordination [<xref ref-type="bibr" rid="ref2">2</xref>,<xref ref-type="bibr" rid="ref18">18</xref>-<xref ref-type="bibr" rid="ref20">20</xref>], a total of nine error categories have been identified. For each error category, specific guidelines have been developed and are provided for an individual PCE. A general overview of the error categories and the focus of the guidelines is shown in <xref ref-type="fig" rid="figure6">Figure 6</xref>. The following sections provide a detailed description of each error category. Examples of the individual error categories are available on GitHub [<xref ref-type="bibr" rid="ref21">21</xref>].</p><fig position="float" id="figure6"><label>Figure 6.</label><caption><p>An overview of the various error categories (left side) and the corresponding correction focus (right side). For all categories, the processed Concept Model in JSON format plays a certain role. For the correction instructions highlighted in red, a terminology server and FHIR services are also used.</p></caption><graphic alt-version="no" mimetype="image" position="float" xlink:type="simple" xlink:href="medinform_v13i1e67984_fig06.png"/></fig></sec><sec id="s2-3-2-2"><title>Invalid Attribute</title><p>If a SNOMED CT concept is used that does not belong to the valid 126 attributes or is not valid in a specific domain, it is categorized under this category.</p><sec id="s2-3-2-2-1"><title>Correction Instruction</title><p>The solution involves identifying a valid SNOMED CT attribute. Users are provided with information about the domain of the focus concept, along with definitions and value ranges for alternative attributes. This helps to replace the invalid attribute with a suitable one. If no appropriate alternative is found, or if no attributes exist within the domain, the user must either modify the attribute value or create a new PCE with a different focus concept. For the invalid PCE shown in <xref ref-type="fig" rid="figure2">Figure 2</xref>, this error category is identified. The algorithm would also determine that the incorrect attribute Allergic process should be replaced with Causative agent or Associated with.</p></sec><sec id="s2-3-2-2-2"><title>Technical Implementation</title><p>To implement this, the FHIR service $expand is used in combination with a terminology server and the Expression Constraint Language (ECL) of SNOMED CT [<xref ref-type="bibr" rid="ref22">22</xref>]. The ECL in this case defines the value range of an attribute, such as &#x003C;&#x003C; 105590001 |Substance| OR .... This allows for verifying whether the current attribute value is included in the provided list. If an alternative attribute is identified, the PCE is revalidated to check for any additional errors.</p></sec></sec></sec></sec><sec id="s2-4"><title>Invalid Attribute Value</title><p>In this case, the chosen attribute value is not in the value range for the attribute.</p><sec id="s2-4-1"><title>Correction Instruction</title><p>For manually created PCEs, the attribute value is typically chosen correctly as it directly relates to a specific medical circumstance. However, the chosen value might not be within the valid range. The focus is on identifying appropriate alternative attribute values. Users will receive similar guidance as in the &#x201C;Invalid Attribute&#x201D; error category, including details on the acceptable value range and potential alternatives.</p></sec><sec id="s2-4-2"><title>Technical Implementation</title><p>The process adheres to the same principle outlined in the &#x201C;Invalid Attribute&#x201D; section.</p></sec></sec><sec id="s2-5"><title>Invalid Domain</title><p>In this error category, the attribute relation (comprising an attribute and its value) is semantically correct but does not match the domain of the focus concept.</p><sec id="s2-5-1"><title>Correction Instruction</title><p>Achieving a semantically correct relation requires a different domain of the focus concept. Users are provided with a list of domains where the current attribute relation is valid, enabling them to modify the focus concept accordingly.</p></sec><sec id="s2-5-2"><title>Technical Implementation</title><p>The appropriate domain is determined using the FHIR service $expand and a terminology server. The request is based on an ECL that specifies the domain constraint from the Concept Model. For instance, an expression might be <italic>&#x003C;&#x003C;</italic> 404684003 |Clinical finding<italic>|</italic>. If the focus concept appears in the results returned by this query, it belongs to the corresponding domain.</p></sec></sec><sec id="s2-6"><title>Different Domains With Multiple Focus Concepts</title><sec id="s2-6-1"><title>Overview</title><p>According to the Compositional Grammar, it is valid to use multiple focus concepts connected by &#x201C;+&#x201D; (AND). If multiple focus concepts from different domains are used&#x2014;such as Clinical finding and Procedure&#x2014;this results in a semantic error. In such cases, the PCE is categorized under this error category.</p></sec><sec id="s2-6-2"><title>Correction Instruction</title><p>The domains of the focus concepts used are displayed.</p></sec><sec id="s2-6-3"><title>Technical Implementation</title><p>We determined the Concept Model Domain performed as described in the &#x201C;Incorrect attribute relation&#x201D; category.</p></sec></sec><sec id="s2-7"><title>Incorrect Grouping</title><sec id="s2-7-1"><title>Overview</title><p>This category includes errors related to the bracketing of RoleGroups, which are crucial for the syntactic and semantic integrity of PCEs. Common issues involve missing or incorrect brackets, as well as imbalances between open and closed brackets.</p></sec><sec id="s2-7-2"><title>Correction Instruction</title><p>Users are provided with detailed information on which attributes are incorrectly grouped and where bracket corrections are necessary. Specific guidance is given on how to fix incorrectly placed brackets.</p></sec><sec id="s2-7-3"><title>Technical Implementation</title><p>A straightforward analysis of the error message and the PCE is conducted to provide targeted correction instructions. The error message shows the position and the concept before which the error occurs. For example, it may indicate that the character &#x201C;{&#x201D; is missing, suggesting that a RoleGroup is missing and should be started at the specified location. In this case, the tool would also determine the position where the RoleGroup should be closed again. Technically, this is done through simple processing of the strings for the error message, as well as the JSON object of the PCE.</p></sec></sec><sec id="s2-8"><title>Inactivated Codes</title><p>This error category pertains to PCEs that include codes that are no longer valid or active in the current version and have been replaced by others.</p><sec id="s2-8-1"><title>Correction Instruction</title><p>Users are provided with an alternative concept that is semantically equivalent to the inactivated concept.</p></sec><sec id="s2-8-2"><title>Technical Implementation</title><p>Identifying active concepts for inactivated codes is part of version management. SNOMED International offers Historical Association Reference Sets (RefSets) for this purpose. In this work, the following two RefSets are used:</p><list list-type="bullet"><list-item><p>900000000000527005 | SAME AS association reference set|: For identifying semantically equivalent active concepts.</p></list-item><list-item><p>900000000000526001 | REPLACED BY association reference set|: For linking deactivated concepts that have been replaced by new concepts.</p></list-item></list><p>These RefSets can be integrated into ECL. Additionally, ECL provides member filters that can be used in combination with respective RefSets, for example:</p><p>^ [targetComponentId] 900000000000526001 | REPLACED BY association reference set|</p><p>{{ M referencedComponentId = 224799004 |Unfamiliar environment (environment)| }}.</p><p>This ECL queries the REPLACED BY association reference set to identify the concept that has replaced the inactivated concept 224799004 |Unfamiliar environment (environment)|. In this case, the result would be 1186687002 |Unfamiliar environment (finding)|.</p></sec></sec><sec id="s2-9"><title>Syntactically Incorrect Codes</title><sec id="s2-9-1"><title>Overview</title><p>This error category refers to SNOMED CT Identifiers that cannot be linked to any valid SNOMED CT concept. The issue is not that the concept is inactive, but rather that the identifier is missing characters.</p></sec><sec id="s2-9-2"><title>Correction Instruction</title><p>Identifying a valid SNOMED CT concept that corresponds to the numerical sequence of the incorrect identifier is necessary for correcting a PCE. The user will then be provided with this concept.</p></sec><sec id="s2-9-3"><title>Technical Implementation</title><p>For this category, the FHIR service $expand, a terminology server, and ECL are also used. The ECL expression <italic>&#x003C;&#x003C;</italic> 138875005 |SNOMED CT Concept| is used to return all SNOMED CT concepts. Subsequently, all concepts containing the specified numeric sequence are identified. These concepts are then validated using the FHIR service $validate-code to determine which one fits both syntactically and semantically with the original identifier.</p></sec></sec><sec id="s2-10"><title>Cardinality Violation</title><sec id="s2-10-1"><title>Overview</title><p>As previously mentioned, the Concept Model defines cardinalities that specify the minimum and maximum occurrences of an attribute. A PCE is categorized in this category if it does not adhere to these cardinality constraints.</p></sec><sec id="s2-10-2"><title>Correction Instruction</title><p>Initially, the user is shown the attribute that violates the cardinality constraints, along with the cardinalities defined for this attribute in the Concept Model. If there is a violation of the minimum cardinality, the attribute must be added. In case of a violation of the maximum cardinality, either a grouped attribute should be moved to an additional RoleGroup or ungrouped attributes should be deleted.</p></sec><sec id="s2-10-3"><title>Technical Implementation</title><p>A basic analysis of the error message and the PCE is performed using the processed Concept Model in JSON format. The error message precisely indicates which attribute violates a cardinality (minimum or maximum) constraint. This information is automatically extracted from the JSON. Using the JSON object, an appropriate error correction can be easily determined.</p></sec></sec><sec id="s2-11"><title>Further Syntactic Errors</title><sec id="s2-11-1"><title>Overview</title><p>If a PCE contains characters that do not conform to the Compositional Grammar rules, it falls into this category. For instance, using the symbol &#x201C;:@&#x201D; instead of &#x201C;:&#x201D; before refinement would trigger an error indicating that the symbol &#x201C;@&#x201D; is not allowed.</p></sec><sec id="s2-11-2"><title>Correction Instruction</title><p>The instructions specify which character needs to be replaced and the exact position where the replacement should occur.</p></sec><sec id="s2-11-3"><title>Technical Implementation</title><p>A fundamental analysis of the error message and the PCE is conducted to provide accurate correction instructions. Through string processing and parsing, the position and the incorrect character are also extracted here.</p></sec></sec></sec><sec id="s3" sec-type="results"><title>Results</title><sec id="s3-1"><title>Validation Tool</title><p>The validation tool has been seamlessly integrated into the existing web application WASP [<xref ref-type="bibr" rid="ref18">18</xref>], which was developed in a previous project. Accessible to the public via [<xref ref-type="bibr" rid="ref23">23</xref>], the application enables users to use the new tool through the &#x201C;Validation&#x201D; option in the main menu. Users can choose to validate a single PCE directly or upload a file for validation. The tool supports various formats, including FHIR Questionnaires [<xref ref-type="bibr" rid="ref24">24</xref>] and FHIR ValueSets [<xref ref-type="bibr" rid="ref25">25</xref>] in JSON format, as well as CSV files, offering a flexible and versatile approach for validating different types of data.</p><p>Upon completing the validation, users receive a comprehensive overview of any errors detected during the process. These errors are clearly displayed on the user interface, ensuring easy traceability and resolution. Additionally, users have the option to download the error reports as a text file, enabling further analysis or optimization when needed. A screenshot of the web application, highlighting the user interface and layout, is shown in <xref ref-type="fig" rid="figure7">Figure 7</xref>.</p><fig position="float" id="figure7"><label>Figure 7.</label><caption><p>Extract from the tool for validating the postcoordinated SNOMED CT expressions.</p></caption><graphic alt-version="no" mimetype="image" position="float" xlink:type="simple" xlink:href="medinform_v13i1e67984_fig07.png"/></fig></sec><sec id="s3-2"><title>Use Case 1: Existing PCEs in FHIR Questionnaires</title><p>For the validation of the tool, real existing postcoordinated SNOMED CT expressions were used to establish a practical and reliable testing environment. These PCEs were incorporated into the FHIR Questionnaires developed by Thieme Compliance, which are designed for modeling anamnesis forms. Thieme Compliance offers these anamnesis forms in multiple languages to enhance usability for both patients and medical professionals. For machine processing and analysis, on the other hand, language-independent codes are used, ensuring precise and efficient data evaluation regardless of the language used [<xref ref-type="bibr" rid="ref8">8</xref>]. This validation specifically focused on the German-language anamnesis forms as FHIR Questionnaires [<xref ref-type="bibr" rid="ref24">24</xref>].</p><p>In total, 1122 postcoordinated SNOMED CT expressions were identified across 303 FHIR Questionnaires. Since many of these PCEs were repeated, 136 unique PCEs were distinguished. The validation results using the developed tool were as follows:</p><list list-type="bullet"><list-item><p>118 (86.8%) correct PCEs</p></list-item><list-item><p>18 (13.2%) invalid PCEs</p></list-item></list><p>In addition to identifying the correct and invalid PCEs, the developed algorithm carried out a detailed error categorization, uncovering six distinct error categories as shown in <xref ref-type="table" rid="table1">Table 1</xref>. These errors were analyzed in collaboration with the coders from Thieme Compliance. It was confirmed that all errors were correctly identified, and the correction suggestions were content-wise accurate.</p><table-wrap id="t1" position="float"><label>Table 1.</label><caption><p>Various error categories and their frequency in the 18 invalid PCEs<sup><xref ref-type="table-fn" rid="table1fn1">a</xref></sup>.</p></caption><table id="table1" frame="hsides" rules="groups"><thead><tr><td align="left" valign="bottom">Error categories</td><td align="left" valign="bottom">Frequency</td></tr></thead><tbody><tr><td align="left" valign="top">Invalid attribute value</td><td align="left" valign="top">9</td></tr><tr><td align="left" valign="top">Invalid grouping</td><td align="left" valign="top">2</td></tr><tr><td align="left" valign="top">Inactivated codes (International Edition, 2024-05-01)</td><td align="left" valign="top">3</td></tr><tr><td align="left" valign="top">Syntactically incorrect codes</td><td align="left" valign="top">1</td></tr><tr><td align="left" valign="top">Cardinality violation</td><td align="left" valign="top">2</td></tr><tr><td align="left" valign="top">Further syntactic error</td><td align="left" valign="top">1</td></tr></tbody></table><table-wrap-foot><fn id="table1fn1"><p><sup>a</sup>PCE: postcoordinated expression.</p></fn></table-wrap-foot></table-wrap></sec><sec id="s3-3"><title>Use Case 2: Existing PCEs in FHIR ConceptMaps</title><p>In a previous project, ICD-O tuples were mapped to the OncoTree, using SNOMED CT as an intermediary step [<xref ref-type="bibr" rid="ref20">20</xref>]. All 868 OncoTree codes were represented as postcoordinated SNOMED CT expressions based on the International Edition, 2021-01-31 in a FHIR ConceptMap [<xref ref-type="bibr" rid="ref26">26</xref>]. The developed tool is now being used to validate all PCEs. Since the ConceptMap is from 2021, it was expected to contain inactive concepts. If this is the case, they will be replaced by active concepts from the International Edition, dated May 1, 2024 [<xref ref-type="bibr" rid="ref20">20</xref>]. Any other errors will also be corrected accordingly.</p><p>Using the tool, 161 (20.9%) out of 868 PCEs were identified, each containing a concept that is no longer present in the International Edition, 2024-01-05. Some of these inactive concepts occurred multiple times, leading to the identification of 79 distinct inactive concepts. For all inactive concepts, an equivalent active SNOMED CT concept was found and was manually validated by an SNOMED CT expert, ensuring that the PCEs in the newer version are once again both semantically and syntactically correct. In addition, no other causes of error could be identified in the data.</p></sec><sec id="s3-4"><title>Usability Survey</title><p>For the user survey, the participants received four real existing invalid PCEs along with the corresponding error messages. It was ensured that each was assigned to a different error category (<xref ref-type="supplementary-material" rid="app1">Multimedia Appendix 1</xref>). The following error categories were used:</p><list list-type="bullet"><list-item><p>Syntactically incorrect code</p></list-item><list-item><p>Inactivated code</p></list-item><list-item><p>Invalid attribute</p></list-item><list-item><p>Invalid attribute value</p></list-item></list><p>To select these categories, PCEs from the literature were reviewed and analyzed. Additionally, discussions were held with professionals actively involved in coding PCEs. This allows us to identify the error categories most commonly causing issues in practice.</p><p>In addition, the authors developed a customized questionnaire with ten questions that assessed both the self-evaluation of SNOMED CT knowledge and the overall user experience with the error messages. For nine of the questions, an ordinal scale with five levels ranging from 1=worst to 5=best rating was used, while the last question was open-ended. None of the questions were mandatory, and no answer options were preselected. The complete questionnaire with the answer options is displayed in <xref ref-type="supplementary-material" rid="app1">Multimedia Appendix 1</xref>. The survey was conducted with five employees of Thieme Compliance, all of whom have basic knowledge of SNOMED CT postcoordination. Each participant was given the four invalid PCEs along with the corresponding error messages. Subsequently, the participants completed the questionnaire anonymously.</p><p>The chart in <xref ref-type="fig" rid="figure8">Figure 8</xref> summarizes the survey results on various aspects of the tool&#x2019;s functionality. Overall, the tool received predominantly positive feedback, as indicated by the fact that only one question garnered slightly negative ratings from two participants. The comprehensibility of the error messages&#x2014;both in terms of language and structure&#x2014;was rated with high or neutral scores, with the structure being assessed somewhat more critically than the language. Opinions were divided regarding the level of detail in the error messages: two participants found the level appropriate, another participant gave a neutral rating, and two participants provided less favorable feedback. These were also documented in the free-text comments. Despite these criticisms, trust in the tool and the readiness to use it regularly for PCE validation remain high, as reflected in the overall positive ratings. Additionally, all participants rated the tool&#x2019;s potential expansion to include automatic PCE correction functionality with the highest score of 5. In summary, the chart demonstrates a positive assessment of the tool&#x2019;s functionality, though there is room for improvement in areas such as the level of detail in the error messages.</p><fig position="float" id="figure8"><label>Figure 8.</label><caption><p>Results of the usability survey. PCE: postcoordinated expression.</p></caption><graphic alt-version="no" mimetype="image" position="float" xlink:type="simple" xlink:href="medinform_v13i1e67984_fig08.png"/></fig></sec></sec><sec id="s4" sec-type="discussion"><title>Discussion</title><sec id="s4-1"><title>Principal Findings</title><p>In this work, a tool for validating postcoordinated SNOMED CT expressions was developed that detects both syntactic and semantic errors. Incorrect PCEs are classified into one of the nine developed error categories, enabling the user to receive targeted feedback. The key added value and focus of the tool lies in generating specific correction suggestions for each identified error.</p><p>The successful integration of this tool into the existing web application WASP [<xref ref-type="bibr" rid="ref23">23</xref>] was confirmed through tests with real existing PCEs in FHIR Questionnaires [<xref ref-type="bibr" rid="ref24">24</xref>] and an FHIR ConceptMap [<xref ref-type="bibr" rid="ref26">26</xref>]. The use of these PCEs, provided in the FHIR Questionnaires from Thieme Compliance [<xref ref-type="bibr" rid="ref8">8</xref>], demonstrated that the tool can reliably verify the correctness and validity of expressions. This is particularly relevant for accurate modeling of medical data and its integration into electronic health records. Additionally, the error files of the 18 PCEs were provided to Thieme Compliance for correction. Another use case, the validation of PCEs in the context of a mapping between ICD-O and OncoTree [<xref ref-type="bibr" rid="ref20">20</xref>], highlights the tool&#x2019;s flexibility and usefulness in identifying and replacing inactive concepts. The ability to replace outdated concepts with current ones is crucial for the quality and relevance of medical data. The tool contributes to enabling cross-version analyses. It offers a solution for legacy data coded with earlier versions of SNOMED CT, where certain concepts may no longer exist. In such cases, the developed tool can assist in replacing these concepts with current equivalents.</p><p>A user survey has indicated that there is both interest and trust in the application. The results show a generally positive evaluation of the tool&#x2019;s functionality, although there is some potential for improvement regarding the level of detail in the error messages. In fact, 50% of participants rated the messages as too complex. Considering this, the development of the tool will place a special emphasis on revision. The plan is to allow users to choose between a newly developed, concise error message, and a more detailed version.</p><p>A comparison with existing methods, such as the SNOMED International APG Parser [<xref ref-type="bibr" rid="ref9">9</xref>] and the FHIR service $validate-code [<xref ref-type="bibr" rid="ref11">11</xref>] combined with the terminology server Ontoserver [<xref ref-type="bibr" rid="ref10">10</xref>], shows that the developed tool adopts a more comprehensive validation approach, placing particular emphasis on providing correction suggestions. While the APG Parser primarily checks syntactic correctness and the $validate-code service is limited to technical errors, the developed tool goes a step further: it enables in-depth error analysis, allowing for more precise corrections. This ensures that PCEs are created not only with correct syntax but also with accurate semantics. As a result, the quality and applicability of these expressions in practice are significantly improved.</p><p>A key aspect of this work is that the tool should not be understood as an automatic system for improving PCEs; rather, it provides targeted suggestions for the manual optimization of expressions. As the results of the user survey indicate, this would be a worthwhile feature. Automated corrections are often difficult to implement, as there is rarely a single correct solution. For instance, the tool suggests alternative attributes for the example PCE of <xref ref-type="fig" rid="figure1">Figure 1</xref>:</p><p>1155942004 |Allergy to metal and/or metal compound|:</p><p>{719722006 |Has realization| = 472964009 |Allergic process|,</p><p>472964009 |Allergic process| = 256526003 |Cobalt-chromium alloy|} such as:</p><list list-type="bullet"><list-item><p>Causative agent</p></list-item><list-item><p>Associated with</p></list-item></list><p>In this case, the attribute Causative agent should be used because this attribute is typically used in combination with allergies. A system that autonomously selects the appropriate attributes by analyzing attribute relations would indeed be an advancement, yet, manual validation by users remains essential. This ensures that no invalid PCEs are generated, which could negatively affect subsequent processes.</p><p>It should also be noted that the output of error messages is always dependent on the input PCE. If very complex PCEs with numerous errors are created, it may not be possible to correct them immediately. In such cases, the user must refine the PCE and validate it again, repeating the process until all errors are resolved iteratively. Users should be encouraged to construct manageable PCEs rather than attempting to encapsulate an entire medical history within a single PCE.</p></sec><sec id="s4-2"><title>Conclusions</title><p>In conclusion, this work demonstrates that the development of a comprehensive validation tool for postcoordinated SNOMED CT expressions can significantly enhance data quality and interoperability in health care, while also addressing and resolving versioning issues. The successful integration of the tool into existing systems highlights that it provides both syntactic and semantic support at a high level.</p><p>The creation of postcoordinated SNOMED CT expressions (PCEs) is not straightforward, as it requires adherence to the complex rules of the Compositional Grammar and the Concept Model. As seen in validations with real-world PCEs, ensuring syntactic and semantic accuracy can be challenging. The development of a validation tool for postcoordinated SNOMED CT expressions represents a significant advancement in addressing these challenges. In addition to technical validation, the tool provides helpful correction guidance, enabling the iterative improvement of PCEs. Users receive error reports and correction suggestions based on nine identified error categories. While the level of detail in the error messages can still be further optimized, the tool already offers valuable support for targeted and effective error resolution. The tool leverages state-of-the-art technologies such as the FHIR $validate-code service, the terminology server Ontoserver, and the SNOMED CT Concept Model. Ontoserver is indeed commercial, which poses a minor limitation. However, it was chosen because it is currently the only terminology server that supports postcoordination&#x2014;a crucial criterion for the requirements of this project. The methodological approach combines intelligent error detection with tailored correction suggestions, making it easier for users to independently optimize their expressions. In this way, the tool makes a significant contribution to improving data quality in health care.</p></sec></sec></body><back><ack><p>This work is funded by the German Federal Ministry of Education and Research (BMBF) as part of the Medical Informatics Initiative Germany, grant 01ZZ2312A.</p></ack><fn-group><fn fn-type="conflict"><p>None declared.</p></fn></fn-group><glossary><title>Abbreviations</title><def-list><def-item><term id="abb1">ECL</term><def><p>Expression Constraint Language</p></def></def-item><def-item><term id="abb2">FHIR</term><def><p>Fast Healthcare Interoperability Resource</p></def></def-item><def-item><term id="abb3">MRCM</term><def><p>machine-readable Concept Model</p></def></def-item><def-item><term id="abb4">PCE</term><def><p>postcoordinated expression</p></def></def-item><def-item><term id="abb5">SNOMED CT</term><def><p>SNOMED clinical terms</p></def></def-item></def-list></glossary><ref-list><title>References</title><ref id="ref1"><label>1</label><nlm-citation citation-type="book"><person-group person-group-type="author"><name name-style="western"><surname>Benson</surname><given-names>T</given-names> </name><name name-style="western"><surname>Grieve</surname><given-names>G</given-names> </name></person-group><source>Principles of Health Interoperability: FHIR, HL7 and SNOMED CT</source><year>2021</year><edition>4</edition><publisher-name>Springer</publisher-name></nlm-citation></ref><ref id="ref2"><label>2</label><nlm-citation citation-type="book"><person-group person-group-type="author"><name name-style="western"><surname>Ingenerf</surname><given-names>J</given-names> </name><name name-style="western"><surname>Drenkhahn</surname><given-names>C</given-names> </name></person-group><source>REFERENZTERMINOLOGIE SNOMED CT: Interlingua Zur Gew&#x00E4;hrleistung Semantischer Interoperabilit&#x00E4;t in Der Medizin [REFERENCE TERMINOLOGY SNOMED CT: Interlingua To Ensure Semantic Interoperability in Medicine]</source><year>2024</year><publisher-name>Springer</publisher-name><pub-id pub-id-type="doi">10.1007/978-3-658-35562-3</pub-id></nlm-citation></ref><ref id="ref3"><label>3</label><nlm-citation citation-type="web"><person-group person-group-type="author"><collab>International Health Terminology Standards Development Organisation</collab></person-group><article-title>SNOMED CT compositional grammar specification and guide</article-title><year>2020</year><access-date>2024-09-12</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://confluence.ihtsdotools.org/display/DOCSCG?preview=/33496020/115880553/doc_CompositionalGrammar_v2.4-en-US_INT_20201116.pdf">https://confluence.ihtsdotools.org/display/DOCSCG?preview=/33496020/115880553/doc_CompositionalGrammar_v2.4-en-US_INT_20201116.pdf</ext-link></comment></nlm-citation></ref><ref id="ref4"><label>4</label><nlm-citation citation-type="web"><person-group person-group-type="author"><collab>International Health Terminology Standards Development Organisation</collab></person-group><article-title>SNOMED CT starter guide</article-title><year>2019</year><access-date>2024-09-12</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://confluence.ihtsdotools.org/display/DOCSTARTDE/SNOMED+CT+Starter+Guide?preview=/61153991/87039892/doc_StarterGuide_de_INT_20190611.pdf">https://confluence.ihtsdotools.org/display/DOCSTARTDE/SNOMED+CT+Starter+Guide?preview=/61153991/87039892/doc_StarterGuide_de_INT_20190611.pdf</ext-link></comment></nlm-citation></ref><ref id="ref5"><label>5</label><nlm-citation citation-type="book"><person-group person-group-type="author"><name name-style="western"><surname>Rinaldi</surname><given-names>E</given-names> </name><name name-style="western"><surname>Saas</surname><given-names>J</given-names> </name><name name-style="western"><surname>Thun</surname><given-names>S</given-names> </name></person-group><person-group person-group-type="editor"><name name-style="western"><surname>R&#x00F6;hrig</surname><given-names>R</given-names> </name><name name-style="western"><surname>Bei&#x00DF;barth</surname><given-names>T</given-names> </name><name name-style="western"><surname>Brannath</surname><given-names>W</given-names> </name></person-group><article-title>Use of LOINC and SNOMED CT with FHIR for microbiology data</article-title><source>Studies in Health Technology and Informatics</source><year>2021</year><publisher-name>IOS Press</publisher-name><pub-id pub-id-type="doi">10.3233/SHTI210064</pub-id></nlm-citation></ref><ref id="ref6"><label>6</label><nlm-citation citation-type="book"><person-group person-group-type="author"><name name-style="western"><surname>Thun</surname><given-names>S</given-names> </name><name name-style="western"><surname>Stellmach</surname><given-names>C</given-names> </name><name name-style="western"><surname>Sa&#x00DF;</surname><given-names>J</given-names> </name><name name-style="western"><surname>Bartschke</surname><given-names>A</given-names> </name></person-group><person-group person-group-type="editor"><name name-style="western"><surname>Henke</surname><given-names>V</given-names> </name><name name-style="western"><surname>H&#x00FC;lsken</surname><given-names>G</given-names> </name><name name-style="western"><surname>Meier</surname><given-names>PM</given-names> </name><name name-style="western"><surname>Be&#x00DF;</surname><given-names>A</given-names> </name></person-group><article-title>Der GECCO datensatz f&#x00FC;r die COVID-19-forschung</article-title><source>Digitalstrategie Im Krankenhaus</source><year>2022</year><publisher-name>Springer Fachmedien Wiesbaden</publisher-name><fpage>505</fpage><lpage>516</lpage><pub-id pub-id-type="doi">10.1007/978-3-658-36226-3_36</pub-id></nlm-citation></ref><ref id="ref7"><label>7</label><nlm-citation citation-type="web"><person-group person-group-type="author"><collab>Kassen&#x00E4;rztliche Bundesvereinigung</collab></person-group><source>Medizinische Informationsobjekte (MIO) [Medical Information Objects (MIO)]</source><access-date>2024-09-02</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://www.kbv.de/html/mio.php">https://www.kbv.de/html/mio.php</ext-link></comment></nlm-citation></ref><ref id="ref8"><label>8</label><nlm-citation citation-type="web"><person-group person-group-type="author"><collab>Thieme Compliance</collab></person-group><source>Simplifier: Thieme Compliance Anamnese</source><access-date>2024-09-03</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://simplifier.net/thiemecomplianceanamnese">https://simplifier.net/thiemecomplianceanamnese</ext-link></comment></nlm-citation></ref><ref id="ref9"><label>9</label><nlm-citation citation-type="web"><person-group person-group-type="author"><collab>SNOMED International</collab></person-group><source>SNOMED International APG Parser (for PCEs) oD</source><access-date>2022-04-27</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://apg.ihtsdotools.org/SCT-cg.html">https://apg.ihtsdotools.org/SCT-cg.html</ext-link></comment></nlm-citation></ref><ref id="ref10"><label>10</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Metke-Jimenez</surname><given-names>A</given-names> </name><name name-style="western"><surname>Steel</surname><given-names>J</given-names> </name><name name-style="western"><surname>Hansen</surname><given-names>D</given-names> </name><name name-style="western"><surname>Lawley</surname><given-names>M</given-names> </name></person-group><article-title>Ontoserver: a syndicated terminology server</article-title><source>J Biomed Semantics</source><year>2018</year><month>09</month><day>17</day><volume>9</volume><issue>1</issue><fpage>24</fpage><pub-id pub-id-type="doi">10.1186/s13326-018-0191-z</pub-id><pub-id pub-id-type="medline">30223897</pub-id></nlm-citation></ref><ref id="ref11"><label>11</label><nlm-citation citation-type="web"><person-group person-group-type="author"><collab>HL7 International</collab></person-group><article-title>Operation $validate-code on codesystem&#x2014;FHIR v4.0.0</article-title><access-date>2024-09-04</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://hl7.org/fhir/R4/codesystem-operation-validate-code.html">https://hl7.org/fhir/R4/codesystem-operation-validate-code.html</ext-link></comment></nlm-citation></ref><ref id="ref12"><label>12</label><nlm-citation citation-type="web"><person-group person-group-type="author"><name name-style="western"><surname>Lau</surname><given-names>T</given-names> </name></person-group><article-title>Gesundheitsdaten: FHIR wird europaweiter standard</article-title><access-date>2024-01-04</access-date><publisher-name>&#x00C4;rzteblatt</publisher-name><comment><ext-link ext-link-type="uri" xlink:href="https://www.aerzteblatt.de/nachrichten/142159/Gesundheitsdaten-FHIR-wird-europaweiter-Standard">https://www.aerzteblatt.de/nachrichten/142159/Gesundheitsdaten-FHIR-wird-europaweiter-Standard</ext-link></comment></nlm-citation></ref><ref id="ref13"><label>13</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Vorisek</surname><given-names>CN</given-names> </name><name name-style="western"><surname>Lehne</surname><given-names>M</given-names> </name><name name-style="western"><surname>Klopfenstein</surname><given-names>SAI</given-names> </name><etal/></person-group><article-title>Fast Healthcare Interoperability Resources (FHIR) for interoperability in health research: systematic review</article-title><source>JMIR Med Inform</source><year>2022</year><month>07</month><day>19</day><volume>10</volume><issue>7</issue><fpage>e35724</fpage><pub-id pub-id-type="doi">10.2196/35724</pub-id><pub-id pub-id-type="medline">35852842</pub-id></nlm-citation></ref><ref id="ref14"><label>14</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Ayaz</surname><given-names>M</given-names> </name><name name-style="western"><surname>Pasha</surname><given-names>MF</given-names> </name><name name-style="western"><surname>Alzahrani</surname><given-names>MY</given-names> </name><name name-style="western"><surname>Budiarto</surname><given-names>R</given-names> </name><name name-style="western"><surname>Stiawan</surname><given-names>D</given-names> </name></person-group><article-title>The Fast Health Interoperability Resources (FHIR) standard: systematic literature review of implementations, applications, challenges and opportunities</article-title><source>JMIR Med Inform</source><year>2021</year><volume>9</volume><issue>7</issue><fpage>e21929</fpage><pub-id pub-id-type="doi">10.2196/21929</pub-id></nlm-citation></ref><ref id="ref15"><label>15</label><nlm-citation citation-type="web"><person-group person-group-type="author"><collab>SNOMED International</collab></person-group><article-title>SNOMED CT MRCM (machine readable concept model) maintenance tool</article-title><access-date>2021-04-08</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://browser.ihtsdotools.org/mrcm/">https://browser.ihtsdotools.org/mrcm/</ext-link></comment></nlm-citation></ref><ref id="ref16"><label>16</label><nlm-citation citation-type="web"><person-group person-group-type="author"><collab>International Health Terminology Standards Development Organisation</collab></person-group><article-title>Template syntax DRAFT specification</article-title><year>2020</year><access-date>2024-09-12</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://confluence.ihtsdotools.org/display/DOCSTS?preview=/45529301/115875508/doc_TemplateSyntax_v1.1.1-en-US_INT_20201020.pdf">https://confluence.ihtsdotools.org/display/DOCSTS?preview=/45529301/115875508/doc_TemplateSyntax_v1.1.1-en-US_INT_20201020.pdf</ext-link></comment></nlm-citation></ref><ref id="ref17"><label>17</label><nlm-citation citation-type="web"><person-group person-group-type="author"><name name-style="western"><surname>Ohlsen</surname><given-names>T</given-names> </name></person-group><source>Processed MRCM as JSON</source><access-date>2024-09-04</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://gitlab.com/tessa00/wasp-data/-/blob/main/wasp/mrcm.json">https://gitlab.com/tessa00/wasp-data/-/blob/main/wasp/mrcm.json</ext-link></comment></nlm-citation></ref><ref id="ref18"><label>18</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Drenkhahn</surname><given-names>C</given-names> </name><name name-style="western"><surname>Ohlsen</surname><given-names>T</given-names> </name><name name-style="western"><surname>Wiedekopf</surname><given-names>J</given-names> </name><name name-style="western"><surname>Ingenerf</surname><given-names>J</given-names> </name></person-group><article-title>WASP&#x2014;a web application to support syntactically and semantically correct SNOMED CT postcoordination</article-title><source>Appl Sci (Basel)</source><year>2023</year><volume>13</volume><issue>10</issue><fpage>6114</fpage><pub-id pub-id-type="doi">10.3390/app13106114</pub-id></nlm-citation></ref><ref id="ref19"><label>19</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Ohlsen</surname><given-names>T</given-names> </name><name name-style="western"><surname>Ingenerf</surname><given-names>J</given-names> </name><name name-style="western"><surname>Essenwanger</surname><given-names>A</given-names> </name><name name-style="western"><surname>Drenkhahn</surname><given-names>C</given-names> </name></person-group><article-title>PCEtoFHIR: decomposition of postcoordinated SNOMED CT expressions for storage as HL7 FHIR resources</article-title><source>JMIR Med Inform</source><year>2024</year><month>09</month><day>17</day><volume>12</volume><fpage>e57853</fpage><pub-id pub-id-type="doi">10.2196/57853</pub-id><pub-id pub-id-type="medline">39287966</pub-id></nlm-citation></ref><ref id="ref20"><label>20</label><nlm-citation citation-type="journal"><person-group person-group-type="author"><name name-style="western"><surname>Ohlsen</surname><given-names>T</given-names> </name><name name-style="western"><surname>Kruse</surname><given-names>V</given-names> </name><name name-style="western"><surname>Krupar</surname><given-names>R</given-names> </name><name name-style="western"><surname>Banach</surname><given-names>A</given-names> </name><name name-style="western"><surname>Ingenerf</surname><given-names>J</given-names> </name><name name-style="western"><surname>Drenkhahn</surname><given-names>C</given-names> </name></person-group><article-title>Mapping of ICD-O tuples to OncoTree codes using SNOMED CT post-coordination</article-title><source>Stud Health Technol Inform</source><year>2022</year><month>05</month><day>25</day><volume>294</volume><fpage>307</fpage><lpage>311</lpage><pub-id pub-id-type="doi">10.3233/SHTI220464</pub-id><pub-id pub-id-type="medline">35612082</pub-id></nlm-citation></ref><ref id="ref21"><label>21</label><nlm-citation citation-type="web"><person-group person-group-type="author"><name name-style="western"><surname>Ohlsen</surname><given-names>T</given-names> </name></person-group><source>Examples of error categories</source><access-date>2024-10-15</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://gitlab.com/tessa00/wasp-supporting-snomed-ct-postcoordination/-/tree/main/SpringBoot/src/main/resources/validation-pce-examples?ref_type=heads">https://gitlab.com/tessa00/wasp-supporting-snomed-ct-postcoordination/-/tree/main/SpringBoot/src/main/resources/validation-pce-examples?ref_type=heads</ext-link></comment></nlm-citation></ref><ref id="ref22"><label>22</label><nlm-citation citation-type="web"><person-group person-group-type="author"><collab>SNOMED International</collab></person-group><source>Expression constraint language&#x2014;specification and guide</source><access-date>2024-09-17</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://confluence.ihtsdotools.org/display/DOCECL">https://confluence.ihtsdotools.org/display/DOCECL</ext-link></comment></nlm-citation></ref><ref id="ref23"><label>23</label><nlm-citation citation-type="web"><person-group person-group-type="author"><name name-style="western"><surname>Ohlsen</surname><given-names>T</given-names> </name></person-group><source>Web application &#x201C;WASP.&#x201D;</source><access-date>2024-09-12</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://wasp.imi.uni-luebeck.de">https://wasp.imi.uni-luebeck.de</ext-link></comment></nlm-citation></ref><ref id="ref24"><label>24</label><nlm-citation citation-type="web"><source>HL7 International Resource Questionnaire&#x2014;FHIR v4.0.0</source><access-date>2024-09-12</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://hl7.org/fhir/R4/questionnaire.html">https://hl7.org/fhir/R4/questionnaire.html</ext-link></comment></nlm-citation></ref><ref id="ref25"><label>25</label><nlm-citation citation-type="web"><source>HL7 International Resource ValueSet&#x2014;FHIR v4.0.0</source><access-date>2024-09-12</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://hl7.org/fhir/R4/valueset.html">https://hl7.org/fhir/R4/valueset.html</ext-link></comment></nlm-citation></ref><ref id="ref26"><label>26</label><nlm-citation citation-type="web"><source>HL7 International Resource ConceptMap&#x2014;FHIR v4.0.0</source><access-date>2024-09-25</access-date><comment><ext-link ext-link-type="uri" xlink:href="https://hl7.org/fhir/R4/conceptmap.html">https://hl7.org/fhir/R4/conceptmap.html</ext-link></comment></nlm-citation></ref></ref-list><app-group><supplementary-material id="app1"><label>Multimedia Appendix 1</label><p>Usability survey.</p><media xlink:href="medinform_v13i1e67984_app1.docx" xlink:title="DOCX File, 36 KB"/></supplementary-material></app-group></back></article>