In this step, a joint CIG development team consisting of both medical specialists and informaticists must be established. Medical specialists provide clinical requirements for decision support. According to the requirements, the informaticists select related guidelines, read through each narrative guideline, segment interesting sections in the guidelines, and finally confirm their selections with medical specialists. Selected and segmented human-readable guideline files are organized as the output of this step.

This step bridges the human-readable narrative guideline and the CIG by breaking narrative text into entities and relations. Informaticists read through the narrative guideline and break the guideline into small logic blocks, which can be represented by production rules. Each block contains a left-hand side representing the conditions and a right-hand side representing the consequent actions. These relationships are collected as a relationship table and delivered as an artifact. Both the left-hand side and right-hand side are further broken down from phrases into individual terms. Entities are marked up and extracted from those terms to form an entity table, which is also an artifact. The extraction results must be reviewed by medical specialists to ensure their correctness.

These steps are performed concurrently and in collaboration by two groups of informaticists to accelerate the development pace. This process should be coordinated by senior informaticists to ensure consistency in both groups. Domain concept modeling refers to the openEHR template development process. Based on the aforementioned entity table, informaticists search the openEHR archetype repository and select suitable archetypes that best represent the entities. An archetype should be created if there is no appropriate archetype for a specific entity. An openEHR template is developed to organize these archetypes. The detailed approach of openEHR template modeling is described elsewhere [32]. In the clinical algorithm editing step, another group of informaticists translates the relationship table into GDL rules. The translation is straightforward because GDL follows the general structure of production rules. When editing the clinical algorithms, the domain concept model is needed as the input. At the same time, the clinical algorithm editing raises domain concept requirements that must be created or refined. This bidirectional dependence must be coordinated by senior informaticists.

In this step, the CIG is validated with clinical data. Guideline authoring tools usually contain a CIG validation module, which receives data from manual input by informaticists. The CIG can be further validated by implementing clinical decision support systems (CDSSs). This work requires the involvement of software engineers. If the validation results have any inconsistency with the original narrative guideline, the whole process from guideline extraction to authoring is reviewed.

Finally, the well-developed guideline should be made publicly available by informaticists. Code-sharing platforms such as GitHub and forums of professional societies are good options for disseminating these guidelines.

To manage the proposed 6-step approach, especially considering online collaboration, we used the Atlassian Confluence team collaboration platform [33] as a tool to coordinate the work (see Figure 2). The six steps were elicited on the platform. Each participant was requested to submit their outcome artifacts on the platform. Version controls were implemented to track the history of documents. Archetypes were searched in the openEHR Clinical Knowledge Manager (CKM) [34]. The GDL rules were edited using the GDL2 Editor in docker [35].

The Chinese COVID-19 guideline was published by the NHC to share the latest evidence-based best practices regarding COVID-19 diagnosis and treatment and to nationally standardize caregiver practices.

The seventh edition of the Chinese COVID-19 Diagnosis and Treatment Plan consists of 13 sections. Sections 1 to 4 provide general introductions to the pathogen, epidemiology, pathology, and patient features of SARS-CoV-2. Then, in sections 5 to 8, the diagnostic criteria are discussed in detail. In Section 9, guidelines are defined as to how cases should be reported. In Section 10, treatment plans are introduced. From Section 11 to Section 13, discharge criteria, transportation, and in-hospital infection are briefly discussed. The CIG development team spent three days reading and discussing the guideline. Because our primary goal was to develop an executable guideline, the CIG development team jointly decided to select the diagnosis and treatment sections (ie, sections 5 to 8 and sections 10 and 11). The traditional Chinese medicine section was not included in the treatment suggestions because it is not available in other countries. Both the original copy published by the NHC and the English version translated by a public society were used in the next steps.

One informaticist (TT) read the guideline and split the sentences into a spreadsheet (Multimedia Appendix 1). Four days were spent on this task. A color system was used in the splitting: blue indicated that the sentence was related to diagnosis or treatment; black indicated that the sentence was not suitable for translation to a clinical rule; and red indicated that the sentence contained vague content and required later consultation with medical specialists. The document was uploaded to the Confluence platform in a timely fashion. Each update was double-checked by two other informaticists (SN and HF).

Then, TT annotated the entities in the text and extracted them into another spreadsheet (Multimedia Appendix 2). Repeated entities were merged. TT uploaded the document to Confluence, and two other informaticists (HF and ML) double-checked the annotation and the extracted results. The final extracted results were reviewed and confirmed by an external medical specialist. Two additional days were spent on this task. In total, this step took six days.

Based on the entity table developed in the previous step, ML and HF mapped the listed entities to the openEHR concepts. While mapping, the openEHR template was expanded accordingly. The mapping was checked by a senior informaticist (SN) and an external openEHR expert. A group of archetypes in the format of archetype definition language (ADL) files were exported from the CKM. The detailed archetype searching and template development process is reported elsewhere [32]. Ten days were required for the domain concept modeling because the selection of proper archetypes required confirmation by the external openEHR expert. Three rounds of teleconferences were held to finalize the domain concept model.

Sentences in the narrative guideline were broken down into the left-hand side and right-hand side blocks by TT in the guideline extraction step. In this step, HF used the GDL2 Editor to encode the clinical algorithms in GDL.

ADL files describing the COVID-19 data requirements were imported into the GDL2 Editor. Following the structure of the extracted guideline file, HF translated each left-hand side and right-hand side pair to a GDL rule in a when-then format.

The GDL rules were checked and confirmed by SN. SN and HF took part in both the domain concept modeling and clinical algorithm authoring. They bridged the two groups of informaticists and lowered the communication cost. The clinical algorithm authoring was performed at the same time as the domain concept modeling. Once a part of the domain concept model was finalized, the related GDL rules were created accordingly. The entire authoring process was synchronized with the domain concept modeling step.

The CIG developed in the previous step was validated both by GDL2 Editor and a prototype CDSS for COVID-19. Our research team previously developed a configurable CDSS platform named Tracebook to develop CDSS applications rapidly [38]. In this study, we used the Tracebook platform to configure a fast prototype of a COVID-19 CDSS. Because there are no open-source or openly available GDL2 execution engines, we chose the Drools rule engine to execute the clinical rules [39]. Mapping was required between GDL2 and Drools at both the data model level and the language level. The mapping rule and mapping specification were defined jointly by SN, TT, and HF (Multimedia Appendix 2). Then, the mapping was performed manually by TT. An additional Drools rule for the user interface presentation was also developed. The additional rule mapping and system development were performed over five days.

Test patient data were adopted from patient case report published in a medical journal [40]. The patient was a 35-year-old man who had cough and fever symptoms and had recently traveled to Wuhan, China. The patient’s demographic information, history, and observations were captured from the publication and entered into both the GDL2 Editor guideline validation module and our own CDSS. The output was compared with both the guideline and the reported diagnosis and prescription. Inconsistencies between these three outputs were reported to external medical specialists, and the CIG was reviewed.

Archetypes in ADL file format and the GDL rules in GDL2 format were exported from their editors, packaged together, and committed to GitHub [41]. Java data models and Drools rules were also committed to GitHub to benefit people who do not use openEHR. Then, the dissemination was reported on the openEHR disclosure forum [42].

The domain concept model is illustrated in detail in Table 1.

A total of 27 archetypes were used for the COVID-19 CIG, among which 26 were directly acquired from the CKM and 1 (openEHR-EHR-CLUSTER.imaging_result-COVID_19.v0) was acquired from the CKM and modified for the COVID-19 CDSS. These 27 archetypes were sorted into 9 categories: demographic, history, medical record, exam, vital sign, laboratory test, symptom, diagnosis, and order. The organization of the Java data models followed the concept categories.

The COVID-19 diagnosis and treatment rules are listed in Table 2.

Sections 5 to 8 and sections 10 and 11 of the Chinese COVID-19 Diagnosis and Treatment Plan were encoded in both GDL and Drools. These rules support diagnosis, classification, early warning, treatment, and discharge for caregivers.

For sections 5, 10, and 11, there are multiple GDL rules for one section. This is because GDL2 Editor now only allows one rule in a file, whereas these sections contain several rules. This limitation does not exist in Drools; therefore, we merged the rules for one purpose into one Drools rule file.