Add Paging for VitalSign

[ZuzooVn]

Hi Ripple team,

According to #31 here is the pull request for Vital Sign Paging.

Please send me any comment, suggestion or correction you may have.

Old API: /api/patients/9999999000/vitalsigns

New API: /api/patients/9999999000/vitalsigns?offset=1&fetch=3
offset (optional)
fetch (optional)

Best Regards,

Nam Vu from ThinkLabs-VN

[tony-shannon]

thanks @ZuzooVn

Can you explain a little more what this code is trying to achieve please
Can you explain what "offset" does?
Assume "fetch" gets a number of vital signs?
Can you briefly outline the code changes.. 5 files involved I see.

Please note the travis-ci test would fail if this is implemented.. please consider this & what changes would be needed there.

thanks for the effort involved
Tony

[ZuzooVn]

Hi @tony-shannon

Can you explain a little more what this code is trying to achieve please

Currently, Ripple fetches all of the vital signs information from EtherCIS via REST API.
However, it quickly becomes obvious that the size of data that is of interest is usually on the order of megabytes and spans thousands of objects. Thus, paged, REST endpoints start to really suffer in terms of performance when a query takes 45-50 seconds to complete and perform 1,000 roundtrips.

• Pros:
  Standard API
  Acceptable performance on small datasets

• Cons:
  Poor performance on large datasets
  Connection latency severely impacts performance
  Mobile native application implementation of paging can add technical overhead

Below is our Android Native Application that displays Vital Signs

In recap, a lot of the time, when you're making calls to the REST API, there'll be a lot of results to return. For that reason, we paginate the results to make sure responses are easier to handle.

Can you explain what "offset" does?
Assume "fetch" gets a number of vital signs?

We used OFFSET FETCH Clause (SQL Server Compact)

• OFFSET { integer_constant | offset_row_count_expression } { ROW | ROWS }
  Specifies the number of rows to skip, before starting to return rows from the query expression. The argument for the OFFSET clause can be an integer or expression that is greater than or equal to zero. You can use ROW and ROWS interchangeably.
• FETCH { FIRST|NEXT } { ROW|ROWS } ONLY
  Specifies the number of rows to return, after processing the OFFSET clause. The argument for the FETCH clause can be an integer or expression that is greater than or equal to one. You can use ROW and ROWS interchangeably. Similarly, FIRST and NEXT can be used interchangeably.

Ref: https://technet.microsoft.com/en-us/library/gg699618(v=sql.110).aspx

Can you briefly outline the code changes.. 5 files involved I see.

We changed 5 files:

• vitalsignspaging.sql: Use SQL instead of AQL because AQL does not support Offset and Fetch.
• vitalsignspaging.js: Map the returned data from the SQL in vitalsignspaging.sql.
• patientHeadingTable.js: Treat Paging as optional.
• spv.js: Add more args which required in patientHeadingTable
• headings.js: Cache the Offset and Fetch to Redis or GT.M database

Please note the travis-ci test would fail if this is implemented.. please consider this & what changes would be needed there.

The error came from this commit bd95205022b4aa5603c6a2f4720d8cac51362cd7. @robtweed could you please re-check your commit?

Failures:

1. OpenEHR Server marand using counts can get Ivor Cox details using AQL
   Message:
   TypeError: Cannot read property 'resultSet' of undefined
   Stack:
   TypeError: Cannot read property 'resultSet' of undefined
   at Object.processBody (/home/travis/build/RippleOSI/Ripple-Qewd/spec/headings_spec.js:84:22)
   at Request._callback (/home/travis/build/RippleOSI/Ripple-Qewd/lib/openEHR/openEHR.js:173:38)
   at Request.self.callback (/home/travis/build/RippleOSI/Ripple-Qewd/node_modules/request/request.js:188:22)
   at emitTwo (events.js:106:13)
   at Request.emit (events.js:191:7)
   at Request. (/home/travis/build/RippleOSI/Ripple-Qewd/node_modules/request/request.js:1171:10)
   at emitOne (events.js:96:13)
   at Request.emit (events.js:188:7)
   at IncomingMessage. (/home/travis/build/RippleOSI/Ripple-Qewd/node_modules/request/request.js:1091:12)
   at IncomingMessage.g (events.js:292:16)

thanks for the effort involved

You're welcome, we (ThinkLabs) are a product-based startup company specializes in the applications of telehealth and telemedicine in Vietnam.

As a developing country, Vietnam shares the same issue in lack of access to healthcare. The provincial hospitals are lacking more advanced infrastructure and technology as well as high-skilled doctors and healthcare professionals. These factors altogether result in the lack of appropriate care availability in rural and remote areas. These factors also influence patients’ decision to skip district and commune facilities to get treatments at provincial and central hospitals, which results in additional costs such as higher treatment expenses, travel expenses, accommodation expenses for companions etc.

With a lot of potential benefits, Telemedicine services are able to transform the healthcare service delivery in Vietnam. The development of Telemedicine in Vietnam with Ripple Foundation as the pioneer is truly showing hopes for the acceleration of healthcare service in Vietnam. As being on its very first stage in bringing the product to the market, ThinkLabs’s concern is now directed to the adoption of its system.

Our goal is to provide an answer to a big question: How can Telemedicine and specifically Ripple Foundation’s solution being adopted in Vietnam?

Wow, such a long comment! My hope is that more of us will commit our energy to building Ripple together.

Best Regards,

Nam Vu

[tony-shannon]

many thanks Nam Vu,

Appreciate your detailed comment and explanation of the pull request.
Your mission in Vietman is a very important one and we're very pleased to here that Ripple components may be useful.

In terms of files changes to this repo I have an immediate key question..
Re: vitalsignspaging.sql: Use SQL instead of AQL because AQL does not support Offset and Fetch.

This would have an impact on this repo.. as we are leveraging the openEHR AQL standard available in EtherCIS from Ripple-QEWD.

3 questions;

1. Have you explored within EtherCIS.org to check this is the case/explore what other approach you could use to leverage AQL
   http://ethercis.org/
   https://github.com/ethercis

2. you may note that we have set up PulseTile UI framework to accept core & plugin modules.
   See here
   http://www.pulsetile.com/
   https://github.com/PulseTile
   https://github.com/PulseTile-Plugins
   .. would a library of Ripple-Qewd plugins help you in a case like this?
   ie where you contribute other mappings?

3. If you wish to use SQL based persistence rather than openEHR based AQL are you wishing to host your Re: vitalsignspaging.sql in your own repos.. though obviously we recommend you work to align with openEHR & AQL etc.. a sql based approach is a fork from the openEHR approach we recommend within Ripple

[ZuzooVn]

Hi Tony @tony-shannon

1. Have you explored within EtherCIS.org to check this is the case/explore what other approach you could use to leverage AQL
   http://ethercis.org/
   https://github.com/ethercis

We already contacted EtherCIS:

"AQL FETCH NEXT, OFFSET are not yet supported by EtherCIS. A possible workaround would be to use a direct SQL query instead." said Christian

Ref ethercis/ethercis#5

2. you may note that we have set up PulseTile UI framework to accept core & plugin modules.
   See here
   http://www.pulsetile.com/
   https://github.com/PulseTile
   https://github.com/PulseTile-Plugins
   .. would a library of Ripple-Qewd plugins help you in a case like this?
   ie where you contribute other mappings?

That's a good idea. I will following this tutorial http://docs.pulsetile.com/Plugin_Process.html

3. If you wish to use SQL based persistence rather than openEHR based AQL are you wishing to host your Re: vitalsignspaging.sql in your own repos.. though obviously we recommend you work to align with openEHR & AQL etc.. a sql based approach is a fork from the openEHR approach we recommend within Ripple

Thanks for your recommendation. I will check PulseTile Plugins first to make the approaches suitable for Ripple.

[tony-shannon]

thanks @ZuzooVn
Please update us after
T