Wonder how many times you heard this as an answer to a specific question by an expert of the matter. Scratched your head about what it means and question their authority. Yes?And it is true in many respects too given the choices we have around our technologies. That is a good thing, right? Well, guess what... it depends...
Recently I have been tasked with creating a technical specification document for a given application module. I delivered the document knowing what I know at the time and tried to avoid Big Design Up Front (BDUF) anti-pattern. I have to admit there are quite a few holes in my document but my goal is to fill up them as I find more about the requirements and increase my understanding of the application. So far we have is a few screens of wire-frames, an initial functional specification document. The business analysts are hard at work in peeling those requirements and creating/modifying the functional specifications. It's all good in the end as long as we have a grasp on the amount of the documentation. And, yes, we are using an agile methodology and have daily scrum meetings and two week Sprints. We are staying focused.
Including myself, the team is very new to this company. What are some of the challenges? Well, lack of requirements one might say, but I am yet to be on a project where this isn't the case. The second that you think you nailed down the requirements, guess what happens. It changes! Head First Object Oriented Analysis and Design book had a good chapter for this, “You're perfect. Now change!” Exactly. So I am not too hung on this. Just get me enough to start coding...
There is some worry about the business process, and lack of decisions. We are also going to use an off-shore team as well to do some of the development and testing. I expect to be working closely with this team at some level. I have a few questions and concerns with that, but I will bring it as it moves forward. Keeping development cycles short, feed-back loops tight and close. Wire-frame developers griped a little about not seeing the whole picture, but sometimes you don't need to.
As far as technologies go, I am all about .NET development which is our platform. This is a web-based application with multiple tiers, heavy emphasis on separation of concerns, testable, decoupled layers. There will be WCF services used by the business tier as well as third parties. I am pushing ahead with ASP.NET MVC framework with business objects (logic) in the middle, and ADO.NET Entity Framework in the data access layer. We are going to use Test Driven Development, writing our tests first, thinking “unit testing”. I realize that TDD is not unit-testing, but I am already spreading the words/ideas about the functionalities to test. I really believe this will help us increasing our code-coverage numbers as well as CCHIT requirements fulfilled. My goal is when some one asks me how this works, I could just run a few unit/integration tests and show that they meet the requirements. Yes, got to have tests... there is no other way around that!
Meantime I plan to write quite a few throw-away proof of concept code to aid the actual coding. I plan to address the cross-cutting concerns, exception management, authorization, authentication, logging, caching (defer it until I have more hands on with application), encryption and security.
Our database is SQL Server with some interfaces to legacy DB2 databases, We do have an aggressive time-line, as with most development teams. We are definitely going to be busy. Well, if you are going to ask me how is it going? You will know my answer...
Happy Coding!
Wednesday, May 27, 2009
Wednesday, April 8, 2009
Introduction to HL7
As part of my new role and job, I am getting up-to-speed with health care information systems. A few backs during our TechMasters' meeting, I spoke briefly about HL7, but could not find enough material to summarize what it is. As I researched more, I found more material. So what is HL7?
HL7 stands for Health Level Seven(7). Why is seven? Accordingly the network protocol, if you have ever studied computer networks, the OSI (Open System Interconnection) model is typically conceived with seven layers. The seventh layer correlates to the application layer. Hence the HL7 focuses on the issues occur at the seventh layer.
The standard deals with interfaces between systems that send/receive patient admissions/registrations, admission, discharge or transfer (ADT) data, queries, resource and patient scheduling, orders, results, and clinical observations, billing, master file update information, medical records, scheduling, patient referral and patient care. It's an effort to let disparate applications and data architectures in heterogeneous system environments operate and communicate with each other.
A typical hospital today have its own (proprietary, from a specific vendor) computer systems for admission, discharge and transfer, billing and accounts receivable applications. These systems may have been designed in a centralized or a distributed architecture. Overtime, these applications are re-written or patched to meet current computing needs. Remember Windows 95? The security model which was perceived then is not what we use today. Now think Windows Vista's security model. If you put this in terms of health information systems, you will see a similar progression. However, often the application development cycles are not well-defined, lots of patching and updating have to occur. Having many vendors with their own protocols and applications, there raises a big need for interoperability.
A framework is needed to minimize incompatibility and maximize information exchange between systems. HL7 is deemed as a superstructure in this environment to facilitate a common specification and specifications methodology.
So far, there has been three versions of HL7. The first version was created in 1987 and subsequently the second version came out in 1988, but version 2 had a few revisions. HL7 version 3 came later (time frame?), and it's XML based. I plan to blog more about HL7 versions separately later on.
To summarize HL7 and what it tries to accomplish, here are some bullet points:
After the initial posting of this blog, I have been followed by "HL7-Tools", and it was mentioned that a link to their resources can be added. Certainly. Here is another resource for learning and practicing HL7 Tools, Utilities and Resources. Thanks for following.
HL7 stands for Health Level Seven(7). Why is seven? Accordingly the network protocol, if you have ever studied computer networks, the OSI (Open System Interconnection) model is typically conceived with seven layers. The seventh layer correlates to the application layer. Hence the HL7 focuses on the issues occur at the seventh layer.
The standard deals with interfaces between systems that send/receive patient admissions/registrations, admission, discharge or transfer (ADT) data, queries, resource and patient scheduling, orders, results, and clinical observations, billing, master file update information, medical records, scheduling, patient referral and patient care. It's an effort to let disparate applications and data architectures in heterogeneous system environments operate and communicate with each other.
A typical hospital today have its own (proprietary, from a specific vendor) computer systems for admission, discharge and transfer, billing and accounts receivable applications. These systems may have been designed in a centralized or a distributed architecture. Overtime, these applications are re-written or patched to meet current computing needs. Remember Windows 95? The security model which was perceived then is not what we use today. Now think Windows Vista's security model. If you put this in terms of health information systems, you will see a similar progression. However, often the application development cycles are not well-defined, lots of patching and updating have to occur. Having many vendors with their own protocols and applications, there raises a big need for interoperability.
A framework is needed to minimize incompatibility and maximize information exchange between systems. HL7 is deemed as a superstructure in this environment to facilitate a common specification and specifications methodology.
So far, there has been three versions of HL7. The first version was created in 1987 and subsequently the second version came out in 1988, but version 2 had a few revisions. HL7 version 3 came later (time frame?), and it's XML based. I plan to blog more about HL7 versions separately later on.
To summarize HL7 and what it tries to accomplish, here are some bullet points:
- HL7 is not a "complete solution", rather it provides a common framework for implementing interfaces between disparate vendors
- Protection of Health care information
- Roles and relationships, such as patients, physicians, providers.
- Accountability, audit trails
- Uniform data definition and data architecture
- Integration of health record
- Interface engines
- Rules engines
After the initial posting of this blog, I have been followed by "HL7-Tools", and it was mentioned that a link to their resources can be added. Certainly. Here is another resource for learning and practicing HL7 Tools, Utilities and Resources. Thanks for following.
Monday, March 23, 2009
Remember... it all starts small
Recently I have been working on a Windows client VB.NET project. With my client, we took some time to re-design the solution, project files and created layers to handle certain tasks, decoupled interfaces. I took charge of creating a simple database to support configuration and automatic/batch processing of certain tasks.
I opted to use Linq-to-SQL, but still have a separate business layer, and data access objects to talk to the UI. I still favor this approach. It is going slow, but working nicely.
Now couple of sticking points... first of all, I did underestimate the time to integrate the database/business object layer to the existing UI. This is a very small project, at least on my side, don't have any software specification. Made the database model after looking at the existing XML files. Used a Linq-to-Sql Dbml file to generate the model in the code, implemented CRUD's with TDD. Created a test harness, and that good stuff...
The biggest problem is lack of time and testing the UI. Since I took over an existing UI, it wasn't all clear what each button would do, what the states are, where is it going to be stored and such.
Looking a week or so back, what I should have done prior to giving an estimate was put down the UI as I see it, map out the functionality and give a more granular & accurate estimates on how long each task takes. You know you can always write a piece of functionality pretty quickly. But to test it, integrate with the other components of the project, take time and need to be refactored.
And communication is also key. My client is also pressed in time and resources and is running into issues with code integration. We are having a few problems and I am trying to help out as much as I could. Last week not being available for a quick call and not getting feedback threw me off and it was hard to get back to it after that.
On top of it, I got busier with my main task, finding another full time position. At the end of February, the consulting company I have been with laid me off along with a few other consultants due to economic downturn and lack of projects. Fortunately, I was offered a full time position last Thursday and expecting to start full time next week. This is obviously good news and sigh of relief in this economy. I would like to thank all my friends and family during this transition. Their support and friendship really made it happen and gave me focus.
Meantime, I really appreciate the fact that I have a side project to work on and yet stayed (staying) busy, however need to do a better job with giving work estimates. And remember it all starts small...
I opted to use Linq-to-SQL, but still have a separate business layer, and data access objects to talk to the UI. I still favor this approach. It is going slow, but working nicely.
Now couple of sticking points... first of all, I did underestimate the time to integrate the database/business object layer to the existing UI. This is a very small project, at least on my side, don't have any software specification. Made the database model after looking at the existing XML files. Used a Linq-to-Sql Dbml file to generate the model in the code, implemented CRUD's with TDD. Created a test harness, and that good stuff...
The biggest problem is lack of time and testing the UI. Since I took over an existing UI, it wasn't all clear what each button would do, what the states are, where is it going to be stored and such.
Looking a week or so back, what I should have done prior to giving an estimate was put down the UI as I see it, map out the functionality and give a more granular & accurate estimates on how long each task takes. You know you can always write a piece of functionality pretty quickly. But to test it, integrate with the other components of the project, take time and need to be refactored.
And communication is also key. My client is also pressed in time and resources and is running into issues with code integration. We are having a few problems and I am trying to help out as much as I could. Last week not being available for a quick call and not getting feedback threw me off and it was hard to get back to it after that.
On top of it, I got busier with my main task, finding another full time position. At the end of February, the consulting company I have been with laid me off along with a few other consultants due to economic downturn and lack of projects. Fortunately, I was offered a full time position last Thursday and expecting to start full time next week. This is obviously good news and sigh of relief in this economy. I would like to thank all my friends and family during this transition. Their support and friendship really made it happen and gave me focus.
Meantime, I really appreciate the fact that I have a side project to work on and yet stayed (staying) busy, however need to do a better job with giving work estimates. And remember it all starts small...
Friday, February 13, 2009
putting it altogether
In the last few days, I have been diving into a variety of .NET technologies. This should be no surprise to anyone in this industry if one wishes to stay current and employed. Especially in this economy. So there it goes...
Well, I started dabbling with Silverlight 2.0. Creating XAML pages, simple Silver application which is available once you install the Silverlight 2.o SDK. The place to start is Learn Silverlight. Creating circles and elipses, buttons, stackpanels and grids on usercontrol is cool, but does not help my business. So after reading a few chapters in one certain book and watching a few videos from the official site, I have decided to give it a go.
As it turns out, Silverlight was just the prelude and wetted my appetite to dig deeper. Since I am data oriented, I started creating a SQL Server database in SQL Server express. Created a four-table data model which I will provide details later, but I just want to summarize the work I have done as of this Friday afternoon.
With the database in place, created a Data Access Layer project in Visual Studio, using C# (.NET framework 3.5). According to the feedback and posts I have read, I felt inclined to use Entity Framework. As you may know, Entity Framework is available in Visual Studio 2008 SP1. Setting this object/file up in Visual Studio is pretty easy, but I have ran into a few snags in my data model, especially with the associations. And my version of Visual Studio does not open the modeller at first, but there is a trick which I found out. If I open and close the file with the XML editor, the modeller becomes available.
With the model in place, I wrote data object classes to enable basic CRUD operations. I made sure I created a separate test project/class to run my unit, I mean integrity tests. After the model checked out fine, I moved on the next stage.
Next was creating a WCF service which exposes the above data object. I created separate classes and host the service on the local IIS (running on XP, so IIS is 5.1). Have to remind myself of certain WCF command line utils.
Then I created a WCF client to test the service I hosted on IIS. Used the "svcutil" utility to create a proxy class and included the app.config file. My client was a simple console application, don't include the service client. So far so good.
Then early this afternoon, I watched another video for consuming WCF services using Silverlight. There were a few things I have to do and I have a few gripes about why certain things are done that way, but again will talk about that later. Oh, have I mentioned I am using ASP.NET MVC as my web.host project. So hooking up separate XAML pages (or) I should, was fun.
I have really worked on each individual component separately and just an hour ago, I was able to put it altogether. I got it working. And of course, there is a lot more work. I will update this post as I find time. Thanks for reading.
Well, I started dabbling with Silverlight 2.0. Creating XAML pages, simple Silver application which is available once you install the Silverlight 2.o SDK. The place to start is Learn Silverlight. Creating circles and elipses, buttons, stackpanels and grids on usercontrol is cool, but does not help my business. So after reading a few chapters in one certain book and watching a few videos from the official site, I have decided to give it a go.
As it turns out, Silverlight was just the prelude and wetted my appetite to dig deeper. Since I am data oriented, I started creating a SQL Server database in SQL Server express. Created a four-table data model which I will provide details later, but I just want to summarize the work I have done as of this Friday afternoon.
With the database in place, created a Data Access Layer project in Visual Studio, using C# (.NET framework 3.5). According to the feedback and posts I have read, I felt inclined to use Entity Framework. As you may know, Entity Framework is available in Visual Studio 2008 SP1. Setting this object/file up in Visual Studio is pretty easy, but I have ran into a few snags in my data model, especially with the associations. And my version of Visual Studio does not open the modeller at first, but there is a trick which I found out. If I open and close the file with the XML editor, the modeller becomes available.
With the model in place, I wrote data object classes to enable basic CRUD operations. I made sure I created a separate test project/class to run my unit, I mean integrity tests. After the model checked out fine, I moved on the next stage.
Next was creating a WCF service which exposes the above data object. I created separate classes and host the service on the local IIS (running on XP, so IIS is 5.1). Have to remind myself of certain WCF command line utils.
Then I created a WCF client to test the service I hosted on IIS. Used the "svcutil" utility to create a proxy class and included the app.config file. My client was a simple console application, don't include the service client. So far so good.
Then early this afternoon, I watched another video for consuming WCF services using Silverlight. There were a few things I have to do and I have a few gripes about why certain things are done that way, but again will talk about that later. Oh, have I mentioned I am using ASP.NET MVC as my web.host project. So hooking up separate XAML pages (or
I have really worked on each individual component separately and just an hour ago, I was able to put it altogether. I got it working. And of course, there is a lot more work. I will update this post as I find time. Thanks for reading.
Subscribe to:
Posts (Atom)