Databases honey systems based on HL7 RIM

This time the article should be much closer than the description of some EHR-S FM standards, so welcome comments. If everything below said to someone seems from the series “I don’t understand what it is about,” I suggest reading some of my earlier articles on Health Level 7.

Let's get started For some reason, it is believed that if we are talking about creating a medical system, then this is necessarily an electronic medical record of the patient and maybe something else, but quite a bit. However, patient EHR is not the only category of medical systems.

We can distinguish the following three:
Electronic Patient Record-centric - this includes what applies to a specific patient. Applications are not limited to the storage of patient demographics and patient history. Telemedicine, medical portals, etc. can be attributed to this category.
Public Health Information Networks - systems of this level abstract away from the individual and aggregate quantitative data from a variety of patient-oriented systems to predict the development of events such as epidemics, bioterorism, etc.
Clinical Research Support - in this group systems for decision making, drug modeling, etc.
')
There is no explicit border between categories, data flow from one to another, processed, supplemented and returned. Without experience in a particular field or category, it is often very difficult to guess what data can be used in it, in which case the HL7 Reference Information Model (RIM) offers invaluable help by providing the experience of many experts who worked day and night on classes and their relationships.

In this regard, when FHIR was not even on the horizon yet, such a topic arose - if the HL7 standard is such a cool thing and describes everything you need to exchange honey data, why not use it as a database structure, then exactly what will be accepted in a message from any other system you can somehow save. Take the entire RIM, or RMIM or DMIM belonging to the desired domain, and use only the classes required for the system being developed to design the database. Well, let's look at the HL7 RIM in all its glory:



where the following is coded with color: some entity (green), acting as (yellow), participates (blue) in some action (red), which is part of (pink) another action (red). Everything, more or anything like that in RIM is not! At first glance, this somehow seems a little like the finished model for an EHR.

Now let's see what's on the "second" view. And at a second glance, the HL7 data types, which, in most cases, are different from “normal” data types. Data types in the form of UML diagrams in the standard are presented as follows:



For example, HL7 Point-In-Time is similar to the Timestamp type in databases, but since the first is inherited from the abstract type ANY, the mandatory property NullFalvor spoils the whole picture.

A more complex example is the Concept Descriptor (CD) type, which is described by the attributes: code, codeSystem, codeSystemName, codeSystemVersion, displayName, originalText, qualifier, translation. The last two, moreover, are lists. Coded with Equivalents (CE), Coded Value (CV), Coded Ordinal (CO) and Coded Simple Value (CS) are inherited from the CD type. The CS type contains only code and NullFalvor. The question arises whether to create separate tables for CDs and whether to store all inheritable types in it? Or create a CS field inside the table being created, and put data with a CD type into a separate table?

Let's now take some simple entity, for example, Place and look at the ADDR field with the data type AD, it consists of:
• use type DSET;
• useablePeriod of type GTS which, in turn, is QSET;
• isNotOrdered type BL;
• formatted type ST.NT.

From the point of view of the logical structure of the database, the use and usablePeriod attributes are one-to-many relationships.
The isNotOrdered attribute is not just a Boolean in terms of a database, but may have a third null state.

The formatted attribute of type ST.NT (StringNoTranslations), in turn, has the following components:
• data type BIN;
• mediaType type CS;
• charset type CS;
• language type CS;
• headCharacter type ST.NT;
• tailString type ST.NT;

in which each element with the CS data type mentioned above consists of:
• code type ST.SIMPLE;
• UID type codeSystem;
• codeSystemName of type ST.NT;
• codeSystemVersion of type ST.SIMPLE.

And such a matryoshka (as it is easy to notice in some cases looped) with almost every field of the HL7 RIM classes.

This results in two extreme ways of implementing a database scheme based on and not based on RIM, as well as their derivatives:
• Each data type in its own table. In this case, it is not difficult to imagine what the request will be even for the formation of the simplest Ack (MCCI_IN000002).
• All data types in tables. This is also a possible approach, but then the database becomes unnormalized.
• It is logical to get rid of extremes and use a mixed approach - take RMIM for a specific area, some data types in separate tables, some within tables.
• Create a base structure from scratch as needed for the application, without looking at RIM.

An example of the implementation of the first type presented Abdul-Malik Shakir, the one who once “combed” clusters of classes in RIM to its current form - www.slideshare.net/AShakir/rim-based-relational-database-design-tutorial- september 2008

In my opinion, this is a more academic approach to show that creating a database structure based on RIM is still possible. In reality, the performance of such a system will be a big question. And, by the way, at least one such implementation, which is known to me, was very “stunted”.

Another commercial implementation with not so much information on its internal structure is the Oracle Healthcare Transaction Base (Oracle HTB). As far as I know from communication, only some data types, such as Entity Name (EN), Address Part (ADXP), Telecommunication Address (TEL), are in separate tables. HTB performance tests show that the base is spinning fast enough on a good iron. ( Link is dead.)

As for the internal structure of InterSystems Caché or 1C or other implementations, I don’t know anything, they themselves, if they wish, will write.

So there is ample room for maneuvering in the construction base for medical systems.

=====
RMIM - Refined Message Information Model
DMIM - Domain Message Information Model
FHIR - Fast Healthcare Interoperability Resources