PROM heading

[anna-otrokhova]

New heading is planned: https://projects.invisionapp.com/share/CSBN9XEYX#/screens/278187375 We suppose to get this kind of fields in responses to API requests: GET List Response [ { name: string, score: number, dateCreated: number, source: string, sourceId: string }, ]

GET Detail Response { name: string, records: [ { date: string, (05-Jan-2018 the same as we get on Transfer of Care) name: string, source: string, sourceId: string, type: string, typeTitle: string, } ] score: number, dateCreated: number, specific_q1: string, specific_q2: string, specific_q3: string, specific_q4: string, source: string, sourceId: string }

PUT/POST edit/create Detail Response { name: string, records: [ { date: string, (05-Jan-2018 the same as we get on Transfer of Care) name: string, source: string, sourceId: string, type: string, typeTitle: string, } ] score: number, dateCreated: number, specific_q1: string, specific_q2: string, specific_q3: string, specific_q4: string, source: string, sourceId: string, userId: number }

This document might be helpful http://docs.pulsetile.com/react-proms.html#proms-detail Related issue: https://github.com/RippleOSI/Ripple-Qewd/issues/81

[anna-otrokhova]

@tony-shannon We are waiting for an update from the backend.

[tony-shannon]

Hi @freshehr Can we get an update on the openEHR template on this please

[freshehr]

The template is finished. Will have it deployed into the CDRs with a bit of documentation for Rob by the end of today. It is based on a very cut-down version of the SF-36 questionnaire along with a pain score (as you have already).

[tony-shannon]

thanks @freshehr

Look forward to that update later.

See link here in comment mode to see current candidate drop down values in PROMS form https://projects.invisionapp.com/share/CSBN9XEYX#/screens/277060059/comments/92989963

Do let us know in your documentation what others are better fit

Thanks Tony

[freshehr]

https://github.com/RippleOSI/Ripple-openEHR/blob/master/docs/bindings/Current%20Ripple%20Headings/PROMS/proms.md

PROMS template now ready with .opt and example compositions uploaded to both Ethercis and Marand.

[robtweed]

Ian - shouldn't the AQL for the proms heading have this:

from EHR e [ehr_id/value = '{{ehrId}}']

instead of just

from EHR e ?

[freshehr]

Yes sorry. Should be from EHR e [ehr_id/value = '{{ehrId}}']

[robtweed]

I've done some initial investigation of how to implement this, but I'm afraid I'm pretty lost. This appears to be quite an unusual heading to implement.

I'm afraid I can't figure out how the Get Summary and Get Detail examples of Anne's (see start of this thread) map onto the AQL values in Ian's Template specification.

Some actual example data in the Marand or EtherCIS systems would be useful, so I could see the data returned by the AQL. Currently there's nothing for Ivor Cox on EtherCIS - it just returns an empty dataset.

Similarly some typical examples would be useful of how the fields in PulseTile will map onto the Flat JSON fields in Ian's specification. Like I say, I don't understand this heading sufficiently to figure it out without some examples in Marand or EtherCIS that I can play around with

Rob

[robtweed]

Here's an example of what I mean - from the PulseTile examples for Get PROMS Detail, it's expecting a response that looks like this:

{ name: 'test Proms 1', records: [ { date: 1482190593395, name: 'test records', source: 'test records source', sourceId: 'test records sourceId', type: 'test records type', typeTitle: 'test records typeTitle', }, ], score: 9, dateCreated: 1482170593395, specific_Q1: 'No Pain', specific_Q2: 'No limitations', specific_Q3: 'Around the house', specific_Q4: 'No difficulty', author: 'DR Mary Jones', source: 'openehr', sourceId: 'testSourceID1', }

I don't understand how these fields can be derived from what's in the AQL definition, particularly the array within the response which implies it's somehow going to get a sub-resultSet of data from the AQL query

[freshehr]

@robtweed - I am equally confused by what the UI is trying to reflect. The template is intended to work with the usual summary/detail approach so I'm not sure where the array of records fits. I think we need a multi-way discussion before proceeding further.

[anna-otrokhova]

@robtweed @freshehr This heading is very similar to Transfer of Care heading that is why it has the same approach as on that heading. Could you please compare your AQL and API configurations for that heading. Maybe it would help. Could you have a look, please? http://prntscr.com/ikeiud

[robtweed]

I see no way of aligning the Ripple UI fields with ones that correspond with anything in the OpenEHR Template / AQL / Flat JSON

[freshehr]

This closer to what we are delivering from openEHR.... adding procedure date is trivial, if that helps

{
name: 'Generic PROMS',
procedureName: 'Hip arthroplasty'
score: 91,
dateCreated: 1482170593395,
specific_Q1: 'No Pain',
specific_Q2: 'No limitations',
specific_Q3: 'Around the house',
specific_Q4: 'No difficulty',
author: 'DR Mary Jones',
source: 'openehr',
}

This is sympathetic to the current simple Summary/ Detail arrangement that QEWD works on. Anything else will require quite a bit more analysis and effort. The key thing with most PROMS is that the exact PROMS questions will vary by procedure and by timing before and after the procedure. My understanding is that Tony just wanted something simple as a demo. My suggestion is that we simplify for now to One Proms per summary row/detail screen.

PROMS are definitely worth doing but they will not fit neatly into the current PulseTile gneric format.

[robtweed]

How do the UI fields line up with this Flat JSON which is mainly at codes for values from what I can see:

"proms/procedure:0/ism_transition/careflow_step|code": "at0047", "proms/procedure:0/procedure_name|value": "total replacement of hip", "proms/procedure:0/procedure_name|terminology": "SNOMED-CT", "proms/sf-36:0/a1._health_in_general|code": "at0011", "proms/sf-36:0/a2._health_compared_to_1_year_ago|code": "at0017", "proms/sf-36:0/limitations_to_activities_during_typical_day/a3._vigorous_activies|code": "at0021", "proms/sf-36:0/limitations_to_activities_during_typical_day/a4._moderate_activies|code": "at0027", "proms/sf-36:0/limitations_to_activities_during_typical_day/a5._lifting_or_carrying_groceries|code": "at0031", "proms/pain_vas/pain_vas:0/pain_scale": 44 }

[freshehr]

@robtweed - the answers to the questions should be coded, not just text as real PROMS questions responses are associated with a particular coded answer and associated score. The text of the answer is not sufficient.

I have documented the relationship between the textual answers and the related codes in the PROMS.md document.

It will be up to the UI team to embed the appropriate codes behind the textual answers and supply them to QEWD, so something more like ...

{ name: 'Generic PROMS', procedureName: 'Hip arthroplasty' score: 91, dateCreated: 1482170593395, specific_Q1: 'at0001', specific_Q2: 'at0015', specific_Q3: 'at0134', specific_Q4: 'at0004', author: 'DR Mary Jones', source: 'openehr', }

That's the easy bit. We are also associating each PROMS with a procedure Name. I have modelled this just to capture the name of the procedure, not (as yet) the link back to the original procedure. That can be added but it means running an AQL in the context of the detail screen to produce a list of existing procedures and their associated uid's. We can easily embed that uid as a link in the PROMS composition but I would capturing the procedure name as well, so that the link does not have to be resolved each time.

This is the structure that I don't understand...

records: [ { date: 1482190593395, name: 'test records', source: 'test records source', sourceId: 'test records sourceId', type: 'test records type', typeTitle: 'test records typeTitle', }, ],

[robtweed]

Regarding the first bit, have the required / appropriate set of codes & associated phrases been set up on Marand & EtherCIS? Or are those just examples of what the codes might look like?

How do you set up / define codes such as these on OpenEHR, and how do you discover what they are (which is what QEWD is going to have to do)?

As to that second question - I agree, that's completely out of line with any other heading

[freshehr]

Hi @robtweed - the codes and associated text terms are defined in the archetype and exposed in the template. I have documented them in the PROMS.md file but they are also in the .opt and associated web template.

[robtweed]

Ian: One unresolved issue that makes it tricky to make progress on this: in the screenshots etc for Proms, each one has a name displayed in the UI, and the name field is sent in POST requests and expected from the GET requests. However I don't see a placeholder in the AQL and Flat JSON for a field that could be used for the Prom Name. Am I missing something, or does the template require a new additional field?

[freshehr]

Realistically we will effectively have a single template for each PROMS score set. This is what we found with the Northumbria work. It is possible to rationalise a wee bit by creating super-templates that cover more than one PROMS dialog but that leaves more work for the UI / middleware to apply some business rules to know which components are included - which depend on the procedure and whether this was a pre or post-op assessment. The real world is much more messy than this demo implies.

The current composition name is just called 'PROMS' and is essentially baked into the composition. My suggestion is that the drop-down just has a single item called 'Generic Proms' and that this is just ignored and not carried into the patient data.

[tony-shannon]

thanks @robtweed and @freshehr Let me know if we need a skype chat to unpick this further please , or if you can action without that thanks Tony

[tony-shannon]

Hi @kbeloborodko

@robtweed will be updating the API on this as soon as he gets the latest template from @freshehr Once that is done, can we aim to get the PulseTile UI side updated early/middle next week please?

[robtweed]

OK - Proms should be available in the middle tier, at least on dev for now

It follows the usual pattern for a heading, with just one special difference, and that is that the PulseTile UI response structure will contain a field:

• procedureSourceId

  which is the SourceId for the associated Procedure. I'll explain below:

Before displaying the PROM table for a patient, I'd recommend you first fetch the Procedure summary, so you can display this table if the user wants to add a new PROM record. This will also ensure that the Procedure records for the patient are in the QEWD user's session cache:

GET http://dev.ripple.foundation/api/patients/9999999000/procedures

Once you get the response back for this, you're ready to display the PROMS UI

To GET the summary (ie all PROM records for a patient, if any exist):

GET http://dev.ripple.foundation/api/patients/9999999000/proms

The Response will be the usual array structure, containing: [ { name: //Name of PROM record, score: // 0 - 100, dateCreated: // date record created, source: // ethercis or marand, sourceId: // sourceId for this PROM record - used to fetch its detailed info }, // ...etc ]

To fetch the detailed info for a specific PROM record:

GET http://dev.ripple.foundation/api/patients/9999999000/proms/{{sourceId}}

The response is as follows:

{
  name: //Name of PROM record,
  score: // 0 - 100,
  procedureSourceId: // SourceId of associated procedure
  specific_q1: // lookup-code for Q1
  specific_q2: // lookup-code for Q2
  specific_q3: // lookup-code for Q3
  specific_q4: // lookup-code for Q4
  specific_q5: // lookup-code for Q5,
  author: // author,
  dateCreated: // date record created,
  source: // ethercis or marand,
  sourceId: // sourceId for this PROM record
}

So you'll then need to fetch the linked procedure record:

GET http://dev.ripple.foundation/api/patients/9999999000/procedures/{{procedureSourceId}}

When Creating a new PROM record, you'll want to show the summary table of procedures for this patient for them to select from. The Procedure sourceId they select will be sent with the POST as "procedureSourceId"

So here's the POST structure:

POST http://dev.ripple.foundation/api/patients/9999999000/proms

{
  name: //Name of PROM record,
  score: // 0 - 100,
  procedureSourceId: // SourceId of associated procedure
  specific_q1: // lookup-code for Q1
  specific_q2: // lookup-code for Q2
  specific_q3: // lookup-code for Q3
  specific_q4: // lookup-code for Q4
  specific_q5: // lookup-code for Q5,
  author: // author
}

Editing a PROM record is the same as for any heading:

PUT http://dev.ripple.foundation/api/patients/9999999000/proms/{{sourceId}}

with the body payload, as for the POST, with the amended values.

Note: the look-up values for the questions are defined in Ian's document:

https://github.com/RippleOSI/Ripple-openEHR/blob/master/docs/bindings/Current%20Ripple%20Headings/PROMS/proms.md#template-constraints

Note: currently the QEWD-side logic does not check or validate the fields that are sent with PUT or POST. It is currently PulseTile's responsibility to validate the fields and ensure that the correct Question code values are sent with POST / PUTs