Skip to content
This repository has been archived by the owner on Jan 9, 2023. It is now read-only.

Modify the patient object to capture configurable fields #470

Closed
3 tasks
tangollama opened this issue May 19, 2016 · 4 comments
Closed
3 tasks

Modify the patient object to capture configurable fields #470

tangollama opened this issue May 19, 2016 · 4 comments
Assignees
Labels
🚀enhancement an issue/pull request that adds a feature to the application in progress indicates that issue/pull request is currently being worked on

Comments

@tangollama
Copy link
Member

tangollama commented May 19, 2016

Currently, the patient object is a limited set of fields. It's right and good that the application would ship with a preferred set of fields on a patient entity. However, even our first few deployments have made it clear that there needs to be an ability to both remove and add fields. Given that ORM nature of our data storage, this should be (generally a non-issue). However, that requires a few changes.

One of which is the implementation of a dynamic form build capability. Current thinking is that this Ember Addon would be the appropriate way to go. https://github.com/toddjordan/ember-cli-dynamic-forms

Thus, the following steps should be taken.

  • Replacing the existing patient registration screen (add/edit) with the configurable form tool.
  • Creating an administrative capability to create new patient fields and make them optional or required, utilizing a series of controls, depending on the input ranges and needs
  • Implementing a set of automated tests to exercise this functionality

That said, the following fields must ALWAYS be available on the patient registration screen, even if they are not all required:

  • ID (id)
  • External Patient Id (externalPatientId)
  • First Name (firstName)
  • Last Name (lastName)
  • Sex (sex)
  • Date of Birth (dateOfBirth)
  • Phone Contact (phone)
  • Patient Status (status)

cc: @jkleinsc for review.

@tangollama tangollama added 🚀enhancement an issue/pull request that adds a feature to the application Patient labels May 19, 2016
@jkleinsc
Copy link
Member

@tangollama I think in general this is a good idea, but that there probably is a set of fields that always render. One reason for this is that reporting gets really complicated if you are trying to report on dynamic fields.

@tangollama
Copy link
Member Author

Good word @jkleinsc I'll update the main issue with the list on fields that must be retained.

@jkleinsc
Copy link
Member

After evaluating ember-cli-dynamic-forms, I felt that it wasn't as useful as I was hoping, so I decided to create a custom component for HospitalRun so that we can add custom forms wherever we need them. More details about that component are here:
https://github.com/HospitalRun/hospitalrun-frontend/wiki/Custom-Form-Component

@jkleinsc jkleinsc self-assigned this Nov 8, 2016
@jkleinsc jkleinsc added the in progress indicates that issue/pull request is currently being worked on label Nov 8, 2016
@jkleinsc
Copy link
Member

This was completed with #788, closing issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
🚀enhancement an issue/pull request that adds a feature to the application in progress indicates that issue/pull request is currently being worked on
Projects
None yet
Development

No branches or pull requests

2 participants