minor edits to paper.

report/academic_paper.Rmd

@@ -1,4 +1,5 @@
 ---
+title: ""
 output: 
  #html_document: default
  pdf_document: default
@@ -9,9 +10,9 @@ bibliography: academic_paper.bib
 knitr::opts_chunk$set(echo = TRUE)
 ```
 
-# Living HEOR: Automating HTA with R
+# Living HEOR: Automating HTA with R {.tabset}
 
-*Smith R^1^, Schneider PP^1^*
+*Robert A Smith^1^ & Paul P Schneider^1^*
 
 <br>
 
@@ -33,7 +34,7 @@ knitr::opts_chunk$set(echo = TRUE)
 
 The process of updating economic models is time-consuming and expensive, and often involves the transfer of sensitive data between parties. This paper aims to demonstrate how updates to models in the Health Economics & Outcomes Research (HEOR) industry can be conducted in a way that allows clients, primarily those in the pharmaceutical industry, to retain full control of their data. We continue on to show how to automate reporting as new information becomes available, without the transfer of data between parties.
 
-## Method
+## Method {.tabset}
 
 We developed an automated analysis and reporting pipeline for health economic modelling and made the source code openly available on a GitHub repository. It consists of three parts:
 - An economic model is constructed by the consultant using pseudo data (i.e. random data, which has the same format as the real data).
@@ -47,9 +48,25 @@ All of the scripts discussed in this paper, as well as the code for the demonstr
 
 ### The API
 
+An application programming interface is a set of rules, in the form of code, that allow different computers to interact with one another in real time. Whereas user-interfaces such as those generated by *shiny* allow humans to interact with data, APIs are designed to enable computers to interact with data.
+
+When a 'client' application wants to access data, it initiates an API call (*request*) via a web-server, to retrieve the data. If this request is deemed valid, the API makes a call to an external program/server, the server sends a response to the API with the data, and the API transfers the data to the 'client' application. In a sense, the API is the broker (or middle-man) between two systems.
+
+There are numerous benefits to APIs:
+- in aiding speed of collaboration between institutions, ensuring inputs and outputs are standardised so that applications can 'talk' to one another.
+- in security, eliminating the necessity to share data manually (e.g. via email). All interaction with data can be logged and access can be restricted by passwords and by limiting IP address access.
+- eliminating computational burden on the client side (since all computation is done on the API owner side.)
+
+There are lots of different implementations of APIs, but the main focus of this paper is on **Partner APIs**, which are created to allow data transfer between two different institutions. This requires a medium level of security, usually through the creation of login keys that are shared with partners.
+
+In the examples below we use JSON to pass information to and from our API.
+
+
 #### Plumber
 
-```{r, file='../darthAPI/plumber.R',eval = F, echo = T}
+Insert description of plumber and what it does....
+
+```{r, file='../darthAPI/plumber.R',eval = F, echo = T, class.source = 'fold-hide'}
 ```
 
 #### RStudio Connect
@@ -61,7 +78,7 @@ Once you have an account, it is simple to deploy the API direct to [RStudio conn
 
 This model code has been amended from the DARTH group's open source Cohort state-transition model (the Sick-Sicker Model) which can be found in this [GitHub repository](https://github.com/DARTH-git/Cohort-modeling-tutorial/) and is discussed in @alarid2020cohort.
 
-```{r, file='../R/darth_funcs.R', eval = F, echo = T}
+```{r, file='../R/darth_funcs.R', eval = F, echo = F}
 ```
 
 ### Automating the model run