How do you handle narrative text in HL7 CDA? see discussion at the following blog
CDA Narrative Text
Showing posts with label CDA. Show all posts
Showing posts with label CDA. Show all posts
Tuesday, June 12, 2012
Monday, June 4, 2012
Discrepancy in HITSP C83 CDA Content Modules
I am reading through HITSP C83 - HITSP_v2.0.1_2010_C83_-_CDA_Content_Modules.pdf. In section 2.2.2.8 MEDICATION, it specifies the following mapping for medication,
A sample XML snippet is given below in 'additional specification 2.2.2.8.16'.
Based on the mapping table, I will assume that the correct XML snippet should be as following, with the 'code' element describing that this observation is for medication type data , and 'value' element describing the actual type of medication.
<entryRelationship typeCode='SUBJ'>
<observation classCode='OBS' moodCode='EVN'>
<templateId root='2.16.840.1.113883.3.88.11.83.8.1' />
<code code='xxxx' displayName='Medication Type'
codeSystem='xxxx' codeSystemName='xxxx' />
<value xsi:type='CE' code='73639000' displayName='Prescription Drug'
codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'/>
</observation>
<entryRelationship>
I think the sample medication XML needs to be updated.
A sample XML snippet is given below in 'additional specification 2.2.2.8.16'.
Based on the mapping table, I will assume that the correct XML snippet should be as following, with the 'code' element describing that this observation is for medication type data , and 'value' element describing the actual type of medication.
<entryRelationship typeCode='SUBJ'>
<observation classCode='OBS' moodCode='EVN'>
<templateId root='2.16.840.1.113883.3.88.11.83.8.1' />
<code code='xxxx' displayName='Medication Type'
codeSystem='xxxx' codeSystemName='xxxx' />
<value xsi:type='CE' code='73639000' displayName='Prescription Drug'
codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'/>
</observation>
<entryRelationship>
I think the sample medication XML needs to be updated.
Tuesday, May 22, 2012
Health IT Standards: Where went wrong
Over the past few years I have been facing people with two extreme views - one view is that 'standard is magic', the other extreme view is that 'standards never work'.
I am not going to address the second one here, since I concluded that it is primarily caused by the people who is holding the first view, as long as we address the root cause of the first view, hopefully we are able to help the second group of people see the benefits of standards.
To avoid confusion and set the context correct, the HIT standards I am talking about here is interoperability standards such as HL7v2, HL7v3 RIM, CDA etc, excluding terminology.
For those people who has the view of "standard solves everything" tends to have the following characteristics
1. Lacks the mindset and experience of architecture design
2. Theoretical view of the world out there, and pursue the dream of 'silver bullet'
3. Not Invented Here (NIH) Syndrome
Let me share with you few real conversations I had in the past. Once I was asked about how we know that the interoperability standard developed is ready for implementation. Guess what is my reply, my simple suggestion is the following question,
"Do you know HOW to implement this standard if you are the one to implement?"
I continued to say that if the answer is "No", then I am 100% sure that there must be something very wrong with it even before I look at it.
In another situation, I was asked how the standard can help to churn good data out of low quality data, that's really amusing! How can it be possible that interoperability standard itself turn bad data into good data? If some data is missing from the received message, yes, the receiving system may be able to figure out the missing data, but that is not going to be solved by standards itself even if it is achievable.
For people who holds the view of 'silver bullet', they tends to misplace the use or application of one particular technology or standard, take the case of ISO13606 or openEHR, which I find it very useful for clinical requirement definition as I commented on this blog - Complexity of Standards, however if we are going to turn that standard into a universal data exchange and OLTP/OLAP model, that's where standard scares away the people who want to adopt standards in the first place. This kind of debate is just as useless as arguing 'whether to use SQL or MapReduce', the right answer shall be 'Use the technology where it thrives'.
The last one - NIH syndrome, it is so pervasive, different people do have different views and opinions, I guess everyone wants to create his/her own thing so that we can leave some legacy behind, I am not exception. This can only be solved by the organization which shall enforce the rule of putting personal views and opinions behind organization's and extended community's collective objective. If you do not use the standards the industry already developed, and continue to enhance and extend, then what is the point of developing standards in the first place? It defeats the whole purpose of using standards.
So how to equip yourself with the architectural mindset to solve the first two problems mentioned above?
Lets look at the definition of an architecture used in ANSI/IEEE Std 1471-2000:
"The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."
The most difficult part of architecture design is reflected in the second part of the above definition, the principles governing its design and evolution to ensure that architecture's agility - extensibility, configurability, customizabillty, etc. It is extremely easy to design an architecture or information model without considering its evolution, however this kind of system is extremely fragile, I think this point will somehow relate to some of the projects you are involved, and you might be smiling. If so, please continue to read.
So how to ensure the architecture's agility?
1) Why? We shall ask the WHY question before you develop anything, whether it is interoperability standard or a piece of software, it is all about design. Only when you ask WHY, you will be able to uncover the real objectives. The tendency is that users give very vague requirement, and sometimes they are just clueless.
2) Anticipate! With the correct understanding of objectives, you will perform some level of predictive analysis. How far and deep you can predict is based on your experience, that's why architecture design is an art to some extent.
3) Tradeoff. Architecture design is all about trade-off, it is the design of different choices, you can use ATAM (Architecture Tradeoff Analysis Method) to help you on that.
4) Outcome. We shall think about outcome before we start to develop anything.
5) Engineering. We need to have strong engineering discipline to do the work. I have mentioned this point in my previous post - Standards based Implementation
To conclude, interoperability standards development is architecture design activity, treat it seriously, realisticly and holistically
If you are in the middle of developing your own backyard standards, think about twice here! Are you on the right path?
I am not going to address the second one here, since I concluded that it is primarily caused by the people who is holding the first view, as long as we address the root cause of the first view, hopefully we are able to help the second group of people see the benefits of standards.
To avoid confusion and set the context correct, the HIT standards I am talking about here is interoperability standards such as HL7v2, HL7v3 RIM, CDA etc, excluding terminology.
For those people who has the view of "standard solves everything" tends to have the following characteristics
1. Lacks the mindset and experience of architecture design
2. Theoretical view of the world out there, and pursue the dream of 'silver bullet'
3. Not Invented Here (NIH) Syndrome
Let me share with you few real conversations I had in the past. Once I was asked about how we know that the interoperability standard developed is ready for implementation. Guess what is my reply, my simple suggestion is the following question,
"Do you know HOW to implement this standard if you are the one to implement?"
I continued to say that if the answer is "No", then I am 100% sure that there must be something very wrong with it even before I look at it.
In another situation, I was asked how the standard can help to churn good data out of low quality data, that's really amusing! How can it be possible that interoperability standard itself turn bad data into good data? If some data is missing from the received message, yes, the receiving system may be able to figure out the missing data, but that is not going to be solved by standards itself even if it is achievable.
For people who holds the view of 'silver bullet', they tends to misplace the use or application of one particular technology or standard, take the case of ISO13606 or openEHR, which I find it very useful for clinical requirement definition as I commented on this blog - Complexity of Standards, however if we are going to turn that standard into a universal data exchange and OLTP/OLAP model, that's where standard scares away the people who want to adopt standards in the first place. This kind of debate is just as useless as arguing 'whether to use SQL or MapReduce', the right answer shall be 'Use the technology where it thrives'.
The last one - NIH syndrome, it is so pervasive, different people do have different views and opinions, I guess everyone wants to create his/her own thing so that we can leave some legacy behind, I am not exception. This can only be solved by the organization which shall enforce the rule of putting personal views and opinions behind organization's and extended community's collective objective. If you do not use the standards the industry already developed, and continue to enhance and extend, then what is the point of developing standards in the first place? It defeats the whole purpose of using standards.
So how to equip yourself with the architectural mindset to solve the first two problems mentioned above?
Lets look at the definition of an architecture used in ANSI/IEEE Std 1471-2000:
"The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."
The most difficult part of architecture design is reflected in the second part of the above definition, the principles governing its design and evolution to ensure that architecture's agility - extensibility, configurability, customizabillty, etc. It is extremely easy to design an architecture or information model without considering its evolution, however this kind of system is extremely fragile, I think this point will somehow relate to some of the projects you are involved, and you might be smiling. If so, please continue to read.
So how to ensure the architecture's agility?
1) Why? We shall ask the WHY question before you develop anything, whether it is interoperability standard or a piece of software, it is all about design. Only when you ask WHY, you will be able to uncover the real objectives. The tendency is that users give very vague requirement, and sometimes they are just clueless.
2) Anticipate! With the correct understanding of objectives, you will perform some level of predictive analysis. How far and deep you can predict is based on your experience, that's why architecture design is an art to some extent.
3) Tradeoff. Architecture design is all about trade-off, it is the design of different choices, you can use ATAM (Architecture Tradeoff Analysis Method) to help you on that.
4) Outcome. We shall think about outcome before we start to develop anything.
5) Engineering. We need to have strong engineering discipline to do the work. I have mentioned this point in my previous post - Standards based Implementation
To conclude, interoperability standards development is architecture design activity, treat it seriously, realisticly and holistically
If you are in the middle of developing your own backyard standards, think about twice here! Are you on the right path?
Friday, March 30, 2012
Standards based implementation
Yesterday (Mar 29, 2012) I attended Singapore IT Standards Committee (ITSC) plenary meeting at Hotel Fort Canning, at present there were about 10 TC (Technical Committee) such as ADC (Auto Data Collection), Biometrics, Green Data Center and HITC (Health Informatics TC) which I am part of. After the plenary, a pleasant night of beer, food and very enjoyable conversations with standards enthusiasts and practitioners.
During the conversions with the standards enthusiasts, I am extremely shocked at the miserable state of how standards are being applied in Singapore healthcare industry compared with other industries. I asked myself what is the main reason?
Does 'Being standards-based' equal to 'overlooking practical constraints and boil-the-ocean solutions"? What and How that misconception is created in the first place in healthcare industry? How we can make it right?
1) Developing standards is a serious software engineering practice requiring discipline and process
Developing standards is just like developing a software solution, we need to have product vision and long term roadmap, and plan all the efforts (business needs, conceptual design, detail design, implementation, testing, rollout and ongoing maintenance) into each measurable deliverable, it is so obvious to a person with basic software engineering discipline, but the sad truth is that it is not so obvious in healthcare industry,this is the most problematic issue in healthcare. However just take note, the effort I described such as design and implementation are not necessarily just software development, the gist is the engineering process to ensure constant quality deliverable and incremental road map to long term vision realization.
Developing standards is a serious software engineering requiring discipline and proper planning, analyze what's possible and not possible given the current technology landscape and limitation, and make the necessary architecture trade-off, and in the mean time also keep in view o the technology landscape change and user community maturity in order to implement the unrealized strategy and features
We also need to distinguish between 'research' and 'development' types of standards, should have clears strategy to transition 'research' to 'development'.
2) The right talent
Because of the above misconception about standards, the right talent is not recruited and managing the standards development. As more and more 'unqualified' people are recruited and involved in the development of standards, the most obvious outcome we can see is the so-called standards become more and more complex to the point no one can understand what's the real purpose.
This is the typical downward spiral that could happen to every industry.
3) Standards shall be VERB instead of NOUN
Standards is a VERB instead of NOUN - 'standards-based implementation' needs to translate into the action of standardizing instead of producing standards only. Just like what we develop software product? Is it for demonstrating to customers only or delivering features to help customers do their job better?
4) Standards is an ecosystem
If we are developing standards, this point is extremely important. whenever we start to develop a standard, we are in fact trying to create a new ecosystem, so we have to take into consideration the following key stakeholders in the entire ecosystem, and make alignment in early planning phase when defining vision.
Source : What’s a Good Exchange Specification
During the conversions with the standards enthusiasts, I am extremely shocked at the miserable state of how standards are being applied in Singapore healthcare industry compared with other industries. I asked myself what is the main reason?
Does 'Being standards-based' equal to 'overlooking practical constraints and boil-the-ocean solutions"? What and How that misconception is created in the first place in healthcare industry? How we can make it right?
1) Developing standards is a serious software engineering practice requiring discipline and process
Developing standards is just like developing a software solution, we need to have product vision and long term roadmap, and plan all the efforts (business needs, conceptual design, detail design, implementation, testing, rollout and ongoing maintenance) into each measurable deliverable, it is so obvious to a person with basic software engineering discipline, but the sad truth is that it is not so obvious in healthcare industry,this is the most problematic issue in healthcare. However just take note, the effort I described such as design and implementation are not necessarily just software development, the gist is the engineering process to ensure constant quality deliverable and incremental road map to long term vision realization.
Developing standards is a serious software engineering requiring discipline and proper planning, analyze what's possible and not possible given the current technology landscape and limitation, and make the necessary architecture trade-off, and in the mean time also keep in view o the technology landscape change and user community maturity in order to implement the unrealized strategy and features
We also need to distinguish between 'research' and 'development' types of standards, should have clears strategy to transition 'research' to 'development'.
2) The right talent
Because of the above misconception about standards, the right talent is not recruited and managing the standards development. As more and more 'unqualified' people are recruited and involved in the development of standards, the most obvious outcome we can see is the so-called standards become more and more complex to the point no one can understand what's the real purpose.
This is the typical downward spiral that could happen to every industry.
3) Standards shall be VERB instead of NOUN
Standards is a VERB instead of NOUN - 'standards-based implementation' needs to translate into the action of standardizing instead of producing standards only. Just like what we develop software product? Is it for demonstrating to customers only or delivering features to help customers do their job better?
4) Standards is an ecosystem
If we are developing standards, this point is extremely important. whenever we start to develop a standard, we are in fact trying to create a new ecosystem, so we have to take into consideration the following key stakeholders in the entire ecosystem, and make alignment in early planning phase when defining vision.
- Standards Development Organization (SDO). HL7 has developed comprehensive healthcare data exchange standards such as HL7v2, HL7v3 CDA etc.
- National Standards organization (NSO). NSO' s primary objective should be 'evaluate and ratify the suitable standards for use for the nation', and only recommend to develop if there is really no suitable existing standards in the market
- User community. Evaluate what existing standards they are using and comfortable at this moment, take in their inputs and opinions, choose a standard where the user community is able to adopt it incrementally and equally importantly, it is commercially justifiable and sustainable in the long run.
- Commercial software vendors. Ultimately what is being used rules the world. So we need to see what these vendors are using. If majority of the commercial vendors are using standards A, and you try to develop another completely different standard, then you already defeat the whole purpose of standards which is to reduce integration cost in the case of data exchange standards, unless you can educate and convince the entire user community, vendor community, and respective government agency.
Source : What’s a Good Exchange Specification
Subscribe to:
Posts (Atom)