This is what I would like to see in HL7 v.Next. This entry I hope serves to be launch pad for other entries. I have spent a great deal of time thinking over the following guideline in the HL7 standards, which are not followed in the BTAHL7 accelerator.
Ignore segments, fields, components, subcomponents, and extra repetitions of a field that are present but were not expected.
Let's take a look at the current situation. You have all of these fields that are defined in the schema as required, and they are at various levels in the schema.
Here there is a obviously wrong implementation of the standard. If I don't care about this, why is this element required, and why might it have to match a pattern and possibly have an enumeration that it needs to match against?
What I would like to do is four things initially:
- When I start up a new project where I am going to need to create a new trigger message for a data source, I don't want to have to hack into the schemas to change the target namespace for the base schemas (datatypes, segments, and tablevalues). Why can't there be a way from within the schema to define a party that this message is defined to, and it have it derive a new definition off of the base schemas for that party? In the BTAHL7 Configuration explorer, it will automatically make the targetnamespace coincide with the party name. Something that looks like this:
which would automatically change the Target Namespace to this when I choose the Partner URI in the schema
- I would like to open up the schema and be able to do a 'Select All' and then with the CTRL button go and de-select the fields I care about, and with the right click make all of the fields optional and override the data type to ST or TX with no enumeration or patterns.
- I would like to be able to see the enumeration lists for the base schemas even though I am looking at an inherited schema. When I click on PID 2.5.0 in the ORM^O01 schema, because it has imported that definition, I don't see the enumeration. I have to go and open up the tablevalues schema and search thru it to change those values to have to recompile and redeploy. Why can't I first see the values and second override the existing values with values I know are going to come in, sometimes less, sometimes more values.
- The last thing is that every segment, sub element should have the optional Trailer to consume additional data that might be there:
It should be pretty easy to accomplish, shouldn't it?
This is just something that I thought of this week while at MS-HUG. I do not doubt that there are many issues with my theory, but those three things would make implementing HL7 with BizTalk SO MUCH easier and bring Microsoft's HL7 component much closer to the standard.
Send me an email thru my contacts page if you have more ideas.
posted @ Thursday, September 27, 2007 12:00 PM