Code status proposal #46

jraffa · 2018-07-31T20:14:31Z

tompollard · 2018-08-02T01:26:15Z

concepts/Code_status/carePlan_getItemValues.Rmd

+require("RPostgreSQL")
+drv <- dbDriver("PostgreSQL")
+con <- dbConnect(drv, dbname = "eicu",
+ host = "localhost", port = 5432,


If possible avoid including your own username etc here. Might be better to include config settings at the top to make it easier for people to reuse the code. In other examples, we've included this at the top:

# Load configuration settings dbdriver <- 'PostgreSQL' host <- '127.0.0.1' port <- '5432' user <- 'postgres' password <- 'postgres' dbname <- 'mimic' schema <- 'mimiciii'

I have added the configuration settings at the top.

tompollard · 2018-08-02T01:26:39Z

concepts/Code_status/carePlan_getItemValues.Rmd

+con <- dbConnect(drv, dbname = "eicu",
+ host = "localhost", port = 5432,
+ user = "josephpark", password = rstudioapi::askForPassword("Database password"),
+ options = "--search_path=eicu")


For most people, I think the schema will be something like eicu_crd

With the configuration setting, hopefully it is clearer despite the different schema name.

tompollard · 2018-08-02T01:27:24Z

concepts/Code_status/Readme.md

@@ -0,0 +1,9 @@
+The files here create a patient table that tracks the changes to the patient code status. The careplangeneral table was used instead of careplaneol because careplaneol had much less recorded patients, and the type of code status change was recorded in careplangeneral. There are two versions of the files: .Rmd and .sql. The Rmd version is the supported version, while the SQL version is not supported and was added just as a template.


What does it mean for the version to be supported? If they are likely to get out of sync, it might be safer just to include one or the other?

I have added a little more explanation to the Readme, stating that the SQL version was mostly autogenerated by using show_query(). I have included both versions, although I have done the analysis through R, for consistency since most of the MIMIC code repo is in SQL, so having an .sql file might be useful as a template.

tompollard · 2018-08-02T01:27:52Z

concepts/Code_status/Readme.md

+The files here create a patient table that tracks the changes to the patient code status. The careplangeneral table was used instead of careplaneol because careplaneol had much less recorded patients, and the type of code status change was recorded in careplangeneral. There are two versions of the files: .Rmd and .sql. The Rmd version is the supported version, while the SQL version is not supported and was added just as a template.
+
+Rmd:
+ - carePlan_getItemValues creates a csv that contains all the cplitemvalues for inspection, in order to choose the values that correspond to patient code status.


Unless there's a good reason to use camelcase, I'd suggest following current style and changing to lower case. Mixing upper and lower is awkward when typing things out.

I have changed all filenames to lowercase instead of using camelcase.

tompollard · 2018-08-02T01:38:01Z

concepts/Code_status/carePlan_getPatientCode.sql

+DROP MATERIALIZED VIEW IF EXISTS patientCodeStatus;
+CREATE MATERIALIZED VIEW patientCodeStatus AS
+
+SELECT "patientunitstayid", "cplitemoffset", string_agg("cplitemvalue", ', ') AS "cplitemvalue"


It's difficult to make sense of this query, I guess because it was automatically generated. If we are going to include SQL, then ideally it should be readable. If the plan is to automatically generate it, then perhaps include an option to output SQL in the R Markdown?

I have added comments in both the .Rmd and .sql files that tells people how the .sql file was generated (using show_query()) to clarify how this was produced.

tompollard · 2018-08-02T02:00:44Z

concepts/Code_status/Readme.md

@@ -0,0 +1,9 @@
+The files here create a patient table that tracks the changes to the patient code status. The careplangeneral table was used instead of careplaneol because careplaneol had much less recorded patients, and the type of code status change was recorded in careplangeneral. There are two versions of the files: .Rmd and .sql. The Rmd version is the supported version, while the SQL version is not supported and was added just as a template.


Instead of ignoring the information in careplaneol, could it be used to supplement the information in careplangeneral?

It seems careplaneol is focused on discussion (e.g., family meeting), and contains little information about treatment limitations.

tompollard · 2018-08-02T02:04:55Z

concepts/Code_status/carePlan_getPatientCode.Rmd

+ arrange(desc(n))
+```
+
+Example of a patient. This patient was strange with both full therapy and no CPR at the same time.


If we add this code, then there is an expectation that it provides a reasonable summary of changing status. Do the numbers seem reasonable when checked with nursing staff, compared with MIMIC etc?

@psy01212 created the list with Jerome. It's likely hospital dependent like most data in eicu.

tompollard · 2018-08-02T02:14:12Z

concepts/Code_status/carePlan_getItemValues.Rmd

+ except cplitemvalue = 'End of life', which was in cplgroup = 'Ordered Protocols'.
+
+```{r, connection = con}
+library(dplyr)


The SQL is only 4 lines long, so it seems overkill to include a whole RMarkdown file. Couldn't we just use the SQL, which is more consistent with the usual approach?

We could do either. @psy01212 did it in R, I asked him to use the translate facility in dplyr to have that option available.

I have included both versions, although I have done the analysis through R, for consistency since most of the MIMIC code repo is in SQL, so having an .sql file might be useful as a template.

tompollard · 2019-02-01T18:01:28Z

Thanks for the updates. I'm okay to merge, but I've listed a few thoughts below:

R vs SQL

I'm not sure that the R notebooks add anything beyond the SQL. Some clean SQL would be consistent with our general approach, and easier to interpret, update, and reuse.

e.g. why not replace careplan_getpatientcode.rmd and careplan_getpatientcode.sql with (which I think is doing the same thing as the current auto-generated SQL, but in a more readable way):

DROP MATERIALIZED VIEW IF EXISTS patientcodestatus;
CREATE MATERIALIZED VIEW patientcodestatus AS

SELECT patientunitstayid, cplitemoffset, string_agg(cplitemvalue, ', ') AS cplitemvalue
FROM careplangeneral
WHERE cplitemvalue IN ('Full therapy', 'Do not resuscitate', 'No CPR', 
    'No intubation', 'Comfort measures only', 'No cardioversion', 
    'No vasopressors/inotropes', 'No augmentation of care', 'End of life', 
    'No blood products', 'No blood draws', 'Advance directives')
GROUP BY patientunitstayid, cplitemoffset
ORDER BY patientunitstayid, cplitemoffset, cplitemvalue;

If we are going to include the R notebooks, it feels like they should be doing more than simply generating SQL. Perhaps they could be expanded to visualise the tables generated by the SQL?

names and dates in files

Following the style guide, please remove author names or dates in files (these are tracked in the commit history). Trying to fairly maintain these details in files is tricky.

example patient in `careplan_getpatientcode.rmd`

careplan_getpatientcode.rmd finishes with the following chunk:

Example of a patient. This patient was strange with both full therapy 
and no CPR at the same time.

{r, connection = con,eval=FALSE}
patientCodeStatus %>%
  filter(patientunitstayid == 266999)

This example returns a single row for me, which seems inconsistent with the comment:

patientunitstayid   266999
cplitemoffset       21041
cplitemvalue        No intubation

If the R notebook is going to be included with this example, it would be helpful to dig a little deeper. Are there any explanations for the inconsistency?

psy01212 added 9 commits January 10, 2018 14:31

Creating new directory

efa9eb7

Add files via upload

2b095a7

Added SQL files

d5e66ac

Added readme

0f8b6ea

Added not supported comments to sql files

32bd42d

Added materialized view in sql getPatientCode

766ac8b

fixed semicolon errors

5349bfe

getItemValues.sql creates a materialized view

a26dab3

Update Readme.md

6ffa417

jraffa requested review from tompollard and alistairewj July 31, 2018 20:14

tompollard reviewed Aug 2, 2018

View reviewed changes

psy01212 and others added 6 commits December 3, 2018 15:19

Added config settings for connecting to database.

13bc85e

Renamed files/directory to only use lowercase

26cf2f6

Renamed to use lowercase

bf803b8

Added explanation of how .sql files were autogenerated

f172f8f

Added configuration settings for getpatientcode

f3186eb

Fixed small typo

4dd353b

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Code status proposal #46

Code status proposal #46

jraffa commented Jul 31, 2018 •

edited by tompollard

Loading

tompollard Aug 2, 2018

jraffa Aug 2, 2018

psy01212 Dec 4, 2018

tompollard Aug 2, 2018

psy01212 Dec 4, 2018

tompollard Aug 2, 2018

psy01212 Dec 4, 2018

tompollard Aug 2, 2018

psy01212 Dec 4, 2018

tompollard Aug 2, 2018

psy01212 Dec 4, 2018

tompollard Aug 2, 2018

jraffa Aug 2, 2018

tompollard Aug 2, 2018

jraffa Aug 2, 2018

tompollard Aug 2, 2018

jraffa Aug 2, 2018

psy01212 Dec 4, 2018

tompollard commented Feb 1, 2019 •

edited

Loading

		@@ -0,0 +1,9 @@
		The files here create a patient table that tracks the changes to the patient code status. The careplangeneral table was used instead of careplaneol because careplaneol had much less recorded patients, and the type of code status change was recorded in careplangeneral. There are two versions of the files: .Rmd and .sql. The Rmd version is the supported version, while the SQL version is not supported and was added just as a template.

Code status proposal #46

Are you sure you want to change the base?

Code status proposal #46

Conversation

jraffa commented Jul 31, 2018 • edited by tompollard Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tompollard commented Feb 1, 2019 • edited Loading

R vs SQL

names and dates in files

example patient in careplan_getpatientcode.rmd

jraffa commented Jul 31, 2018 •

edited by tompollard

Loading

tompollard commented Feb 1, 2019 •

edited

Loading

example patient in `careplan_getpatientcode.rmd`