At the heart of CGM LIFE is a personal health record (PHR) of a patient. A PHR consists of a list of entries of different types. Such an entry is called Medical Data Object (MDO).
Each MDO is associated with an owner (the patient, whose PHR the entry belongs to) and a creator (the user who stored the entry in CGM LIFE). The creator can be the patient himself but also a third person who has appropriate access rights to the owner’s PHR (e.g. an institution or an HCP).
MDO types can include medical findings, diagnoses, lab values, medication, allergies but also measurements such as height, weight, blood pressure and even personal entries such as diaries.
CGM LIFE supports a very flexible and secure storage system for arbitrary MDO types, using encrypted JSON structures. Each MDO has exactly one MDO type which defines the syntax (allowed fields, allowed values per field, required fields) for this structure. This structural syntax is defined in an MDO schema. For example, a medical diagnosis (MDO type core.diagnosis) entry may look like this (simplified for brevity):
description: "Fracture of patella"
The schema for the core.diagnosis type looks like this (again simplified for brevity):
"enum": ["UNSPECIFIED", "CONFIRMED", "SUSPECTED", "NOT_CONFIRMED", "NO_SYMPTOMS"]
"enum": ["LEFT", "RIGHT", "BILATERAL", "UNSPECIFIED"]
The list of all supported schema types is called the CGM LIFE Core Data Model.
CGM LIFE provides a separate storage mechanism for (large) documents. In contrast to structured MDOs, documents contain unstructured data such as images or PDFs. When storing a document, the associated MDO will only contain the metadata of the document (file name, type, and size) while the actual document content is stored separately. This enables your app to load the document metadata only, e.g. for a quick overview or listing. The document content can then be loaded separately when needed. The document storage also supports streaming, so you can even process large documents that would otherwise exceed the memory resources available to your app.
Creating and retrieval of large documents is directly supported by the CGM LIFE Client SDK, handling on-the-fly decryption of the document content during streaming.
Custom MDO Types
Sometimes your application may want to store data in CGM LIFE that is not supported by the schema definitions of the CGM LIFE Core Data Model. For example, you may want to store additional attributes for an existing schema or maybe even a completely new data type that is not part of the Core Data Model at all. In these cases, you may define your own Custom Data Type by specifying an MDO schema as seen above and submitting this schema to CGM LIFE. Note though, that these Custom MDO types can only be read and interpreted by your application. So if you want to exchange medical data with other applications, it is best to use the Core Data Model whenever possible.
History & Versioning
Each MDO is fully versioned. Whenever the owner or the original creator update the content of an MDO, a copy of the previous content is stored in CGM LIFE and the version number of the MDO is increased. This allows clients to display the history of each entry and ensures that the content of a previous MDO version at a certain point in time can be reconstructed in an attestable way.
MDO Meta Data
In addition to the actual MDO content, the following metadata is stored with each MDO:
- the participant id of the MDO’s owner
- the participant id of the MDO’s creator
- the MDO’s transmission date to the server (i.e. when the MDO was stored or last updated in CGM LIFE)
- the MDO type, i.e. the identifier of the associated MDO schema
- a timestamp which describes at which date the MDO is medically relevant (e.g. the prescription date of a medication or the day which is described by a diary entry). This date can and will often differ from the transmission date.
- the MDO’s version (automatically incremented with each update to the MDO)
- a digital signature of the MDO content. The signature must be calculated using a valid working credential of the MDO’s creator.
When the MDO is retrieved from the server at a later point in time, the integrity and authenticity of the MDO can be verified using the signature and the corresponding public key of the MDO’s creator, which is stored in the PKI.
Security & Rights Management