### A Pluto.jl notebook ###
# v0.16.0

using Markdown
using InteractiveUtils

# ╔═╡ 54640fbe-86ce-42bf-89cd-6085fa2052cb
md"""
# Data collection and usefulness

The way data is collected is immensely impactful to how useful the data is subsequently. 

First, we need to differentiate between computerized data and computable data.

## PDF Files

### Scanned Documents

A scanned document stored as a PDF is computerized but it is not computable. From the computer's perspective it is simply a blob of pixels or more precisely an array of numbers between 0 and 255 that describe the brightness on the screen that we as humans read as letters, horizontal and vertical lines, letterhead, etc. As an example, consider this scanned document

![chemo worksheet](https://github.com/chapmanbe/raw-stuff/blob/main/DataSources/chemo_worksheet.png?raw=true)

I could potentially run an optical character recognition program to identiy text, but this is going to be a noisy (error prone) process that does not preserve an structure/context that may be implied in the original document. For example, running the OCR program [tesseract](https://github.com/tesseract-ocr/tesseract) on this document and then trying to copy the identified text yielded "mrieTorich" for "Antibiotics" on line 12. Recognizing the handwriting was hopeless.


### PDF generated by word processing software

## Text entry

Here is an excerpt from an actual note in my medical record:

```text
 PROBLEM:   HYPERTENSION
 
     1. CLINIC BP TODAY = 122/79  WITH GOAL BELOW 130/80
         
 
     2. CURRENT MEDICATION:  LISINOPRIL 10 MG DAILY
 
 
PROBLEM:  Chronic kidney disease DUE TO REMOVAL OF KIDNEY
 
     1. LAST CREATININE = 1.52 12/2018
           --HAVE BEEN STABLE FOR YEARS
         NORMAL MICROALBUMIN/CREATININE RATIO AND URINALYSIS
```

From a computational perspective, this string is an advance over the PDF-as-image data described previously. The computer recognizes `B` as a _B_ and `P` as a _P_ yet has no concept that `BP` represents blood pressure or that `122/79` represents the dual concepts 

- _systolic blood pressure: value=122, units of measurement=mmHg_
- _diastolic blood pressure: value=79, units of measurement=mmHg_

In order to make these values computable, a natural language processing program would have to be designed and implemented to recognize this, a process that would be imperfect at best, most likely imperfect and time consuming.

By contrast, below is an excerpt from the HL7 document (converted from XML to JSON) containing the structured data entry for the blood pressure measurement taken during this visit. While hard to interpret by eye without knowing all the OID values used for HL7 documents, we can make the following observations about the observation:

1. The coding system that the data uses is clearly identified: (LOINC)
1. The concept is provided with its non-semantic ID (_"8480-6"_) as well as its text representation _"Systolic blood pressure"_
1. _"122"_ is identified as the value
1. _"mm[Hg]"_ is identified as the unit
1. Similar observations for the diastolic value

__These data are computable!__



```JSON
"component": [
                    {
                      "observation": {
                        "@classCode": "OBS",
                        "@moodCode": "EVN",
                        "templateId": [
                          {
                            "@root": "2.16.840.1.113883.10.20.22.4.27"
                          },
                          {
                            "@root": "2.16.840.1.113883.10.20.22.4.27",
                            "@extension": "2014-06-09"
                          }
                        ],
                        "id": {
                          "@root": "1.2.840.114350.1.13.90.2.7.1.2109.1",
                          "@extension": "5623842480-sysBP-22122"
                        },
                        "code": {
                          "@code": "8480-6",
                          "@codeSystem": "2.16.840.1.113883.6.1",
                          "@codeSystemName": "LOINC",
                          "originalText": "Systolic blood pressure"
                        },
                        "text": {
                          "reference": {
                            "@value": "#sysBP_5623842480"
                          }
                        },
                        "statusCode": {
                          "@code": "completed"
                        },
                        "effectiveTime": {
                          "@value": "20190318182800+0000"
                        },
                        "value": {
                          "@xsi:type": "PQ",
                          "@unit": "mm[Hg]",
                          "@value": "122",
                          "@xmlns:xsi": "http://www.w3.org/2001/XMLSchema-instance"
                        }
                      }
                    },
                    {
                      "observation": {
                        "@classCode": "OBS",
                        "@moodCode": "EVN",
                        "templateId": [
                          {
                            "@root": "2.16.840.1.113883.10.20.22.4.27"
                          },
                          {
                            "@root": "2.16.840.1.113883.10.20.22.4.27",
                            "@extension": "2014-06-09"
                          }
                        ],
                        "id": {
                          "@root": "1.2.840.114350.1.13.90.2.7.1.2109.1",
                          "@extension": "5623842480-diaBP-22122"
                        },
                        "code": {
                          "@code": "8462-4",
                          "@codeSystem": "2.16.840.1.113883.6.1",
                          "@codeSystemName": "LOINC",
                          "originalText": "Diastolic blood pressure"
                        },
                        "text": {
                          "reference": {
                            "@value": "#diaBP_5623842480"
                          }
                        },
                        "statusCode": {
                          "@code": "completed"
                        },
                        "effectiveTime": {
                          "@value": "20190318182800+0000"
                        },
                        "value": {
                          "@xsi:type": "PQ",
                          "@unit": "mm[Hg]",
                          "@value": "79",
                          "@xmlns:xsi": "http://www.w3.org/2001/XMLSchema-instance"
                        }
                      }
                    }
```

One thing that might strike you about this data is how verbose it is. To express "79 mm[Hg]" (8 characters). The number of characters used to represent this in JSON is 132 characters. This inefficiency is an important tool to reduce ambiguity.

> Redundancy—inefficient by definition—serves as the antidote to confusion. It provides second chances. Every natural language has redundancy built in; this is why people can understand text riddled with errors and why they can understand conversation in a noisy room. Most of the time, redundancy in language is just part of the background....Another specialized language provides a perfect analog: the language of aviation radio. Numbers and letters make up much of the information passed between pilots and air traffic controllers: altitudes, vectors, aircraft tail numbers, runway and taxiway identifiers, radio frequencies. This is critical communication over a notoriously noisy channel, so a specialized alphabet is employed to minimize ambiguity. The spoken letters B and V are easy to confuse; bravo and victor are safer. M and N become mike and november. In the case of numbers, five and nine , particularly prone to confusion, are spoken as *fife* and *niner*. (Gleick, James, _The Information: A History, a Theory, a Flood_)

### "Structured" Free Text Entry

The text excerpt I provided above was a small section of the SOAP note generated by my GP after the visit. Although there is structure provided by the SOAP format, it is essentially a free flowing stream of text.

Other text entry occurs in more constrained fields. For example, there might be a field for "First/Given Name" and "Surname/Family Name/Last Name". With the plethera of names in the world, this could not feasibly be entered anyway other than typing. This mgives all sorts of opportunities for typographical errors. I think that I'm `Brain` rather than `Brian` in a significant number of databases. The longer the text field, the more opportunity for typos, synonyms, ambiguous abbreviations. etc.

"""

# ╔═╡ 568ad495-ac20-40e3-9abb-220e5a0e1c78
md"""

## Problems with structured entry

Using standards for data greatly expand the usefulness of the resulting information. However, just because standards are used does not mean the standards are correct. As mentioned earlier with ICD codes, the purpose and manner in which codes are used  will introduce error and or bias into the resulting information.

Further, codes are still liable to data entry errors. 

Jo-Anne Manski-Nankervis, a GP participating in this course, shared the following examples of coded data entry errors:

>One pathology company labelling both fasting and random glucose pathology tests results with the same code: 14749-6.
>
>The other example is a large general practice data set which included an ATC code for a vaccine that had been applied to other medications at random. Relying on the codes would have resulted in a underestimation of the prescription of cardiovascular medications in general practice.


### Drop down menus (and other prepopulated selection forms) for data entry


Consider this story that ran on ABC News 14 September 2021:

- [Indigenous vaccination rates in Victoria revised downwards after software error detected](https://www.abc.net.au/news/2021-09-14/indigenous-vaccination-rates-in-victoria-dashed-software-error/100459000)

Default values are problematic as they don't require conscious assertion of a fact by the person entering the data. For example, should we prepopulate all blood pressure measurements with 120 mmHg for systolic and 80 mmHg for diastolic?

Other problems with drop downs include:

- Simply selecting the first element
- Proximity errors where an adjacent menu item is selected instead of the intended/correct item.

### How can structured entry help ensure data quality?

On the positive side, coded data entry allows for checking for data integrity at the point of data entry.


- Data validation:
   - Data entry can be designed such that range checking is enforced. For example, weight must be a positive quantity or blood pressure be within physiologically possible values, with conscious overrides possible
   - Format checking:
      - Ensure that numbers are numeric
      - Phone numbers, email, etc. are in appropriate format


However, coded data entry is more tedious than simply typing free text and so a data collection strategy needs to balance ease of use with accuracy and completeness.
"""

# ╔═╡ Cell order:
# ╟─54640fbe-86ce-42bf-89cd-6085fa2052cb
# ╠═568ad495-ac20-40e3-9abb-220e5a0e1c78
