Standards This is a guide about standards, with links to standard development organizations and other important standards resources. What is a standard? They: provide a common language to measure and evaluate performance, make interoperability of components made by different companies possible, and protect consumers by ensuring safety, durability, and market equity. Why do we have standards? Why are standards important? Watch: International Standards Organization's What Standards Do For You Explore: American National Standards Institute's Why Standards Matter This course is designed as a basic introduction to standards for management and technical personnel in business, industry association management, government, and public policy; university faculty and students; engineers, quality control and purchasing staff; consumers; and those new to organizations that develop standards.
Some view monetary systems developed for the exchange of goods as the earliest standards. A language is a standard for communication. A technical standard is an established norm or requirement for a repeatable technical task.
It is usually a formal document that establishes uniform engineering or technical criteria, methods, processes, and practices. Standards contain technical specifications or other precise criteria designed to be used consistently as a rule, guideline, or definition. They help to make life simpler and increase the reliability and the effectiveness of many of the goods and services we use.
On the basis of these two factors, it is possible to classify standards as ideal, normal, basic, current or expected actual standards. Message protocols specify the form of the information that is exchanged but not exactly how the programs actually do the exchange.
A standard form is necessary so that each program knows how to interpret the information. There are many standard message protocols, but HL7 is different in several ways. First, it is not a general standard; it only applies to healthcare data. Also, it defines a form for the data that is human-readable — that is, you or I can look at the data stream and understand it for the most part.
Finally, it is very flexible. It needs to be because the data it deals with is not uniform. For example, not every name or address is 64 characters long, and the programs need enough information to differentiate between similar or identical names, addresses, etc. HL7 defines messages in 13 areas such as Patient Administration, Scheduling, Financial Management and Observations diagnosis and treatment. This sounds easy, but it takes real work to get the two systems connected appropriately, often even when they are supplied by the same vendor.
There are currently five versions of the message protocol, three versions of the context architecture and, unless you write your own HL7 system, you need to rely on a vendor to supply you with a system that allows you to use some subset of the HL7 standards.
Each vendor leaves out certain parts of the data required or optional fields , structures the messages slightly differently, etc. You, your vendor or your consultant has to do a lot of programming to make this work.
Actually, HL7 is one of the better sets of standards in the healthcare area; but like others, it requires a lot of work to provide even minimal data interoperability. OK, enough alphabet soup — the point is there are many standards relevant to healthcare. Most are specialized to provide a certain type of interoperability and not all need to be addressed at once. You and your vendors can deal with those standards most relevant to what you are trying to accomplish, and not the whole universe of standards.
0コメント