Going live...

Closing to production such fun

Actually it is, I'm writing this as I'm waiting on a few data service packages to run the follow it up with some key load scripts to bring our system to life.  Database hovering  between 3rd and 4th normal form.  Table driven architecture for the app and a rich logic layer that can support a multitude of sub applications.  We've put in a continual delivery pipeline with frequent updates.  It is really exciting when a plan comes together.  I'm sure the great team at Daverci is tired of me saying that.  Now on to the rest of the story...

Step one, convert the database from SQL 2012 to SQL Azure v12. 

For the last four years, the Daverci requirements squad was defining requirements, discussing date which ultimately I translated into the physical and logical layer of the system

Step two,  line up the application to consume the database in a stateless manner. 

The application has to run on many devices.  You could possibly run ours on a Kindle...but while it MIGHT run, I'd recommend at least a Chrome Book.  Come on guys, gals, you are going to want a keyboard with this application.  The system architecture supports a stateless architecture based on a structured object model.  Only minor changes were needed to the core product delivered by ESN to push the application to Azure.

Step three, convert the serial requirements gathering to customer driven requirements. 

Our classic application had an excellent work flow approach to care management.  That was a prime requirement I needed to make sure we achieved while support the new and future requirements of our system.  I know pretty bold, future requirements...but, build a very sound and strict data layer to support a rich object layer you end up with a design that cleanly supports adding new elements without disturbing the base layer.  Nor is the application layer impacted since the physical layer is cleanly extracted from the logical layer.   Include in the design, table driven application design(support) for the expandable areas.  This is the area that will impact future features the most.  While the underlying architecture supports expanding all the leaf (property) values in the application, expanding types requires an application update but not a database update.  The data base design is built around flexibility in the changing areas of healthcare.  When adding a feature to a system, the most costly impact is a database change.  To minimize this impact, a strategic set of mapping tables (link datasets) to bridge and complete the objects for the logical layer is included in the design.  Sorry, "I love it when a plan comes together".  Had to say it... :)

Step four close the project

I am glad I spent time as a consultant.  Consultants have to close projects and close them well.  I always tried to ensure I conveyed two things at the close of a project.  Post customer acceptance of course...was the model clear and maintainable.  This is true for closing any project internal or external.

Closing:

See closing

Sales or real estate the term still applies to projects.  In my humble opinion, closing is often over looked in software development projects.  Why?  I think it is because a high population of developers never experience the "whole" project.  Sure, they are very good at creating this or that but they are only part of the project wheel and may not see the whole scope.  Like a real estate home closing, a project is charged with emotion, contra-objectives, and generally a whole host of "inspections" that have to pass before the deal is closed.  We are in the closing stage and like any closing it takes time.  We are targeting to have all our inspections done (customer sign off) by July 25th.  Then, it's time to spin it all up.

In the end...Summary

Four years in the making.  Hey, solid healthcare management takes some serious requirements gathering.  On the one hand, it's the Government and it moves at a glacial pace compared to software.  However, Government wants detailed analytics on various dimensions.  I am confident that we've hit a high portion.  The "History" structure of our system is ready for cubing and analytics.  All data is locked and written once.  Once written, the state is recorded in time.  Even if the "state" is corrected to the correct value, both entries and time stamp are captured.

Azure hosted, two factor authentication, full script 10.6 and hl7 interfaces (bi-directional).

<Azure Update>

The system database deployed fine.  Loading external data from NPPES (NPI information) is still not working quiet as hoped.  Switching to an ODATA solution is probably in order.  Full drug compendium load.  So now it is time to start the base data load for the system.  Ok, that took no time...now on to the base system load...now the fun...load the default system data...somewhat of a challenge due to the highly inforced referential integrity.  Everything has to load in object order.  Side note: Kittens in general start behaving badly when they are being ignored.  My youngest kitten, Hemingway, who is now the size of a large house cat with two years to grow, is most insistent.  Well, he will just have to wait.  Yes, getting the stink eye but...it's fortunate, due to the highly constrained structure, the load scripts can be re-run until all data is filled.  I know this sounds a bit off but, initially the system was build focused on bare metal.  While this is still supported, adjusting to what was available on the Azure platform required a change in the deployment approach.  It boiled down to a three step process:

1. Deploy the database blank
2. Push out the external data through data factories
3. Load the core application data
4. Deploy the application to Azure
5. Test Application

It is nice to have a clear deployment strategy and a basically turnkey system.  Granted, NPPES SCRIPT 10.6 and HL7 take time to coordinate with various systems.  This all depend on how fully they have implemented 10.6 and HL7.  We have implemented the full standard specification for both pipelines.  So...

We built our application on Rock and Roll

All things must come to a close, so we are on the clock.  Marching to production.  This is my favorite part of any project.  Bringing it to life.  We've got a great team and we've built a great product with a lot of future growth.  I started with a picture of a large gap between tested items and resolved items.  With a target release of July 25th, this is the type of testing picture I want to see now.  Full push on the application, full fix to make release.  See, plan...coming together...it's good.  Well, the rest of my data is moving into the system...  if you would like to play in the new application, I'm looking for beta users.

Here is the link to the application. This is a link into the beta system and will remain active until 07-25-2016.  After the terminal date, all beta customers who elect to continue will be placed on a priority conversion list:

Davderci's Healthcare Management System. 

Reply to this post to request access.  My friends and connections, I encourage your participation and providing rich critique to make sure this system is the best that it can be.

In the end, I love it when a project is on the path to completion.  System architects get to build products.  Some work, some don't and some follow the plan.  Ok, little excited here.  Four years of work coming together.  :)