What should be the standards (for example, medical data)
Briefly about the author of the original article: Adam Bosworth (Adam Bosworth) began his career in Borland, where he worked on the Quattro spreadsheet system . Moving to Microsoft, he held various management positions, including the position of chief WebData team leader in creating and promoting XML. In addition, he worked on Access and the Internet Explorer 4.0 engine, codenamed Trident . After leaving Microsoft, Adam became one of the co-founders of Crossgain, after a series of acquisitions, their main product turned into Oracle Workshop for WebLogic. In 2004-2007, Bosworth served as vice president of product development at Google, where he worked on Google Docs and led the development of Google Health ( closed since January 1, 2012 , once wrote about it on Habré ). After leaving Google, he founded Keas , a startup that uses elements of social networking and games to improve health.
This week I was kindly asked to participate as an expert in the government meeting (1) on standards. At this time, I usually sleep, but at the right moment I was alert and sat on the phone, despite all my aversion to not getting enough sleep. What made me do that? The ways in which medical data could actually be made transparent were discussed. What standards should be used to combine such data?
To my own surprise and to some degree of pain, I managed to participate in the development of several standards. One of them was used to exchange data between databases and user applications like spreadsheets or Access. It was called ODBC and showed itself perfectly, despite some difficulties at the beginning. Another was the standard of what is now called AJAX, creating complex, interactive web pages like Gmail. Probably the most important was XML. This is all a success. There were failures. Especially well, I remember the OLE DB , which we wanted to replace / supplant ODBC. One of those balancing on the verge of success and failure was / is XML Schema . As a result of all these efforts, I learned a few lessons that I will try to share with you. What are they?
1. Make standards extremely simple and stupid . The probability of failure is at least the square of the complexity of the standard. Successful standards are generally simple, focused and easy to read. In the world of medicine, this means that we must first focus on the data that can be uniquely encoded: demographic parameters, test results, drugs. Do not try to cover all types of medical data from all areas of medicine. Do not focus on the access rights of your partners to different data (see points 2, 3 and 4 below).
')
2. The data that will be exchanged must be human readable and understandable. The fate of the standards depends on the engineers who will implement them in the code. They will only do this if they can easily understand (see above) and test the standard. That is why over the past 15 years, text standards such as HTTP, HTML and XML have been winning. Developers can view received / transmitted data in any editor and make sure everything goes as it should. When Tim Bernes Lee first applied this approach to building the Internet, most “serious” network specialists considered using text in HTTP to be insane. But it worked very well. Obviously, in the case of XML, it worked just as well. From this we can draw certain conclusions. It is not enough just to say "XML." The average engineer (who will implement the standard) must be able to look at the format and understand it. Seeing only the computer-understandable grammar, you can immediately predict that they will not be widely used. There are several so-called XML grammars that hide XML inside a model of abstract knowledge, like RDF , I feel they are much more difficult to read / understand and not widely used. In my opinion, Hl7 suffers from this.
3. Concentrated standards work best. Do not build a hefty truck for trips to neighboring neighborhoods. Standards very often fail simply because the committees with a variety of complex objectives work without creating working versions to test the complexity (see clause 1) and clarity (see clause 2). Part of the genius of the web was that Tim Berners-Lee correctly separated the protocol (HTTP) from what the browser should display (HTML). It looks like a detached letter from an envelope. This is the basis. And the need. Standards in which layers or levels are wedged into one big entity are prone to failure, because poor engineers need to understand everything, although in fact they only need to understand one thing and therefore they declare a boycott. In health care, this means that rules should not be included in one standard for encoding data and for accessing it and for ensuring security. If I, as an engineer, need only encode the list of prescribed medications to the patient and send him somewhere where he really needs it, do not force me to do something else. The resulting XML should look like a list of drugs. If something does not work, I can call my colleague and find out in five minutes what exactly went wrong. In most cases, I will be able to solve the problem in a couple of days, since I will not have to study the specification as thick as a telephone directory. I will not need to understand the "abstract data model." The bulk of the original XML specification was tiny. Intentionally. I heard someone say indignantly about the attempts to simplify information standards for health care, that we should “raise the level of standards” instead of lowering it. This is analogous to the requirement to teach our children how to fly an airplane so that they can go outside. A distinctive feature of all successful standards was the utmost simplicity, not the utmost complexity.
4. Standards must include exact encoding rules. ODBC precisely defined data types. In the description of XML, everything was brief, except for the exact rules for encoding characters in text, Unicode. This is probably the most important part of the standard, as it guarantees the accuracy of the encoding. In health care, this means that the standard must clearly define the rules for drug coding, test results, demographic data, patient data, and ensure that everyone can use these rules without paying licensing fees. The government can influence this by requiring NPI for all data on physicians' actions, SNOMED CT for all patient data, LOINC for all laboratory data, certain coding rules for all drugs (which can be NDC , rxNorm, or FDB ) and ensuring that use of these rules will always be free.
5. There should always be practical implementations that are actually taken into account when constructing a standard. Without having done something it is very difficult to understand whether it will work and have an engineering sense. When creating ODBC, many of us implemented it in the process. In the healthcare world, many of us have developed and used CCR during its creation, immediately understanding what works and what is not particularly useful, making it a good, easy-to-use standard for integrating medical data. An ordinary engineer should be able to understand the implementation of the standard in a few weeks.
6. Consider the possibility of unforeseen circumstances. Network standards work very well with this. If there is something incomprehensible to HTTP for the recipient, it ignores it. It does not break. If in HTML there is something incomprehensible to the browser, it ignores it. It does not break. Consider the Postel law. Admit the unexpected. False accuracy is a graveyard of successful standards. XML Schema is very bad in this respect, CCR is much better.
7. Make the standard itself free and publish it on the Internet along with many simple examples. Engineers are people too, the easiest way is to learn from examples and if the standard follows the principles described above, the examples will be clear and obvious. Usually, you can immediately predict the success of the standard, if its site has a clear description and simple, clear to all examples. The complexity, generality and abstractness of the HL7 completely overwhelms the average person who has visited his site . She confuses even me. Make no mistake, engineers are ordinary people who have very little time. Most of them do not have a degree.
To be honest, most standards are not created to ensure compatibility. Some are designed to protect an existing position or to profit from intellectual property. Others exist on their own, supporting the infinite existence of the body of the standard and allowing the authors to earn very good money on a banal explanation for the poor engineers of the features of the work of their standard. Probably everyone will agree that such standards are not good. Compatibility of medical data is too important for all of us to allow us to fall victim to this approach.
Notes:
1. The link to the meeting description does not work. The blog in which it was published is no longer there either. According to the title of the link, it can be assumed (without knowing the American specifics) that this was the blog of the FACA - one of the special advisory organizations created on the basis of the 1972 law and intended to develop publicly available recommendations to government bodies and the president
This week I was kindly asked to participate as an expert in the government meeting (1) on standards. At this time, I usually sleep, but at the right moment I was alert and sat on the phone, despite all my aversion to not getting enough sleep. What made me do that? The ways in which medical data could actually be made transparent were discussed. What standards should be used to combine such data?
To my own surprise and to some degree of pain, I managed to participate in the development of several standards. One of them was used to exchange data between databases and user applications like spreadsheets or Access. It was called ODBC and showed itself perfectly, despite some difficulties at the beginning. Another was the standard of what is now called AJAX, creating complex, interactive web pages like Gmail. Probably the most important was XML. This is all a success. There were failures. Especially well, I remember the OLE DB , which we wanted to replace / supplant ODBC. One of those balancing on the verge of success and failure was / is XML Schema . As a result of all these efforts, I learned a few lessons that I will try to share with you. What are they?
1. Make standards extremely simple and stupid . The probability of failure is at least the square of the complexity of the standard. Successful standards are generally simple, focused and easy to read. In the world of medicine, this means that we must first focus on the data that can be uniquely encoded: demographic parameters, test results, drugs. Do not try to cover all types of medical data from all areas of medicine. Do not focus on the access rights of your partners to different data (see points 2, 3 and 4 below).
')
2. The data that will be exchanged must be human readable and understandable. The fate of the standards depends on the engineers who will implement them in the code. They will only do this if they can easily understand (see above) and test the standard. That is why over the past 15 years, text standards such as HTTP, HTML and XML have been winning. Developers can view received / transmitted data in any editor and make sure everything goes as it should. When Tim Bernes Lee first applied this approach to building the Internet, most “serious” network specialists considered using text in HTTP to be insane. But it worked very well. Obviously, in the case of XML, it worked just as well. From this we can draw certain conclusions. It is not enough just to say "XML." The average engineer (who will implement the standard) must be able to look at the format and understand it. Seeing only the computer-understandable grammar, you can immediately predict that they will not be widely used. There are several so-called XML grammars that hide XML inside a model of abstract knowledge, like RDF , I feel they are much more difficult to read / understand and not widely used. In my opinion, Hl7 suffers from this.
3. Concentrated standards work best. Do not build a hefty truck for trips to neighboring neighborhoods. Standards very often fail simply because the committees with a variety of complex objectives work without creating working versions to test the complexity (see clause 1) and clarity (see clause 2). Part of the genius of the web was that Tim Berners-Lee correctly separated the protocol (HTTP) from what the browser should display (HTML). It looks like a detached letter from an envelope. This is the basis. And the need. Standards in which layers or levels are wedged into one big entity are prone to failure, because poor engineers need to understand everything, although in fact they only need to understand one thing and therefore they declare a boycott. In health care, this means that rules should not be included in one standard for encoding data and for accessing it and for ensuring security. If I, as an engineer, need only encode the list of prescribed medications to the patient and send him somewhere where he really needs it, do not force me to do something else. The resulting XML should look like a list of drugs. If something does not work, I can call my colleague and find out in five minutes what exactly went wrong. In most cases, I will be able to solve the problem in a couple of days, since I will not have to study the specification as thick as a telephone directory. I will not need to understand the "abstract data model." The bulk of the original XML specification was tiny. Intentionally. I heard someone say indignantly about the attempts to simplify information standards for health care, that we should “raise the level of standards” instead of lowering it. This is analogous to the requirement to teach our children how to fly an airplane so that they can go outside. A distinctive feature of all successful standards was the utmost simplicity, not the utmost complexity.
4. Standards must include exact encoding rules. ODBC precisely defined data types. In the description of XML, everything was brief, except for the exact rules for encoding characters in text, Unicode. This is probably the most important part of the standard, as it guarantees the accuracy of the encoding. In health care, this means that the standard must clearly define the rules for drug coding, test results, demographic data, patient data, and ensure that everyone can use these rules without paying licensing fees. The government can influence this by requiring NPI for all data on physicians' actions, SNOMED CT for all patient data, LOINC for all laboratory data, certain coding rules for all drugs (which can be NDC , rxNorm, or FDB ) and ensuring that use of these rules will always be free.
5. There should always be practical implementations that are actually taken into account when constructing a standard. Without having done something it is very difficult to understand whether it will work and have an engineering sense. When creating ODBC, many of us implemented it in the process. In the healthcare world, many of us have developed and used CCR during its creation, immediately understanding what works and what is not particularly useful, making it a good, easy-to-use standard for integrating medical data. An ordinary engineer should be able to understand the implementation of the standard in a few weeks.
6. Consider the possibility of unforeseen circumstances. Network standards work very well with this. If there is something incomprehensible to HTTP for the recipient, it ignores it. It does not break. If in HTML there is something incomprehensible to the browser, it ignores it. It does not break. Consider the Postel law. Admit the unexpected. False accuracy is a graveyard of successful standards. XML Schema is very bad in this respect, CCR is much better.
7. Make the standard itself free and publish it on the Internet along with many simple examples. Engineers are people too, the easiest way is to learn from examples and if the standard follows the principles described above, the examples will be clear and obvious. Usually, you can immediately predict the success of the standard, if its site has a clear description and simple, clear to all examples. The complexity, generality and abstractness of the HL7 completely overwhelms the average person who has visited his site . She confuses even me. Make no mistake, engineers are ordinary people who have very little time. Most of them do not have a degree.
To be honest, most standards are not created to ensure compatibility. Some are designed to protect an existing position or to profit from intellectual property. Others exist on their own, supporting the infinite existence of the body of the standard and allowing the authors to earn very good money on a banal explanation for the poor engineers of the features of the work of their standard. Probably everyone will agree that such standards are not good. Compatibility of medical data is too important for all of us to allow us to fall victim to this approach.
Notes:
1. The link to the meeting description does not work. The blog in which it was published is no longer there either. According to the title of the link, it can be assumed (without knowing the American specifics) that this was the blog of the FACA - one of the special advisory organizations created on the basis of the 1972 law and intended to develop publicly available recommendations to government bodies and the president
Source: https://habr.com/ru/post/179651/
All Articles