social.sokoll.com

Search

Items tagged with: johndcook

Time spent on the moon


Bild/Foto

This post will illustrate two things: the amount of time astronauts have spent
on the moon, and how to process dates and times in Python.

I was curious how long each Apollo mission spent on the lunar surface, so I
looked up the timelines for each mission from NASA. Here's the timeline for
Apollo 11
, and
you can find the timelines for the other missions by making the obvious change
to the URL.

Here are the data on when each Apollo lunar module touched down and when it
ascended.
data = [ 
        ("Apollo 11", "1969-07-20 20:17:39", "1969-07-21 17:54:00"), 
        ("Apollo 12", "1969-11-19 06:54:36", "1969-11-20 14:25:47"), 
        ("Apollo 14", "1971-02-05 09:18:13", "1971-02-06 18:48:42"), 
        ("Apollo 15", "1971-07-30 22:16:31", "1971-08-02 17:11:23"), 
        ("Apollo 16", "1972-04-21 02:23:35", "1972-04-24 01:25:47"), 
        ("Apollo 17", "1972-12-11 19:54:58", "1972-12-14 22:54:37"), 
    ]

Here's a first pass at a program to parse the dates and times above and report
their differences.
from datetime import datetime, timedelta 

    def str_to_datetime(string): 
        return datetime.strptime(string, "%Y-%m-%d %H:%M:%S") 

    def diff(str1, str2): 
        return str_to_datetime(str1) - str_to_datetime(str2) 

    for (mission, touchdown, liftoff) in data: 
        print(f"{mission} {diff(liftoff, touchdown)}")

This works, but the formatting is unsatisfying.
Apollo 11 21:36:21 
    Apollo 12 1 day, 7:31:11 
    Apollo 14 1 day, 9:30:29 
    Apollo 15 2 days, 18:54:52 
    Apollo 16 2 days, 23:02:12 
    Apollo 17 3 days, 2:59:39

It would be easier to scan the output if it were all in hours. So we rewrite
our diff function as follows.
def diff(str1, str2): 
        delta = str_to_datetime(str1) - str_to_datetime(str2) 
        hours = delta.total_seconds() / 3600 
        return round(hours, 2)

Now the output is easier to read.
Apollo 11 21.61 
    Apollo 12 31.52 
    Apollo 14 33.51 
    Apollo 15 66.91 
    Apollo 16 71.04 
    Apollo 17 74.99

These durations fall into three clusters, corresponding to the Apollo mission
types G, H, and J. Apollo 11 was the only G-type mission. Apollo 12, 13, and
14 were H-type, intended to demonstrate a precise landing and explore the
lunar surface. (Apollo 13 had to loop around the moon without landing.) The
J-type missions were more extensive scientific missions. These missions
included a lunar rover ("moon buggy") to let the astronauts travel further
from the landing site. There were no I-type missions; the objectives of the
original I-type missions were merged into the J-type missions.

One note about the Python code: subtracting dates works unlike you'd expect,
depending on your expectations. The difference between an earlier date and a
later date is positive. You might expect that when speaking of dates
informally. But if you think of the difference in dates as subtracting the
number of seconds from some epoch to a that date, you'd expect the opposite
sign.

Incidentally, UNIX systems store times as seconds since 1970-01-01 00:00:00.
That means the first two lunar landings were at negative times and the last
four were at positive times. More on UNIX time
here.

Related posts


* The orbit that put men on the moon
* Kalman filters
* The weight of code
* Team Moon
* Duct tape on the moon

Bild/Foto

http://feedproxy.google.com/~r/TheEndeavour/~3/B8Stw7J3sQg/
#johndcook #Python #Science
Time spent on the moon

John D. Cook: Time spent on lunar surface | Python date time processing

 

Time spent on the moon


Bild/Foto

This post will illustrate two things: the amount of time astronauts have spent
on the moon, and how to process dates and times in Python.

I was curious how long each Apollo mission spent on the lunar surface, so I
looked up the timelines for each mission from NASA. Here's the timeline for
Apollo 11
, and
you can find the timelines for the other missions by making the obvious change
to the URL.

Here are the data on when each Apollo lunar module touched down and when it
ascended.
data = [ 
        ("Apollo 11", "1969-07-20 20:17:39", "1969-07-21 17:54:00"), 
        ("Apollo 12", "1969-11-19 06:54:36", "1969-11-20 14:25:47"), 
        ("Apollo 14", "1971-02-05 09:18:13", "1971-02-06 18:48:42"), 
        ("Apollo 15", "1971-07-30 22:16:31", "1971-08-02 17:11:23"), 
        ("Apollo 16", "1972-04-21 02:23:35", "1972-04-24 01:25:47"), 
        ("Apollo 17", "1972-12-11 19:54:58", "1972-12-14 22:54:37"), 
    ]

Here's a first pass at a program to parse the dates and times above and report
their differences.
from datetime import datetime, timedelta 

    def str_to_datetime(string): 
        return datetime.strptime(string, "%Y-%m-%d %H:%M:%S") 

    def diff(str1, str2): 
        return str_to_datetime(str1) - str_to_datetime(str2) 

    for (mission, touchdown, liftoff) in data: 
        print(f"{mission} {diff(liftoff, touchdown)}")

This works, but the formatting is unsatisfying.
Apollo 11 21:36:21 
    Apollo 12 1 day, 7:31:11 
    Apollo 14 1 day, 9:30:29 
    Apollo 15 2 days, 18:54:52 
    Apollo 16 2 days, 23:02:12 
    Apollo 17 3 days, 2:59:39

It would be easier to scan the output if it were all in hours. So we rewrite
our diff function as follows.
def diff(str1, str2): 
        delta = str_to_datetime(str1) - str_to_datetime(str2) 
        hours = delta.total_seconds() / 3600 
        return round(hours, 2)

Now the output is easier to read.
Apollo 11 21.61 
    Apollo 12 31.52 
    Apollo 14 33.51 
    Apollo 15 66.91 
    Apollo 16 71.04 
    Apollo 17 74.99

These durations fall into three clusters, corresponding to the Apollo mission
types G, H, and J. Apollo 11 was the only G-type mission. Apollo 12, 13, and
14 were H-type, intended to demonstrate a precise landing and explore the
lunar surface. (Apollo 13 had to loop around the moon without landing.) The
J-type missions were more extensive scientific missions. These missions
included a lunar rover ("moon buggy") to let the astronauts travel further
from the landing site. There were no I-type missions; the objectives of the
original I-type missions were merged into the J-type missions.

One note about the Python code: subtracting dates works unlike you'd expect,
depending on your expectations. The difference between an earlier date and a
later date is positive. You might expect that when speaking of dates
informally. But if you think of the difference in dates as subtracting the
number of seconds from some epoch to a that date, you'd expect the opposite
sign.

Incidentally, UNIX systems store times as seconds since 1970-01-01 00:00:00.
That means the first two lunar landings were at negative times and the last
four were at positive times. More on UNIX time
here.

Related posts


* The orbit that put men on the moon
* Kalman filters
* The weight of code
* Team Moon
* Duct tape on the moon

Bild/Foto

http://feedproxy.google.com/~r/TheEndeavour/~3/B8Stw7J3sQg/
#johndcook #Python #Science
Time spent on the moon

John D. Cook: Time spent on lunar surface | Python date time processing

 

Ratio of area to perimeter


Given a curve of a fixed length, how do you maximize the area inside? This is
known as the isoperimetric problem.

The answer is to use a circle. The solution was known long before it was
possible to prove; proving that the circle is optimal is surprisingly
difficult. I won't give a proof here, but I'll give an illustration.

Consider a regular polygons inscribed in a circle. What happens to the ratio
of area to perimeter as the number of sides increases? You might suspect that
the ratio increases with the number of sides, because the polygon is becoming
more like a circle. This turns out to be correct, and it's not that hard to be
precise about what the ratio is as a function of the number of sides.

For a regular polygon inscribed in a circle of radius r ,

Bild/Foto

and

Bild/Foto

For a regular n -gon inscribed in a unit circle, we have

Bild/Foto

We used the double-angle identity for
sine in the second line above.

As n increases, the ratio increases toward 1/2, the ratio of the area of a
unit circle to its circumference.

Here's a plot of the ratios as a function of the number of sides.

Bild/Foto

Bild/Foto

http://feedproxy.google.com/~r/TheEndeavour/~3/7KhpTEfZD4s/
#johndcook #Math
Ratio of area to perimeter

John D. Cook: Illustrating isoperimetic problem with regular polygons

 

Ratio of area to perimeter


Given a curve of a fixed length, how do you maximize the area inside? This is
known as the isoperimetric problem.

The answer is to use a circle. The solution was known long before it was
possible to prove; proving that the circle is optimal is surprisingly
difficult. I won't give a proof here, but I'll give an illustration.

Consider a regular polygons inscribed in a circle. What happens to the ratio
of area to perimeter as the number of sides increases? You might suspect that
the ratio increases with the number of sides, because the polygon is becoming
more like a circle. This turns out to be correct, and it's not that hard to be
precise about what the ratio is as a function of the number of sides.

For a regular polygon inscribed in a circle of radius r ,

Bild/Foto

and

Bild/Foto

For a regular n -gon inscribed in a unit circle, we have

Bild/Foto

We used the double-angle identity for
sine in the second line above.

As n increases, the ratio increases toward 1/2, the ratio of the area of a
unit circle to its circumference.

Here's a plot of the ratios as a function of the number of sides.

Bild/Foto

Bild/Foto

http://feedproxy.google.com/~r/TheEndeavour/~3/7KhpTEfZD4s/
#johndcook #Math
Ratio of area to perimeter

John D. Cook: Illustrating isoperimetic problem with regular polygons

 

Leap seconds


Bild/Foto{.alignnone
.size-medium width="500" height="333"}

We all learn as children that there are 60 seconds in a minute, 60
minutes in an hour, 24 hours in a day, and 365 days in a year.

Then things get more complicated. There are more like 365.25 days in a
year, hence leap years. Except that’s quite right either. It’s more like
365.242 days in a year, which is why years divisible by 100 do not have
leap years unless they’re also divisible by 400. So even though 2000 was
a leap year, 2100 will not be.

The ratio of the time it takes Earth to circle the sun to the time it
takes it to rotate on its axis is not an integer, and not even a nice
fraction. Why should it be? It’s convenient that the ratio is
approximately 365 ¼, and that’s good enough for many purposes, but
that’s not the full story. And not only is the ratio not a nice
fraction, it’s not even constant!

The earth’s rotation is slowing imperceptibly. Atomic clocks made is
possible to measure how much it’s slowing down, but also make it
necessary to measure. Now that atomic time is widely used, say to
synchronize computer networks, the discrepancy between atomic time and
astronomical observation matters.

Leap seconds have been inserted into the year occasionally to keep
atomic time in sync with time relative to Earth’s rotation. These cannot
be inserted on a regular basis like leap days because the change in
Earth’s rotation is not regular. So committees have to decide how and
when to insert leap seconds, and the process can be surprisingly
acrimonious.

Unix time


It is often said that Unix time is the number of seconds since the
“Epoch,” midnight of January 1, 1970. But it’s not that simple because
leap seconds are not included.

Suppose you were in London a few weeks ago. If you were sitting at a
Linux command prompt to ring in the New Year and typed
date +%s

at the stroke of midnight, the result would have been 1577836800. This
number factors as

1577836800 = 60 × 60 × 24 × (365 × 50 + 12)

corresponding to the number of seconds in a day times the number of days
since New Year’s Day 1970, including 12 leap days. However, if a device
with an atomic clock beeped once per second since the Epoch, it would
beep for the 1577836827th time as 2020 began because there have been 27
leap seconds since then.

International Atomic Time


If you don’t want to deal with Daylight Saving Time, you can use
Universal Coordinated
Time
(UTC)
[1]. If you want to go a step further and not deal with leap seconds,
then International Atomic Time (TAI) is for you [2].

With TAI, every day has exactly 86,400 seconds by definition. When that
many seconds pass, it’s a new day. Makes things very simple, as long as
you don’t have to make reference to UTC, which tries to accommodate
Earth’s rotation.

At the moment, TAI is 37 seconds ahead of UTC. There have been 27 leap
seconds since leap seconds were first instituted, and TAI started out 10
seconds ahead. The next time we add a leap second [3], TAI will be
ahead by 38 seconds.

More posts on time

[1]Why is this not UCT? Because the French wanted to call it TUC for
[temps universel coordonné]{lang="fr"}. The compromise was UTC, which
doesn’t make sense in English or French.

[2]The French won this battle: TAI stands for [temps atomique
international]{lang=""fr"}.

[3]There are proposals to stop adding leap seconds, though the issue
has been contentious. Maybe we won’t add any more leap seconds. Or maybe
we’ll let them accumulate and add them all in at once, analogous to when
several days were removed when converting from the Julian calendar to
the Gregorian calendar.

Bild/Foto{width="1"
height="1"}

http://feedproxy.google.com/~r/TheEndeavour/~3/e8UF1h373iY/
#johndcook #Science
Leap seconds

John D. Cook: Leap seconds, Unix time, and TAI time

 

Leap seconds


Bild/Foto{.alignnone
.size-medium width="500" height="333"}

We all learn as children that there are 60 seconds in a minute, 60
minutes in an hour, 24 hours in a day, and 365 days in a year.

Then things get more complicated. There are more like 365.25 days in a
year, hence leap years. Except that’s quite right either. It’s more like
365.242 days in a year, which is why years divisible by 100 do not have
leap years unless they’re also divisible by 400. So even though 2000 was
a leap year, 2100 will not be.

The ratio of the time it takes Earth to circle the sun to the time it
takes it to rotate on its axis is not an integer, and not even a nice
fraction. Why should it be? It’s convenient that the ratio is
approximately 365 ¼, and that’s good enough for many purposes, but
that’s not the full story. And not only is the ratio not a nice
fraction, it’s not even constant!

The earth’s rotation is slowing imperceptibly. Atomic clocks made is
possible to measure how much it’s slowing down, but also make it
necessary to measure. Now that atomic time is widely used, say to
synchronize computer networks, the discrepancy between atomic time and
astronomical observation matters.

Leap seconds have been inserted into the year occasionally to keep
atomic time in sync with time relative to Earth’s rotation. These cannot
be inserted on a regular basis like leap days because the change in
Earth’s rotation is not regular. So committees have to decide how and
when to insert leap seconds, and the process can be surprisingly
acrimonious.

Unix time


It is often said that Unix time is the number of seconds since the
“Epoch,” midnight of January 1, 1970. But it’s not that simple because
leap seconds are not included.

Suppose you were in London a few weeks ago. If you were sitting at a
Linux command prompt to ring in the New Year and typed
date +%s

at the stroke of midnight, the result would have been 1577836800. This
number factors as

1577836800 = 60 × 60 × 24 × (365 × 50 + 12)

corresponding to the number of seconds in a day times the number of days
since New Year’s Day 1970, including 12 leap days. However, if a device
with an atomic clock beeped once per second since the Epoch, it would
beep for the 1577836827th time as 2020 began because there have been 27
leap seconds since then.

International Atomic Time


If you don’t want to deal with Daylight Saving Time, you can use
Universal Coordinated
Time
(UTC)
[1]. If you want to go a step further and not deal with leap seconds,
then International Atomic Time (TAI) is for you [2].

With TAI, every day has exactly 86,400 seconds by definition. When that
many seconds pass, it’s a new day. Makes things very simple, as long as
you don’t have to make reference to UTC, which tries to accommodate
Earth’s rotation.

At the moment, TAI is 37 seconds ahead of UTC. There have been 27 leap
seconds since leap seconds were first instituted, and TAI started out 10
seconds ahead. The next time we add a leap second [3], TAI will be
ahead by 38 seconds.

More posts on time

[1]Why is this not UCT? Because the French wanted to call it TUC for
[temps universel coordonné]{lang="fr"}. The compromise was UTC, which
doesn’t make sense in English or French.

[2]The French won this battle: TAI stands for [temps atomique
international]{lang=""fr"}.

[3]There are proposals to stop adding leap seconds, though the issue
has been contentious. Maybe we won’t add any more leap seconds. Or maybe
we’ll let them accumulate and add them all in at once, analogous to when
several days were removed when converting from the Julian calendar to
the Gregorian calendar.

Bild/Foto{width="1"
height="1"}

http://feedproxy.google.com/~r/TheEndeavour/~3/e8UF1h373iY/
#johndcook #Science
Leap seconds

John D. Cook: Leap seconds, Unix time, and TAI time

 

Doing a database join with CSV files


It’s easy to manipulate CSV files with basic command line tools until
you need to do a join. When your data is spread over two different
files, like two tables in a normalized database, joining the files is
more difficult unless the two files have the same keys in the same
order. Fortunately, the xsv utility
is just the tool for the job. Among other useful features, xsv
supports database-like joins.

Suppose you want to look at weights broken down by sex, but weights are
in one file and sex is in another. The weight file alone doesn’t tell
you whether the weights belong to men or women.

Suppose a file weight.csv has the following rows:
ID,weight 
    123,200 
    789,155 
    999,160

and a file person.csv has the following:
ID,sex 
    123,M 
    456,F 
    789,F

Note that the two files have different ID values: 123 and 789 are in
both files, 999 is only in weight.csv and 456 is only in person.csv.
We want to join the two tables together, analogous to the JOIN command
in SQL.

The command
xsv join ID person.csv ID weight.csv

does just this, producing
ID,sex,ID,weight 
    123,M,123,200 
    789,F,789,155

by joining the two tables on their ID columns.

The command includes ID twice, once for the field called ID in
person.csv and once for the field called ID in weight.csv. The
fields could have different names. For example, if the first column of
person.csv were renamed Key, then the command
xsv join Key person.csv ID weight.csv

would produce
Key,sex,ID,weight 
    123,M,123,200 
    789,F,789,155

We’re not interested in the ID columns per se; we only want to use
them to join the two files. We could suppress them in the output by
asking xsv to select the second and fourth columns of the output
join Key person.csv ID weight.csv | xsv select 2,4

which would return
sex,weight 
    M,200 
    F,155

We can do other kinds of joins by passing a modifier to join. For
example, if we do a left join, we will include all rows in the left
file, person.csv, even if there isn’t a match in the right file,
weight.csv. The weight will be missing for such records, and so
$ xsv join --left Key person.csv ID weight.csv

produces
Key,sex,ID,weight 
    123,M,123,200 
    456,F,, 
    789,F,789,155

Right joins are analogous, including every record from the second
file, and so
xsv join --right Key person.csv ID weight.csv

produces
Key,sex,ID,weight 
    123,M,123,200 
    789,F,789,155 
    ,,999,160

You can also do a full join, with
xsv join --full Key person.csv ID weight.csv

producing
Key,sex,ID,weight 
    123,M,123,200 
    456,F,, 
    789,F,789,155 
    ,,999,160

Related posts

Bild/Foto{width="1"
height="1"}

http://feedproxy.google.com/~r/TheEndeavour/~3/ENI-x5u_m3M/
#johndcook #Computing
Doing a database join with CSV files

John D. Cook: Doing a SQL join with CSV files with xsv

 

Doing a database join with CSV files


It’s easy to manipulate CSV files with basic command line tools until
you need to do a join. When your data is spread over two different
files, like two tables in a normalized database, joining the files is
more difficult unless the two files have the same keys in the same
order. Fortunately, the xsv utility
is just the tool for the job. Among other useful features, xsv
supports database-like joins.

Suppose you want to look at weights broken down by sex, but weights are
in one file and sex is in another. The weight file alone doesn’t tell
you whether the weights belong to men or women.

Suppose a file weight.csv has the following rows:
ID,weight 
    123,200 
    789,155 
    999,160

and a file person.csv has the following:
ID,sex 
    123,M 
    456,F 
    789,F

Note that the two files have different ID values: 123 and 789 are in
both files, 999 is only in weight.csv and 456 is only in person.csv.
We want to join the two tables together, analogous to the JOIN command
in SQL.

The command
xsv join ID person.csv ID weight.csv

does just this, producing
ID,sex,ID,weight 
    123,M,123,200 
    789,F,789,155

by joining the two tables on their ID columns.

The command includes ID twice, once for the field called ID in
person.csv and once for the field called ID in weight.csv. The
fields could have different names. For example, if the first column of
person.csv were renamed Key, then the command
xsv join Key person.csv ID weight.csv

would produce
Key,sex,ID,weight 
    123,M,123,200 
    789,F,789,155

We’re not interested in the ID columns per se; we only want to use
them to join the two files. We could suppress them in the output by
asking xsv to select the second and fourth columns of the output
join Key person.csv ID weight.csv | xsv select 2,4

which would return
sex,weight 
    M,200 
    F,155

We can do other kinds of joins by passing a modifier to join. For
example, if we do a left join, we will include all rows in the left
file, person.csv, even if there isn’t a match in the right file,
weight.csv. The weight will be missing for such records, and so
$ xsv join --left Key person.csv ID weight.csv

produces
Key,sex,ID,weight 
    123,M,123,200 
    456,F,, 
    789,F,789,155

Right joins are analogous, including every record from the second
file, and so
xsv join --right Key person.csv ID weight.csv

produces
Key,sex,ID,weight 
    123,M,123,200 
    789,F,789,155 
    ,,999,160

You can also do a full join, with
xsv join --full Key person.csv ID weight.csv

producing
Key,sex,ID,weight 
    123,M,123,200 
    456,F,, 
    789,F,789,155 
    ,,999,160

Related posts

Bild/Foto{width="1"
height="1"}

http://feedproxy.google.com/~r/TheEndeavour/~3/ENI-x5u_m3M/
#johndcook #Computing
Doing a database join with CSV files

John D. Cook: Doing a SQL join with CSV files with xsv

 

Rare and strange ICD-10 codes


ICD-10 is a set of around 70,000 diagnosis codes. ICD stands for
International Statistical Classification of Diseases and Related Health
Problems. The verbosity of the name is foreshadowing.

Some of the ICD-10 codes are awfully specific, and bizarre.

For example,
  • V95.4: Unspecified spacecraft accident injuring occupant
  • V97.33XA: Sucked into jet engine, initial encounter
  • V97.33XD: Sucked into jet engine, subsequent encounter
As I understand it, V97.33XD refers to a subsequent encounter with a
health care professional, not a subsequent encounter with a jet engine.
But you have to wonder how many people who have been sucked into a jet
engine survive to have one, much less two, medical visits.

There is a specific code, Y92.146, for injuries in a prison swimming
pool. It seems strange to combine a medical diagnosis and its location
into a single code. Is a swimming injury in a prison pool medically
different than a swimming injury in a YMCA pool?

I understand that the circumstance of a diagnosis is not recorded
strictly for medical reasons. But while 70,000 is an unwieldy large set
of codes, it’s kinda small when it has to account for both malady and
circumstance. Surely there are 70,000 circumstances alone that are more
common than being in a spacecraft, for instance.

Is there a code for being at the opera? Why yes there is: Y92.253.
However, there are no codes for being at a Costco, Walmart, or Jiffy
Lube.

Bild/Foto{width="1"
height="1"}

http://feedproxy.google.com/~r/TheEndeavour/~3/P3FOHVTvAsw/
#johndcook #Uncategorized
Rare and strange ICD-10 codes

John D. Cook: Rare and strange ICD-10 codes

 

Rare and strange ICD-10 codes


ICD-10 is a set of around 70,000 diagnosis codes. ICD stands for
International Statistical Classification of Diseases and Related Health
Problems. The verbosity of the name is foreshadowing.

Some of the ICD-10 codes are awfully specific, and bizarre.

For example,
  • V95.4: Unspecified spacecraft accident injuring occupant
  • V97.33XA: Sucked into jet engine, initial encounter
  • V97.33XD: Sucked into jet engine, subsequent encounter
As I understand it, V97.33XD refers to a subsequent encounter with a
health care professional, not a subsequent encounter with a jet engine.
But you have to wonder how many people who have been sucked into a jet
engine survive to have one, much less two, medical visits.

There is a specific code, Y92.146, for injuries in a prison swimming
pool. It seems strange to combine a medical diagnosis and its location
into a single code. Is a swimming injury in a prison pool medically
different than a swimming injury in a YMCA pool?

I understand that the circumstance of a diagnosis is not recorded
strictly for medical reasons. But while 70,000 is an unwieldy large set
of codes, it’s kinda small when it has to account for both malady and
circumstance. Surely there are 70,000 circumstances alone that are more
common than being in a spacecraft, for instance.

Is there a code for being at the opera? Why yes there is: Y92.253.
However, there are no codes for being at a Costco, Walmart, or Jiffy
Lube.

Bild/Foto{width="1"
height="1"}

http://feedproxy.google.com/~r/TheEndeavour/~3/P3FOHVTvAsw/
#johndcook #Uncategorized
Rare and strange ICD-10 codes

John D. Cook: Rare and strange ICD-10 codes

 

Rare and strange ICD-10 codes


ICD-10 is a set of around 70,000 diagnosis codes. ICD stands for
International Statistical Classification of Diseases and Related Health
Problems. The verbosity of the name is foreshadowing.

Some of the ICD-10 codes are awfully specific, and bizarre.

For example,
  • V95.4: Unspecified spacecraft accident injuring occupant
  • V97.33XA: Sucked into jet engine, initial encounter
  • V97.33XD: Sucked into jet engine, subsequent encounter
As I understand it, V97.33XD refers to a subsequent encounter with a
health care professional, not a subsequent encounter with a jet engine.
But you have to wonder how many people who have been sucked into a jet
engine survive to have one, much less two, medical visits.

There is a specific code, Y92.146, for injuries in a prison swimming
pool. It seems strange to combine a medical diagnosis and its location
into a single code. Is a swimming injury in a prison pool medically
different than a swimming injury in a YMCA pool?

I understand that the circumstance of a diagnosis is not recorded
strictly for medical reasons. But while 70,000 is an unwieldy large set
of codes, it’s kinda small when it has to account for both malady and
circumstance. Surely there are 70,000 circumstances alone that are more
common than being in a spacecraft, for instance.

Is there a code for being at the opera? Why yes there is: Y92.253.
However, there are no codes for being at a Costco, Walmart, or Jiffy
Lube.

Bild/Foto{width="1"
height="1"}

http://feedproxy.google.com/~r/TheEndeavour/~3/P3FOHVTvAsw/
#johndcook #Uncategorized
Rare and strange ICD-10 codes

John D. Cook: Rare and strange ICD-10 codes

 
Later posts Earlier posts