HCIM ProcessPatterns

Introduction

HCIMs (Health and Care Information Model) model the information of clinical concepts. They describe those elements of the clinical concept that are relevant for almost all use cases.
When using HCIMs in information standards in particular, the need often arises to add additional information that in itself does not describe an aspect of the clinical concept, but rather forms part of the (often more administrative or logistical) process in which the clinical concept is used and which is described in the information standard.
The relevance of this information has been recognized since the inception of the HCIM methodology.
To this end, the HCIM BasicElements was introduced in the HCIM release 2015. The intention of this HCIM was to make explicit that, in addition to the elements that are modelled in a HCIM, a number of elements are assumed to be present in every HCIM. Before publication 2015, this assumption was implicit.
The basic elements were positioned as generic HCIM elements, whereby the distinction between clinical information and process-related information was insufficiently identified.

Making the basic elements explicit therefore led to many questions and even confusion.
The applicability of the basic elements was not equally straight forward for all HCIMs, comparable elements were sometimes already present in the HCIMs, and moreover not all described (more technical) elements were considered clinically relevant.

That is why the BasicElements HCIM has been deprecated in release 2020, whereby the elements described in the deprecated HCIM could only be added to the individual HCIMs where it was clinically relevant by submitting change requests.
This gave rise to a large number of issues in which it was proposed to add almost all basic elements to any HCIM, without specifying a clear use case.
Moreover, this still did not provide a solution to the need to add other types of information.

Analysis

Many of the issues can be traced back to a difference in requirements from the information standards on the one hand and the information that a HCIM models on the other. From an EHR or data exchange perspective, the HCIM is often used as the model of recorded information or even as the model of a (part of) an EHR record, while the HCIM 'only' describes the information aspects of the clinical concept and not aspects of e.g., capturing the information. At the conceptual level, the recording of the information is not a necessary condition for the existence of the information.
A patient may have a condition and the information about it may exist without this information being recorded in any EHR. This difference of approach is perhaps best illustrated by the frequent request to (generically) add an author, for example to the Problem HCIM. A (health) complaint from a patient exists in itself and has no author. The author is only relevant when recording it in an EPD and will therefore also differ per recording. It is therefore not part of the concept, but of the registration process. However, a diagnosis can have a person linked to it, because the diagnosis, unlike a complaint, is made by the healthcare provider based on a diagnostic process and is therefore inextricably linked to the concept of Diagnosis. In addition, a recorded diagnosis can of course also have an author (who records it in the EPR). Because in many cases this is the same person, the difference in role is often not mentioned for pragmatic reasons or not even recognized.
The above example also points out that such a generic element introduces ambiguity because it’s meaning changes with the context in which it is used.

Process Patterns

Because data of the registration process does form part of the information requirement for information recorded in an EPD, the different approach of the above subject will continue to lead to a great deal of uncertainty and thus to much discussion. This can only be solved by recognizing that it concerns different types of information and that there is a need for both. An HCIM is therefore important for all this information, just as much for process-related information as it is for clinical concepts. By modelling the process-bound information separately, this only needs to be done once and standardization is also achieved in this area.

The advantages of process patterns over a generic set of elements (such as the basic elements) are evident:

• Process patterns are by definition not declared applicable to every HCIM in every use case.
• It's up to the information standard to determine that. It is possible to indicate in an ‘clinical’ HCIM whether the process pattern is applicable.
• Because the data is explicitly defined as process data, the existing or non-existing overlap with elements present in the HCIM becomes clearer, e.g., a prescriber does not overlap with the author, because the roles come from different processes. This also makes the definition of the concepts less ambiguous. If information standards want to combine the two roles for reasons of their own, that is up to the information standard. However, the HCIM remains conceptually pure.
• Because process patterns are determined per process, flexibility is created: several process patterns can be defined and used, e.g., for the registration process, for the ordering process, etc.

Practical implementation

For the most part, the process patterns will follow the HCIMs in the practical implementation:

• The form in which the patterns are created and published will be as similar as possible to the HCIM format.
• The patterns will have versions just like HCIMs. In (pre-)publications it will be stated which versions belong to a (pre-)publication (as is the case with HCIMs). Patterns are therefore part of the (pre-)publications.
• They are therefore also listed on the publication landing page as a separate group (as partial HCIMs are listed in a separate group).
• Process patterns are exported to Art-Decor under the same conditions as the HCIMs.
• The HCIMs and the process patterns come together in the information standards. The use case underlying the information standard is part of a process. This process determines which information is desired in addition to the elements of the clinical concept. To this end, the elements from the associated process pattern are added to the relevant HCIM. As a result, composing the information standard is increasingly merging standardized building blocks and bricks
• Adding the patterns to a HCIM in the information standards results in adding a container with the process pattern elements at HCIM root concept level.
• Adding patterns has an impact on the technical artefacts (CDA, FHIR), but not more than adding those elements in an individual HCIM. In any case, the use of patterns will ensure that this is done in a standardized manner.
• Since both CDA and FHIR tent to model EHR record fragments to be transferred rather than purely clinical concepts, the elements from the patterns often are already present natively in the templates and resources.
• Although process patterns are modelled as HCIMs, the independent use of these process patterns is not the intended and makes little sense: registration data without an object of registration.

Notes

• Process patterns describe process-related information. They are not models of processes with their process steps.
• Information in a process pattern can indeed be clinically relevant, just as the process to which it is associated can be clinically relevant.
• Some HCIMs model a clinical activity, such as the HCIM Procedure. These clinical activities are not the focus of the process patterns, which often have a more administrative or logistical emphasis