Improving Formatted/Stored Output in Synapse

Discussion in 'Feature: Requests and Planning' started by Jerry, Dec 7, 2008.

  1. Jerry

    Jerry Administrator Staff Member

    This has been re-posted from the "Less is More" thread with a little added


    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:

    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?
  2. Jason

    Jason Developer / Handyman Staff Member

    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.
  3. Graham

    Graham Developer Staff Member

    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.
  4. Jason

    Jason Developer / Handyman Staff Member

    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.
  5. Graham

    Graham Developer Staff Member

    You can already do basic tables ... see the medication list template for an example.

  6. laumansm

    laumansm New Member

    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
  7. Graham

    Graham Developer Staff Member

    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

  8. Jerry

    Jerry Administrator Staff Member

    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.
  9. Graham

    Graham Developer Staff Member


    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.
  10. Jerry

    Jerry Administrator Staff Member

    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?
  11. Graham

    Graham Developer Staff Member

    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 ...
  12. laumansm

    laumansm New Member

    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
  13. Graham

    Graham Developer Staff Member

    Only in postscript template. If you need to access the others .. I need to create variables such as <$sex> etc.

  14. Jason

    Jason Developer / Handyman Staff Member

    List of Variables available to the Consult Editor
  15. Jerry

    Jerry Administrator Staff Member


    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.
  16. Graham

    Graham Developer Staff Member

    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.
  17. Jerry

    Jerry Administrator Staff Member

    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.

Share This Page