Refactoring for better scaling and understandability.

So it has been another week in GSoC coding period. And one of the very first things that I worked on is to refactor the existing structure of components so that it is easier to understand and scale as the list of components grows. Current we have all the components in one folder (packages). And the components are name according to their resource or datatype.

Current structure:

So as we can clearly see. The current problem with the structure is that there is no hierarchy. All the components are in one line. Although they are named correctly. According to their type and resource. For example the fhir-allergy-category. Is a allergy resource specific component which is a codeable concept. And fhir-coding is a complex datatype which is used in a lot of components.

Moving forward:

So lets make it better. As we can see we have resource specific components, datatypes (primitive, general purpose (complex)). I think the best way to organize them would be in these categories.

If we look at the datatypes. We have the following components:

Primitive:

instant, timedate, dateTime, decimal, boolean, integer, string, uribase64, Binarycode, id, oid, unsignedInt, positiveInt, markdown, url, canonical, uuid

General Purpose:

Ratio, Annotation, Period, Money, Coding, CodeableConcept, Attachment, HumanName, Address, ContactPoint, Identifier, Signature, Quantitiy, BackboneElement, Timing, SampledData, Repeat.

Resource Specific:

Allergy: assertdate, category, clinicalstatus, criticality, lastoccurance, note, onset, type, verficationstatus.

Location: description, mode, operationstatus,

Organization: contact, name, type

Patient: identifier, deceasestatus, martial status

Refactoring Names:

In the current list of components. There are some components that can be renames to better fit in their category. For Example:

fhir-birth-date: This components can be renames to date. As date is a primitive datatype which is already defined and is reused in multiple resources. So it should be in the primitive datatypes directory. And we can reuse it anywhere.

fhir-martial-status: This component is actually a part of the patient resource. So it would be best if we add it in the patient resource.

Updated Structure:

So as we can see in the updated structure. We have a clear hierarchy. The datatypes are separate from the resources. Which shows that they can be used in any resource. And the resource specific codeable concepts are in their specific directory.

And in order to for lerna to use all those packages we need to add them in the packages array like:

"packages": [
    "packages/types/*",
    "packages/resources/allergy/*",
    "packages/resources/location/*",
    "packages/resources/organization/*",
    "packages/resources/patient/*",
    "packages/resources/practitioner/*",
    "packages/ui-components/*"
  ],

I will discuss further with my mentors on how I can improve the structure. And it there are any mistakes in the current one. I will solve them asap.

Next up. I would be working on creating components for the new resources that I am working on. Hopefully by the end of next week. I will finish at least one complete resource and add it in the demos.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.