1 Time is money. Idle time is opportunity cost. Innovation is how tech-focused organizations stay relevant. Innovation, done right, takes time. GOTO 1This infinite loop lives rent-free in my head. As the sometimes leader of a merry band of technical consultants, I am eternally aware of the customer-facing work we do that keeps the lights on. I am also keenly aware that the industry is constantly evolving with new standards, regulations, and technologies: FHIR, TEFCA, AI, more cloud services, new QHINs....
The drive to innovate is not merely a bid to meet market demand. Our team is a mix of careered tech gurus and fresh-faced developers who are excited by the opportunity to build something new. I want to keep their brains well-oiled and happy.
But how does an organization that is not a software product company, employing implementors who are typically allocated full-time to client work, with limited resources and budget actually have the time to INNOVATE?
Recently all the pieces came together in a mini-project that highlighted how we manage Innovations at LEAD North. We have a lot of factors to juggle between client commitments, resource allocation, and timing. In this case, everything came together when we learned of the InterSystems Developers Tool Contest 2024.
Nathan Holt, one of our implementers with front-end development skills was assigned to a client project that was experiencing delays. I had written a set of testing utilities for our team to work with C-CDA integrations. There would be many more of these in the future and with increased demand for C-CDA to FHIR integrations, we would need better visualization and implementation tools to support our team and customers.
Why write up this process, with all our missteps and hacker sins? - Because we are trying to solve more than one problem here.
We had worked with multiple solutions found on the InterSystems Open Exchange (which is a great resource, BTW) and were familiar with some of the solution templates. When I saw that the contest was opening in the next week, it created the perfect time-bounded opportunity. I pulled up that wish list item and put the project on our JIRA board for the next two-week sprint.
The Process:
With a tight two-week timeline:
I designed a front-end in Figma.
Cloned the iris-rest-api-template repository and adapted our XSL testing utilities into an API.
Had our first development meeting where Nathan showed me something that looked like this. Maybe it wasn't exactly like this, but it's about what I remember:
I side-eye Nathan for a long time during which he assured me that this is just how UI development starts with layout and functionality and then you can do styling and CSS later....
I tell Nathan I trust him. We set the next goal posts, and go back to our tasks.
Over the next week, I configure Docker with IRIS for Health and set it up with the right context for XSLT mappings. Nathan codes the front-end. We hook up the API calls. We struggle through CORS.
I suggest serving the application from Apache since IRIS runs on Apache. Nathan Googles, he researches, he makes a build. It kind of almost runs as a web application from IRIS, but not really. I swear I've done this before. We spend precious hours finagling with things. We debate. Nathan explains how Next.js works. We change course.
More #!@# CORS.
In the final days, the front-end looked like this:
The APIs all come together. Integration tests all work.
We start documenting, cleaning, and packaging up the repo for public consumption. We realize what hackers we truly are when there's a lot of cleanup to be done.
I try to set up ZPM package deployment for the learning experience and brownie points. Realize that the multi-container solution we decided on introduces challenges for that.
Published to the open exchange. Write an article. Record a demo video.
Received a few issues from the community. Fixed them. Learned a few more things about open exchange standards.
Debriefed the experience with Nathan and then wrote this blog.
Why write up this process, with all our missteps and hacker sins?
Because we are trying to solve more than one problem here. As much as I've wanted to build a useful tool, this endeavor, our short-term mini-project, also illustrates how LEAD North is innovating as a small company without a substantial R&D budget. The secret sauce is this:
We have to pick our projects wisely. They have to align with the work we're doing, the work we will be doing in the future, and the work our customers are looking for. Our projects must have the potential to create opportunities for the company.
We have to target solutions to gain maximum value for a limited time investment. We identified a need and a pain point and tried to address it with a tool that will help implementors in their daily tasks. We picked a solution that we could accomplish in two weeks.
We must serve LEAD North's training goals. To build our company, we have to develop our people. To do this, learning is a must, for everyone.
We strive to create opportunities for mentoring and collaboration. This includes opportunities for more fresh-faced developers to work with senior developers.
We intentionally incorporate diversity of thought and experience. Creativity means bringing in new blood, new skills, and new ideas. Our dev team (of 2, in this case) experienced what it means to engage people with different backgrounds. We had obstacles and disagreements, but the working sessions were productive and led to a solution that worked and that we both learned from.
We recognize our team members as individuals with unique abilities and valuable experiences. As long as they keep the lines of communication open, I trust my team's instincts and their judgment. Even when they disagree with me -- especially if they disagree with me. It doesn't matter if they have twenty years of professional experience, or ten, or two.
We make mistakes and we learn from them. When the first issues came in from the Community, I told Nathan - this is what we're here for. To be held to a higher standard. To put ourselves out there and learn.
When people hear about innovation in technology, they are thinking of clever tools and whizbang applications. AI and slick devices. At LEAD North, our definition is broader than that. Our product is in the solutions we provide, but our product is truly in how we develop our people.
About the iris-ccd-devtools project:
I'm often asked why are C-CDA integrations so time-consuming which I blogged about previously. Though some of the challenges are unavoidable, the learning curve can certainly be lowered.
The CCD DevTools Application version 1.0 is available on the Open Exchange. Try it out and let us know what you'd like to see added. It's also an entry in the InterSystems Developers Tool Contest 2024 should you be looking to cast a vote. Deadline for voting is Sunday, September 29, 2024.
Comments