It's intended for our people in the implementation department, not the customer. They need to be able to map fields in our software to a field or fields in the HL7 message. However, it is often not a simple one-to-one relationship. Quite often we need to go through multiple conditionals, string operations, comparisons, etc. in order to determine how the data is mapped.I'm still confused, who is this gui intended for and how does it help compared to programming in ANY scripting language?
That's my fear is that we'll constantly have to update the tool to accommodate some special condition at site X. One thing I learned is that we have no spine. Management consistently folds to a client's demands.Also they only added a bunch of features after people requested them, so you had to update it like everytime you loaded it.
Hey, I worked with an Allscripts analyst once. If remember correctly, they did pretty much the same type of work as we. Do you know what they use/used for mapping HL7 data?I worked at Allscripts a while back and they were big on offshoring whatever they could.
This is not going to work. It never does. I work in the healthcare industry in Middleware and my job is to do what this "software" is supposed to so that the business teams don't have to. Giving non-technical people "easy to use technical tools" never, ever works. Especially not with something as convoluted as HL7. I'm assuming they want this because of how HL7 v2 works. It's a guideline more than a spec and every hospital, doctor's office, etc that sends HL7 messages puts different information in different segments and sub sections. So they want an "easy" tool to map it to the correct field in your internal system. It ain't gonna work man. It just ain't gonna work.It's intended for our people in the implementation department, not the customer. They need to be able to map fields in our software to a field or fields in the HL7 message. However, it is often not a simple one-to-one relationship. Quite often we need to go through multiple conditionals, string operations, comparisons, etc. in order to determine how the data is mapped.
Again, currently we are using Visual Basic scripts to perform this logic. Easy. The company now wants to provide a GUI-based tool for our people to do this sort of work. Not easy. At least, not easy in the respect that they want this GUI tool to be "nearly" as flexible as what they now do in VB.
I don't know what they have against using some sort of other scripting language that's framework-agnostic. It feels like they do not like the idea of our "grunt" employees having to write code.
Yeah, you're preaching to the choir, brother. Problem is, I'm the only dev on the team that has actually worked with this stuff. The others are clueless and are just designing based on the requirements given by the even more clueless product owners.This is not going to work. It never does. I work in the healthcare industry in Middleware and my job is to do what this "software" is supposed to so that the business teams don't have to. Giving non-technical people "easy to use technical tools" never, ever works.
That's every company I've ever worked for. The business people tend to think software is magic and anything is both possible, and simple.These people here man. All these experimental requirements, requirements that are up in the air, no real priority on the tasks, asking me to add stuff that has no right being in the code. I am losing my mind, slowly.
Adderall. You are next to MIT... this shouldn't be hard.Anyone got tips on staying focused at work? At Emc it was easier, I was the lead on the firmware for one of our server designs as well as some other tasks and meetings. Felt pretty important. Here I'm just starting out. When I hit the build button and it takes 20 minutes I find it easy to load up reddit or rerolled.
I tried a chrome extension before that would lock me out, but found myself disabling it.
Is it normal to build then browse the web?
Don't do it!So, after some thinking, I'm going to propose we construct our own scripting language. It sounds like a daunting task, but quite honestly the language does not have to be that complicated. All the guys do, typically, are check for values in some HL7 field or fields, then assign a string value or do some kind string manipulation (concat, substring, whatever).
Instead of having to build this incredibly complicated GUI with drop-downs and shit, we can simply have one UI control: a textbox. One of the problems with the current Visual Basic implementation is that they have this huge monolithic script that performs assignments to all the mapped fields. My idea is to break it out so that each mappable field has it's own mini-script that works against the HL7 message. I think this will be far more manageable. Additionally, the language isn't platform specific so it can be easily ported to some future framework.
Also, I found a great book on compilers and interpreters:Writing Compilers and Interpreters: A Software Engineering Approach.
It actually includes a full Pascal interpreter/compiler written in Java. I'm thinking/hoping it will pretty effortless to convert this to .NET and change the language to something dumb.
Way to spend my Christmas break....
I totally agree that making our own isn't a great idea. But I can hear the bitching and moaning right now if I suggest Javascript, Python, or anything else that doesn't originate from our loins. A few months ago we wanted to implement a more thorough logging system (just for diagnostics) in our application. Instead of writing our own I suggested Log4net (.NET port of the popular Apache Log4J framework). They recoiled in horror at the mere thought of that.Don't do it!
We automated a thing earlier this year by creating a javascript API that would support very basic routines. It was pretty successful. I'd recommend using an existing scripting language and not try making your own.
Making your own will add a lot of development cost, will be buggier in weird, annoying ways and will be much harder to extend later.