What's a standard supposed to look like? What does it tell you?
These aren't as simple as you think:
Consider the following different kinds of "standards"
All of these are standards.
ASTM recognizes six types of standards: test method, specification, classification, practice, guide, and terminology.
NIST recognizes a somewhat different set, one of which they describe as process, but you won't be able to use this link since the US government shutdown last year.
I even have my own classification.
HL7 publishes functional specification (see 2 and 3 above), protocol specifications (like #4, but see MLLP which is essentially the HTTP of Version 2), schemas and specifications (very much like HTML 5), and other things. Some of them they call standards, others they call informative documents, but many use these interchangeably. Some call them specifications, others implementation guides, and others profiles.
Some standards describe best practices, models of systems, or provide for ways to talk about things. Others talk about bits and bytes (or octets). That's what you were probably thinking about.
There's really nothing magic about describing what a standard is. It's an way to do something that some group has agreed to follow. The something part is VERY nebulous. The some group part is very nebulous. The enforcement mechanism of the agreement is very nebulous. In some cases, even a standard itself is very nebulous.
The biggest distinction between what a standard is and isn't has to do with who agreed to it. Portable Document Format wasn't a standard until it was. The difference had to do with who agreed to it. In the first case, it was a single company. In the second, it was an international standards committee.
This was the "de facto" (in fact) standard for C, until is was supplanted by an earlier version of this as the "de jure" (in law/jurisdiction) standard.
People like standards because it means they don't have to think hard, just smart. And that's why "who" made it a standard is very important. Sometimes, even when everyone agrees, it seems that nobody agrees on what the standard is (see HTML5, or perhaps you want HTML5) [but at least they agree on what it does].
I read standards like this (a very architectural cookbook), and like this (A pretty decent functional standard with some pretension of being an API as well, but with some notable deficiencies in that latter part that I hope will be corrected in the standards making process), and like this (a vaguely useful thing if you like your standards regurgitated into another publication format with a lot of reused content), and like this (something important, but possibly blown away by this, we'll see what happens when it shows up).
And yes, it's ballot season at HL7, just in case you were wondering. How do I feel about that? In a word: Nebulous.
In a thousand words:
Keith
These aren't as simple as you think:
Consider the following different kinds of "standards"
- A standard for light bulb bases.
- A collection of functional requirements that CAN be applied to a particular type software.
- A collection of functional requirements that HAVE been applied to a particular type of software.
- A protocol specification such as HTTP.
- The specification for a markup language.
- The specification for a specific implementation of a markup language (or perhaps this is it).
- A standard for a programming language.
- A standard for performing a particular test.
- A standard for performing a particular task.
All of these are standards.
ASTM recognizes six types of standards: test method, specification, classification, practice, guide, and terminology.
NIST recognizes a somewhat different set, one of which they describe as process, but you won't be able to use this link since the US government shutdown last year.
I even have my own classification.
HL7 publishes functional specification (see 2 and 3 above), protocol specifications (like #4, but see MLLP which is essentially the HTTP of Version 2), schemas and specifications (very much like HTML 5), and other things. Some of them they call standards, others they call informative documents, but many use these interchangeably. Some call them specifications, others implementation guides, and others profiles.
Some standards describe best practices, models of systems, or provide for ways to talk about things. Others talk about bits and bytes (or octets). That's what you were probably thinking about.
There's really nothing magic about describing what a standard is. It's an way to do something that some group has agreed to follow. The something part is VERY nebulous. The some group part is very nebulous. The enforcement mechanism of the agreement is very nebulous. In some cases, even a standard itself is very nebulous.
The biggest distinction between what a standard is and isn't has to do with who agreed to it. Portable Document Format wasn't a standard until it was. The difference had to do with who agreed to it. In the first case, it was a single company. In the second, it was an international standards committee.
This was the "de facto" (in fact) standard for C, until is was supplanted by an earlier version of this as the "de jure" (in law/jurisdiction) standard.
People like standards because it means they don't have to think hard, just smart. And that's why "who" made it a standard is very important. Sometimes, even when everyone agrees, it seems that nobody agrees on what the standard is (see HTML5, or perhaps you want HTML5) [but at least they agree on what it does].
I read standards like this (a very architectural cookbook), and like this (A pretty decent functional standard with some pretension of being an API as well, but with some notable deficiencies in that latter part that I hope will be corrected in the standards making process), and like this (a vaguely useful thing if you like your standards regurgitated into another publication format with a lot of reused content), and like this (something important, but possibly blown away by this, we'll see what happens when it shows up).
And yes, it's ballot season at HL7, just in case you were wondering. How do I feel about that? In a word: Nebulous.
In a thousand words:
Keith
HL7 is the most nebulous version of a standard that exists - particularly given the fluidity with which different institutions employ different segments within a specific message type. APIs remain the best examples of standards we have today and are in place within every technology company across the world. We are really good at defining new standards, but healthcare has unfortunately been unsuccessful at finding one that scales to span the industry. Hoping for some changes in 2019 :)
ReplyDelete