Hello everyone ! I have a doubt related to create type resource based webcomponent. Some of the fields in the resource are of Array prototype with nested objects, for webcomponents other than the create type these objects are shown one after the other but in these create type webcomponent we can only send one object as the request…
below is the patient-get webcomponent with multiple name and telecom details fields…
so should we provide an addition type button (for all multiple value taking fields) which increases one more element with default empty values (only for these create type webcomponents)?
I think we should allow the developer implementing the UX using the web components should have a choice for that, like a repeat button or simply just add that subcomponent back to the page. i.e., this is implementation flexibility that should not be brought into the web component itself.
Does my reply make sense or did I not get what you are proposing?
Some of the mocked-up components are not very useful to build an EHR. e.g., money, annotation, timing, signature. It would be useful, if you could look at an EHR system, maybe the lh-radiology or lh-toolkit UI and think of components that will be useful to replace the existing JSP based web pages.
Once the dataypes are ready, GET / POST component of the above can be created using the new and already created datatype webcomponents, only a few resource-specific-component will be required like :
Yup – ideally when this project is completed, we’ll have components for all FHIR Resources which will allow developers to build things out in any way they choose.
Will this project be more based on creation of new webcomponent for general EHR systems or implementing the toolkit app using the already created webcomponents?
As according to the first post the new webcomponents which were
required to be created for the app were order and observation resources: i could not find the order resource and observation was created last year?
I think we have created enough web components and the goal for this project would be to implement an EHR system using those components. Some components might be missing and those have to be implemented simultaneously. A good project proposal will be able to mock the screens for the EHR and identify those that will be required to be developed.
Hello mentors, I have shared the draft proposal through the website, hoping to get your feedbacks and work on the improvements, I have also shared the proposal here :
@sunbiz Thanks a lot for giving me the feedbacks earlier, I have made the additions according to your comments, should I submit the final pdf proposal?
I was looking into the security part of fhir and found that there are no resources to administer access control management or authentication. Also, an EHR should have some kind of security system that administers users, user authentication, and user authorization, so what would be the proper way to implement the above mentioned features ?
Those should probably come from the system in which the API is implemented. So, the EHR backend will have to implement some form of security. In the past, we used Spring security and through that we authenticated through Basic Auth based on the request header. This worked only when using SSL for end-to-end encrypted sessions. However, for web components, this is something that can be ignored because the request for those web components can be blocked for lack of authentication on the server pages that include the web components in them.
Continue the discussion 