Week9


LibreHealth

PROGRESS MADE THIS WEEK:

Hi, We are almost done with the implemention of the proposal. The additional work is to make improvements and fixes. According to the feedback of the UI/UX designer from the team, the following improvements should be made to the webcomponents:

  • Outlined type for all the fields to maintain consistency.
  • Appropriate placeholder text.
  • Fix spelling mistakes.
  • Convert sections to collapsable rows/columns.
  • Improve spacing between fields.
  • Add asterisks to indicate mandatory fields.

In the coming week these pointers will be implemented along with documentation and other fixes.

DESCRIPTION:

pssing params to the search component

pssing params to the search component

Merge Requests:

NEXT WEEK’s PLAN:

  • Write documentation
  • React optimization
  • find and fix bugs.

see you next week 😄.

Week8

LibreHealth

PROGRESS MADE THIS WEEK:

Hi, As discussed in the last week’s blog, Week 8 was to be used for the following tasks:

  • Completing the visit-provider workflow.
  • Completing the e-prescription workflow.
  • fixing build fail.

DESCRIPTION:

The above mentioned points were covered this week.

visit-provider workflow : this workflow was very much similar to the visit nurse workflow that was implemented last week.

  • The provider first finds the patient.
  • The provider selects the encounter under which the meeting will proceed.
  • The provider then gets directed to the dashboard where he/she can see the patient’s already existing observations and can create an observation report.
  • the provider can also create an order request.

Out of these the first 2 points were already implemented in the visit-nurse workflow.

The rendering of different screens is done using redux, each click when required changes a redux state that renders a different screen.

here is the reducer for this workflow:

pssing params to the search component

The editActivePage reducer is for changing the screen. The observation results shown require the Patient Id hence the Id is stored after the provider selects the patient.

All of these screens are a part of a custom High order Navbar component that renders different tabs based on state values.

here is the navbar component :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
import React, { useState, useRef } from 'react'
import PropTypes from 'prop-types'
import { useStyles } from './style'
import {
AppBar,
Tabs,
Tab,
Typography,
Box,
CssBaseline,
Container,
Button,
Dialog,
DialogActions,
DialogContent,
DialogTitle
} from '@material-ui/core'
import ExittoApp from '@material-ui/icons/ExitToApp'
import logo from '../../assets/images/logosm.png'
import {
logout
} from '../../reducers/auth/authSlice'
import '@lh-toolkit/fhir-encounter/fhir-encounter.js'
import { useDispatch } from 'react-redux'
import { useHistory } from 'react-router-dom'
import { toast } from 'react-toastify'
import axios from 'axios'
import { config } from '../../config'
import 'react-toastify/dist/ReactToastify.css'

function TabPanel (props) {
const { children, value, index, ...other } = props

return (
<div
role="tabpanel"
hidden={value !== index}
id={`simple-tabpanel-${index}`}
aria-labelledby={`simple-tab-${index}`}
{...other}
>
{value === index && (
<Box p={4}>
{children}
</Box>
)}
</div>
)
}

TabPanel.propTypes = {
children: PropTypes.node,
index: PropTypes.any.isRequired,
value: PropTypes.any.isRequired
}

export const Navbar = ({ labels, component, encounterID, includeEncounter }) => {
const classes = useStyles()
const [value, setValue] = useState(0)
const dispatch = useDispatch()
const history = useHistory()
const [open, setOpen] = useState(false)
const [disablepost, setDisablePost] = useState(false)
const reference = useRef()

const handleClickOpen = async () => {
setOpen(true)
try {
const res = await axios.get(`${config.basename}Encounter/${encounterID}`)
if (res.status === 200) {
reference.current.value = res.data
}
} catch (error) {
console.log(error)
}
}

const handleClose = async () => {
try {
setDisablePost(true)
reference.current.value.resourceType = 'Encounter'
reference.current.value.id = encounterID
const res = await axios.put(`${config.basename}Encounter/${encounterID}`, reference.current.value)

if (res.status === 200) {
toast.dark('EDITED SUCCESSFULLY !')
setOpen(false)
}
} catch (error) {
// eslint-disable-next-line node/handle-callback-err
error.response.data.issue.forEach(err => {
toast.error(err.diagnostics)
})
} finally {
setDisablePost(false)
}
}

const handleChange = (event, newValue) => {
setValue(newValue)
}

return (
<Container component="main" maxWidth="lg">
<CssBaseline />
<div className={classes.paper}>

<div>
<img src={logo} alt='logo'/>
</div>

{includeEncounter
? (
<div className={classes.exit}>
<Button
aria-label="submit"
type="submit"
variant="text"
color="secondary"
className={classes.submit}
onClick={handleClickOpen}
>
EDIT ENCOUNTER
</Button>
</div>
)
: ''
}

<div className={classes.exit}>
<button onClick={() => {
dispatch(logout())
toast.dark('LOGGED OUT !')
history.push('/')
}} className={classes.logoutbtn}
>
<ExittoApp />
</button>
</div>

<AppBar position="static" color="default" className={classes.navbar}>
<Tabs value={value} onChange={handleChange} aria-label="checkIn tabs">
{labels.map((item) => <Tab key={item} label={<Typography variant="subtitle1">{item}</Typography>} />)}
</Tabs>
</AppBar>

{component.map((Component, index) => {
return <TabPanel key={index} value={value} index={index}><Component key={index} /></TabPanel>
})}
</div>
{
includeEncounter
? (
<Dialog open={open} onClose={handleClose}>
<DialogTitle id="form-dialog-title">EDIT ENCOUNTER</DialogTitle>
<DialogContent>
<fhir-encounter ref={reference} />
</DialogContent>
<DialogActions>
<Button onClick={handleClose} disabled={disablepost} className={classes.submit} color="secondary">
SUBMIT
</Button>
</DialogActions>
</Dialog>
)
: ''
}

</Container>
)
}

Navbar.propTypes = {
labels: PropTypes.array,
component: PropTypes.array,
encounterID: PropTypes.string,
includeEncounter: PropTypes.bool





The e-prescription workflow is almost similar to the visit-provider workflow, other than 1/2 screens.

  • The prescriber first finds the patient.
  • The prescriber selects the encounter under which the meeting will proceed.
  • The prescriber then gets directed to the dashboard where he/she can see the patient’s allergies and medication and can create a medication request.

Merge Requests:

Implementation video:

NEXT WEEK’s PLAN:

  • Write documentation
  • Add extra test files.
  • React optimization
  • find and fix bugs.

see you next week 😄.



Week7

LibreHealth

PROGRESS MADE THIS WEEK:

Hi, As discussed in the last week’s blog , Week 7 was to be used for the following tasks:

  • Complete the visit-nurse workflow (the parts which are not implemented yet.)
  • Complete the visit-provider workflow.
  • Start working on the e-prescription workflow.

This week I was a little busy with some academic work, hence all of the above pointers were not possible, Hence the last 2 pointers will be shifted to the upcoming week. (WEEK 8)

DESCRIPTION:

This week I have mainly worked on completing the visit nurse workflow. As the vitals signs and medication statement components were merged, the react-ehr application was updated to include the screens which use these components in the visit-nurse workflow.

Another interesting thing is that most of these screens are having almost a similar structure, hence there is a possibility that a single component can be created as a layout component for different screens.

NEXT WEEK’s PLAN:

  • Complete the visit-provider workflow.
  • Start working on the e-prescription workflow.
  • fix build fail.

The dosage component seems to cause a build failure, which will be fixed in the coming week.

reiterating the pointers from last week’s blog for the implementation points of the visit-provider workflow:

  • First screen contains a find-patient component to select a patient.
  • After the patient is selected a redux action is triggered which updates redux state and stores the selected patient Id.
  • Another redux action updates the active screen and changes it to that of patient encounters.
  • The patient encounter screens contains all the patient encounters which are fetched using the stored patient Id.
  • On clicking an encounter a redux action updates active page to dashboard.
  • the dashboard page contains 2 tab: physical exams, order.
  • the physical exams tab shows the observations of the patient and contains a component to create any observation.
  • the orders tab will be used to create orders using service request component.
  • the user can log out and select a different patient to repeat the above points.

the pointers for the implementation points of the e-prescription workflow:

  • First screen contains a find-patient component to select a patient.
  • After the patient is selected a redux action is triggered which updates redux state and stores the selected patient Id.
  • Another redux action updates the active screen and changes it to that of patient encounters.
  • The patient encounter screens contains all the patient encounters which are fetched using the stored patient Id.
  • On clicking an encounter a redux action updates active page to dashboard.
  • the dashboard page contains a single screen with a search component for allergies and medications of the patient.
  • the screen also contains a create medication request component.

see you next week 😄.


Week6

LibreHealth

PROGRESS MADE THIS WEEK:

Hi, According to the proposal timeline, week 6 was to be based on:

  • finishing pending work.
  • fixing bugs.
  • starting week7 tasks.

Fortunately, there was no pending work, hence the focus was mainly on the remaining points.

The tasks of week7 are to:

  • implement the visit-nurse and visit-provider workflow in the react application.

As most of the components required for implementing the visit-nurse workflow are already present in the web-component library, I started working on it.

DETAILED DESCRIPTION:

The visit-nurse workflow consists of many screens and multiple components.

  • First screen contains a find-patient component to select a patient.
  • After the patient is selected a redux action is triggered which updates redux state and stores the selected patient Id.
  • Another redux action updates the active screen and changes it to that of patient encounters, it also updates redux state and stores the current encounter Id.
  • The patient encounter screens contains all the patient appointments, encounters and a component to create an encounter for the undergoing visit.
  • On creating the encounter a redux action updates active page to dashboard.
  • the dashboard page contains 4 tab: home, vitals, allergies, medication.
  • the home tab is the default active tab and contains already exisiting vitals, allergies and medications of the patient.
  • the other tabs are used to create specific resource entry.
  • the user can log out and select a different patient to repeat the above points.

Some of the required components are not merged in the main repo yet, hence respective tab is unimplemented.

Each worklow in the application is a different page with a unique url. Hence the use of redux in immense in the project.
Each workflow also has a dedicated reducer which handles all the operations related to a specific workflow without editing any other state.

Inside the project’s src directory, the workflow directory contains all the code distributed into separate directories for different workflows. This makes it very simple to create / edit or even delete a workflow without affecting other parts of the application!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
import React from 'react'
import { Navbar } from '../../components/navbar'
import { Home } from '../../pages/home'
import { activePageName } from '../../reducers/visit/visitNurseSlice'
import { CreateEncounter } from './pages/createEncounter'
import { SelectPatient } from './pages/selectPatient'
import { Dashboard } from './pages/dashboard'
import { useSelector } from 'react-redux'

export const VisitNurse = () => {
const activePage = useSelector(activePageName)
let components
switch (activePage) {
case 'SelectPatient':
components = [Home, SelectPatient]
break
case 'CreateEncounter':
components = [Home, CreateEncounter]
break
case 'Dashboard':
components = [Home, Dashboard]
break
}
return (
<Navbar labels={['HOME', 'VISIT']} component={components} />
)
}

This is the main component that is exported. Based on different redux state values different screens are displayed.

All the implemented screens and the workflow can be seen here:

https://gitlab.com/librehealth/toolkit/lh-toolkit-webcomponents/uploads/a9e04307d1199767e3b2c400de785370/screen-capture__2_.webm

NEXT WEEK’s PLAN:

  • Complete the visit-nurse workflow (the parts which are not implemented yet.)
  • Complete the visit-provider workflow.
  • Start working on the e-prescription workflow.

For the visit-nurse workflow, the medication statement and the vitals tabs are left to be implemented, these must be completed within the next week.

There are also some additions to be made in the webcomponents : some fields like encounter and subject (patient) are required to be added to the allergy and medication statement components.

The visit-provider workflow has similarities to the visit-nurse workflow, some of the screen are similar for both, hence the provider workflow should be completed faster than the nurse workflow.

these are the implementation points for the visit-provider workflow:

  • First screen contains a find-patient component to select a patient.
  • After the patient is selected a redux action is triggered which updates redux state and stores the selected patient Id.
  • Another redux action updates the active screen and changes it to that of patient encounters.
  • The patient encounter screens contains all the patient encounters which are fetched using the stored patient Id.
  • On clicking an encounter a redux action updates active page to dashboard.
  • the dashboard page contains 2 tab: physical exams, order.
  • the physical exams tab shows the observations of the patient and contains a component to create any observation.
  • the orders tab will be used to create orders using service request component.
  • the user can log out and select a different patient to repeat the above points.

see you next week 😄.

Week5

WEEK5

LibreHealth

PROGRESS MADE THIS WEEK:

Hi! We have a small change in the implementation plan. As per the proposal this week => week 5 was meant for implementing the visit workflow in the react / EHR application. The implementation required some new components, which were created last week as per the plan, but the Merge Requests are not merged yet. As there can be multiple changes and modifications required after the MRs are reviewed, It would be better to wait till the components are merged after modifications if required.

Therefore this week was based on doing the tasks of the 7th Week as Week6 is planned for improvements and bug fixing.

Primarily this week was spent creating the last set of components that will be required for the workflows planned.

The following components were created -

  • MedicationRequest
  • dosage

These components will be used for e-prescription workflow, although the dosage backbone element can be used for other Medication workflow based resources as well.

The pattern used for creating these components is same as the one used for other components.

Here is the screenshot:

medicationrequest


next week:

  • find and fix bugs in the react app.
  • start implementing visit workflows in the react application.

see you next week 😄.

Week4

WEEK4

LibreHealth

PROGRESS MADE THIS WEEK:

Advancing into the 4th week, everything is going as per the plan. By the end of this week, most of the components planned are already created.

This week (4th week) was utilised creating components for the visit workflow.

The visit workflow primarily involves the nurse and the provider along with the patient, the nurse checks the arrival of the patient, takes the vitals, verifies and creates medications and allergies.

Provider then checks the patient and performs exams and orders lab tests if necessary.

FHIR does not have a visit resource so every operation related to a visit event is handled by the modified encounter resource.

In FHIR, Appointment is used for establishing a date for the encounter,

When the patient arrives and the visit is about to start, then the appointment will be marked as fulfilled, and linked to the newly created encounter.

The following components were created for this: (other components which will be required apart from the following mentioned components are already created)

  • Encounter
  • Service Request
  • Medication Statement
  • Quantity datatype component
  • Allergy intolerance
  • Observation

The web component repo already had components for allergy and observation, but their utility was limited, moreover for every property there was a components which was actually not required as using created datatype components all the properties of any resource could be included in a single component.

A definte pattern is used for creating these components. The pattern is demonstrated below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
/*imports required*/
import { LitElement, html, css } from 'lit-element';

class MyCustomElement extends LitElement {

//all the properties are defined here
static get properties() {
return {
value: { type: Object, reflect: true },
}
}

constructor() {
super();
this.value = {};
}

// handle the change in input
setDisplayValue(e) {
this.value.display = e.target.value;
}

// templates to render the component
displayTemplate() {
this.value.display = this.value.display || "";
return html`<div>HELLO!</div>`
}

// render al the templates created
render() {
return html`
${this.displayTemplate()}
`
}
}

customElements.define('my-custom-element', MyCustomElement);

Here are the screenshots:

observation


servicereq


medicationstatement

allergy

encounter


next week:

  • create the remaining component.
  • implement visit workflows in the react application.

see you next week 😄.

Week3

WEEK 3:

LibreHealth

PROGRESS MADE THIS WEEK

Hello everyone. As dicussed in the previous blog, this week was to be utilised for creating the Appointment workflow in the React application.
Surpisingly, the task hardly took 24hrs for completion, henceforth by the end of Tuesday I was done with this week`s work 😄.
Anyways there were a few bugs in test files that were to be fixed, so I utilised my weeks fixing some web-component tests.

here are the screenshots of the workflow:

Appointment workflows

upcoming days:

  • start working on the task of the coming weeks.

next week:

  • complete the components for the visit workflow.

see you next week 😄

Week2

WEEK 2:

Hello folks! Another week done and another batch of code written and merged !! In the coming sections I will be explaining the details of the work done this week.

LibreHealth

PROGRESS MADE THIS WEEK

In the previous week, I had implemented the checkin workflow in the react application. According to my plan in the proposal, this week was to be used to create components for the resources that will be used in the Appointment workflow.

the resources are:

  • Slot
  • Schedule
  • Appointment

In the beginning of the week, I started looking into the lit: upon which the components are based. I read the documentation and decided how to create the components so that they can be utilised for different CRUD operations.

I also noticed a few bugs in the components while implementing the checkin workflow, for this I created a MR and fixed them :





By wednesday I started creating the components. Most of these components have a reference or codeable-concept property datatype, hence creation of components that can be used in different contexts to implement the mentioned datatypes will help a lot.

By the end of wednesday I had created these datatype components :


Once these components were created, the resource components were not difficult to develop. By thursday I had created Slot-Schedule and by friday Appointment.

During this period my mentor noticed a few bugs in the project:

  • inconsistent label case use
  • unavailable demo files (build issue)

So along with the development of the components, I made a couple of commits for these issues as well.

Template used for component creation:

As a component will be used for CREATE / GET / PUT request , I made it compatible with everything.

For the create part, inside the constructor an initial empty skeleton value was provided. This value property would be overwritten if the component contains the value attribute. Hence this supports both the cases of create and get operations as a user can avoid the value attribute if the intention is to use the component for creating entries and provide a value after fetching a specific endpoint if the intent is to show entries.

Moreover even if a value property is provided and some of the keys are missing, the component will still remain the same as I have done a check for individual property existence and default value allocation as well, this feature will be helpful for the edit operation.

here is the default value property set inside the Appointment component constructor. Similar structure is used in the other 2 components.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
identifier: [{}],
status: '',
serviceCategory: [{coding: [{ system: "", code: "", display: ""}],text: ""}],
serviceType: [{coding: [{ system: "", code: "", display: ""}],text: ""}],
specialty: [{coding: [{ system: "", code: "", display: ""}],text: ""}],
appointmentType: {coding: [{ system: "", code: "", display: ""}],text: ""},
slot: [{reference: "", display: "", type: ""}],
comment: '',
start: moment().format('YYYY-MM-DDThh:mm:ss[Z]'),
end: moment().format('YYYY-MM-DDThh:mm:ss[Z]'),
participant: [{type: [{coding: [{ system: "", code: "", display: ""}],text: ""}], status: '', actor: {reference: "", display: "", type: ""}}]
}

here are the screenshots of the implemented components:

Appointment


Slot


Schedule


upcoming days:

  • write unit test for the components.

thanks for reading till the end ❤️ , see you next week 😄

Week1

WEEK 1:

Finally the community bonding priod is over and the coding period has commensed. In this blog I have loads of content and code to cover!

LibreHealth

ANALYSIS OF COMMUNITY BONDING PERIOD
In the community bonding period there were mainly 2 objectives we had set :

  • SETUP THE REACT APPLICATION WITH CI/CD.
  • DESIGN THE APPLICATIONS WITH THE ENDPOINTS.

Most of my community bonding period was spend on the CI/CD part. The major cause of this was
cross-browser, cross-platform testing integration with React. The tool which was planned to be used was saucelabs and unfortunately for me 😕 there was no proper content regarding saucelabs integration with react to be found anywhere, I tried to make things work on my own and nearly succeeded testing on jest with snowpack and react, but snowpack could not resolve the dependencies inside the lh-toolkit-webcomponent monorepo when it was caching the files.

Snowpack serves the application unbundled during development. Each file needs to be -built only once and then is cached forever. When a file changes, Snowpack rebuilds that single file

As mainly we will be covering unit and integration testing, saucelabs will not be a neccessity as suggested by the saucelabs community. So I went on to setup the react app

  • testing : using react-testing-library with jest
  • deployment : gitlab pages
  • some eslint integration and git hooks.

Design part was smooth sailing and offered many insights that I might have not noticed until later, upon the suggestion of my mentor I have also documented the api endpoints. I will drop the file with the designs and the endpoints here : https://geforce6t.github.io/blog/categories/EHR/

PROGRESS MADE IN THE WEEK

the plan for the first coding week is to do the following:

  • setup the application
  • create home, login pages
  • implement the checkin workflow

monday: I started coding 🎉️ , and completed the first part of the plan.


tuesday: I started working on the project layout and accomplished the following :

  • organized project into different directories including pages, components, redux store, redux slices etc
  • added MUI with theme
  • created login and auth pages with support for other workflows in mind.
  • created redux auth workflow

wednesday: looked for ways to style the lit-components………, lit components uses shadow dom and the style encapsulation feature make it a little tricky to style custom components from the outside, I made some hacks to do the same using callback refs inside the react component where the lit component resides,but this approach would not be optimal.

Probably some minimal styles could be applied inside the lit components and would do great, anyhow I was able to style the material components using the global material css variables.

One of the things that I need to look into is to add some style to the lit-components as a whole : “margin, border shadow and stuff”, this will not be a big issue as I have a lot of other components to create so mainly the style will be global and can be done anytime.

So here is how the create-patient component has changed visually:

After

compared to above, this is what we have as default:

Default


thursday: created the general search component.

the general serach component is something that I would like to talk about. The general search component was actually little difficult to implement. For different cases the search params, columns, query parameter may differ so to create a general purpose search component all of this features must be passed as attributes which was done in the implementation,

passing params to the search component

the functions used in the seach component are

  • one for search, based on fetching and storing the result after filtering the result to only include results for the columns using the query.
  • another for storing pagination contexts: next page and previous page url,

the most difficult part about the implementation was filtering results to form column enteries, the values that we may want can be nested one/many levels so it is very important to provide a query string to execute this filtering, it is not possible to pass this query string via props as it is inside a map method, so I created a function with switch case for different workflows that we will implement.

filtering data to display in the columns

finally the components looks like this :

serach component

friday: wrote the edit and show patient code to complete the layout of the checkin worklfow 🎉️, but there was one issue that came across while creating the put request, for some of the fhir components the values are not changing even after visually their value is changed, this might be an issue in the react app or the wc repo. I will take a look and solve this issue in the coming days!

UPCOMING DAYS

  • add event handlers for the create patient page.
  • debug the value not changing issue while making a put request.
  • add css for element (not compulsary for now)

thanks for reading till the end ❤️ , see you next week 😄

community-bonding

LibreHealth (@LibreHealthIO) | Twitter


Hello !

Its been quite a while since the GSoC results were announced and community bonding period commenced. The calendar says May 30 and the coding period will begin in about 10 days. So lets move on to how I actually spent the community bonding period yet and what plans do I have for the coming days before the coding period starts.

Project Introduction

The project bases its goal on creating an EHR system using the webcomponents implementing FHIR resources developed during the previous versions of GSoC. For the implementation some new resource based components will be required as well which will be created simultaneously.

During GSoC 2018, under this project a polymer application was developed which combined all the web component0s (developed at that time) into a PWA.

The current project will be built upon this application by adding and implementing workflows. the workflows that will be implemented in the EHR are :

  • Check-in
  • Visit
  • e-Prescription
  • Appointment
  • Lab orders

Amazing Mentor Team

  1. Saptarshi Purkayastha
  2. Namratanehete

Community Bonding Period

Background

During the application period upon the suggestions of the mentors I had decided to mainly work on the CI and the Designs of the PWA during the community bonding period.

Even before the results were announced I was already experimenting with setting up the project so as to identify any problems that may occur as using lit-components inside React can be a little trouble because React never exposes the real DOM.

Bonding Period

So as soon as the results were released I started looking on these parts. I started with the CI part first, one of the pointers in this was also to look for a cross platform - cross browser testing method (SauceLabs) suggested by my mentor. I looked at some of the possibe integrations with these automation tools here.

But most of these are based on e2e testing ( cypress , Puppeteer and others ) and our main focus is on unit and integration testing which will require the react component to be mounted and tested , for which many tools are available but I could not find their integration with sauce or any cross browser-cross platform tool. Once I figure out a way for this issue the CI part will hardly take any time !


the design part:

I have designed one workflow ( check-in ) and will complete the remaining in the coming 2-3 days ! adding to these I will document the endpoints that will be used in each steps in the designed workflows. The endpoints of the check-in workflow is provided below.

here is the video of the designed check-in workflow:

check-in.mp4 from Shashwat on Vimeo.


CHECK-IN WORKFLOW :
SEARCH PARAMS :

GET [base]/Patient?identifier=[value]

GET [base]/Patient?name=[value]

CREATE PATIENT :

POST [base]/Patient

GET PATIENT :

GET [base]/Patient/[_id]

Conclusion

This week’s blog was not too long as I have not written any code, but hoping to deliver some interesting content in the upcoming weeks! I will be posting a blog every week highlighting the things I completed during the week and the things that I plan to achieve.

See you next week 😄