One of the benefits of working with other experts is the ability to cross link information they generate with information that you generate to save time and effort. Today, John Moehrke writes about reasons why you shouldn't try to use audit logs as disclosure logs in his blog. I'm going to save myself a longer post and refer you to his blog because what he has to say about ATNA and Accounting of Disclosures is important before you read further.
This is another case of the "If I had a hammer" syndrome that I posted on 18 months ago, but in this case the tool is a crescent wrench and the object it is being pounded on is a phillips screw. If you really compare the requirements of an Audit Log and of a Disclosure Log you will see that you have almost none of the same business requirements, and only about a 60-70% overlap in the information requirements. Yes, there is a common core there, but that doesn't make one equivalent to, or a superset of the other. Some of the requirements also conflict with each other. An Audit log almost certainly includes more details used for forensic investigations that would never be released in a Disclosure Log.
So, what we have identified here is two different use cases with some overlapping requirements. This is a pretty common phenomena in computer architecture. The occurence of an overlap may point to a common ancestor in the analysis and design, but it does not imply equivialence or supersetting of requirements, nor need it. Sometimes overlaps are interesting and useful, and this one certainly is, but not nearly so much as some would expect.
Monday, November 30, 2009
Addresses in CDA
Writing a book about a standard is different from implementing it. When you are implementing, you can get away with ignoring parts of the standard that aren't of concern to you. However, when writing a book about it, you need to cover details that wouldn't normally concern you, at least to explain to your audience why they do or don't matter, and when those rubriks apply. Somewhere in the middle of that is writing implementation guides. Because I'm now writing a book, I'm rereading the standard, and discovering things I didn't know. I'll be reporting these discoveries from time to time.
Over the weekend, I discovered something about addresses in CDA that I didn't previously know. Now I have an even deeper understanding (and perhaps some remaining confusion) about the AD data type.
There are about 27 different kinds of information that can appear in an address data type. They are all different kinds of address parts (ADXP) in the Version 3 Data Types standard. I knew that.
What I didn't know was the difference between <streetAddressLine> and <deliveryAddressLine>, and some fine details about the XML representation of these parts. You've probably never seen the <deliveryAddressLine> referenced in any implementation guide, but it should have been. The difference between a <streetAddressLine> and a <deliveryAddressLine> is the difference between a physical delivery address and a PO Box, rural route or other sort of delivery address. A dearth of examples probably contributes to my lack of knowledge.
The Version 3 data types standard (both release 1 and 2) represents the address data type (AD) as a list of Address parts (ADXP), which can repeat any number of times. Practically, some of these should only appear once (e.g., postal code, city, state, country or county), while others could appear multiple times (e.g., streetAddressLine or deliveryAddressLine). There is also hierarchy of address part types which seems to imply a whole/part relationship between elements of the hierarchy. For example, you would imagine that the <streetAddressLine> could contain a <streetName> element. However, the data types schema doesn't allow the content of a <streetAddressLine> to contain a <streetName> element. If you are going to parse any portion of the street address in detail, you cannot wrap the parsed elements in a <streetAddressLine> element.
The long and short of it is that I learned something new, and now, hopefully, you have too.
Over the weekend, I discovered something about addresses in CDA that I didn't previously know. Now I have an even deeper understanding (and perhaps some remaining confusion) about the AD data type.
There are about 27 different kinds of information that can appear in an address data type. They are all different kinds of address parts (ADXP) in the Version 3 Data Types standard. I knew that.
What I didn't know was the difference between <streetAddressLine> and <deliveryAddressLine>, and some fine details about the XML representation of these parts. You've probably never seen the <deliveryAddressLine> referenced in any implementation guide, but it should have been. The difference between a <streetAddressLine> and a <deliveryAddressLine> is the difference between a physical delivery address and a PO Box, rural route or other sort of delivery address. A dearth of examples probably contributes to my lack of knowledge.
The Version 3 data types standard (both release 1 and 2) represents the address data type (AD) as a list of Address parts (ADXP), which can repeat any number of times. Practically, some of these should only appear once (e.g., postal code, city, state, country or county), while others could appear multiple times (e.g., streetAddressLine or deliveryAddressLine). There is also hierarchy of address part types which seems to imply a whole/part relationship between elements of the hierarchy. For example, you would imagine that the <streetAddressLine> could contain a <streetName> element. However, the data types schema doesn't allow the content of a <streetAddressLine> to contain a <streetName> element. If you are going to parse any portion of the street address in detail, you cannot wrap the parsed elements in a <streetAddressLine> element.
The long and short of it is that I learned something new, and now, hopefully, you have too.
Wednesday, November 25, 2009
Turducken
Thinking about what it takes to get healthcare information communicated securely from one point to another reminded me of a Thanksgiving feast I still haven't tried yet.
A Turducken is a chicken, stuffed inside of a duck, stuffed inside of a turkey, and then cooked for a good long time. I'm told by people who've had them that they are:
My friends' third observation on Turducken was that it was worth the effort, and that parallels my own experience with standards based health information exchanges.
Have a happy Thanksgiving for those of you in the US, and for those of you who are not, have a good week.
UPDATE: My wife pointed out to me after having heard about this morning's post that you can purchase a Turducken already prepared. The same is true for the multiple standards put together by HITSP. See OHF, IPF and CONNECT for some examples. Another excellent comparison.
A Turducken is a chicken, stuffed inside of a duck, stuffed inside of a turkey, and then cooked for a good long time. I'm told by people who've had them that they are:
- Wonderful to eat
- Complicated to prepare
My friends' third observation on Turducken was that it was worth the effort, and that parallels my own experience with standards based health information exchanges.
Have a happy Thanksgiving for those of you in the US, and for those of you who are not, have a good week.
UPDATE: My wife pointed out to me after having heard about this morning's post that you can purchase a Turducken already prepared. The same is true for the multiple standards put together by HITSP. See OHF, IPF and CONNECT for some examples. Another excellent comparison.
Tuesday, November 24, 2009
Looking for CDA Stories
Writing on "The CDA Book" has started. It is amazing the amount of non-writing writing that you have to do when you start a book. The amount of reading you have to do is also pretty mind-numbing. Thanks to the web, at least some of that material is readily accessible, even 10 years after the fact.
I'm looking for CDA stories right now, especially stories of the early days of CDA, PRA, or KEG. If you have any of these you'd like to share, please let me know. I'm also interested in real-world, "today" CDA stories. If you have good (or bad) stories about CDA implementations today, I'd like to hear them. Finally, I'm curious as to whether I need to spend any time in the book on "The great SDO debacle of 2006". What are your thoughts?
I'm looking for CDA stories right now, especially stories of the early days of CDA, PRA, or KEG. If you have any of these you'd like to share, please let me know. I'm also interested in real-world, "today" CDA stories. If you have good (or bad) stories about CDA implementations today, I'd like to hear them. Finally, I'm curious as to whether I need to spend any time in the book on "The great SDO debacle of 2006". What are your thoughts?
Friday, November 20, 2009
Simplification
My how times change. In 2005, the largest problem facing healthcare IT interoperability in the US was the harmonization of standards. ANSI/HITSP was formed in October of 2005 with the goal of addressing this particular issue. It is now four years (and a month) since HITSP was created, and we no longer talk about the "Harmonization" problem. The problem facing us now is the "Simplification" of standards. I'm glad to see that we are moving onto the next problem, but hope that in so doing, we don't "unsolve" the previous one.
HITSP's great success in achieving its contract objectives goes largely unnoticed in this new phase because its objectives no longer address the most pressing issue. I've heard several complaints about how the HITSP specifications are too complex, long and not directive enough for implementors. These are valid complaints if you are trying to use these specifications as "implementation guides". They were designed to specify enough to address the harmonized use of standards. Iimplementation guides are much more than that. Many of us involved in HITSP have argued that we need to find a better way to communicate. However, the development of implementation guides requires a great deal more resources that were made available to HITSP under the ONC contract for harmonization, and the scope of the harmonization contract did not include that requirement.
To put this all into perspective, I did a little bit of research into what we (US taxpayers) are paying for with respect to implementation guides for healthcare standards. See http://www.fedspending.org/ for one place where you can dig up some of this data for yourself. My own survey was anything but scientific, but based on my findings, I will assert that a 50-100 page implementation guide seems to cover from 2 - 4 transactions, and costs anywhere from $175,000 to $350,000 dollars to develop. It is usally done in anywhere from 6 - 15 months. The costs don't seem to scale up linearly with complexity either, twice as much complexity results in more than twice the cost.
So, how do we move forward from here? The next step needs to be forward, towards simplification and education, yet not reject the harmonization that we just spend four+ years and spent tens of millions of dollars of both public and private funds addressing.
There are some concrete actions that we can take:
HITSP's great success in achieving its contract objectives goes largely unnoticed in this new phase because its objectives no longer address the most pressing issue. I've heard several complaints about how the HITSP specifications are too complex, long and not directive enough for implementors. These are valid complaints if you are trying to use these specifications as "implementation guides". They were designed to specify enough to address the harmonized use of standards. Iimplementation guides are much more than that. Many of us involved in HITSP have argued that we need to find a better way to communicate. However, the development of implementation guides requires a great deal more resources that were made available to HITSP under the ONC contract for harmonization, and the scope of the harmonization contract did not include that requirement.
To put this all into perspective, I did a little bit of research into what we (US taxpayers) are paying for with respect to implementation guides for healthcare standards. See http://www.fedspending.org/ for one place where you can dig up some of this data for yourself. My own survey was anything but scientific, but based on my findings, I will assert that a 50-100 page implementation guide seems to cover from 2 - 4 transactions, and costs anywhere from $175,000 to $350,000 dollars to develop. It is usally done in anywhere from 6 - 15 months. The costs don't seem to scale up linearly with complexity either, twice as much complexity results in more than twice the cost.
So, how do we move forward from here? The next step needs to be forward, towards simplification and education, yet not reject the harmonization that we just spend four+ years and spent tens of millions of dollars of both public and private funds addressing.
There are some concrete actions that we can take:
- Make simplification of standards an important topic for SDOs and profiling organizations to address.
The ebXML Reference information model and the HL7 RIM are great information models (of meaning), but what we are hearing from the "Internet" crowd is that we need to be closer to how the information modeled for use (see my ramblings on Synthensis). So, how can we simply go from meaning to use and back again?
- Develop tools to make simplification easier (tool development is cheaper in the long run than just throwing more labor at the problem).
The HL7 Templates workgroup is in the process of starting a project to build a templates registry. Imaging having an information resource that would pull together all the templates that you need to implement a HITSP construct in one place. One could readily use that resource to more quicky develop complete implementation guides that wouldn't have some of the challenges that our current HITSP specifications face.
- Move away from linear documents for specifications.
We are dealing with the information age, it's about time we moved away from linear documents, and the constraints that they place upon us. Developers want richly linked media to help them find what they are looking for. The HL7 V3 Ballot site is an overdone example of what I'm talking about, but it is surely better than a 100 page document to deliver the necessary content. One of the biggest challenges that HITSP faces is how to take the content that we have now in documents and make it something that would allow us to put together a real implementation guide.
- Figure out how to move away from single-SDO based interchange and vocabulary models
One thing that the world wide web and XML have taught us is the power of structured information that can be easily transformed. We have 5-6 different key standards for communication in healthcare, only two of which are in XML. We have some 7-9 different key vocabularies, with very similar high level models, yet no common terminilogy interchange format. Can we provide common model across the space of healthcare for both interchange and terminilogy standards.
Wednesday, November 18, 2009
ISO+ to UCUM Mapping Table
Please note the disclaimer: I am not an expert on ISO+, UCUM or laboratory units in general. Therefore, you should validate this data before using it in any clinical applications.
ISO+ Units needing a Mapping
| ISO+ | UCUM | ISO+ | UCUM | ISO+ | UCUM | ISO+ | UCUM |
|---|---|---|---|---|---|---|---|
| (arb_u) | [arb'U] | 10.un.s/(cm5.m2) | dyn.s/(cm5.m2) | iu/mL | [iU]/mL | mL/hr | mL/h |
| (bdsk_u) | [bdsk'U] | 10.un.s/cm5 | dyn.s/cm5 | k/watt | K/W | mm(hg) | mm[Hg] |
| (bsa) | {bsa} | cm_h20 | cm[H20] | kg(body_wt) | kg{body_wt} | mm/hr | mm/h |
| (cal) | cal | cm_h20.s/L | cm[H20].s/L | kg/ms | kg/m2 | mmol/(8.hr.kg) | mmol/(8.h.kg) |
| (cfu) | {cfu} | cm_h20/(s.m) | cm[H20]/(s.m) | kh/h | kg/h | mmol/(8hr) | mmol/(8.h) |
| (drop) | [drp] | dba | dB[SPL] | L/(8.hr) | L/(8.h) | mmol/(kg.hr) | mmol/(kg.h) |
| (ka_u) | [ka'U] | dm2/s2 | REM | L/hr | L/h | mmol/hr | mmol/h |
| (kcal) | kcal | g(creat) | g{creat} | lb | [lb_av] | ng/(8.hr) | ng/(8.h) |
| (kcal)/(8.hr) | kcal/(8.h) | g(hgb) | g{hgb} | ng/(8.hr.kg) | ng/(8.h.kg) | ||
| (kcal)/d | kcal/d | g(tot_nit) | g{tit_nit} | m/s | ms/s | ng/(kg.hr) | ng/(kg.h) |
| (kcal)/hr | kcal/h | g(tot_prot) | g{tot_prot} | mas | Ms | ng/hr | ng/h |
| (knk_u) | [knk'U] | g(wet_tis) | g{wet_tis} | meq/(8.hr) | meq/(8.h) | osmol | osm |
| (mclg_u) | [mclg'U] | g.m/((hb).m2) | g.m/{hb}m2 | meq/(8.hr.kg) | meq/(8.h.kg) | osmol/kg | osm/kg |
| (od) | {od} | g.m/(hb) | g.m/{hb} | meq/(kg.hr) | meq/(kg.h) | osmol/L | osm/L |
| (ph) | pH | g/(8.hr) | g/(8.h) | meq/hr | meq/h | pa | pA |
| (ppb) | [ppb] | g/(8.kg.hr) | g/(8.kg.h) | mg/(8.hr) | mg/(8.h) | pal | Pa |
| (ppm) | [ppm] | g/(kg.hr) | g/(kg.h) | mg/(8.hr.kg) | mg/(8.h.kg) | sec | '' |
| (ppt) | [pptr] | g/hr | g/h | mg/(kg.hr) | mg/(kg.h) | sie | S |
| (ppth) | [ppth] | in | [in_us] | mg/hr | mg/h | ug(8hr) | ug(8.h) |
| (th_u) | [todd'U] | in_hg | [in_i'Hg] | miu/mL | m[iU]/mL | ug/(8.hr.kg) | ug/(8.h.kg) |
| /(arb_u) | /[arb'U] | iu | [iU] | mL/((hb).m2) | mL/{hb}.m2 | ug/(kg.hr) | ug/(kg.h) |
| /(hpf) | [HPF] | iu/d | [iU]/d | mL/(8.hr) | mL/(8.h) | ug/hr | ug/h |
| /(tot) | /{tot} | iu/hr | [iU]/h | mL/(8.hr.kg) | mL/(8.h.kg) | uiu | u[iU] |
| /iu | /[iU] | iu/kg | [iU]/kg | mL/(hb) | mL/{hb} | ||
| 10*3(rbc) | 10*3{rbc} | iu/L | [iU]/L | mL/(kg.hr) | mL/(kg.h) | ||
| 10.L | 10.L/(min.m2) | iu/min | [iU]/min | mL/cm_h20 | mL/cm[H20] |
| Units that are the same in ISO+ and UCUM | |||||||
|---|---|---|---|---|---|---|---|
| % | bar | g/L | L.s | mg | mmol/(kg.d) | ng/L | ueq |
| /kg | Bq | g/m2 | L/(min.m2) | mg/(kg.d) | mmol/(kg.min) | ng/m2 | ug |
| /L | cel | g/min | L/d | mg/(kg.min) | mmol/kg | ng/min | ug/(kg.d) |
| /m3 | Cm | Gy | L/kg | mg/d | mmol/L | ng/mL | ug/(kg.min) |
| /min | cm2/s | h | L/min | mg/dL | mmol/m2 | ng/s | ug/d |
| /m3 | d | hL | L/s | mg/kg | mmol/min | nkat | ug/dL |
| /min | dB | J/L | lm | mg/L | mol/(kg.s) | nm | ug/g |
| /mL | deg | kat | m | mg/m2 | mol/kg | nmol/s | ug/kg |
| 1/mL | eq | kat/kg | m/s2 | mg/m3 | mol/L | ns | ug/L |
| 10*12/L | eV | kat/L | m2 | mg/min | mol/m3 | Ohm | ug/m2 |
| 10*3/L | kg | m2/s | mL | mol/s | Ohm.m | ug/min | |
| 10*3/mL | fg | kg.m/s | m3/s | mL/(kg.d) | mosm/L | pg | ukat |
| 10*3/mm3 | fL | kg/(s.m2) | mbar | mL/(kg.min) | ms | pg/L | um |
| 10*6/L | fmol | kg/L | mbar.s/L | mL/(min.m2) | mV | pg/mL | umol |
| 10*6/mL | g | kg/m3 | meq | mL/d | pkat | umol/d | |
| 10*6/mm3 | g.m | kg/min | meq/(kg.d) | mL/kg | pm | umol/L | |
| 10*9/L | g/(kg.d) | kg/mol | meq/(kg.min) | mL/m2 | ng | pmol | umol/min |
| 10*9/mL | g/(kg.min) | kg/s | meq/d | mL/mbar | ng/(kg.d) | ps | us |
| 10*9/mm3 | g/d | kPa | meq/kg | mL/min | ng/(kg.min) | pt | uV |
| 10.L/min | g/dL | ks | meq/L | mL/s | ng/d | Sv | V |
| a/m | g/kg | L | meq/min | mm | ng/kg | t | Wb |
If you have corrections or comments, please post a response below. I will make every attempt to keep these tables up to date and accurate.
Updated November 19, 2009:
Deleted mapping from ISO+ mm to UCUM to (transformation error)
Corrected mapping from ISO+ sec to UCUM '' (was ')
Updated October 20, 2010
Corrected mm(hg) to mm[Hg]
Changed oms/kg to osm/kg
verified mapping for mas (Megasecond according to HL7 V2) to Ms
deleted mapping from lm/m2 to lm
Still trying to resolve issues around (hb)
verified dm2/s2 = REM
Updated October 23, 2020
Fixed a number of problems with capitalization: Changed wb to Wb, v to V, uv to uV, sv to Sv, pAmp to pA, ohm to Ohm, mv to mV, kpa to kPa, gy to Gy, cel to Cel, bq to Bq and 8h to 8.h
Removed f, n because while these prefixes are the same, they aren't units by themselves
Removed n.s because the proper form is ns
Breast Cancer Screening
Recent news discusses the controversy over new recommendations on breast cancer screenings. While the headlines focus on the changed recommendations, I’d rather pay attention to how interoperability healthcare IT can help to identify the at risk patients and enable them to receive the necessary care. I’ve asked my colleague Scott Bolte to cover the details for us, since this is one of his areas of both expertise and passion. Here's Scott on the topic:
Everyone hates feeling helpless and wants to be able control their life. Rarely is that more trueTo follow up on Scott's posting, I'll add that in 2008, ANSI/HITSP developed the IS08 Personalized Healthcare Interoperability Specification for the communication of detailed family histories in response to the the Personalized Healthcare Use Case. This specification includes the necessary detail for communicating these family histories in a wide variety of clinical documents. Healthcare providers with access to this information can thus readily identify patients who are at high risk, and act accordingly.
then when facing cancer, or trying to avoid cancer in the first place. It isn’t surprising then, that changes in breast cancer screening recommendations have provoked passionate debate by clinicians, clinical associations, patient advocacy groups, and patients themselves.
Earlier this week the US Preventative Services Task Force (USPSTF) changed the recommended age for routine screening for breast cancer from age 40 to 50. There were other changes too, but that's the most dramatic one. The USPSTF is the premier body in the United States for screening recommendations. It greatly influences clinical practice and reimbursement guidelines. However, their recommendation for change is not accepted by other authoritative organizations like the American Cancer Society (ACS).
I will not second-guess either the USPSTF or the ACS. What I will do is point out that these recommendations are for large groups of individuals with average risk. If you go beyond the headlines, you will find that the USPSTF guidelines still explicitly recognize some people have a genetic predisposition to develop cancer and that the new guidelines do not apply to them.
Most people have heard of “cancer genes” like BRCA1 and BRCA2. Actually, everyone has the BRCA1 and BRCA2 genes. All genes naturally come in a variety of forms called alleles. Some alleles are harmless. They lead to no measurable difference, or differences in cosmetic features like the color of your eyes. Other alleles are more significant, determining how your body processes drugs for example. But the alleles that we're worried about here are for BRCA1/2 genes and how that changes the chance that you develop a disease like breast cancer.
The BRCA1/2 genes tend to dominate discussions about breast cancer, but they account for less than 10% of breast cancers. Just because someone has breast cancer, even at an early age, they may not have a genetic predisposition. There are effective tools to identify risks of developing breast cancer, and one of the most useful is a detailed family history.
The advantage of a family history is it reflects both genetics and environment. It can capture factors such as where you live - with corresponding exposure to environmental pollutions, the family dinner table, exercise habits, and other components that increase or decrease risk. It is the interplay of genetics and environment that ultimately determine if you develop cancer.
If the new guidelines leave you feeling exposed, especially if you have a sister or aunt who has had breast cancer, I strongly recommend you assemble a detailed family history. Use a free web tools such as My Family Health Portrait from the US Surgeon General to survey not just breast cancer, but all other cancers since they are often interrelated. That will capture not only the extent of all cancers in your family, it will also collect critical details like maternal vs. paternal relations, and the age of onset of the disease.
With the family history in hand, you and a trusted clinician can determine if additional genetic testing is appropriate. Whether it is or not, the open conversation about clinical risk - in the context of your personal tolerance for more or less testing - will determine if the new USPSTF guidelines are appropriate for you. Having an ongoing dialog with the clinician, and trusting them when they determine if your risk is high, low, or average, puts you back in control.
Subscribe to:
Posts (Atom)