A Next Generation of IT: A Health Record Example with Terminology Binding

Introduction

There is a pending information system development revolution. The arrival of the sixth generation of computing is imminent and it is found in the mechanism for developing applications based on two concepts:

• 1.

  Open data platforms providing execution of a high-level language (annotation markup) and supporting distributed ecosystems based on wiki technology

• 2.

  Emergence of Semantic Web as a knowledge structure for use in ordinary applications (not just artificial intelligence)

The fourth generation of computing has fourth generation language (4GL) support and is aimed at improving development productivity. Enterprise resource planning (ERP) systems typically use 4GL to define system behavior.

The fifth generation is aimed at the field of artificial intelligence based on Semantic Web which introduced the triple store, as well as the management of graph knowledge structures beyond the relational database.

So, in the migration to this next generation we need to be aware of the changes to software construction needed to take advantage of new capabilities and not just apply old programming practices. Specifically, this necessitates the implementation of concepts such as structured data capture in the language of a Semantic Web platform and not in Java (which is not a 4GL).

Part of the motivation for using a Semantic Web platform is the speed with which implementation can be achieved over traditional programming mechanisms. Some precursor development tools exhibited productivity gains in the order of 20 times over traditional development methods Gartner Inc. (2003).

The change of thinking, which must occur between existing programming techniques and those supported by Semantic Web platforms, is demonstrated by how an Electronic Health Record (EHR) could be migrated to this environment.

The paper explores implementation of an EHR in a sixth generation as represented by Semantic MediaWiki. It examines a specific case of the binding of a health care record entry to a term expressing the entry’s type as part of a standard terminology where both the record and the terminology are loaded in a Semantic Web environment.

The Change In The Binding Mechanism

Existing approaches have binding from a health record entry to a terminology as a multi-string match (a coded element structure including the code system and the term code) to a terminology concept often through a Common Terminology Service (CTS).

The CTS is a service to access the terminology callable by the health record system with legacy programming techniques. One function is that it allows access to the display value of a concept.

The binding example which is described here illustrates the lower capability of existing traditional programming environments compared to the Semantic Web. Data is stored in primitive types – strings, numbers, dates and all relationships are built in the constructed software. Examples of this are found through multiple generations of Health Level 7 [HL7] including the latest standard Fast Healthcare Interoperability Resource [FHIR]. (HL7 FHIR, 2018)

A healthcare record is a complex graph usually anchored with a patient resource. Healthcare actions planned and taken for this patient are recorded in clinical and administrative records (subgraphs) linked to the patient. Identification, coding from terminology systems, and display representation precisely state the records’ contents. Examples of terminology systems include Logical Observation Identifiers Names and Codes (LOINC), International Statistical Classification of Diseases and Related Health Problems (ICD), and Systematized Nomenclature of Medicine Clinical Terms (SNOMED International).

The HL7 coded element, as part of the health record entry, supplies a structure containing the unique identity of the coding system (namespace), version of the coding system, unique code, and display text of the semantic. These components will be called system, code, and display. To achieve a precise semantic identification, the system and code components are required. The display is derived from their combination.

Here is a fragment of an HL7 FHIR Allergy Intolerance (HL7 FHIR, 2017) in XML where the entry display is “No Known Drug Allergy.”