Concepts

Owned by Rick Freeman
Last updated: Mar 04, 2020 by Dimitar Dimitrov (Deactivated)

Introduction


This guide provides defintions and explanations for all of the components required to build and publish Logica applications.

Overview

The Logica development efforts exists to fulfill the mission of Logica: "Improve health by creating a vibrant, open ecosystem of interoperable platforms, applications, and knowledge assets.  The various systems, technologies, tools, and applications created by Logica exist to enable the ecosystem."

Logica Sandbox

The Logica Sandbox is the heart of the Logica ecosystem.  The Logica Sandbox is a place where a developer can build and test apps according to standards that allow the apps to be fully compatible with production systems from Healthcare industry leaders.  The Logica Sandbox provides EHR simulation, tools, and data to enable a user or a team of users to quickly bring an app to production.  

Logica Platform

The Logica Platform are the backend systems that enable the Logica Sandbox and support the FHIR and SMART on FHIR specifications.  The Logica Platform uses technologies such as MySQL, HAPI FHIR, JPA, OpenID Connect, OAuth2, Java, HTML, and JavaScript to build authentication servers, resource servers, messaging servers, and reference applications.  The Logica Platform artifacts are open source.  A developer that is interested in platform components may host and extend Logica Platform artifacts.  A developer that is interested in app development should use the Logica Sandbox and the hosted Logica Platform components found there.

SMART on FHIR Apps

The SMART on FHIR specification defines how an app can become integrated within the EHR.  EHR integration involves the following:  

  • The app registering with the EHR
  • The EHR presenting the app as a link or icon within the EHR that the practitioner can open
  • The app receiving a launch request from the EHR containing the location of the EHR FHIR resource server
  • The app following the OAuth process for receiving authorization for the EHR FHIR resource server
  • The app querying data from the EHR FHIR resource server

Most of the tools and sample apps produced by Logica are SMART on FHIR apps.

HL7 FHIR

For an application or system to be Logica compatible it must use HL7 FHIR to exchange data.  FHIR describes an object model, a messaging payload, and an API.  FHIR users resources to model clinical and administrative concepts, profiles for semantic interoperability, and RESTful HTTP networking protocol.  FHIR modeling efforts try to model the most common 80% of real-world object models as representations in FHIR Resources.  To accommodate the less common 20%, FHIR Resources offer extension mechanisms.

Syntactic Interoperability

Syntactic interoperability refers to the ability of separate systems to use a common representation for structure.  Logica achieves syntactic interoperability using FHIR Resources.  An example of syntactic interoperability is where two systems agree that a "patient" has a "first name" that is a xs:string and a "date of birth" that is a xs:date. Syntactic interoperability is the first level of interoperability.

Semantic Interoperability

Semantic interoperability refers to the ability of separate systems to understand each other.  Semantic interoperability is buildt upon syntactic interoperability.  Logica achieves semantic interoperability using FHIR Profiles.  An example of semantic interoperability is where two systems agree that a "patient" with a coded value for "ethnicity" will use the HL7 codes for ethnicity (http://www.hl7.org/fhir/v3/Ethnicity/index.html).  There is a lot of modeling activity around different profiling efforts.  Profiles that are known to the HL7 FHIR community can be found on the Profiles tab of the Resource definition (http://www.hl7.org/fhir/observation-profiles.html).

Detailed Clinical Models

From wiki.hl7.org: Detailed Clinical Models (DCM) are descriptions of items of clinical information that include the clinical knowledge on the concept, the data specification, a model and where possible, technical implementation specifications. A DCM is a conceptual specification of the semantics of discrete structured clinical information. It provides the data elements and attributes, including the possible values and types of the attributes, needed to convey the clinical reality in a fashion that is understandable to both clinical domain experts and modelers.