German Medical Exams

Based on work documented in previous post, I then decided to allow the user to configure whether multiple selections made within one multiselect field should be related to each other by OR or AND, for example to allow
remedy = bloodletting AND purge
as well as
remedy = bloodletting OR purge
The operator within each field works independently of the control for the existing operator between fields, so any of these queries is now doable:
(examiner = smith) OR (remedy = bloodletting OR purge)
(examiner = smith) AND (remedy = bloodletting OR purge)
(examiner = smith) OR (remedy = bloodletting AND purge)
(examiner = smith) AND (remedy = bloodletting AND purge)

I had to extend the code modifications described before, and add a pair of radio buttons to the interface of the popup window to allow the user to specify. Entailed changes to a javascript file, lib.php and libsql.php, search.php and datalist.php by the time all was done.

MLH told me that if he did queries involving more than one choice in a multiselect field, the results coming back were wrong. For example,
If I search for remedy = bloodletting, I get 23 results
If I search for remedy = purge, I get 52 results
Before, when I searched for remedy = bloodletting OR purge I got 0 hits.

Problem was with code that generates the where clause in the SQL query, in particular where that code has to search 2 fields. It was generating a clause like this:
((remedy1 = "bloodletting OR purge") OR (remedy2 = "bloodletting OR purge"))
and so I corrected it to create a clause like this:
(((remedy1 = "bloodletting") OR (remedy1 = "purge")) OR ((remedy2 = "bloodletting") OR (remedy2 = "purge")))

Now, when I search for remedy = bloodletting OR purge, I get 58 hits.

MH asked to be able to query large blocks of text in the condition field. I gave him controls so that he could try:

"Condition begins with"
"Condition any word begins with"
"Condition contains"
"Condition also contains"
"Condition does not contain"

For now, the query just returns the same results as all the other types of query. Once he's settled on the type of query interface he wants, I'll likely implement it on a separate page and have a different presentation of the report.

substituted the "Approved Measure" field in place of the Document ID (and omitted the Document ID out--MH doesn't want it there

In the initial search display, moved the results for "Bathing and "Res. Care" that are now in the Exam detail and put them in the initial display of search results

Wrote the code to figure out if any of the fields in the previous area of each record have non-default values, and if so, to display an 'expand the previous history details' area for this record.
Decided to structure each report record into 4 lines:
- always-visible fields
- patient and examiner details
- exam details
- previous history details
Modified the expand/contract controllers and added new ones so the user can:
- expand or contract the patient details for one record or for all records
- expand or contract the exam details for one record or for all records
- expand or contract the history details for one record or for all records
- expand or contract all details for one record or for all records
Those controls occupy 1/3 of the the always-visible space for each record, but I can't think of a more compact way of presenting the controls.

Also discovered a couple of instance of the dreaded "=" where it should be "==". Greg was the extra pair of eyes that helped me spot that error.

Sent MH an email asking him to review.

Made a lot of modifications to the search.php file to accommodate changes in the fields we care about:
added variables for observation, disorder, remedy, bath, residential_care and commented out condition, treatment, facility
modified $query variable based on those changes to fields we care about
modified $left_join variable based on changes to fields we care about
modified $where variable based on changed to fields we care about
Querying appears to work successfully, reports sensible number of hits, but actual reporting is a mess until I rewrite the code which generates the results table to reflect the newly created and deleted variables.

Met with MH to go over changes we need to make in the search and report interface to reflect the changes that have been made in the database and in the add and edit record pages.

He wants in the query part a section on "patient and practioner" a section on "examination" a section on "date".
He wants in the report part a few fields to appear by default, a way to expand details on the current examination, a separate way to expand details on previous history details, and a third way to expand details on all fields.

MH asked to be able to search on a number of new fields. I looked into the implications of that (listed below) and sent him an email asking for clarification before I start changing code.
We are deprecating these fields in the database:
previous_treatment_1
previous_treatment_2
recommended_treatment_1
recommended_treatment_2
On the Search interface, there is currently a field for "Treatment" which searches all four of the treatment field in the database. Suggest we eliminate the Treatment field from the search interface.

We added a number of new fields to the database:
previous_food_rest (checkbox)
previous_exam_noted (checkbox)
previous_complex_treatment (checkbox)
previous_bath
previous_remedy
previous_residential_care
disorder_1
disorder_2
bathing
residential_care
remedy_1
remedy_2

I need MH input on
- which of these new fields to be able to search?
- what elements to add to the search interface and how do those elements relate to the fields?

To be specific:
1) able to search for those records which have the "previous_food_rest" checkbox checked or not. If so, we'd likely add an item in the search interface called "previous food rest" and which could have the values "yes", "no", "all".
2) similar question to above for the previous_exam_noted checkbox
3) similar question to above for the previous_complex_treatment checkbox

4a) "disorder_1" field in the database to be searchable?
4b) "disorder_2" field in the database to be searchable?
4c) If both, then one item in the search interface which searches them both (similar to how the treatment interface now works) or a separate item in the interface for each?

5a) "previous_bath" field in the database to be searchable?
5b) "bathing" field in the database to be searchable?
5c) If both, then one item in the search interface which searches them both (similar to how the treatment interface now works) or a separate item in the interface for each?

6) similar questions to above for "previous_residential_care" and "residential_care" fields in the database

7) similar questions to above for "previous_remedy", "remedy_1" and "remedy_2" fields in the database

Created renmedical/sampleGUI/index.htm to show list of 18 records each of which consists of a text title, a small image of a page, the transcript, the translation of the transcript and a notes box. Each box is collapsible to just the text title.

I did one instance with divs and one with tables. Having a hard time getting the decorative effects (e.g. bounding rectangles) to appear properly in the div-based one because of course the two elements on the right hand side are floated so aren't considered graphically "inside" their containing object in the DOM. I've had this headache before.

Made about a dozen modifications to the edit and add pages to include additional values for a number of fields and to remove values from certain other fields.

Also investigated report that submission of record to database wasn't working, but couldn't reproduce the problem and ZS then reported everything was fine.

In the previous treatment area added the following controls:
"food and rest" checkbox
"previous exam noted" checkbox
"complex treatment" checkbox
"bathing" drop-down list
"remedy" drop-down list
"residential care" drop-down list

In the examination area, added the following controls:
"food and rest" checkbox
"nursing card" checkbox
"complex treatment" checkbox
"bathing" drop-down list
"remedy" drop-down list
"residential care" drop-down list

Here's the generic procedure

1) modify database
add new tables as needed for lookups, even though they're not actually being used (other than by developer to generate code through create_selects.php)
add new fields to the exams table
The create_selects.php file can be used to generate code for GUI for the add.htm and doGetRecordRenMedic.php files based on the values in specified fields in a specified table.
2) in the add.htm page
add new GUI elements
3) in doSubmitRenmedic.php
add new variables at top of file
add new arguments to $query = "INSERT INTO exams ...
4) in doGetRecordRenMedic.php
add new GUI elements for display in the edit.php page
5) in doUpdateRecordRenmedic.php:
add new variables at top of file
add new arguments to $query = "UPDATE exams ...
5) in doReportAllRecordsRenmedic.php and doReportOneRecordRenmedic.php:
modify header cells and content cells
6) in renmedic.js:
add arguments to function getVarsToSubmit(formIn)

Started testing my new code by adding and editing a new item in the database. Everything seems to be working so far with the new stuff, but I noticed a couple of problems with other fields not showing up when I went back to edit the record after submitting it. I found that:

• the patient_notes field is actually called "p_notes" in the database, but the doGetRecordRenmedic.php file was retrieving data using "patient_notes", so the data was missing.
• The code retrieving the followup_notes had "<?php echo $followup_notes;?>" instead of "<?php echo $row['followup_notes'];?>.

After fixing these bugs, the two fields now show up OK. Adding and editing a record also now seem to work with all my new fields, so I think I'll sign off at this point; ML should be able to continue adding data. The one part of the site which I haven't modified is the Search field, because it's quite complicated, and because it seems to be in more active development. I'll inform ML of that limitation, and Stew can integrate the new fields into the search when he comes back.

These are the changes I've made:

• Full backups of site and db before starting (on my HD, and will also be pushed to Rutabaga).
• Created a new table called "observations" containing "observation_id" and "observation_text", on the model of other lookup tables in the db.
• Populated that table with data as required (21 items).
• Created a new table called "locations" containing "location_id" and "location_text".
• Populated that table with data as required (13 items).
• Created a new table called "disorders" containing "disorder_id" and "disorder_text".
• Populated that table with data as required (17 items).
• Added six new tinyint fields to the "exams" table following the "condition_2" field:
  • observation_1
  • location_1
  • disorder_1
  • observation_2
  • location_2
  • disorder_2
  Following the existing practice with this database, I have NOT set up any formal structural relationships between these fields and the lookup tables they will reference. I presume that those relationships will be set up later, when the structure has been finalized.
• Added a boolean value called "multiple_conditions" after "disorder_2": ALTER TABLE `exams` ADD `multiple_conditions` TINYINT( 1 ) NOT NULL DEFAULT '0' AFTER `disorder_2` ;
• Added a second boolean value for multiple treatments, in the same way: ALTER TABLE `exams` ADD `multiple_treatments` TINYINT( 1 ) NOT NULL DEFAULT '0' AFTER `treatment_2` ;
• Added two new values to the "facilities" table: 11="infirm house OR hospital", 12="weekly bath", as requested.

That concludes changes to the database. Next, the interface pages. First, the changes related to new items in the "facilities" table:

• In doGetRecordRenmedic.php, added two new option elements to the facility_1 dropdown.
• In add.htm, added two new options to the select list.
• NO CHANGES to other files for this specific change, because they just report numerical values.
• Uploaded changes and confirmed they show up OK.

Next, changes to the edit for in doGetRecordRenmedic.php:

• First, I wrote a little script to auto-generate the select elements I need from the database structure; this seems to me to be far more reliable and convenient than hard-coding. The script is at create_selects.php, and it can be modified to create any select element you need.
• From that, I generated select elements for the doGetRecordRenmedic.php page, and inserted them after the condition_1 and condition_2 elements, leaving those in place for the moment.
• Finally, I added two checkboxes for the new multiple_conditions and multiple_treatments fields, like this:

  <input type="checkbox" name="multiple_conditions" <?php if ($row['multiple_conditions'] == '1'){echo ' checked="checked"';} ?> />

Next, moving on to the add.htm page:

• Same six drop-downs added.
• Same two checkboxes added.

Then I added columns for all eight of the new fields to doReportAllRecordsRenmedic.php.

Then I made appropriate changes to doSubmitRenmedic.php, including adding the new fields to the commented-out debugging code.

Then I made the same changes to doUpdateRenmedic.php.

Finally, I made changes to renmedic.js to add my eight new fields at the end of the array that's submitted, also adding some special handling for the checkboxes.

Finishing up for the day, everything LOOKS OK and I see no JS errors, but I haven't actually tested anything at all yet. That will be done on Monday.

Stew's currently away, so I'm fielding a request from ML to make the following changes to the db. I'll log the changes I make as I go along. I took a good look at the code on Tuesday, and it looks fairly straightforward, but I'll do a complete backup of the db and the site before making any changes.

1. Please replace condition _1 and condition_2 with two sets of the following three menus (just use the English on the left, 
the German is my key to the terms actually used in my documents)

--also please add a button labeled "multiple" that I can check off to indicate that 
there are more than two distinct conditions as described in the six available fields. 

OBSERVATION:
weak				(matt, erschopft, schwach, ermudet, armut, verhungert, verzehrt, krafftlos,
				onmechtig, unfähig, beruf  nit auswarten kan)
old				(alt, veraltet, im hohen alter, 60+)
pain				(schmertzen, weh)
fever				(fieber)
heat				(hitz, innerliche hitz)
flow-cold			(erkaltung, kalte fluss, frost)
flow-hot			(hitziger fluss, scharpfen fluss, saltziger fluss)
flow-blood			(blut harnen, nasenblut, unrein blut)
retention of menses		(keine weiblichen reinigung)
blockage of flow		(ausgestopft, bose feuchtigkait, unflat)
weight loss			(abnemung des leibes)
cough				(husten)
cold				(erkeltung, erfroren)
lame				(erlehmung, die leme)
swollen			(geschwollen)
skin-rash			(kratzen, masern, rauden, scabies, flecken)
skin-swellings			(fistel, krebs, geschwulst, carbunkel, beulen, bitzell, rotlauf)
skin-sores			(offene schaden, loch, pocken, blattern, beissen)
skin-general disturbance	(schadhafft, unsauber, unrein, ausgefallen, erbgrind)
irregular bowel movement	(hefftigen undewen) 
irregular urination		(verstopffung, nit harnen kan)

LOCATION: 
entire body			(am gantzen leib, durchaus)
head				(kopfschmerz, -wehe, -störung, angesicht, antlitz, hauptblödigkait)
lungs/chest			(lungensucht/siech, engbrustigkait, catarrh, schwindsucht, -schleim)
liver				(lebersucht, -fluss, -geschwulst)
stomach-digestion		(magen-, verdawen-, darm-, durchfall, ruhr, grimmen)
heart				(herz erkrankung)
genitalia			(schadhafft am heimlichen ort, störung des manlichen glid)
back/spine			(ruckenweh, axeln )
limbs				(glieder, beine)
arms				(arme)
legs				(schenckhel)
hands				(hende)
feet				(fussen)


DISORDER:
French disease			(frantzosen, frantzosische pocken, "die f. nit ungleich," böse blattern)
consumption			(phthisis, lungensucht)
dropsy				(wassersucht)
dysentery			(durchfall)
jaundice			(gellsucht, gelbsucht)
leprosy				(aussatz, lepra, sondersiech)
gangrene			(kalte brand)
hernia				(bruch)
stroke				(schlag, onmecht)
epilepsy			(fallende sucht/krankheit, wehetage, arbeit)
depression			(anfechtung, schwermutigkeit, melancholia)
mental deficit			(blödsinnig, leichtsinnig, kindisch, verruckt, wahnwitz)
wound/injury			(wund, stich, schuss, verletzung, _ gebrochen)
kidney/bladder stones		(stein, calculi)
old age				(wegen seinem hohem alters)
rheumatism			(gicht)
other (see text box)			

2. For RECOMMENDED TREATMENT:

Add a place (just a button would be fine) that I could check off when there are "multiple" (ie more than 2) treatments. 
Right now "multiple" is now an option on the menus. 
When I use it, it takes up a place where I could simply put a second treatment. 
I'd like to be able to specify two treatments then use the button to refer people to the text box when there are more than two. 

3. For FACILITY:

--Add an option for "infirm house OR hospital." Some of the documents actually specify this choice.

--add an option for "weekly bath"  

At request of MH, I've added a field called "Relate fields with" in the Options area of the search.
Using as en example treatment = bath-May and facility = Wembding :

I did a search with treatment = bath-May and got 4 hits. None of those hits had Wembding for the facility.
I did a search with facility = Wembding and got 2 hits. Neither of those hits had bath-May for a treatment.
I did a search with facility = Wembding, treatment = bath-May and relate-with = AND and I got 0 (zero) hits
I did a search with facility = Wembding, treatment = bath-May and relate-with = OR and I got 6 hits. Other tests also gave me sensible results.

The scope of this AND/OR setting is all the fields in the query, so if you set the option to OR, you get more hits as you add values to more of the other fields, and if you set the relate-with option to AND, you get fewer hits as you add values to more of the other fields.

Implemented this as another field in the form, which then forms part of the post array which I parse and put the value into a variable which is then used when I'm assembling the query.

Added a new search and report field (e.g. family status)

For search form, create new form element by adding to searchformbasic.inc

<label for="p_family">Family Status</label>
<a class="DataListButton" onclick="showDataList('p_family_text','p_families','Family Statuses','f_family_id','p_family','n','y');">
<img src="images/buttons/DataListButton.png" alt="Show a list of possible values for this field" title="Show a list of possible values for this field" class="button" /></a>
<input name="p_family" type="text" id="p_family" value="<? print $p_family; ?>" />

On search.php, grab the value from the form on page load:
$p_family = load_data('p_family');

On search.php, extend SELECT clause of $query by appending:
" p_families.p_family_text"

On search.php, do JOIN of exams table and p_families table:
$left_join .= " LEFT JOIN p_families ON (p_families.p_family_id = exams.p_family) ";

On search.php, add to WHERE clause if user has specified a value in the Family field of the search form:
if (!empty($p_family)) {
$where .= make_where_pattern($p_family, 'p_families.p_family_text', $where);
}

On searchresults.inc, grab the family status item from the current row array returned from the search query:
$curPFamily = $row["p_family_text"];

On searchresults.inc, display the family status data:
<th>Family Status</th>
<td><?php echo $curPFamily;?></td>

Further testing of recent modifications and report by ML indicated that for records with two treatments, only one seemed to be displayed. Turned out to be an instance of the classic '"=" instead of "==" operator in an IF clause' bug in my php in searchresults.php. Fixed that.

Also abstracted out the delimiter used to separate multiple values in one field (treatments, examiners, conditions) and put that in a variable so that it's easy to change that from the current vertical pipe to a comma or semi-colon if desired.

My previous tests had used only a simple search (i.e. only the treatment field specified) and they worked. ML provided a specific example of a compound search (year and treatment specified) and I could then reproduce the behaviour he reported. The problem is that I had accidentally deleted this line of code from the code that generates the treatment clause:
if (!empty($where)) {$where .= " AND ";}
I tried treatment=blood-letting and year=1591 and found 2 records, which seems a plausible result as blood-letting alone produces 6 results, 2 of which are in 1591, and 1591 alone produces 90 results, 2 of which are blood-letting.

ML reported that he was getting an SQL error message when he tried to search by treatment

Query failed: You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near
'( t1.treatment_text LIKE '%cure%' OR t2.treatment_text LIKE '%cure%')
GROUP BY ' at line 1

I could not reproduce the behaviour, so asked him to confirm the problem and report on browser and OS, so I could try to reproduce it.

ML asked to have treatments added to list of fields that one can use to search the database. Added that to the GUI in searchformbasic.inc and to the where clause code in search.php. Latter pretty straightforward after I'd made the necessary changes to get the two treatments to display properly in a recent bug fix.

Decided to add treatments to the list of fields that one can sort the results by. Added value to order-by table in database and modified php switch statements for order_by_1_text and order_by_2_text in search.php.

In testing, it looks like the order by 2 isn't doing what I expect it to, so I'll have to look into that further. That argument seems to be having no effect at all.

The treatment(s) (between zero and two) in each record in the search results used to be displayed in the details table for that record in the search results. The details table is by default not displayed in the search results page. MH wanted to put the treatments into the top line of each record in the search results, so that they would be visible at all times.

I edited the php code in searchresults.inc to move the treatments into that top line and then adjusted other bits of code (like colspan arguments) to make the table layout work. I also silghtly rejigged the display of some of the other fields in the display (e.g. move the document id field into the row with the gender, age and socioeconomic status fields).

Bug report from MH that in some records the wrong treatment was being displayed in the search results, with some specific examples.

There are two treatment fields in each record in the database. My code was returning only the first if the second field was empty and only the second if the second field was not empty. I fixed that so that the first field was displayed if not empty and the second field was displayed if not empty.

Adjusted display of the Examiner field so that if examiner 2 is "unknown" then I don't display it. If examiner 1 is "unknown" then that is displayed.

Also added a field to the examiner's table called examiner_full_text which contains the full name of the examiner (which I copied from the examiner_text field for each record), then in the examiner_text field I shortened the first name for each examiner to an initial. The examiner_text field is displayed to the user and MH wanted to reduce the amount of space occupied by the examiner name in the search results. I am not currently using the examiner_full_text field for anything. Example: formerly John Smith in examiner_text field and no examiner_full_text field; now, J. Smith in examiner_text field and John Smith in examiner_full_text field.

In all browsers other than FF for Mac, the css for the items in the popup list of options is corrupted. The cause is that in search.css.php the code is looking for variables such as $_browser_is_ie, and I'd removed the code that defined (in config.php) and set values for (in browserdetect.inc) those variables.

When I inserted the appropriate code, then the css in the popup window worked properly, but the css in the main search window appears to be compeletely disabled. Obviously I'll have to figure out why that is happening. ML has said this is a lower priority than other issues, so I'll deal with those other issues before returning to this one.

Thoroughly edited the help file.
Added two new values to the previous treatment lists and one new values to the recommended treatment lists.
Added "Facility" as a field one can search on. Also made facility one of the fields that appears by default in the results table.
Moved the document_id field in the results table so that it now appears as the last row of the default hidden rows for each record.

Repurposed bits of David's code so that about five fields show up by default for each record, and all the rest are hidden by default and show up only if user clicks a button.

Also tidied up behaviour if no results are returned, made a few other modifications to code to normalize behaviour and presentation.

Added those three fields to the interface. Took me a while to get gender working. When a gender was specified, the gender field in each record appeared. When the gender was not specified, no value appeared in the gender field for each record. I had been asking to display the p_sex field from the exams table (which should have been an integer). When I asked instead to display the gender_text field from the genders table, everything worked perfectly, even though the gender_text value is obtained by a lookup from the p_sex value. I don't get it.

The next two fields went in no problem.

I had a table exams which had a conditions_1 field and a conditions_2 field. Each of those is an integer pointing to a record in the conditions field. Each record in the conditions field contains an index field (integer) and a text field. What I wanted was to return the text value for both conditions. I have to use some kind of alias so that I can refer to the conditions table twice in the one query. Here's the code that works:

SELECT exams.exam_id, exams.condition_1, exams.condition_2 , c1.condition_text AS condition_text_1, c2.condition_text AS condition_text_2
FROM exams
LEFT JOIN examiners ON examiners.examiner_id = exams.examiner_1
LEFT JOIN conditions as c1 ON (
c1.condition_id = exams.condition_1
)
LEFT JOIN conditions as c2 ON (
c2.condition_id = exams.condition_2
)

Important to note that the "conditions as c1" appears in the LEFT JOIN clause and not in the SELECT or FROM clauses. If the alias is specified in the SELECT or FROM clauses then you get an error 1066 duplicate table name/alias error. The SELECT clause includes c1 AS condition_text_1 and c2.condition_text AS condition_text_2 so that two separate fields are returned in the results each of which is based on an independent JOIN clause using a distinct alias to the same conditions table. Thanks to Martin for helping with this.

WHERE exams.p_surname LIKE '%en%'
GROUP BY exams.exam_id
ORDER BY exam_date

I've more or less started from scratch in the search.php file and written the code that generates the sql query based on the values in a number of form elements. The text search right now uses a LIKE %search string% clause (so entering "zen" finds all records in which that string of characters appears somewhere. I'll write to ML to see if that's suitable, or if he wants something else or a choice of different types of string searches.

The problem is that because the e.g. condition query does an OR operation on the condition_1 field and the condition_2 field, I end up with duplicate hits on the same record.

Spent most of today creating an interface to allow the user to specify a record number they want to edit, then grab that record from the db and present the html form with all the values in the elements set based on the values for that record obtained from the db. Validated the page too.

Have written the stubs for the code to update the db from the page, but did not have time to start on the actual code.

I had a php page with 'meta http-equiv="Content-Type" content="text/html; charset=UTF-8"' on the page and 'accept-charset="UTF-8"' on the form submitting German characters to a mysql database with utf8_unicode_ci as the character encoding for the table and for each text field in the table

In the database
ß appeared where an ß should have been
ü appeared where an ü should have been
ä appeared where an ä should have been
ÿ appeared where an ÿ should have been

Found answer in Martin's post on same subject. Tested that sucessfully. Then manually edited each wrong character in the existing records in the database.

Did a bit of reading on AJAX / PHP / mySQL and decided to complete the exercise of reproducing the functionality of the two-page php interface for entering records into the renmedic db with one page using AJAX to call the appropriate methods and update itself. A simple project.

By end of day had successfully created such an interface - on first opening the page displays the input form and current records in db, on submit button, checks data, submits it, updates display of records. Mechanically working, needs polishing.

Reworked a couple of the fields in the db and broke up php into separate files as needed, too.

Completed populating the mysql db with fields, gave them what seem like reasonable datatypes, sizes, defaults etc.

Completed the js code to check text fields and date fields before submitting the form elements to php to be sent to the mysql database.

Completed the php that submits the data to the database, presents the results in a table to the user etc.

Emailed ML to let him know I need his input before it makes sense for me to do much more.

Wrote the code to send all the fields with the exception of information on head of house, second examiner and a couple of other fields that will be trivial to add. Also still need to work out how to write the GUI for the dates and then process that into the format required for an SQL data object.

Also wrote the beginnings of the JS code that grabs the submit event on the form, checks the data before submitting it and then either submits to server if data is OK or presents Alert to user if not. I've next to write the actual test for each field of data that needs one.

Now have INSERT working reliably, though inelegantly.
Assembled form elements on page, sent email to ML to confirm kind of data in each field and kind of interface (text box, drop-down list).
Will likely add a big text field for transcription, in case it exists.
Will likely have to add a couple of additional fields for secondary, tertiary complaints, etc. based on feedback from ML.

Got a MySQL database created for the RenMedics project.

Started work on the php front end to display records in the table and to add a new record to the table from the values in a web form. Using very simple approach (one php page with form, action on form invokes another php page which submits the data and confirms to user, allows user to return to form page) - may come up with something a bit more elegant as time allows. Right now I'm focussing on functionality of data input.

Met with Martin, ML and J to discuss schema Martin and I had done, talk about how to proceed.

- We will use stage-in-life at earliest examination for each patient. That attribute will be with the person element and not in the instance in the document.
- We will keep the square bracket convention they're using for editorial additions, and then in the rendering allow the user to show or hide those. That will remove the need for the choice/abbr/expan structure we have now.
- We will use seg tags with type and subtype attributes. The user will select the value for the seg element from a dropdown list specified in the schema. We'll write Schematron rules which will look at the value of the type attribute in the current instance of the seg element and then ensure that the value for the subtype is appropriate based on the value of the type attribute. The user will have to type in the subtype, but any errors will be flagged.
-ML and J estimate about 30 minutes per document to transcribe; we estimate about 15 minutes per document to tag.
-We ended with a discussion about which is more important: the transcription of the text or the data extracted into the tags. ML seemed to think the data extraction. If that's the case, we'll probably write a web form which will allow M or J to enter the data, and behind the scenes the code will generate the appropriate XML structures and write that into the XML db with placeholder texts as needed. Then later, they can insert the correct text into the structure.

Started doing some pilot markup based on a tei_all schema, and had some back-and-forth with ML about how best to handle the editorial expansions and normalizations. Eventually we decided that there should be one German transcription, fully normalized, and no attempt to do a pure diplomatic translation (given that the facsimile images are available anyway). An Within the transcription, <seg> elements will be used to distinguish different types of data, where these are not encodable directly in TEI elements designed for them (people, dates, roles etc.).

Transcriptions will be linked to images using the facsimile module and @facs, and English versions will be linked to the original German by seg/@corresp. People will be linked to a <personList> entry, which will be centralized (but for the moment is in the same file, for the example). ML and his researcher will come in next Monday morning at 10, by which time we hope to have got lists of the various taxonomies we'll need to establish for conditions, treatments, prognoses etc., and encoded these into the schema.

Set up this blog. Copied following text from Martin's post in the dept's blog posted before I set up this blog.

Stew and I met with ML about the XML markup project for German medical data. Coming out of the meeting:

* We want to move to doing markup as soon as possible.
* Stew and I will concoct a TEI schema within the next two weeks, along with a template, and mark up a couple of the documents as examples. The schema will provide all the constraints on e.g. attribute values (see below), which ensure standardization where required.
* ML will supply lists of the standardized values for key data fields.
* Where data is marked up in the document itself, there's no need to harvest and/or encode it in the header; only information not parsable from the document, or which is absent from the document and inferred from external sources, should be in the header. In other words, we should eliminate duplication, keeping documents lean and reducing the potential for error.
* Later processing can fill out the header with all metadata on the fly, if and when this is required.
* Editorial expansions will be marked up (they're currently in square brackets), but the underlying symbols expanded may not be; this policy needs to be set out in detail and explained.
* External lists of people, places etc. will be maintained, in separate XML files; document instances will point at these.
* Although the identifiers for elements in these lists will be finite, they may change; this will necessitate updates to the schema, since constraints on attributes for these values in the documents will be applied through the schema (for ease of editing). That places the onus for maintaining lists and schemas on Stew and myself, rather than on the content experts, which reduces the requirement for XML skills on the part of the latter.
* We'll meet again on June 16, at which point Stew and I will have our schema, template and examples ready.