When there is change in business need, the change in application is inevitable. From application design perspective, the key is how to design the application so that we manage the ongoing change efficiently, and make our life less worry and happier, we can either
1) Perform "Full body surgery" to change every part of the application, that leads to longer time for
development and testing, more artefacts to deploy, and tends to have more bad
fix. or
2) Structure the application framework so that the change
is contained within a specific area of the application so that the change is
faster, the testing is faster, and deployment is faster
Typical
development approach
When
development starts, in the typical development approach, frontend developer and
backend developer work on the following two activities before defining the
structure and format to expose APIs to frontend.
1) Understand and analyze the business requirements, so
that we understand the data elements and format of each data element for the
respective functional module
2) Define the
data model, how many database tables and table columns, and what’s the
relationship of these tables
3) Understand and
analyze the application UI requirements, understand what data is required on
each UI screen, where all these data come from,
and how the data is presented on the UI
If any of the
above information is not available for us, we are kind of “stuck”. Also if any change
on backend requirement or frontend requirement changes, we have to perform
surgery to the whole body. When you perform full body surgery, there tends to be
a lot of bad fix in addition to the extra time spent for development and testing.
1) Database
access logic to cater for new data elements, how to save, how to retrieve
2) Backend API
change to expose the new data elements in the API
3) Frontend
integration needs to change to retrieve new data elements in the APIs
How
we use HL7 FHIR in our platform
1) FHIR based
data model (Relational DB store or NoSQL data store) – We do not need
to figure out
how to design our data model, and how to manage the persistence and query. What we need
do is to figure
out is what data value we shall constrain for the data element eg what is the
list of valid status code for appointment.
2) FHIR APIs for
external system integration, and APIs for frontend components to call – We do not need
to spend time
to brainstorm on the structure and data elements for the API payload and the
syntax to call the API. What we need do is to define the business operation for the API eg shall we
allow book appointment and reschedule appointment, and which part of the API
payload is required
3) The platform
also supports fully custom designed data model and workflow plugins to handle
business logic enforcement
Key
benefits
1) Since all
backend APIs are standardized to follow HL7 FHIR APIs, we can implement reusable component to handle
frontend-to-backend integration, do once and use for ALL backend services that conforms to HL7 FHIR APIs
2) Both frontend
and backend developers can independently work on the respective development
a) Frontend developers can use any external HL7 FHIR
public server for development and testing on the frontend UI component
b) When backend API is ready, frontend developer just needs to configure
the backend APIs to the new URL
3) In the
situation where there is new data element to be shown on UI, only change
required is frontend UI component – where to display, and how to display.
(Assuming no special business logic handling of this new data element at
backend)
If you are interested to be part of this exciting team and journey, do submit your CV to join us
No comments:
Post a Comment