Jun
7
Written by:
admin
Monday, June 07, 2010
I like the idea of an intelligent text editor.
How about structured text entry as a function of the document and or editor.
For example a BP entry field that is inserted on-the-fly into the editor possibly based on logic for the requirement to measure blood pressure or triggered by typing 'bp'.
Values would be stored in the backing XML as a searchable XML node.
structured data entry assistance benefits from working in reverse.
For example we start by entering in the diagnosis (potential) or main symptom.
Symptoms such as pain would require qualification such as nature, intensity, location, duration, onset, aggravating and relieving factors, course, concomitants & frequency.
Some form of templating system will generate the required entry fields within the document. Lexical validation would benefit from contextual knowledge of the data being entered into fields.
There will still be facility to type or dictate free text. But important items can be generated as 'data entry fields' within the document with actual storage in xml nodes.
Current GP software is a mish-mash of data entry tabs/forms/fields and rich-text note.
Forget about using a rich-text editor.
Think of the editor as an interface to an xml document with the interface having configurable medical logic to create the structure of the document, yet looks like the rich-text editor/ Microsoft infopath hybrid and has no panel popups with data entry text boxes. All data entry is done directly into the document. Forms on steroids Plus macros on steroids. Non-static forms.
This is radical and difficult to conceptualise. If you have used the Doctors Control Panel you may have seen the PCD editor and questionnaire functionality already within the DCP.
The PCD editor has a different goal/function but could be considered a prototype as it uses xml storage and has database persistence of answers from questionnaires within the document.
I only propose this concept because it has been incubating in the depths of my creative consciousness but I have neither the time nor inclination to program it, however, the ideas my spur other ideas in other creative minds.
It would potentially reduce lexical errors, normalise scores and measures, normalise phraseology and offer a formal structured representation of notes Plus offer data retrieval and storage of fields within the document.
Additionally the document editor could be configured for different environments / requirements /individual user.
WPF RTB in action hosting controls. Xml Document storage by default. Just need the inline controls to store as inline TextBlock when saving and The Fundamentals are there.
<
Window x:Class="CCD.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
<Grid >
<RichTextBox Name="richTB" IsDocumentEnabled="True" IsManipulationEnabled="True" Margin="0,0,0,53">
<FlowDocument IsEnabled="true">
<Paragraph>
This is some text before the inline button.
<Button Margin="10,0,10,0">
Hello, Embedded Inline Button
</Button>
And this is some text after the inline button.
</Paragraph>
<Paragraph TextAlignment="Left">
<TextBox Height="23" HorizontalAlignment="Left" Name="textBox1" VerticalAlignment="Top" Width="120" />
</Paragraph>
<Paragraph TextAlignment="Right">
And this is some text after the block button
</Paragraph>
</FlowDocument>
</RichTextBox>
<Button Content="Button" Height="23" HorizontalAlignment="Left" Margin="31,272,0,0" Name="button1" VerticalAlignment="Top" Width="75" Click="button1_Click" />
<Button Content="Button" Height="23" HorizontalAlignment="Left" Margin="159,275,0,0" Name="button2" VerticalAlignment="Top" Width="75" Click="button2_Click" />
</
</Grid>Window>