PCAST, UEL, Molecules and green CDA

I listened to a discussion on Thursday's Structured Documents Work Group call about PCAST, UEL and the relationship to the templated CDA that HL7 uses. We had an earlier discussion about "green CDA".

As often happens, later in the day, it occurred to me that perhaps the UEL that PCAST is seeking could be met by "greening of templated CDA entries." Let me explain.

The President's Council on Science and Technology has called for the development of a Universal Exchange Language to exchange "atomic" health data. They feel that the current exchange standards are not granular enough.

HL7 feels that templated CDA should be sufficient and there is concern that an attempt to get too granular will result in data that lacks context and therefore meaning.

Green CDA is an attempt to create a simpler version of the xml than that which CDA currently is, and to provide transforms that will take a "full CDA" document and transform it into a "green CDA" document, and vice versa. The transforms will allow developers that are comfortable with "full CDA" to use that and to exchange documents with developers (and their systems) that are more comfortable with the simpler "green CDA."

Now, it occurs to me that we can use the concept of the "full to green" translation to take the full, templated CDA and extract the UEL molecule and transform the data into "green UEL." The process of moving from full to "green UEL" should maintain sufficient meta data in the molecule to maintain context.

The translation from the "green UEL" to "full CDA" is trickier and may require fetching data from elsewhere to reassemble a proper "full CDA" instance.

I'm not sure that this is a solution, but it just might work.

2011 Stanley Cup Preview

I have been a hockey fan for as long as I can remember. The Stanley Cup Playoffs are my favorite time of the year.

Each year, I look at the playoff teams and see which are cup contenders, and which have little or no chance to sip from the cup. The bottom line is that goaltending and depth win cups. One line teams that have suspect goaltending make early playoff exits.

Let’s look at the conferences starting with the East.

The Capitals are the #1 seed from the East. They have played better defensively this year, but I do not expect their goaltending to hold up. I don’t see them winning the cup.

The Flyers will go as far as their goaltending and Chris Pronger will take them. They are stumbling in to the playoffs. I don’t see them winning the cup.

The Bruins are as complete a team as there is in the East. Tim Thomas has had a remarkable regular season, and I expect him to keep it up in the playoffs. The Bruins could make a long playoff run.

The Penguins have played better than anyone expected them to. I know that Gary Bettman would love to see the Penguins make a long playoff run, but this team is not deep enough and does not have the goaltending to play for the cup.

The Lightning have played better than any of us expected. Roloson has proven playoff experience. The Lightning could make a long playoff run.

The Canadians are not a deep team. They will go as far as Cary Price carries them, but I don’t expect that to be very far.

The Sabres will not last long. Ryan Miller could stand on his head, but I don’t expect him to carry them very far.

The Rangers could win one round, if Lundquist stands on his head, but I also do not expect him to be able to take this team to the cup finals.

So, I think that either the Bruins or the Lightning will come out of the East. At this point, I think that the Bruins are more likely to do so.

Let’s look at the Western Conference.

The Canucks still have not proven that they can win in the playoffs. They have had a wonderful regular season, but, that is no guarantee of playoff success. I do not expect the Canucks to play for the cup.

The San Jose Sharks are in the same boat as the Canucks. They have better goaltending than they have had in previous years, but I do not see it being good enough to carry them to the cup.

The Red Wings have not played well enough defensively to play for the cup. They are stumbling their way into the playoffs. There is some feeling that they will magically “turn it on” for the playoffs, but I don’t see how they can end all of the bad habits that they have shown over the last month. I don’t see them making it out of the first round. That will depend on the matchup. I do not expect them to play for the cup.

The Ducks will go as far as Hiller can carry them. They might go a round or two, but I do not expect them to play for the cup.

The Predators are a team that could make a long playoff run. They have great goaltending and are a balanced team.

The Coyotes may make it out of the first round. They took the Red Wings to a seventh game in their series last year, and this Red Wings team is not as good as last year. I don’t see the Coyotes being deep enough and having the goaltending to play for the cup.

The Kings might win the first round, but I don’t expect them to play for the cup.

The Blackhawks could upset the Canucks in their first round matchup, but I don’t see the Hawks going much farther.

I’m not sold on any team from the west this year. The Predators could be the sleeper team from the west to play for the cup. The Canucks and the Sharks have yet to prove that they can win in the playoffs.

The relationship between Documents, Sections and Clinical Statements

The content for a clinical document is specified using Sections and Clinical Statements as building blocks.

Each Clinical Document contains exactly one header. The content of the Header is defined by the US Realm Header Template.

Each Clinical Document contains one or more sections. The content of a section is defined by its Section Template.

Each Section contains zero or more Clinical Statements. Some Sections are “narrative only” and do not contain any Clinical Statements. The content of a Clinical Statement is defined by its Clinical Statement Template.

This approach allows each document that contains an Allergy Section to use the same rules for constructing that section.

This approach allows each section that contains a Procedure Activity to use the same rules for constructing that Clinical Statement.

Red Wings Playoff Prospects

The Red Wings lost another home game last night. Badly.

They lost to the St. Louis Blues. The final score was 10-3. I saw some of the first period. I played hockey last night, so I missed most of the debacle.

This team is not very good. They remind me of the teams from several years ago that won a lot of regular season games, but suffered early playoff exits.

Their defense is horrible, and the goaltending is questionable. That's not the sort of team that does well in the Stanley Cup Playoffs.

They seem to think that they will wake up one day in the playoffs and will magically be able to "switch on" and eliminate all of their bad habits and tendencies and have a long run in the playoffs. I fear that they will run into a team that is playing well, has been playing "playoff hockey" for the last month or so just to make the playoffs, has a hot goaltender, and the Wings will lose in five or six games.

Time will tell.

Processing 997 Files. Using an Interface Engine for Process Improvement

I've recently been working on parsing X12 files. My former colleagues referred to these files as "EDI" files, which is kind of silly. There may have been only a single format for the electronic interchange of data once upon a time, but in 2011 there are lots of ways to exchange data.

I worked on x12 848 transaction set (Materials) messages about fifteen years ago. I was part of a team that developed an implementation guide for the exchange of Material Safety Data Sheets (MSDS) between Tier 1 Paint Suppliers and Auto Manufacturers.

This project is much simpler. We receive an x12 997 Acknowledgement file from one of our trading partners. We send charges to them and they submit those charges on our behalf. The 997 file tells us whether the claim has been accepted by the payer.

For as long as anyone can remember, our operators have been receiving these 997 files and then manually looking through them to determine if the claim was accepted.

This is what an inbound 997 file looks like:

ISA*00* *00* *ZZ*562402607 *ZZ*383386347 *100312*0639*U*00401*000002331*0*P*:~GS*FA*562402607*383386347*20100312*06394602*2331*X*004010X098A1~ST*997*2331001~AK1*HC*275615~AK2*837*999999~AK5*A~AK9*A*1*1*1~SE*6*2331001~GE*1*2331~IEA*1*000002331~

Yes, there are no carriage returns in the file. They are optional. The segment separator is the tilde ("~").

I had Rhapsody create a message definition for the 997 file and then built a route that picked the following fields from the file.

• AK2-1 Is the Transaction Set ID (In the example message, the AK2 segment is “AK2*837*999999”, which makes AK2-1 “837”). The ack is for an 837 file.
• AK2-2 is the Transaction Set Control ID (In the example message, the AK2 segment is “AK2*837*999999”, which makes AK2-2 “999999”). This is the ID of the transaction that is being ack’d.
• AK5-1 is the Transaction Set Ack Code (In the example message, the AK5 segment is “AK5*A”, which makes AK5-1 “A”). The transaction set is acknowledged.
• AK9-1 is the Functional Group Ack Code (In the example message, the AK9 segment is “AK9*A”, which makes AK9-1 “A”). The functional group is acknowledged.

I then had the route build an email message using javascript that I send out using the email communication point in Rhapsody.

The script looks at the ack codes and sets text so that I don't have to remember what "R" means. That code looks like this:

if (TSackCode == "A") {
TSackMessage = "Accepted";
}
if (TSackCode == "E") {
TSackMessage = "Accepted, but errors were noted";
}
if (TSackCode == "R") {
TSackMessage = "Rejected";
}

There is similar code for the Functional Group Ack Code.

The email that gets built looks like this:

subject: X12 997 File Received from xxx: Accepted

Rhapsody received 997 Functional Ack Message from xxx for 837 - 999999
Transaction Set Acknowledgement Code is A: Accepted
Functional Group Acknowledgment Code is A: Accepted

The operators will still have the file to look at, should they wish to. We can get the computer to parse the message and send the results in an email. This email should make their job just a little bit easier, and, after all, don't computers exist to make our lives easier?

What is a Null Flavor and How is it Used?

I wrote this for the ONC CDA IG Consolidation project. Well, actually Keith Boone rewrote the first paragraph.

IT solutions are designed to store and manage data, but sometime we do not have the data for various reasons. Typically, in these cases, a special value, known as NULL is stored. There may be several reasons why the data isn’t available. In some cases, it may not be available or known, in others, it is not relevant, and in others it may not be computable or measurable. In HL7, these different reasons for why the data isn’t available are described as the flavor of NULL. This supports the management of the missing data. Let’s look an example.

If a patient arrives at an Emergency Department unconscious and with no identification, the system would represent the lack of information by use of a null flavor. The patient’s birth date would be unknown and would be represented using a null flavor. In this case, the appropriate null flavor would be “NAV” which is the code for “temporarily unavailable”. This information is not available, but is expected to be available later. In this example, when the patient regains consciousness or a relative arrives in the ER, we expect to know the patient’s birth date.

<birthTime nullFlavor=”NAV”/> /* coding an unknown birthdate */

Here is another example of using a null flavor for a patient who does not have a home phone.

<telecom nullFlavor=”NI” use="HP"/> /* coding a patient who does not have a home phone */

For those constraints that require the presence of an attribute that is unknown (SHALL be present with a cardinality of at least one (1..)), use a null flavor.

• NI = No Information. This is the most general and default null flavor.
• NA = Not Applicable. Known to have no proper value (e.g., last menstrual period for a male).
• UNK = Unknown. A proper value is applicable, but is not known.
• ASKU = asked, but not known. Information was sought, but not found (e.g., the patient was asked but did not know).
• NAV = temporarily unavailable. The information is not available, but is expected to be available later.
• NASK = Not Asked. The patient was not asked.

There are a handful of other codes. See the null flavor vocabulary table for the complete list.

A Document Interface

One of our trading partners is sending us clinical documents from their EHR system. These are plain text documents. The documents are being sent in HL7 v2.3 ORU^R01 messages.

They are sending us the document in a single OBX segment with line breaks in the OBX-5 field. I have seen other systems send each line in a separate OBX segment. I call that the "card punch" format, because each line of the report is on its own data card, just like the old days.

This is what one of the messages looks like:

MSH|^~\\&|DOC|K|DOC|WSUPG1|20110328082244||ORU^R01|Q1484927743T1489224997||2.3|||AL
PID|1|...
PV1|1|CD:123456||CD:9999|||0000000000^SMITH^ZACHARY|||...
ORC|RE||...
OBR|1||999999999|PROGN^Progress Note^^^xxx SICU Progress Note|||...
OBX|1|TX|PROGN^Progress Note||...NOTE GOES HERE~New Line~Another New Line||||||F|||20110328082242||

They are sending us the following document types (the left value is the code that I recieve, and the right side is the corresponding LOINC code):

DISCH^Discharge Summary ==> code="18842-5" displayName="DISCHARGE SUMMARIZATION NOTE"
PROGN^Progress Note ==> code="11506-3" displayName="Subsequent evaluation note"
HP^History and Physical ==> code="34117-2" displayName="History and Physical Note"
CONS^Consultation ==> code="11488-4" displayName="CONSULTATION NOTE"
OPRPT^Operative Report ==> code="11504-8" displayName="Surgical operation note"
ADMN^Admission Note ==> code="34862-9" displayName="Admission Evaluation Note"

The document type code appears in the OBR-4 field and the OBX-3 field. The project manager has me filtering out the H&P documents because they are not in scope for the first phase of the project. I added a filter to discard the H&P documents, and I will get to remove that later.

The only other interesting thing is that I have to look up the National Provider Identifier (NPI) for the providers in the PV1 segment. The remote system is sending us their provider ID, and we need the NPI to match on. So, I have a database look-up that retrieves the NPI and places that in the message. I am performing the look-up on the PV1-7 Attending Doctor, PV1-8 Referring Doctor and the PV1-9 Consulting Doctor fields. I then take whichever of these three fields has an NPI (and is therefore, one of our doctors) and place that value into PV1-7.

NextGen will match on PV1-7 and will place the document into the doctor's PAQ (Provider Approval Queue). The document was already signed by a doctor at the sending facility (unless it is a Progress Note, in which case it may be signed by a non-doctor), so our Doctor's are not really "approving" the document. This is just a way to ensure that our doctor's see the document.

NextGen will also add the document to the appropriate patient's chart.

We are doing some final testing on this interface before moving it into production.