My Outreachy internship has officially ended. It’s a bittersweet ending to a great beginning.

What I Have Accomplished During My Internship

My internship tasks centered around bug-fixing and updating documentation for the LibreHealth EHR application.

I worked on troubleshooting existing and newly discovered bugs in the LibreHealth EHR software that existed in the front-end and back-end through the submission of GitHub Issue Reports and Pull Requests (PRs). I also rewrote and updated the Reports Wiki document and updated the included screenshots to properly display each component and guide users to perform certain functions. While doing so, I tested each component to make sure it was working properly, and reported and fixed any bugs that were discovered.

What I Learned

• When you’re fixing a bug: focus on finding the root cause, then create a solution to fix the root cause.

I learned this lesson the hard way, but keeping this in mind helped me solve bugs faster.

• Software and software documentation go hand-in-hand.

It’s important to remember that documentation needs to be updated when a correlating software feature is changed or added. Otherwise, the documentation can become outdated quickly.

• Remote work is all about communication.

I had to learn how to effectively ask for help and in a timely manner. When I was stuck, I reminded myself of the issue and retraced the steps I took to solve the issue. If I was still stuck, I would then ask for help by explaining the issue thoroughly and what I have done to solve the issue. This gave me the opportunity to learn from my mentors. Asking for help is just another opportunity to learn from other great developers!

• “Underpromise, overdeliver.”

This was advice I read in an article that included tips on how to become a successful software engineer that has stuck with me. During my internship, I was always so excited and eager to start new projects, especially ones where I could learn a lot. What I didn’t account for was time. I would sometimes promise results in an intended amount of time that turned out to be underestimated. I’ve learned that being able to effectively determine how long a “project” will take to complete comes with more developer experience.

What’s Next

Contributing to FOSS (Free and Open-Source Software) started as a way to prove to myself that I was meant to be a developer. Now, I contribute to FOSS, because I am more confident in my skills and enjoy contributing to FOSS. More specifically, I’m proud to be a part of the LibreHealth community as if is doing amazing work in the Health IT field!

I could not have made it here without the immense support I received from my mentors. Toni Shortsleeve, Elizabeth Ngai, Mua Rachmann, Harley Tuck, Virginia Balseiro, and Robby O’Conner, thank you all for your guidance and encouragement throughout my internship. Your words have helped me believe in myself when I was questioning my skills and further cemented that I’m meant to pursue this career path. I’m so excited to work alongside you as we mentor the next interns.

I started as a volunteer for LibreHealth around this time last year, and now, one year later, I’ve successfully completed my Outreachy internship and will be a mentor for the upcoming LibreHealth Outreachy interns. I can’t wait to see what’s next!

My current career goal is to find a full-time position as a full-stack developer. I equally enjoy both front-end and back-end development and have experience in both.

Before my Outreachy internship, I interned at a small start-up as a developer intern and graduated from college with Bachelors in Computer Science and Cognitive Science, through which I’ve learned the basics of computer science and OOP (Object Oriented Programming) and gained teamwork and communication skills through technical group projects. Since then, I’ve taken various online classes regarding different topics of programming and contributed to open-source.

Currently, I’m interning through the Outreachy program, in which I’m working remotely with LibreHealth to improve one of their open-source software projects LibreHealth EHR. My work has taught me how to create and maintain good documentation and effectively troubleshoot software issues by finding the root cause and then coding up an efficient solution. I have also gained more experience with the tech stack being used: HTML/CSS, JavaScript, Knockout.js, PHP, MySQL, and Apache. It’s been a great learning experience!

Once my internship is over, I will begin job-hunting. I’ll be looking for remote or in-person jobs in Virginia. While job-hunting, I’ll be spending my time improving upon and learning new developer skills by continuing to contribute to LibreHealth and working on a side-project with one of my close (developer) friends.

I can’t wait to take this next step within my tech career. Wish me luck! Yallah, bye!

I attended FOSDEM this year for the first time ever. In fact, it was my first conference ever, so it was very exciting. Brussels is a lovely city and relatively close to where I live, so I decided to take the opportunity to go.

FOSDEM is one of the biggest Open Source conferences in Europe. It is usually held during the first weekend of February at the Université Libre de Bruxelles. 

The conference is free and no registration is required, which is great, but it also means it gets really crowded. If you’re a person who suffers from anxiety particularly among crowds like me, this can be intimidating, but there are ways to still have a great experience.

The talks are held in different rooms simultaneously, so you can choose between the Keynotes, Main Tracks, Developer Rooms and Lightning talks. The majority of the talks are held in the Developer Rooms, and there are a lot: JavaScript, Internet of Things, Go, Python, Community, and many, many more. 

I enjoyed all the talks I had the chance to attend, but my favorites were in the Community Devroom. Here are some links to the videos in case you are interested:

Building Ethical Software Under Capitalism

The Ethics of Open Source

Cognitive biases, blind spots and inclusion

All the talks are available here: https://video.fosdem.org/2020/ 

There are a lot of food trucks with different food options, and I was able to easily find vegan options. Of course, these spots are usually crowded so if you don’t like crowds, plan to get your meals during less busy moments. 

If you’re thinking of attending next year, here are some tips:

• Plan ahead which talks you want to see. This will help you plan your day. 
• When the rooms are full, the doors close, so you might want to be there 15 minutes before the talk begins.
• If you’re anxious in crowds or closed spaces, like myself, make sure to stay close to a friend or someone you know 
• If you’re not feeling well or you feel unsafe, talk to the volunteers, they will help you.

Overall it was an amazing conference, but it also made me realize how truly unbalanced representation is in tech. Although there were some non cis-male people of course, particularly in the JavaScript and Community Devrooms, in general the crowd was overwhelmingly male. 

Trying to find a woman in the crowd was like playing Where’s Waldo. Oh there’s a lady! Nope, just a long haired dude.

While this is not news to anybody, to actually see it in real life with a live sample of people was an eye opener, and a little unsettling. This is why Outreachy exists.

Outreachy is a paid internship program for people typically underrepresented in tech to work in open source and free software. I got involved with open source as part of my internship with Outreachy, and because Outreachy provides a travel stipend to interns to travel to conferences and events, I was able to attend. So if it wasn’t for Outreachy, I wouldn’t have been in FOSDEM in the first place. I would have probably never even heard of it.

I am definitely planning to go again next year, so if you’re going too, feel free to reach out – maybe we can meet there!

It’s hard to believe that I’ve reached the halfway point of my Outreachy internship with LibreHealth. I’m not ready for this experience to end.

Since my internship doesn’t consist of a specific project, I started my internship with these two project goals outlined: 1) fix issues within the LibreHealth EHR software and 2) create new and update existing documentation that are affected by such bug fixes to keep documentation clear and up-to-date as possible.

I was able to jump right in on my first day, since I was already familiar with LibreHealth’s workflow. My first assigned task was to solve a series of existing issues – bug fixing. I wasn’t given a deadline by my mentors, so I gave myself one: one month. I was able to meet this deadline. (Yay!)

My second, and current, assignment is to revise and update the Reports Wiki documentation, which is a series of smaller documents. The Reports section in the LibreHealth EHR software allows users to generate reports to help improve their daily tasks within a clinical office. Since the Reports Wiki was written, the Reports section within the software has changed, but the documentation hasn’t been updated. That means if current users of LibreHealth EHR go to the Reports Wiki, they will be viewing an out-of-date and incomplete document. This may lead to confusion, which we don’t want!

Once again, I wasn’t given a specific deadline, so I gave myself one: three weeks. Unfortunately, I wasn’t able to meet this deadline. I spent the first week a bit unsure about the requirements until I asked for clarification to put myself at ease. Thank you, Harley Tuck! I have also found that it is going to take me longer to finish due to its large size. Now, I will continue to revise and update the Reports Wiki document, while testing out the forms within the Report modules to report any bugs. My goal is to finish it within a few more weeks – by early or mid-February – in the hopes that I will be able to work on another assignment before my internship is over in early March. Only time will tell!

Until next time. Yallah, bye!

Hi readers! As some of you may know, I am currently interning with LibreHealth through the Outreachy program. When I first started contributing to the LibreHealth EHR project, I didn’t know much about LibreHealth, but have learned much more since then. Hopefully, this blog post will give you a better insight into LibreHealth and motivate you to contribute!

What is LibreHealth

LibreHealth is an online community that is creating free and open-source Health IT software that is targeted towards providing fast and easy solutions for the healthcare needs of developing countries all around the world. More specifically, LibreHealth is an umbrella organization that currently oversees three main open-source projects: LibreHealth EHR (Electronic Health Records), LibreHealth Toolkit (API and data model software for building Health IT apps), and LibreHealth Radiology (customized LibreHealth Toolkit software for Imaging and Radiology practices). The LibreHealth EHR project is also being used in academia settings to expose and help train future clinical students with EHR software. However, what makes LibreHealth stand apart from other similar organizations is their main focus in creating an open and collaborative community between the users and developers.

What am I doing exactly with LibreHealth?

I started as a volunteer with LibreHealth and spent my time writing new and improving old documentation of the LibreHealth EHR software, while reporting any bugs I discovered. Because I wanted to spend more time working on this project, I then became an intern with LibreHealth last December. My internship work consists of improving LibreHealth EHR’s current code and documentation. Currently, I am doing bug fixing!

How to Get Involved with LibreHealth

There is more than one way to get involved with LibreHealth as a developer. Whether it’s through Outreachy or as a volunteer, you can contribute to the code and/or documentation of one of LibreHealth’s open-source projects. You can start by first joining LibreHealth’s online chat and forums, then introducing yourself and how you’re interested in contributing. From there, one of the volunteers or mentors can guide you.

There’s so much more to learn about LibreHealth, and I’ve listed some resources below if you’re interested in learning more. As always, until next time. Yallah, bye!

Resources:

LibreHealth Website

LibreHealth Forums

LibreHealth Wiki Docs

“An Interview by Andy Oram with Open Source Health IT Project: LibreHealth” Video

Let me paint a picture for you.

In 2018, after a year of little time spent programming and constantly debating whether I was “good enough” to work in tech, I wrote down a New Year’s goal: to find and contribute to an open-source project. I figured this would help me, once and for all, determine if I was meant to pursue a career in tech.

Once the new year rolled around, I started researching anything and everything related to “open-source.” This led me to discovering Outreachy.

Outreachy, Take I

The Outreachy program is an organization that is committed to increasing diversity in tech by providing mentored, remote internships with partnering free and open-source projects. Unfortunately, I had discovered Outreachy too late in their application process. During this application period, there was no separation between the initial application and contribution rounds, as there is now. So I submitted my initial app and tried to make some contributions all in the last two weeks of the application period. Although my initial application was accepted, I had no time to make any substantial contributions. Trust me, I tried!

I then decided to go with my initial plan and became a volunteer with the project I had chosen to apply to, LibreHealth.

Volunteering

LibreHealth is an organization that is creating free and open-source Health IT software. I initially chose LibreHealth because it aligned with two of my interests: health and tech. It was also being developed in web languages that I was familiar with. However, their welcoming community became my deciding factor. The mentors were encouraging towards applicants and genuinely wanted to help. I spent the next few months working on LibreHealth EHR’s documentation and reporting bugs. (To read more about my experience, check out my last blog post about it.) I had the best time volunteering and would 10/10 recommend for others to do the same!

Outreachy, Take II

I wasn’t planning on applying to Outreachy again, but I quickly found myself looking for more time in the day, outside of studying and responsibilities, to volunteer with LibreHealth. This time around I was prepared. I had signed up for email notifications for reminders and news about the Outreachy program. I read past blog posts from previous Outreachy interns. I started early in each round. I did everything I didn’t do the last time I applied.

My initial application was once again accepted. Then began the contribution period. I had already known what project I was applying to, which saved me some time during the application period. I consistently made contributions. For LibreHealth, it was in the form of creating documentation that adhered to LibreHealth’s established documentation guidelines, reporting bugs, and submitting PRs.

Although I came in knowledgeable this round, I still encountered many moments of doubt. This round, LibreHealth was only choosing one intern. There were many other qualified people also applying for a chance to work with them. However, I think my volunteering experience really helped me gain confidence in myself and my skills. I just kept going and refused to let fear and doubt stop me.

A month after the application period closed, I found out that I got accepted!

Advice for Future Outreachy Applicants

I’d like to think that I have some substantial advice for future Outreachy applicants. (After all, I did apply twice!) So here it is:

• Research, research, research.

It’s better to come prepared for most things in life, including Outreachy. The good news is that Outreachy has numerous resources to help prepare future applicants. Check out Outreachy’s Applicant Guide, Outreachy’s Blog, Outreachy’s Twitter, and past interns’ blog posts. You can even reach out to Outreachy organizers and past interns with any questions.

• Start early.

Outreachy outlines their application deadlines on their website. Be aware of these and use them to your advantage! You can also sign up for their email notifications.

Once the contribution period starts and you’ve chosen your project(s), start engaging with the community and mentors. Make contributions. Technically, you only have to make one contribution to be eligible to apply for a project. However, the more contributions, the better.

• Believe in yourself! Let go of the fear and negative thoughts of not being good enough.

This is something that I have struggled with and still struggle with sometimes. However, I always remind myself that these feelings of inadequacy have no positive purpose in my life and can actually hinder me from amazing opportunities and experiences. The power of believing in yourself is real.

• Don’t give up.

If you give up, you may miss out on life-changing opportunities. If you ever feel like giving up during the application period, just remind yourself why you’re applying in the first place and what you’ll gain if you’re accepted.

• Don’t be afraid to ask questions.

Asking questions can help you learn and grow. If you have any questions about contribution guidelines or anything programming-related and cannot come up with an answer on your own, ask! The project mentors are there for a reason. They want to help you. You can also reach out to other interns.

Whether you decide to apply for Outreachy or not, contribute to open-source! I cannot stress how much confidence and excitement for software and programming I have gained by contributing to the LibreHealth EHR project this past year.

Feel free to reach out if you have any questions or need some encouragement!

Until next time. Yallah, bye!

It’s almost the end of my internship. Three months seem like a couple of weeks and I remember how I submitted my application like it was yesterday.

I did a lot of things for the first time this summer. I started to work remotely in IT and was successful with tasks and time management. I learned how to use restructured text for documentation and how to run Sphinx docs. I also met wonderful mentors Toni and Robby who supported me all the time and guided through the internship. I also learned to seek help and advice when I wasn’t able to do something myself.

One of the most important things for me was that this internship made me more self-confident. I read many reviews about Outreachy before applying and they highlighted different things: new skills, new connections, a new experience for a CV and so on. I don’t remember anyone writing that the internship made them more confident but it’s exactly what happened to me. I’m not (so) afraid anymore to apply for remote positions because I already have remote experience and skills to perform work successfully. I’m also more confident in my English knowledge because I was writing docs in English not being a native speaker and they didn’t have many mistakes.

This was a great summer and I want to thank my mentors Robby and Tony, LibreHealth community and Outreachy organizers for making it so special. I’d like to continue working on LibreHealth project and helping to improve it: maybe not by writing documentation but by doing other tasks and gaining more skills.

I didn’t regret my choice a moment and I wish all future applicants good luck!

Switching careers was one of the toughest decisions in my life. I got a medical education and became an eye-doctor,  but it turned out that it’s almost impossible to support your family working in Healthcare in Ukraine. I had to look for other options and tech career seemed the most obvious since you get many opportunities, can work flexible hours and learn new things all the time. I was lucky that IT was my second passion after medicine and I liked what I was to learn.

However, there are things people don’t talk about much. Those who switched careers successfully will mostly tell you  that they worked hard and finally got enough skills to find a new job. Full stop. Hard work and dozens of job applications without any answer were things I was prepared to but it wasn’t all. 

When you are trying to switch career, you face the following:

• Doubt. Are you smart enough to learn so many new things and be a competitor to those who got tech education and have professional experience?
• Depression. There will definitely be moments when you’re stuck, can’t understand something and are about to decide that it’s not the right thing to learn and it’s better to give up.
• Disapproval. Many people who learn that you are about to give up your current job and do something completely different will try to discourage you and warn that you might fail. They usually think that they’re doing good for you but it only makes things harder.

I want to share my recipes that helped me along this journey.

How to Fight Doubt?

The first thing is to always remember that you already have a job and skills to earn your living. If something goes wrong, you can return to where you started. So it’s most likely that you aren’t losing anything but you’re getting a chance to have a new better job. If you are working in a fast-changing environment, you might indeed need to catch up if you decide to return to your previous career but since you have experience in it, it won’t be that hard.

What to Do with Depression?

Keep a list of things that motivate you and cheer you up. When you feel down, you might simply forget about these things so having a written list of them on your table is a good idea. It’s totally OK to feel down from time to time when you’re doing something difficult. Never blame yourself for that or for being not efficient enough. Such thoughts can only make the situation worse.

Find a friend or two who support you and talk to them if you feel you need support. If you don’t have such friends, join a chat or a Slack group on the technology that you’re learning. There are many people ready to encourage you and help with advice.

Don’t let Disapproval Make you feel Guilty.

The way people communicate their judgment largely depends on the culture. You’re lucky if you come from a country where it’s impolite to tell others what to do with their lives but it wasn’t the case for me. Family members always worry about your future and they might make you feel unsure or guilty of your choice even without wanting it. Sometimes even people who are not your close friends can make comments on your career switch, telling you that was the worst decision ever. 

Calm down. Breathe. Prepare in advance a short and polite answer. It might be something like “Thanks for your care but I really don’t want to discuss my decision”. Be ready to have such conversations multiple times. That’s how people are, be patient with them.

I want to wish good luck to everyone switching careers. I hope that you’ll succeed and that my advice will help you.

After completing the LH tookit resources. I was advised to also work on the LH toolkit app. The is made to show the proof of concept of how the components will work in a real application. The app is currently available at: https://gitlab.com/parumenon.pm/lh-toolkit-app.

Current State:

Currently the app contains the following views:

1. Create Patient
2. Search
3. Manage Users
4. Location
5. Organization
6. Settings

• 
• 
• 

Material Web Components:

As we have talked before about the material web components. The current UI kit that we are using does not have all the components that we require for example in the existing demo we have native elements for select, date and time etc.

So I will also be forced to use the native elements for the components. Until their respective web components are released and then I will replace them with the material web components.

To Do:

I will also be creating similar views for the resources that I created. That would be

1. Create Appointment
2. Appointment Response
3. Add Slot
4. Add Schedule
5. Diagnostic Report
6. Condition

The application is also in Polymer. And was created using the pwa-starter-kit provided by Polymer. The structure is fairly simple. Let’s see how it turns out. As I am writing this post. I have already started work on this and I will soon be able to update on the progress. Hopefully by the end of this month.

The post Working on lh-tookit app. appeared first on Muhammad Kamran .

Moving on with the web components. After creating the appointment resource. My target for this month was to create the remaining components for the resources. Which are Slot, Schedule, Diagnostic Report, Appointment Response.

Diagnostic Report:

A diagnostic report is the set of information that is typically provided by a diagnostic service when investigations are complete. For this resource I used the following components. I don’t think I have to go in detail about how the components were structured. As we have already discussed that in the previous post. And the new components are also very similar.

• Subject (Reference Component)
• Performer (Reference Component)
• Status (Diagnostic Report Status Component)

Slot:

Slot resources are used to provide time-slots that can be booked using an appointment.  For this resource we have the following components:

• schedule (Reference Component)
• start (Instant Component)
• end (Instant Component)

Schedule:

Schedule resources provide a container for time-slots that can be booked using an appointment. For this resource we have the following components:

• actor (Reference Component)
• planningHorizon (Period Component)

Condition:

This resource is used to record detailed information about a condition, problem, diagnosis, or other event, situation, issue, or clinical concept that has risen to a level of concern. For this components we have the following components:

• clinicalStatus (Condition Clinical Status Component)
• verificationStatus (Condition Verification Status Component)
• subject (Reference Component)

Appointment Response:

Appointment resources are used to provide information about a planned meeting that may be in the future or past. For this resource we have:

• appointment (Reference Component)
• start (Instant Component)
• end (Instant Component)
• actor (Reference Component)
• participantStatus (Participant Status Component)

Next up. I will be working on creating the proof of concept app for the components.

The post Creating reusable FHIR components – part 2 appeared first on Muhammad Kamran .

My primary task for this summer Outreachy internship is helping to optimize and update the documentation for the LibreHealth toolkit and create a static website using Sphinx documentation generator.
I had very little experience writing documentation and never used something like Wiki pages or Sphinx. All my READMEs were regular README.md files laid out with Markdown. When I started reading about Sphinx, I discovered two things:

1. There is no «official» Markdown specification, Markdown rules and rendering can differ depending on a platform.
2. Sphinx uses reST (restructured text), which is a lot like Markdown but has a clear specification and additional features.

I always want to try out things myself so I found a tutorial on the Sphinx website. It outlines how to create simple documentation with Content tree and links to sub-documents and instructions on how to build and run it locally. The tutorial is well-structured and you don’t need to have specific knowledge to go through it.
Another thing that I needed to do, was installing an IDE that supports Java. I have no experience with this programming language but based on previous revision on the project documentation and my experience working in JetBrains’ IDEs, I chose IntelliJ Community Edition. Community edition doesn’t have all features and integration options of the professional edition but it can be used for free and is enough as I was not going to write much (if any) code.
I’m relatively new to Linux and when it comes to installing programs that cannot be installed with apt-get install, I get stuck. I read a manual on installing IntelliJ on Ubuntu from an archive but on the last step I found out that I don’t have a file they were asking to move. There’s a lifehack for those who are like me: you can use Ubuntu Software Center and look for the needed program. It worked for me and in just two mouse clicks I got a running IDE with a familiar layout (all JetBrains’s IDEs that I’ve seen have a similar layout, settings, and tools).
It’s a little weird to see the code in a language you don’t know. When I just started to learn to code, everything looked bizarre and I didn’t understand a thing. Now when I try to read a Java code, I notice familiar patterns like loops or functions and classes but they have different syntax and it’s not always clear what happens in the code.
People often told me that it is much easier to understand or learn your second, third or fourth programming language and it’s totally true! When you understand and can see generic patterns, you can try writing things you can write in JavaScript using, for example, Go. I’m not saying that this is the best idea because different programming languages require you to use different approaches and in most cases, you shouldn’t write in JSy Go.
So learning a little about the tools I will be using and setting up work environment on my machine were the first steps of my summer internship. I’d use the same steps for any new project:

• Learn the main tools.
• Set up work environment.

You will both have a possibility to run a project locally (if it can be done) and become familiar with the tools others are using.

You can see the documentation website that I’m working on here: https://docs.librehealth.io/.

So this week I started on created web components. The first resource that I wanted to target was Appointment resource. As it contained the most components that will be reused in other components. To get some more insight on the resource. I also went through the examples at the FHIR test server. I looked at the appointment resource. ie: http://hapi.fhir.org/baseDstu3/Appointment/1966105/_history/1

{
  "resourceType": "Appointment",
  "id": "1966105",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2019-06-22T23:20:15.284+00:00"
  },
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><div>Routine checkup</div><div>Dr Dave</div></div>"
  },
  "status": "pending",
  "description": "Routine checkup",
  "start": "2019-06-29T16:20:15-07:00",
  "end": "2019-06-29T16:35:15-07:00",
  "minutesDuration": 15,
  "participant": [
    {
      "actor": {
        "display": "Dr Dave"
      },
      "status": "accepted"
    },
    {
      "actor": {
        "reference": "Patient/1966031"
      },
      "status": "accepted"
    }
  ]
}

So looking at the example and the FHIR documentation for the appointment resource. I see that I will need the following components that I need to build for the.

1. fhir-instant: Instant is similar to datetime which we have already used. But it is different in a way that it also contains the time and AM/PM. So it used when we need exact time. Which in our case. We need for the start and end of the appointment.
2. fhir-positiveInt: In the resource we have minutes duration. Which tells the number of minutes the appointment will take. And this number has to be positive.
3. fhir-appointment-status: This is a code component. Which will contain the select options for the status. Which can be either: Proposed, pending, booked, arrived, fulfilled, cancelled, noshow, entered in error, checked-in, waitlist.
4. fhir-reference: This again is a type component. Which will be used in a lot of resource. It contains the display name and the reference url of the resource which we are targeting.
5. fhir-appointment-participant: This component contains the participants of the appointment. It also contains the reference resource that we created earlier as “actor”
6. fhir-create-appointment: This component will combine all components and post the result.

So as I was going to create the appointment resource. I created a git branch for this. After creating each component I committed the changes.

fhir-instant: commit

For the instant. We can use the datetime-local type for our inputs. And then return its value.

<div id="instantDiv">
        ${instant !== 'false'
          ? html`
              <mwc-formfield class="instant" alignEnd>
                <input
                  id="date"
                  type="datetime-local"
                  value="${this.value}"
                  on-input="${e => (this.value = e.target.value)}"
                />
              </mwc-formfield>
            `
          : ''}
      </div>

fhir-positiveint: commit

For the positive int. I am using the type number with min value as 0. So that we can only add positive values.

<div id="positiveIntDiv">
        ${positiveInt !== 'false'
          ? html`
              <mwc-formfield class="positiveInt" alignEnd">
                <input
                  id="positiveInt"
                  type="number"
                  min="0"
                  value="${this.value}"
                  on-input="${e => (this.value = e.target.value)}"
                />
              </mwc-formfield>
            `
          : ''}
      </div>

fhir-appointment-status: commit

For the appointment status. We are using the select component. As in MWC the mwc-select is not available and is under development.

<div id="appointmentStatus">
        ${typeField !== 'false'
          ? html`
              <label>Status:</label>
              <select
                class="typeField"
                value="${this.value}"
                on-change="${e => (this.value = e.target.value)}"
              >
                <option value="proposed">Proposed</option>
                <option value="pending">Pending</option>
                <option value="booked">Booked</option>
                <option value="arrived">Arrived</option>
                <option value="fullfilled">Fulfilled</option>
                <option value="cancelled">Cancelled</option>
                <option value="noshow">No Show</option>
                <option value="entered-in-error">Arrived</option>
                <option value="checked-in">Checked in</option>
                <option value="waitlist">Waitlist</option>
              </select>
            `
          : ''}
      </div>

fhir-reference: commit

For the reference we are using 2 input fields. Display and the Reference. Which points to the resource document.

<div id="referenceDiv">
        ${reference !== 'false'
          ? html`
              <label>Reference</label>
              <mwc-textfield
                outlined
                class="reference"
                value="${this.value.reference}"
                on-input="${e =>
                  (this.value.reference = e.target._input.value)}"
              ></mwc-textfield>
            `
          : ''}
        ${display !== 'false'
          ? html`
              <label>Display</label>
              <mwc-textfield
                outlined
                class="display"
                value="${this.value.display}"
                on-input="${e => (this.value.display = e.target._input.value)}"
              ></mwc-textfield
              ><br />
            `
          : ''}
      </div>

fhir-appointment-participant: commit

The participant in appointment contains the reference as an actor. As well as its status. So we are importing the reference components here and add the status as a select option.

<div id="participantDiv">
        ${status !== 'false'
          ? html`
              <label>Status:</label>
              <select
                class="status"
                value="${this.value.status}"
                on-change="${e => (this.value.status = e.target.value)}"
              >
                <option value="accepted">Accepted</option>
                <option value="declined">Declined</option>
                <option value="tentative">Tentative</option>
                <option value="needs-action">Needs Action</option>
              </select>
            `
          : ''}
        ${reference !== 'false'
          ? html`
              <fhir-reference
                class="reference"
                value="${this.value.actor}"
                on-input="${e => (this.value.actor = e.target.value)}"
              ></fhir-reference>
            `
          : ''}
      </div>

fhir-create-appointment: commit

And the create appointment basically just imports all the required components and posts them.

_render({ url }) {
    return html`
      <fhir-appointment-status id="appointmentStatus"></fhir-appointment-status>
      <p>Start:</p>
      <fhir-instant id="start"></fhir-instant>
      <p>End:</p>
      <fhir-instant id="end"></fhir-instant>
      <p>Minutes Duration:</p>
      <fhir-positiveint id="minutes"></fhir-positiveint>
      <p>Participant:</p>
      <fhir-appointment-participant
        id="participant"
      ></fhir-appointment-participant>

      <br />
      <mwc-button id="button" raised on-click=${() => this.doPost()}
        >Submit</mwc-button
      >
      <iron-ajax
        bubbles
        method="POST"
        id="ajax"
        url="${url}"
        on-response="handleResponse"
      ></iron-ajax>
    `;
  }
  doPost() {
    var status = this.shadowRoot.getElementById('appointmentStatus').value;

    var start = this.shadowRoot.getElementById('start').value;
    var end = this.shadowRoot.getElementById('end').value;
    var minutes = this.shadowRoot.getElementById('minutes').value;
    var participant = this.shadowRoot.getElementById('participant').value;

    this.shadowRoot.getElementById('ajax').contentType = 'application/json';
    this.shadowRoot.getElementById('ajax').body = {
      resourceType: 'appointment',
      status: status,
      start: start,
      end: end,
      minutesDuration: minutes,
      participant: participant
    };
    this.shadowRoot.getElementById('ajax').generateRequest();
  }

Some of the components are not in material design. Like the select component. As we are using mwc and they are still under progress. Several issues have been created on gitlab regarding this. #24 #29 #32 #40 . Hopefully we will soon have more mwc components so we can use them.

Next up: In the next month. I am hoping to create all components for the required resources and add their demos in the index.html. So that in the last month. I am only left with testing and add the demos in the proof of concept application.

The post Creating reusable FHIR components. appeared first on Muhammad Kamran .

It was difficult and easy at the same time to chose an open-source project I want to contribute to. I received medical education and wanted to continue working in this area but now as an IT specialist. So when I thought that LibreHealth Toolkit was in the Outreachy list of projects for application, I read more about what they were doing and decided that it would be a perfect match for me.
LibreHealth has its website with the section dedicated to the Toolkit. LibreHealth projects aim at improving and simplifying medical record systems in healthcare facilities and creating traceable medical records that are easy to use. It is open-source so everyone interested in the project can contribute. I think that it is great to be among people who create something you use at work, to be able to discuss how features are implemented and propose something new. I especially liked one of the taglines of LibreHealth that states “LibreHealth is driven by real needs of patients and last-mile clinicians who want to improve health and health service delivery”. I understood that I want to be a part of it.
I live in Ukraine and the medical system here is far from perfect. Many hospitals lack equipment, especially those in smaller towns and villages. Such record systems as developed by the LibreHealth team could make processes easier but it’s long till it can be implemented here. However, I hope that at least some hospitals in my country could also use modern record systems instead of old-fashioned piles of paper journals.
So what exactly is LibreHealth Toolkit?
It is an API (set of calls that allow users to interact with your code) for a set of healthcare record systems. The project is developed by the community interested in using and enhancing it. You can build applications based on the toolkit that will function according to your needs. The idea of the project is that it is universal and can be used in any kind of medical facility: from large clinics to small hospitals in remote locations. One of the advantages is that Toolkit can run on the most popular operating systems and platforms. It means that you don’t have to switch for example from Windows to Linux or OSX and can continue using the platform you are used. What I find one of the most attractive things is that Toolkit supports many popular languages so people who are not native English speakers can use it in their language.
LibreHealth project is hosted on GitLab. You can submit an issue or start a discussion if you want to take part in its development. There is also an option to donate money to the project available on the main website.
To sum up, there are several things I liked most about working with the LibreHealth community:

• it is open to new people and friendly
• you get encouragement for every effort
• you feel that you are doing something valuable for society.

So after the directory refactoring. I believe there is one more thing that we can improve on. Currently in the project we are using material design web components so that there is . But when they were added first there was no npm module for the components at that time. So they were added as a git sub module untill the npm package was released.

By now. Material design web components are available on NPM. So I decided it would be a good time to switch to the npm module as I will be creating more resources as well. And I will just use the npm modules from here on and just replace the old git submodule with the npm module.

Material Web Components:

So in order to do that. The first thing we need to do is install webcomponents:

 npm i @webcomponents/webcomponentsjs

One we got the bundle.js we need to install individual material components. So I installed the following:

material/mwc-base
material/mwc-button
material/mwc-checkbox
material/mwc-formfield
material/mwc-radio

And updated the all the dependencies in the package.json of each component to the new ones.

Updated package.json

// Old
"@material/mwc-base": "file:../../material-components-web-components/packages/base",

// New
"@material/mwc-base": "^0.6.0",

So this one done for all components until I tried installing mwc-textfield. So that was an awts moment for me. As mwc-textfield was not available on npm. Even tho it was used in the project in the git sub module since version 0.1.0. But still it was missing.

And select was missing even in the sub module. Which seeing the demos I was wondering why the select component was not used. So it appears that select along with textfield and some other components are still under development. That’s why they are not available. According the issue #40

Although I was hoping to completely remove the sub module in favor of the npm modules. But it looks like we will have to wait a little text-field is being used by quite a few components. So for now I think we will have to keep the sub module until we have a solution for the textfield component.

So I far I have committed the changes in the refactor branch.

The post Switching material components from sub module to npm appeared first on Muhammad Kamran .

This May I visited Gophercon EU, a big conference about Go. It was held in the south of Tenerife. There were many things that I experienced for the first time! For example, it was my first time on an island and it was my first time to talk to Mat Ryer, Bill Kennedy and other gophers who write books and articles about Go and make it so popular and understandable. It was also the first time I took a coding workshop.

I was able to take part in this conference because I got a scholarship from GoBridge. I filled in the application form long ago and then forgot about it because I knew that the chance of being selected is very small. How happy I was when I got the email saying that my application was approved! It was about 1 a.m. when I read it and I woke up my mom to tell her great news and the two of us couldn’t sleep for the next couple of hours because we were so excited and happy. I’m smiling now when I’m writing these lines and remembering that night.

Then there were weeks of preparations for the trip and anticipation. I’ve read about speakers I didn’t know (I already knew some of them from previous conferences) and decided what talks I want to hear. Choosing talks beforehand is one of the key steps in preparing for the conference. Many conferences have more than one track and even if there is only one track, it’s extremely hard to stay focused the whole day and keep absorbing new information so you have to chose what is the most interesting. It may be difficult if there are many topics relevant to what you are currently doing at work so it’s nice to have time to think it over and not to leave decisions for the last 5 minutes before a talk.

On the first day of Gophercon, I took part in a workshop “Daily Go” by Miki Tebeka. There was a lot of practice and Miki showed us best practices of code structuring, debugging, performance testing and even some basics of CI/CD. He also shared useful links and I saved them to read later. I think that I’ll use in my daily work a lot of what he showed during this workshop.

There were many great talks on the second day. I especially liked two of them: “Finding Dependable Go Packages” by Julie Qiu and “How I Write HTTP Web Services after 8 Years” by Matt Ryer. I hope the organizers will post videos so that my colleagues who missed the conference could also see these talks. I also had a chance to talk to speakers during breaks. It’s one of the things you should visit conferences for. When you watch recordings, you cannot dive into this atmosphere and profit from real-time communication.

The third day of the conference was Community Day. It was less formal and many people gave talks on important Go-related topics. I made notes so that I can explore in-depth aspects that can be handy for my tasks.

All three days were very different and each of them brought me lots of valuable information. I’m very glad that I had a chance to visit Gophercon EU 2019, learn, network and meet new friends.

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.

The post Refactoring for better scaling and understandability. appeared first on Muhammad Kamran .

I’ve heard many times from different people that they had abandoned some task or project because it had been too difficult. This can be a good excuse when the problem is really over-complicated but often what one needs is a piece of friendly advice and encouragement.

I need to point out that when I’m talking about being stuck, I mean that a person has tried to solve the problem by searching for an answer on the Internet, and debugging or decomposing the task (dividing it into smaller doable tasks). First, you should try to find the solution yourself and only then search for help.

So why people don’t ask for help and seem to abandon what they are doing?

I could think of several reasons:

— they don’t know who has relevant knowledge

— they are afraid of being laughed at or rejected

— they don’t know how to describe the problem concisely

— they were told that asking for help is something bad

For me, the most frequent were the first two. When I was learning to code, I asked questions several times in community chats but I often received unfriendly feedback, so I preferred to do as much myself as possible and not to show others that I didn’t understand something.

And I think that it’s totally wrong!

There are many good professionals ready to help. They may be part of another community or chat so it is worth trying again. For example, if someone told you something harsh in a Facebook group, you can ask your question in the relative Slack channel. Of course, you shouldn’t bother people with questions you can easily google yourself (“How to make a string uppercase in JavaScript?” is probably a bad question to ask).

When looking for people with relevant knowledge, you can consider the following channels:

— Slack (for many software communities it is the primary way of exchanging information and networking)

— Telegram (it has both channels and chats and you can find different lists of them by googling something like “telegram chat [name of a programming language, CRM and so on]”

— Gitter and community chats like Rocket chat (you will usually find links to them on GitHub/GitLab repositories under README or Contributing)

— Facebook (it’s not only a network of friends but it also has groups for professionals)

— Twitter (by posting your question on Twitter and adding hashtags you can get many replies from active community members)

These are just some of the resources where you can look for a person who could help. Don’t hesitate to ask even if the problem is very specific: there may be people who have already struggled with the same thing and found a workaround.

Outreachy is totally unique in the aspect of getting help. You have a mentor (or mentors) for your project, which means that there is definitely a person who can (and is willing) to help. It means a lot for me as I understand that whatever difficulties I can have, my mentors will try to figure out the solution with me and I won’t be left alone. It gives me confidence (which is an awesome feeling by the way).

When I had a problem with Python and destroyed Ubuntu on my machine, Robby and Toni were there to help me with re-installing necessary packages and encouraging. They never told me that my questions were stupid or that something was obvious.

I always try to answer questions in community chats when I have time and know the answer even if they seem trivial for me. I suggest that a person has already tried to google or do something to figure out the solution and that didn’t help. Sometimes all you need is to put information from official docs into simple English!

After graduating college with a computer science background, I faced a serious bout of imposter syndrome. Let me tell you, imposter syndrome is real. I didn’t think I was “good enough” to work in the world of computer software. I decided to take some time off. But no matter what I did, I couldn’t shake the idea of not working in the field of software. Thus, I started looking for an open-source project to help regain my confidence and to improve my tech skills.

This is how I discovered Outreachy, an organization that is committed to increasing diversity in tech by providing remote internships with free and open-source projects. As a woman of color aspiring to work in tech, I was so excited that I could possibly gain an internship through an organization that was dedicated to helping people like me. There were many different types of projects available, but I knew I wanted to work with one that aligned with my interests of health and tech. LibreHealth was one of the few health-tech organizations available, and it was the only health-tech organization that used web-based technologies that I was familiar with.

LibreHealth is an online community that is creating free and open-source Health IT software. They currently have three main projects: LibreHealth EHR (Electronic Health Records), LibreHealth Toolkit (LibreHealth software engine) and LibreHealth Radiology (for Imaging and Radiology practices). Although I was accepted as an Outreachy applicant, I wasn’t able to complete the second portion of the application. I had learned about the program too late in the process. This led me to becoming a volunteer with LibreHealth.

One of the great things about working with an open-source project is that you can connect with so many different people from around the world just by sitting in front of your computer. LibreHealth’s community is ultimately why I decided to stay and volunteer. I was welcomed from day one. Toni Shortsleeve, one of the co-mentors of the LibreHealth EHR documentation team, has taken me under her wing and has been supportive throughout my experience. The rest of the community is so knowledgeable and are open with helping one another when needed.

The only negative aspect I’ve encountered with volunteering on open-source project is finding time within my schedule to volunteer. Currently, I work as a pharmacy technician (in-training). (It’s a temporary job that I’ve gained many transferable skills from, such as communication and teamwork.) On my days off, in between family obligations and studying for the pharmacy technician exam, I try to work on LibreHealth-related assignments.

I am currently working on improving current and creating new documentation for the LibreHealth EHR project. Around the time I joined, there was a major software update to the LibreHealth EHR software. Most of my assignments so far have been to read through current docs regarding specific LibreHealth EHR functions, while testing these functions within the software to report any discrepancies or bugs. I have also been assigned to transcribe an instructional video regarding some of LibreHealth’s functionality, then turning it into a tutorial following the current documentation style.

While working on these assignments, I have learned that documentation is a continuous project. As software changes, documentation must also change. Although I enjoy working on documentation, my goal is to contribute code in addition to documentation. I cannot wait to see what I gain from this experience and hope to contribute as much as I can to this project!

Until next time.

When people ask me why I spend time on working on an open source project, the first thing that comes to my mind is the feeling of being accepted and doing something meaningful.

I can’t tell you that I have had the worst experience being a career-switcher woman without an engineering degree in IT, but I often feel hostility and I have an imposter syndrome. I’m not sure if this is a cultural phenomenon or such things happen everywhere but I didn’t receive much (if any) encouragement from my colleagues and managers in the IT company where I used to work. I was depressed and wanted to leave my job (which I finally did).

I understood that I lacked experience to work independently as a freelancer. I started to look for an open source project where I could improve my skills. I found Outreachy and the application period for the summer had just started. I found a project connected with healthcare, because medicine is my primary degree, and started contributing.

The first thing that I noticed when I started to contribute was that people treated me differently than at the company where I used to work. They thanked me for every effort even when it was fixing a typo in the docs and encouraged to continue.

I also got help and encouragement when I made mistakes. Once I enabled mirroring the main project repository to my forked repository, made a commit and a pull request, and got a message from the mentor a couple of hours later that my commit was empty. Now I know that enabling automatic mirroring can wipe off all your changes and I won’t use it without a reason. I switched it off and pushed my changes from a local repo to the remote again and re-submitted PR. I got positive feedback and my changes were merged. It was great that no one scolded me or told that I’m doing something stupid. Instead, I learned a new thing and made a contribution.

I think that it’s usually fine to make mistakes when you are learning (unless you are deleting a production database with your client’s financial information without making a backup) and it’s great when others understand it and help to improve.

I find work environment in the office to be more demanding and pushing you towards business goals while open-source communities are more product-and people-oriented. Most of the work is done by volunteers and everyone understands that time and skills should be recompensed so as nothing is paid, they are recompensed with gratitude and acknowledgment. This approach totally suits me.

It was a great (and deserved) chance that I was accepted to the Outreachy internship with LibreHealth. I don’t have to go to the office because there is a scholarship that is enough for living. I can increase my skills and prepare to work on my own if I won’t have much desire to go to office. I’m at the beginning of this wonderful three-months long program and I’m looking forward to new skills, networking and contributions to the great project.

My advice for anyone who is thinking whether to try contributing is:

Don’t be afraid and go on!

The community bonding period just came to an end, it’s been filled with lots of reading and QA sessions.
With aim of having clarification of my task and knowing where to begin, my mentor went through the radiology modules to help me address queries about the workflow.

A lot of reading from past GSoc radiology module development blogs was done to get an in depth understanding on what has been accomplished. Also read from OpenMrs since the original radiology module was forked from there. I looked for any writing that will explain the components of the radiology department, the processes, roles and functions of resources. The following references will be helpful to find your way to the understanding of the buildup and reporting workflow of the radiology module:
– Terms, User roles, user stories
http://teleivo.github.io/docs-openmrs-module-radiology/#_requirements
– Gsoc 2017 final report
https://ivange94blog.wordpress.com/2017/08/27/gsoc-2017-final-report/
– Creating a Radiology Report using MRRT Report template LibreHealth Radiology
https://ivange94blog.wordpress.com/2017/08/21/creating-a-radiology-report-using-mrrt-report-template- librehealth-radiology/
– User stories
https://librehealth.gitbooks.io/radiology-user-stories/content/
– Dicom Basics
https://saravanansubramanian.com/creatingdicomfile/
– Video on standard radiology workflow
https://www.youtube.com/watch?v=czApoO5N9K8&feature=youtu.be

To Do

Having done all those findings, this will be my objective throughout the summer:
– Implement the start of the reporting process such that after clicking the ‘claim study’ button:
Allows the user to select a template
Dictate report; integration of voice dictation
– Once a study is completed(report) it should fall off the dictation list
– User can view report by clicking on patient
– Incorporating ACR assist modules for decision support
All these objectives will have sub tasks, which will be arrange in a google doc with an updated
timeline or use the trello boards if permitted. The sub tasks will be modified as I progress.

You may like to know

Faced some errors while trying to run the Lh-radiology-owa
The error message seemed to prove that my angularcli version was higher than the project’s. So I had to downgrade. After searching online, these commands were used to uninstall and install a lower version of angular(angular 4).

npm uninstall -g @angular/cli # If angular version is 5 or greater
npm uninstall -g @angular-cli # If angula version is lower than 5
npm cache verify #if npm version is < 5 then use npm cache clean
npm npm install -g @angular/cli@1.4.9

These link will help address issues on angular versions
-Upgrade/uninstall install instructions
https://www.npmjs.com/package/@angular/cli

NB: It is advised that all packages should be installed locally. This makes sure you can have dozens of applications in your computer, all running a different version of each package if needed. Updating a global package would make all your projects use the new release, and as you can imagine this might cause nightmares in terms of maintenance as some packages might break compatibility with further dependencies, and so on. All projects have their own local version of a package, even if this might appear like a waste of resources, it’s minimal compared to the possible negative consequences.

Being new to Angular and Javascript, I will be following angular tutorials these few days to help me get around the radiology UI and implement or modify different functionalities. This week will be very demanding and I will have to exhaust every bit of my productivity techniques to accomplish these tasks in time. May the force be with me!

Before the coding period starts. Requirements analysis and design is really important. So I have been working on the design of the components that I am going to build. I am advised to look for FHIR components that are of Maturity level 3 or 4. In the latest FHIR version 4.0. A lot of new components were added in the resource list. But almost all of them are of Maturity level 0 (draft). I cant really use them right now.

Before going for the new components. Let’s look at the current state of the project. As I am continuing the project from last year. We don’t want to repeat any components / resources.

Current State

Last year. A lot of work was done. 2 students worked on the project. Around 38 components were created. Which covered the following resources:

Resources:

• Patient
• Organisation
• AllergyIntolerance
• Location
• Practitioner

All the components are made in Polymer 3. And testing was performed using web-component-tester.

Currently all the components are placed in the packages directory. I think it might be a good idea to refactor the structure of the directory making sub directories for each resource and a separate directory for the general purpose components. I think that would be make things easier manage as the list of components grows.

Let’s look at the structure of current component. For example lets take the

human-name component:

Imports:

At the top we have our imports. First is the compulsory LitElement, html import which we will use to create the component. Then there is material text-field. Material design was chosen for the elements. So that all the elements have consistent styling. After that as the human name resource has a period. So we are importing the period component which is built separately. At the last we have iron-ajax. It is used for sending and parsing ajax calls. It is used for testing the components here. We will get back to iron-ajax in a bit.

import {LitElement, html} from '@polymer/lit-element/lit-element.js';
import '@material/mwc-textfield/mwc-textfield.js';
import '@lh-toolkit/fhir-period/fhir-period.js';
import '@polymer/iron-ajax/iron-ajax.js';

State:

Now here we define the state of our components. Similar to how we have props in react and inputs in angular. We also have our state / properties in polymer. The useField is actually used to display or hide the component.

static get properties() {
        return {
            /**useField is a selectable option for use of name. Use this property to show/hide. Default: true */
            useField: String,
            /**suffixField is show suffix. Use this property to show/hide. Default: true */
            suffixField: String,
            /**prefixField is used to show prefix. Use this property to show/hide. Default: true */
            prefixField: String,
            /**fName is to show first name of a person. Use this property to show/hide. Default: true */
            fName: String,
            /**lName is to show last name of a person. Use this property to show/hide. Default: true */
            lName: String,
            /**mName is to show mName name of a person. Use this property to show/hide. Default: false */
            mName: String,
            /**periodField is to have start and end dates. Use this property to show/hide. Default: false */
            periodField: String,
            /**url is used to make AJAX call to FHIR resource. Default: null */
            url: String,
            /**value is used to take the input value of each field*/
            value: Array
        }
    }

Constructor:

As we know constructor is called as soon as the component is instantiated. So here we are just setting the default values of our state.

constructor() {
        super();
        this.useField = 'true';
        this.suffixField = 'true';
        this.prefixField = 'true';
        this.fName = 'true';
        this.mName = 'false';
        this.lName = 'true';
        this.periodField = 'false';
        this.value = [{given:[]}];
    }

_didRender:

Similar to the ngAfterInit in angular. And I believe its componentDidMount in react. The didRender is lifeCycle hook in polymer. It executes when the components has completed rendered. In here we are using it for the iron-ajax response. Adding an event listener to it. So that when the ajax request is made. We set the value of our form / state to that of the response. This way we can test the component that it has the correct value.

_didRender() {
        this.shadowRoot.getElementById('ajax').addEventListener('iron-ajax-response', function (e) {
            var humanName = this.parentNode.host;
            if(e.detail.response.name !== undefined) {
                humanName.value = e.detail.response.name;
            }
            else {
                this.parentNode.removeChild(this.parentNode.querySelector('#humanNameDiv'));
            }
        });
    }

_Render:

This is the fun part. Here we render our html. In react we render JSX. But in polymer. Similar to angular. We have html templates in which we can use string interpolation. Also it supports 2 way data binding. So our state and the template is connected. Here we are just creating the form. And binding the value of the form fields to that of our state.

_render({useField, suffixField, fName, mName, lName, periodField, url, prefixField, value}) {
        if (typeof(value) == "string") {
            this.value = JSON.parse(value);
        }
        return html`${this.value.map((i, index) => html`
   <div id="humanNameDiv">
   <label>Name:</label>
   ${useField !== 'false' ? html`
     <label>Use:</label>
     <select class="useField" value="${i.use}" on-change="${e => this.value[index].use = e.target.value}">
         <option value="usual">Usual</option>
         <option value="official">Official</option>
         <option value="temp">Temporary</option>
         <option value="nickname">Nickname</option>
         <option value="anonymous">Anonymous</option>
         <option value="old">Old</option>
         <option value="maiden">Maiden</option>
     </select>` : ''}
     ${prefixField !== 'false' ? html`<mwc-textfield outlined class="prefixField" value="${i.prefix}" on-input="${e => this.value[index].prefix = e.target._input.value}" id="prefix" label="Prefix"></mwc-textfield>` : ''}
     ${fName !== 'false' ? html`<mwc-textfield outlined class="fName" value="${mName !== 'false' ? i.given[0]:i.given}" on-input="${(e) => mName !== 'false' ? this.value[index].given[0] = e.target._input.value:this.value[index].given = e.target._input.value}" label="First Name:"></mwc-textfield>` : ''}
     ${mName !== 'false' ? html`<mwc-textfield outlined class="mName" value="${i.given[1]}" on-input="${e => this.value[index].given[1]= e.target._input.value}" label="Middle Name:"></mwc-textfield>` : ''}
     ${lName !== 'false' ? html`<mwc-textfield outlined class="lName" value="${i.family}" on-input="${e => this.value[index].family = e.target._input.value}" label="Last Name:"></mwc-textfield>` : ''}
     ${periodField !== 'false' ? html`<fhir-period class="periodField"></fhir-period>` : ''}
     ${suffixField !== 'false' ? html`<mwc-textfield outlined class="suffixField" value="${i.suffix}" on-input="${e => this.value[index].suffix = e.target._input.value}" label="Suffix"></mwc-textfield>` : ''}
     </div>
     <iron-ajax id="ajax" bubbles auto handle-as="json" url="${url}"></iron-ajax>
    `)}`;
    }

And that’s pretty much it. We have our component. We combine all the components like these to make a full resource.

Going forward

Now its my turn. There are quite a few level 3 and 4 resources that I can work on. Following is the list of components with wire frames that I will be working on.

• Appointment
• Condition
• Diagnostic Report

Resource Wireframes:

Components:

The above resource will be composed of several components. Following is the list of components that I will be building.

I have a few questions regarding some codeable concepts. As some of them have a lot of codes. Like 1000+ codes for components. How will we manage that on the front-end. I will be discussing that soon on the forum.

All in all. I am really excited for the coding period. I will try my best to complete all these in time. Wish me luck

The post Getting ready for coding period. appeared first on Muhammad Kamran .

It’s been a wonderful experience so far. It seems rather frightful than surprising how much i have learned these weeks. Ten hours a day have been dedicated for this project, making it seventy hours a week. It will seem much, but i have ninety-eight hours to do my other stuff, so all is well.
In attempt to answer the question “what to do“, communication with mentors have to take place so that i refine my original project proposal to reflect the exact task to be done and in more detail, giving out clear milestones and deadlines. This process prompted me to:
– Read past chats under related topics,
– Read past Gsocers blogs to have a more detailed idea on what they had worked on,
– Ran modules, and other openWeb Apps to see what has been implemented and what hasn’t.
All these was with aim of coming out with a more chronological arrangement of my tasks
to be done (detail workflow). I’ll be preparing a new wireframe based on the new openWeb app that was built for radiology.

Faced many little huddles, but learned a lot form them..
Faced the nvm EACCES: permission denied error when i ran an nvm install in a polymer project directory. I did this with aim of understanding the concept of web components.
That error was caused by the original approach i used to install npm. I highly recommend that NodeJs and nvm package manager should be installed using a node version manager and not the traditional sudo install command. These links could help one rectify that problem.
Documentation
Give permission

Also encountered a Problem with dial: dial tcp: lookup mysql on 127.0.0.11:53: no such host. Sleeping 1 error when running my toolkit/radiology containers. Tried many solutions; restarting mysql, killed processes on ports… but only succeeded running my container after i refreshed my docker system(removing and re-downloading the image/container/volume) using commands:
docker container stop $(docker container ls -a -q) #Stopping all docker containers
docker container prune # Remove all stopped containers
docker volume prune # Remove all unused volumes
docker image prune # Remove unused images
or just docker system prune --all --force --volumes for all the above
as learned from this post and many other little issues.

Now i see how essential it is to document errors for one may face it again, and it’ll be then easier to tackle. One of my previous internship mentors made the statement, “Not all knowledge has been documented” i shall continue to do blogs aimed at reducing the accuracy of that statement.

Just an image I like

Generally i have had a good grasp of:

• How to search for error solutions and filter solutions on online forums,
• Learned more of git branching using the book git pro especially with commands “merge” and “rebase” (a separate blog post will be done on git’s merging and “rebasing” commands and it’s use cases),
• Learned more about the docker engine and now know many commands off the top of my head,
• Learned more about the polymer and web component concept.

Many people have the wrong notion of Gsoc, the google summer of code is all about the wonderful experience of learning; software development, collaboration, communication with aim of gaining insight of the OpenSource, It surpasses just being there to code and get payed. The experience is an integral part of it. If not, organisations will simply get professional developers to do their projects for them in a shorter range of time. Reason why i am grateful for this opportunity and i plan to let it not go to waste.
The feeling is exhilarating, and there will be some additional satisfaction having this project accomplished under my watch.
I look forward to the challenges of next week.

So its the 2nd week of our Google Summer of Code journey. And I have been learning about polymer and thinking about how should I approach the project.

Exploring Polymer

Polymer seems fun to work with. Just like any other JavaScript framwork that we are used to we have components based architecture. Like Angular, React or Vue. But whats really cool about web components is that they can be used with any framework. Like if I have made components with Polymer. I could import them into my react app or an Angular application. That’s cool right. There are other options to create web components of course, Like Angular Elements. But for this project we will be sticking with Polymer.js Polymer has a pretty similar structure to Angular components. So I kinda feel right at home.

import { LitElement, html, property, customElement } from 'lit-element';

@customElement('simple-greeting')
export class SimpleGreeting extends LitElement {
  @property() name = 'World';

  render() {
    return html`<p>Hello, ${this.name}!</p>`;
  }
}

<simple-greeting name="Everyone"></simple-greeting>

• All we have to do is just import LitElement.
• add the custom element decorator to our class which extends from LitElement.
• Then with the property decorator we can take input values like we do in Angular.
• And file instead of the html template separately. We just call the render method. Similar to React. But we don’t need to JSX here. Just good old html will work. 

Refactoring for better organization

A lot of work has been done in the previous GSoC project. As this year is the extension of the same project. I think its time to refactor the structure of components so that they are better maintainable. The current state is like this:

All the components are at the same directory level. With the resource name following by the component. This might get cluttered when we add a lot of resources with multiple components. I think we can improve the structure by created a separate directory for each resource and adding the components for that in their. And if there are components that are reused in multiple resources we can add them in the data types directory. Like this:

• Project
  • DataTypes
    • code
  • Patient
    • active
    • human-name
  • Invoice
    • status

I will discuss with the mentors and see what they think about this.

Refining Proposal

I am also working on creating new wireframes for the components that I will be building. The proposal can be improved. I really need to add some more wireframes. I will be starting with the invoice resource added in the FHIR v4.0. I included this in the project proposal. I will be creating more wireframes similar to this one in the coming days.

The post FHIR and Polymer web components deep dive. appeared first on Muhammad Kamran .

It felt good, it did. A feeling one can’t fake after experiencing a breakthrough after quite some investment; time, money, brain power, healthy spine… All that was felt internally, it would’ve been tough to tell from looking at me. What may betray me are my eyelids, they’d appear narrowly opened, like when savouring a bite-size piece of sugar cane in the dry season knowing it’s a delicacy.

My successes this period was highly influenced by an internship i took part in during the summer holidays of 2018. Did a two months internship with Gr8di where i got to learn a lot about back-end development with groovy(Grails framework) but the knowledge cuts across most JVM technologies. I gained and honed many skills, had a clearer career path and my confidence boosted. I owe them a huge gratitude, for Kraulain and Jenn Strater were the roots of my success in groovy; (Groot). *Bad pun, Roy *. A series of posts will be created based on my experiences at Gr8di.

After receiving a text that read ‘Congratulations Roy…’ I was happy, not excited, there is a clear distinction of both meanings, but most people blatantly refuse to see it. I believe that if i expressed joy by uttering phrases like “Yes, I did it ! ” , a keen someone will be able to see through that thin layer of faut excitement, the phrase “Oh shit! I have a lot on my plate now”. This reaction is not surprising as i’m doing seven university courses this semester with two being project design related courses. With all this I’d have to exhaust all my techniques of productivity, making good use of the Pomodoro technique, through the pormodoro timer and the collaboration tool; Trello.

I’ll dedicate ten hours a day on week days, twelve on weekends for my Gsoc project (Yes it’s much) and six hours for school work. Ten hours on the project is not too much, i may be productive only for four hours within the ten hours and will do other related issues within the remaining time.

I was told to celebrate, i did, but many won’t agree. Watched an episode of
Shingeki no Kyojin (Attack on titans) season 3 part 2 and the latest episode of One Punch man. Had a glass of ‘tole’ tea and rewarded myself with seven hours of sleep. What could beat that?

The chosen google summer of code student participants have been announced and i’m in! 

 

It’s been 2 days since the declaration of Gsoc 2019 selected students. I was accepted into the program under Librehealth open source organization to work on the project Incorporate radiology workflow into radiology  which could be also be referred to, on the Gsoc site, piloted by mentors Judy Gichoya and Ivange Larry Ndumbe.

I could tell i’m excited, there’s this soothing feeling like a whirling pool right beneath my sternum that occasionally scrubs against the spine and gives nothing but satisfaction. It’s tough ignoring this frequent palpitations though. Knowing the task ahead, i guess the palpitations are caused by that speck of fear one feels when taking on a new and demanding journey. I’ll need it, i will. Not too much to cause stress or distort my thought process, neither too little to make me take things for granted, but just enough to keep me focused and disciplined.  Nevertheless, it’s thrilling getting out of your comfort zone to explore new ventures. 

This project encompasses the implementation of the Draft and approval workflow (with respect to radiology user stories) and other functionalities which will be highlighted after discussion with mentors during this bonding period to be incorporated into the radiology module. This will entail that I study the code base of several past Gsoc participants under the following topics:

• Implementing reporting workflow for radiology
• Radiology reporting enhancement

A new work timeline with updated milestones will be created on google Docs by the end of the community bonding period to clearly highlight my goals, milestones and respective deadlines throughout the summer. I’ll also be doing weekly posts on my activities, experiences and accomplishments. 

---

How I Discovered Outreachy

My Name is Ngai Elizabeth Asobi, and here is my story  of how I first discovered and started contributing to Free and Open Source Software through LibreHealth EHR as an Outreachy intern.

I was a final year Computer Engineering student specializing in Telecommunications  at the University of Buea, Cameroon when a friend told me about Outreachy. She wanted me to help her with a challenge she encountered during her online Nanodegree program at Udacity. She told me that she had a lot on her hands because of another program she was committed to online called Outreach and advised me to also apply since I am equally good at coding. This was Outreachy December 2018 to March 2019 round. 

I googled Outreachy and there it was! I was motivated by what I saw on the homepage. I am going to work on a real life project with a mentor, in a community that did not really care about your background or sex. It was a great idea to sit at home and get paid writing code as a girl and still feel appreciated.  I started my initial application process and got the link of the projects one week to the deadline. I got so excited by the number of projects I saw, became confused about which to choose until the round closed without me recording any contributions to any of the projects I chose. I learnt two things the hard way:

1. Start your applications early
2. Narrow your projects to one or two

I patiently waited 3 months, for the next round to be announced. This time I knew exactly what I wanted. I looked through filtered the project list to one project with the following criteria:

• I possess over 80% of the required skills
• My current lap top hardware specification meets the requirements
• Details on how to start is well understood
• Project chat forum is welcoming
• Above all, I have a passion for the organisations vision.

All this search finally brought me to LibreHealth’s project Improve code and Documentation for LibreHealth EHR.

---

 My First Open Source Organisation ( https://librehealth.io/ )

Where Did Motivation come from?

I had a personal connection with LibreHealth because it focused on improving healthcare using technology. This is something I was already working on in a team in my local community and so, I was curious. I wanted to find out what was different about their solution, how they walked around issues we had faced before and above all, how they approached their solution. 

In The Beginning….

Mentors had a challenge for all the applying interns which kept us focused. There were so many interns applying to this organisation and almost every day we had a new intern. I loved that everything was so transparent, you could easily track your progress. 

In the beginning, I was not the best. I had to try to be consistent in my contributions, chatting with my mentors and getting feedback on my work until I had a good standing in the community.

Tough Times Threw Me Back! 

My journey was not smooth though I remembered a time I almost closed my computer and gave up!  But what could have gone wrong? Competition became tough, I fell sick, I faced electricity cuts. By the time I got back to LibreHealth, I could not recognize the chat forum I left. There were new tough interns. One had created the most issues on GitHub, had the most pull requests lined up. While trying to catch on, there was a day I sent 5 contributions I had been working on to my mentor but all were rejected. I felt I was no longer welcomed or needed. I almost cried. That day I closed my computer and told myself it was over. I tried to sleep and forget. Could I even sleep? I could not accept this defeat! It was so painful. I loved programming a lot and so I focused on that and also on building a relationship with my mentor and other community members, helping out new interns settle down. In fact, I wanted to be “me”. I knew when my mentor would come online the next day and so I made sure I had other contributions to submit. This time everything was accepted! I mean everything! My scores were slowly increasing. My mentor was really grateful and provided helpful feedback every time. I started to feel good again. I forgot about the tough guys, focused on giving my best and by the time I realized it, I was the best in terms of scoring. 

My Reward.

Internship application process ended. I had a lot of fun and experience working with my mentors and other community members and so I thought to continue contributing anyway. I waited anxiously for more than a month for the results to be out. It was not easy waiting knowing that all interns did some great work but not knowing what mentors were actually looking for in their chosen intern. On the 6th of May 4 p.m UTC, I was constantly refreshing my browser to see this result. I got to find out I was chosen! So I guess they found what they were looking for in “me” after all.

What the future holds for you.

I am so excited to continue this journey with my community. I look forward to building great stuffs with my mentors. I encourage everyone who is thinking of applying to do just that and focus on what they have to offer,  work closely with your mentor, ask and wait patiently for feedback and taking corrections as they come, love what you do and be grateful!

Hello! I’m Olena and I’m going to blog about my internship with LibreHealth during the next three months.

If you haven’t been following my Outreachy journey, you can read all about it here.

I’m on my last day as an Outreachy intern, thus this is my last blog post. I want to take this opportunity to talk about everything that I have gained from this experience, and why I think it’s an amazing opportunity if you’re getting started in tech.

First, regardless of whether you choose a documentation project or a coding project, this will serve as your first experience in tech, particularly working remotely with a team, which is extremely valuable experience. Potential employers are truly impressed when I discuss my Outreachy experience, and I believe that it makes a big difference if you’re just getting started, to have a remote internship in your CV.

Secondly, it is a paid internship, which is extremely important. Not everyone can afford to do an unpaid internship. This leads to less diversity in tech, since usually underrepresented minorities are financially underprivileged, and this is what makes Outreachy so essential: it provides a paid opportunity for people who aren’t privileged enough to do unpaid internships.

It allowed me to take time to focus solely on contributing to Open Source. If I had been doing an unpaid internship, it would have meant working 60-80 hours per week in order to have my first experience in tech.

Regarding learning new skills, this is something that will definitely happen regardless of which project you choose. In my case, I worked using my existing skills in writing and translating, but I gained extremely valuable skills in technical writing specifically, and working in a remote team. It also helped me boost my confidence that I can carry my work to completion, and that my work is valuable.

Last but not least, I met amazing people during my internship, from the mentors to all the collaborators and other applicants. It was an extremely valuable experience and I know that I will definitely keep in touch with many of them, particularly my mentor, Toni, who was one big reason why my experience was so fantastic.

In conclusion, if you’re eligible, do not miss your chance to apply. You will gain valuable experience even from the application process itself even if you’re not selected. If you are, prepare to work hard, have fun and learn tons in the process!

Introduction

If you haven’t read my previous posts – Hi! I’m Virginia and I’m a documentation Intern for LibreHealth EHR. I got this internship through Outreachy, an amazing organization which provides 3-month paid internships to people from underrepresented minorities all around the world. You can read about how I got this amazing opportunity here, and the struggles I’ve faced though my adaptation period here. My last blog post was about what I’ve learned so far during my internship, and this week I’m going to discuss a somewhat related topic and that is expectations.

In my opinion, this is applicable to every project you work on with other people, or even on your own if the project is too complex or has too many variables. That doesn’t mean you should set high expectations for yourself, but prepare for the possibility that you will not accomplish all your goals in an orderly manner. Things can happen, for instance, other people might get stuck with their work and your work is dependent on theirs. For this, it is important to keep a flexible mindset and switch to other tasks so you’re not idle or feel like you’re wasting your time.

The timeline

At the beginning of my internship, I worked together with my wonderful mentors Toni and Harley to create a list of goals that we wanted to accomplish throughout these three months. The initial timeline we submitted to Outreachy was this:

“Improve existing documentation and create missing documentation in English, Spanish and possibly German if time allows.
Continue working with the LibreHealth EHR documentation to include the individual tutorials and the EHR activities such as Adding a new Patient, Working with the Calendar and Flowboard, The Patient Portal Registration Process, Using the EHR Prescription module, and Creating a Patient Encounter from beginning to end. Create the Administrator User Manual in English, Spanish and possibly German if time allows.”

I remember being particularly worried about the German part of it, because I am still not fluent in German. When I applied, I translated only one short guide to German and it took me about a week to finish it. Also, I needed to bug my German friends to help me proofread and correct them.

With regards to the rest of the tasks, I didn’t really know what to expect since I wasn’t aware of how many of these docs already existed and how many I would have to create from scratch.

Thankfully, my mentor Toni was extremely reassuring so I didn’t get too anxious or overwhelmed about not being able to complete all the tasks. And I have to say, so far I’m very happy with the results, all things considered.

Accomplishments

I have mainly been working on the Administrator docs, since I had already translated the User guide and other user-oriented docs during my application. I have written and translated new docs, and improved and translated existing docs. So far, I have only been working in English and Spanish, so I am still worried about the German translations, but I am still happy with my progress.

I am also working on fixing the translations of the labels in the app, which was a big problem in my opinion and it will finally be fixed. I am very happy about this.

I feel satisfied that I am meeting the goals we set at the beginning of the internship, and a lot of that has to do precisely with being flexible: I have encountered some technical issues that have forced me to leave some projects hanging and refocus on another task.

Challenges

The reason why we have had to refocus on different tasks and maybe not reaching all the goals we had set at the beginning is that some of the Admin docs are taking longer than expected. The main reason is that the stable demo app was taken down right before starting the internship, and when a non-stable version of it was put back up, a portion of the functionality that I have to document was broken, and therefore I cannot go through the workflow until one of the devs fixes it.

I have learned to live with this, since it is completely out of my control, and employ my time in other tasks. This sadly means that a big part of my work is unfinished, but at least the next intern will have something to work upon.

I feel that all in all I would do the same if I started over. I have a problem sitting still and being idle, so reevaluating expectations and goals is something I routinely do in my everyday life.

New goals

This sometimes leads to great things. For example, while waiting for something to be fixed I was looking for something to do, and I came across the contribution guidelines for the project. These guidelines were published some time ago and need improvement. They also contain a link to a Style Guide that does not exist, which is something I think documentation interns would greatly benefit from. I discussed it with my mentor and she agreed, so one of our new, unexpected goals is to at least outline the style guide, and hopefully write it and publish it.

One of my main goals for the second half of the internship, besides the style guide, is to finish the Admin docs and at least outline the Admin User Guide.

Conclusion

It’s unrealistic to believe that a timeline can be followed to a T, but that does not mean you shouldn’t set specific goals for yourself. The timeline has served as a roadmap, and although the progress hasn’t been exactly what I expected, it has still been great.

In my case, the reasons for modifying expectations have been varied: having to learn workflows and pick up new skills or improve existing ones, technical difficulties, external circumstances. Regardless of why sometimes we have to change our expectations, the most important thing is to be flexible and adapt to changes as quickly as possible in order to stay productive.

Introduction

If you haven’t read my previous posts – Hi! I’m Virginia and I’m a documentation Intern for LibreHealth EHR. I got this internship through Outreachy, an amazing organization which provides 3-month paid internships to people from underrepresented minorities all around the world. You can read about how I got this amazing opportunity here, and the struggles I’ve faced though my adaptation period here.

Now that the adaptation period is pretty much over, I’ve been enjoying being more productive and having a lot of fun in the process. I am excited about what I’m doing right now and even more excited about the plans we have for the next few weeks.

One of the reasons I chose this project was that it is a documentation project. I felt that I didn’t have enough technical knowledge to contribute to a development project, and I felt excited about this one in particular for several reasons:

1. It directly benefits people: good documentation can make a world of difference for a user
2. It allows me to combine my passion for technology with my teaching background
3. It also allows me to use my language skills, since one of my main goals is to make the docs multilingual

So this week’s post is for anyone thinking of applying for LibreHealth EHR next round, and also for anyone writing any kind of documentation.

What is LibreHealth EHR?

LibreHealth is a collaborative community for free & open source software organization where several different health information technology projects collaborate. LibreHealth EHR is one of those projects.

EHR stands for Electronic Health Record. An electronic health record is essentially a collection of information about patients that is digitally stored. This makes information easy to share between different healthcare facilities and organizations. The information includes medical history, allergies, medications, demographics, tests results, and vaccination information, among other things.

The LibreHealth EHR application is a “clinically-focused” EHR which aims to be easy to use and customizable for a variety of health care settings. It is designed to cater for two main groups of users: staff members, such as front office staff and doctors. Likewise, LibreHealth EHR has two main types of documentation for these two categories of users: User Guides, and Admin Docs.

Why is documentation important?

According to the Health Care Information and Systems Management Society, adoption rates of electronic health records are remarkably slow compared to adoption of similar technologies by other industries. The reasons they cited for this are initial costs and decreased productivity during the implementation stage, but they also mentioned the quality and usability of the software. This makes documentation especially important: since the EHR will be used by people who don’t have a background in technology, they need documentation to be clear and easy to follow. This is the most important thing to keep in mind while writing User Guides.

This means:

• Clear instructions split into steps: only combine short steps into one bullet point. If you cannot cover the visual part of the explanation with one screenshot only, you need a separate step.
• Helpful screenshots: Use highlights, circles, rectangles, or any highlighting technique you prefer, to draw the reader’s attention to the section of the screen where they will be performing tasks.
• Good references: if you have a more detailed explanation of something somewhere else, direct your reader towards it instead of leaving them to the task of browsing the whole site.

Admin docs are pretty similar to User Guides in that the final user is someone who doesn’t have a background in IT. However they do have administrative permissions, which means they are in charge of certain tasks that other staff do not have to deal with. This usually has to do with permissions, changing configurations, adding or removing users (staff members who are allowed to use the app), and related tasks. So their use of the app is a bit more involved.

The style of the documentation is the same though, and should be the same for every documentation anyone ever writes: don’t assume any prior knowledge and always give reference to concepts you don’t know for a fact the reader is familiar with, be clear and concise, and offer helpful visual aid, which saves the user a lot of time.

Conclusion

Writing good documentation is not easy, but it is extremely important and should not be neglected. We must not assume that users will “figure it out”. It is a really good exercise in empathy and communication skills. My teaching background has certainly helped a lot. Translating also has its own set of challenges, but I will leave that for another post.

If this post got you excited about documentation, and you’d like to contribute to LibreHealth EHR, stop by the LibreHealth Forums, and consider applying for the next round of Outreachy!

 

I’ve been an Outreachy documentation intern for LibreHealth almost a full month now (you can read about how I got the internship here) and I have been enjoying it greatly. That doesn’t mean that it has been all smooth and easy.

When I got the email from Outreachy on this week’s topic, I couldn’t believe how relatable it was. It’s like they were reading my mind. I was struggling for sure, with different aspects of my work. But struggles are the best learning experiences.

The adaptation period

The first few days were hard. I felt lost and useless, I didn’t know what to do and I was struggling to understand what was asked of me because I wasn’t familiarized with many things about the project.

This is totally normal. The key is asking a bunch of questions. If there aren’t any mentors around, make a note and ask later. Ask for clarification anytime you’re unsure about something.

And ask for help if there’s something you feel is beyond your current skill set: this is what will help you learn and grow.

Unforeseen circumstances

During the application process, we were working with a stable demo. After the internship application period ended, they took the stable demo down. The bleeding edge has all the functionality but it looked ugly, so Toni, my mentor, and I spent a couple days trying to make it prettier.

After that, I had finished writing new docs in English so we decided I could start translating some docs that were not translated yet. So when I logged in into the Spanish version I found that many tags were mistranslated, not translated at all, and some were even in Greek!

This is a big problem when it comes to taking screenshots for the docs.

My mentor and I started trying to get help to fix it, but we couldn’t get ahold of the people in charge of localization, and the Holidays were coming up so a lot of people weren’t working. So I was officially stuck!

Don’t bang yourself again the wall: find a hole in it

After a few frustrating days trying to fix the labels myself without success, I decided on an alternative plan: I can do text-only translations for a while, and then put in the screenshots once the labels were fixed.

My thought was: instead of focusing on what I CAN’T do, why don’t I try to see what I CAN do? That thought changed my entire perspective on the situation.

After that, I was able to be productive again, and once my creative juices were flowing I realized that some of the docs could be finished after all, screenshots and all. Not all the labels were off, and for some of the docs I was translating, all the labels were perfectly translated!

The takeaway

If you’re stuck, it’s okay! It happens to everybody. Don’t beat yourself up and try some of the following strategies. These are the ones that worked for me, but if you have any other techniques to get unstuck that work for you, please share them in the comments!

• Ask questions and clarifications as often as you need it. There aren’t stupid questions. Make notes so you don’t forget to ask something that you’re unsure about.
• Get creative: if you can’t continue on one track, find an alternative path that will work for now. This way you do something productive with your time instead of being idle and demotivated.

Once you get started getting yourself unstuck, you will notice that things start flowing. Remember that nothing ever runs perfectly smoothly, and the bumps on the road are the ones that will help you deal with obstacles in a better way in the future.

The beginning

I heard about Outreachy while doing the 1millionwomentotech Summer Of Code program. It’s an all-women coding program, and we have a Discord channel where we talk to each other, share experiences, help each other with homework, and so on. We were discussing internships and someone suggested Outreachy. I was immediately interested so I rushed to the site and read everything about it. I decided I would apply.

I liked Outreachy because first, I loved the fact that it is aimed at “anyone who faces under-representation, systemic bias, or discrimination in the technology industry”. I am excited about making technology a more diverse industry which includes people from all walks of life and allows them to make a valuable contribution. Also, it’s a paid internship. As many of you may know, not all of us can afford to take time off work and work in an unpaid internship, so it is nice that they take lower income people who still need to pay the bills into account.

The application process

Before you actually apply for a project, you have a period where you have to choose a project (they recommend one or two, but I personally couldn’t commit to more than one) and start contributing. I chose LibreHealth because it fits my skill set: my background is in languages, and they needed to make their documentation multilingual. So it was the perfect project for me.

This is important: choose a project that suits your current skill set. You will, of course, learn tons anyway, but make sure you don’t have to learn a whole new language or skill from scratch because the contribution period will be tough for you.

I started very early on, which I think helped me a lot. I had already made several contributions before other people had even arrived. I got very excited about documentation, which is something we rarely think about but we all depend on. I had only paid attention to documentation before when I had to use a library with really bad docs, but beyond that, we tend to dismiss it or take it for granted, where in reality it takes work to produce quality documentation. A LOT of work.

We were allowed three revisions per draft, and I generally could submit a final version after 1-2 revisions by the mentors. It is important to ask all the questions you need before starting to work on something, and during the feedback process, so you will be more efficient and will be able to deliver faster, which will result in more contributions.

Then about 10 days into the contribution period, a lot of people stated showing up, and a lot were working super hard and delivering tons of work! Before that, I was very confident that I had a good chance of getting the internship, but then I started to think “Ok, now I might actually not get it!”. On top of that, life happened and I had to slow down a bit, so I was contributing a bit less and other people still kept a great pace.

So slowly I started to assume it wouldn’t happen. I was okay with it, I just planned to enjoy the rest of the contribution process and take it as an experience in itself. When the actual applications opened, I carefully submitted mine a couple of days before the deadline, as I always get super nervous around deadlines and forms, and I just kept submitting my unfinished work and enjoying the process. By then I was sure I wouldn’t get it. I started planning other things to keep myself from getting really disappointed and sad.

The announcement

When I got the email announcement saying I got the internship, my heart skipped a beat. I couldn’t believe it, I was 99% certain I wouldn’t get it! I immediately got in touch with the mentors and started planning what to do. Then I took a few days off and on December 4^th I started working as a Documentation Intern for LibreHealth. My mentors are awesome and the work is fun, and I hope we are able to achieve every goal for the project during this term.

If you are interested in applying

• Start early: you will have a chance to make more and better contributions
• Make sure your application is ready with ample time before the deadline
• Ask questions: about everything – the application process, the work you have to do, the feedback. Having a clear picture of what is expected of you will help you produce quality work.
• Get excited about your work: this way putting in the hours will be easier. Some time it is hard to stop!

Final words

If you’re eligible for Outreachy and find a project that excites you, don’t hesitate to apply. You will learn a lot from the application process itself and you have nothing to lose.

We had a seminar in our University about GSoC. And it seemed like a really good opportunity to learn and contribute to the open source community.

So I recently applied for Google Summer of Code internship. After searching and going through quite a few projects to work on. I stumbled upon LibreHealth. As I was going through their forums and projects. I really liked the community and the type of work they were doing. Also I found a project related to FHIR and web components.

My final year project was also related to FHIR and web. So that was a perfect fit. I knew I had to apply for it. Robby O’Connor was really helpful through out the period of project selection and helped me work on my proposal.

On 6 May the accepted students were announced and I was so happy that my name was in it. I am really looking forward to working on this project. I am assigned 2 mentors. Saptarshi Purkayastha & Ivange Larry. I hope I can learn a lot from them and work under their guidance in completing the project.

The post Google Summer of Code! appeared first on Muhammad Kamran .