This has been re-posted from the "Less is More" thread with a little added Graham, I am curious to entertain a discussion of how you envision formatted and stored documents to work in Synapse. You've mentioned a few times you would rather have it so that formatted documents are retained in the cache-listener directory on the server. So key items for discussion I think are: 1. What about WYSIWYG word processing inside synapse? As long as synapse editing screens don't show WYSIWYG output, there will always be an issue of metadata and how the formatting will look when printed as postscript or PDF. Hence the need for word processors for formatting to the users taste. If Rebol has a more "full featured" word processor, might it be possible to use it to create more WYSIWYG display in synapse? 2. What about complete user flexibility to create forms or mail merge documents inside synapse and store them? Synapse already has quite a bit of capability to create postscript/PDF documents, but people keep talking about increased needs for generating forms based on datafields from synapse with increasing needs for more formatting in the documents and storing them in synapse. Might it be possible to use all synapse variable tags, like <$first> in any postscript template?
I've asked for the same Outputs .. but for the screen ! see here(DataViews: end user customizable presentations of patient information (what you want, when you want it) If Synapse did venture into "Marked up"/'Formatted" Text, I would want it to be lightweight.
1. Synapse doesn't do WYSIWYG, and nor does Rebol. I don't see a need either ... but for formatting a printed document, you can add PostScript fonts as per the button help 2. Synapse can create forms already ... no one uses them as far as I know, and they may even be broken now! I am going to look at using them for a basis for printing WYSIWYG forms.
Full WYSIWYG is not needed, the discussion could be about what markup would improve the quality of generated notes and consults. Would basic tables help ? Would more than 1 colour help ? I do realize for printing there is already some supported PS markup.
I agree with Graham. Currently, we have some WYSIWYG output abilities. What I am more interested in is better access to patient data to be used in my output forms. I know that a bunch of patient variables are available already in my PS forms. I think that over the years, we should extend the data that is available for access. For instance, Centricity EHR (a major US EHR) has defined >10,000 distinct data fields. Obviously, their developers went overboard. If you want to, you can itemize e.g. the abdominal exam and search your database for all patients that were tender in the epigastric area. That's great for research purposes but, honestly, practically spoken, I do not see its utility.In general, though, I think that we should be open for and provide an infrastructure to easily provide new datafields - such as "patient instructions" as in my other related thread. I am sure other data field requests will follow. Marius
I'm not keen on adding new fields ... just more complexity. There's already a set of 4 fields the SOAP fields. You can access their content in template ... so you could put the patient instructions in the "P" field. txtareaSfld/text - Subjective txtareaOfld/text - Objective txtareaAfld/text - Assessment txtareaPfld/text - Plan
Everyone seems to be in agreement that WYSIWYG editing in synapse is over the top, but maybe some increased ability to markup text would be helpful. The ps markup method on the "PS Fonts" button inside the consult editor doesn't work for me, so it does appear to be broken unless I don't have come settings correct. I am curious about the response of the group about using markup tags in a consult. Are they OK now if they were working? Are you going to use Word anyway? Graham, I did not know I could use "txtareaPfld/text" as method of printing the "Plan" of the SOAP template. Looking through the postscript templates, I see other fields such as "ssnfld/text" that I didn't see mentioned in the Postscript Template "Keyword" documentation on the wiki. Are there a number of other fields like this that can be used in postscript templates that are not of the <$variable> form? If so, maybe we could make a more comprehensive documentation of these if it doesn't already exist somewhere.
Jerry The PS markup only work if you are using Gonzo formatting. I think you are not using Gonzo for your treatment request template. In the ordinary letter, consult where Gonzo is used, then |3This is in bold|1 and now we are back to a normal font is how it works. As for "txtareaPfld/text" .. well, every single field you see on a Synapse screen has a name. There must be hundreds of these ... you can ask and I can tell you what the name is if you wish to access it via a template.
Graham, Ahhh..... perhaps I have previously been asking the wrong question, i.e., can variables like <$variable> ("directly" from a database datafield) be placed in any postscript template. So do I understand correctly that every text field has a name and could be used in a template? I think that's what we're after here. One method I have seen used to document these fields is to type in the name of the fields (like "txtareaPfld/text" or "ssnfld/text") in their respective text boxes and take screenshots of it. Would something like that be doable, at least of selected fields that would be important to people?
Any field that you see can be placed into a ps template. You just have to wrap it in a ( ). So, an example is (uppercase rejoin ["*" ssnfld/text "*"]) which means to take the ssnfld, place * around it and merge it into one string in uppercase. Synaps will then turn that into a barcode. but you could just use (ssnfld/text) and you would have the ssn appear. Now, the named variables we have in the ps templates are often combinations of these fields, or, these fields formatted in a particular way. So, provider-template is a bunch of named fields formatted according to a formatting template. You could screendump each field and then name each one ...
That's awesome. I think that's exactly what I needed. I am still new to this, so permit my question: could I access these fields also from within a consult note or are these variables only available in a PS template? Marius
Only in postscript template. If you need to access the others .. I need to create variables such as <$sex> etc.
Graham, I'm assuming that you probably rarely if never change a field name once assigned. So, mapping more selected field names for use in ps templates would be of greatbenefit.We could just start expanding the lists that you and Jason have referred to. Maybe make screen shots. Put it on the wiki.
I'd suggest a screen shot with all the pertinent fields numbered. And then I can tell you which ones are what .... However, I would much prefer if everyone managed the basic functionality first before delving into this esoteric stuff.
Yes, I totally agree. It's cool to realize that using any field in a ps template is possible. I think we should put some real thought into exactly what we need before starting to map a lot of fields.
