Mirth Connect is the Swiss Army knife of open source integration engines with specific Healthcare support for HL7 message integration. Internally, it uses Rhino as its JavaScript engine. Having the power of both native JavaScript AND the additional power of calling Java from script is extremely powerful but the lack of debugger function in Mirth Connect can make it painful too.
However, Rhino does have a built-in shell and with a simple command line we can invoke the Rhino shell.
From Windows, the easiest way to do this is to create a shortcut with the following parameters (you may need to change the path to Java depending on the version you are running):
Target: "C:\Program Files\Java\jre1.8.0_65\bin\java.exe" -cp "*;../custom-lib/*" org.mozilla.javascript.tools.shell.Main -strict
Start in: "C:\Program Files\Mirth Connect\client-lib"
The parameters passed are "-cp" which sets the class path. In this case, we want all the Mirth Connect JAR files in the main lib folder and anything in the custom-lib folder too. The "-strict" option turns on Strict Mode.
Now, when you launch the shortcut you will find yourself looking at a "js>" command prompt as follows:
js> print('hi')
hi
js> 6*7
42
js> function f() {
return a;
}
js> var a = 34;
js> f()
34
js> quit()
Some useful commands to know:
help() -- Displays a list of commands
quit() -- Closes the JavaScript shell
Don't forget to check out the Rhino Documentation too!
Tuesday, July 12, 2016
Thursday, July 7, 2016
Mirth HL7 to PDF example
Quick example of taking an HL7 message, in this case lab results, and creating a PDF document out of them. Below is an example HL7 message, but keep reading if you want a simple walk through.
PID|1||Z000001078||DOE^JOHN||19500213|M||CA|123 STREET^^KINGSPORT^TN^37660|||||M|||999-99-9999||||||||||||
OBR|1|1973^LAB||BMP^BASIC METABOLIC PANEL^L|||200909301134|||||||200909301134||SLOCA^STRANGE^CARL^W^^^MD||||||||LAB|F||^^^^^R|||||||||||||||||
OBX|1|ST|GLU^GLUCOSE,RANDOM^L||100|mg/dL|74-106|N||A^S|F|||200909301134|ML^MAIN LAB^L|||
OBX|2|ST|BUN^BLOOD UREA NITROGEN^L||10|mg/dL|9-20|N||A^S|F|||200909301135|ML^MAIN LAB^L|||
OBX|3|ST|CRE^CREATININE^L||3.0|mg/dL|0.8-1.5|H||A^S|F|||200909301135|ML^MAIN LAB^L|||
OBX|4|ST|BCRAT^BUN/CREATININE RATIO^L||1.9|RATIO|7.0-25.0|L||A^S|F|||200909301135|ML^MAIN LAB^L|||
OBX|5|ST|NA^SODIUM LEVEL^L||130|mEq/L|137-145|L||A^S|F|||200909301135|ML^MAIN LAB^L|||
OBX|6|ST|K^POTASSIUM LEVEL^L||3.0|mEq/L|3.5-5.1|L||A^S|F|||200909301135|ML^MAIN LAB^L|||
OBX|7|ST|CL^CHLORIDE LEVEL^L||97|mEq/L|98-107|L||A^S|F|||200909301135|ML^MAIN LAB^L|||
OBX|8|ST|CO2^CARBON DIOXIDE LEVEL^L||31|mEq/L|22-30|H||A^S|F|||200909301135|ML^MAIN LAB^L|||
OBX|9|ST|CA^CALCIUM LEVEL^L||9.7|mg/dL|8.4-10.2|N||A^S|F|||200909301135|ML^MAIN LAB^L|||
OBX|10|ST|GFR^GLOMERULAR FILTRATION RATE^L||22|ml/min|80-120|L||A^S|F|||200909301135|ML^MAIN LAB^L|||
So, we have lab results coming to us in HL7 ORU messages. Maybe we are going to route these to a listener on our EMR, but lets say that for some reason we also want to create PDF files for results that may get printed, or faxed to a referring provider’s office, etc… What we want to end up with is something that looks like the following:
We can get there with 10 transformer steps, and a little HTML in a Document Writer destination.
First up, let’s think about what the end result HTML should look like. In cases where I’ve needed to create a PDF file using Mirth Connect, I’ll create an example of the HTML by hand and then think about where pieces of data from my incoming message will live there. That said, the HTML to create the report above looks like:
<body>
<div align="center">
<h1>Laboratory Result Report</h1>
<hr>
</div>
<h2 style="color: #990000;">BASIC METABOLIC PANEL</h2>
<h3>Result Date: 09/30/2009</h3>
<h3>Stage: Final</h3>
<ul>
<li><u>MRN:</u> Z000001078</li>
<li><u>Name:</u> DOE, JOHN</li>
<li><u>DOB:</u> 02/13/1950</li>
<li><u>Address:</u> 123 STREET KINGSPORT, TN 37660</li>
</ul>
<table border="1">
<thead>
<tr>
<th colspan="2">Test</th>
<th>Result</th>
<th>Flag</th>
<th>Reference Range</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<td>GLUCOSE,RANDOM</td>
<td>100 mg/dL</td>
<td>N</td>
<td>74-106 mg/dL</td>
</tr>
<tr>
<td>
<td>BLOOD UREA NITROGEN</td>
<td>10 mg/dL</td>
<td>N</td>
<td>9-20 mg/dL</td>
</tr>
<tr>
<td><img src="/mirth/graphics/flag_red.png"></td>
<td>CREATININE</td>
<td>3.0 mg/dL</td>
<td>H</td>
<td>0.8-1.5 mg/dL</td>
</tr>
.
.
.
</tbody>
</table>
<ul>
<li><u>Ordered By:</u> CARL STRANGE MD</li>
<li><u>Stage:</u> Final</li>
</ul>
</body>
</html>
HTML similar to that above is what needs to ultimately be in the Template of your Document Writer destination in Mirth Connect.
Most of the data that we need to create our HTML can be gathered directly from our incoming HL7 message and added to the Channel Map using simple Mapper transformation steps. For example, the patient’s last name:
In fact, the only somewhat complicated thing that is going on happens in the Javascript transformer step titled “Create Results Table”. In this step, we are looping over all the OBX segments contained in the incoming HL7 message to create an HTML table structured for each resultable item. Have a peek at that code here:
var tr;
for each (mOBX in msg..OBX) {
tr = new XML('<tr></tr>');
tr['td'][0] = '';
if (mOBX['OBX.8']['OBX.8.1'].toString() != "N") {
tr['td'][0]['img']['@src'] = '/mirth/graphics/flag_red.png';
}
// Test Name
tr['td'][1] = mOBX['OBX.3']['OBX.3.2'].toString();
// Result
tr['td'][2] = mOBX['OBX.5']['OBX.5.1'].toString() + " "+ mOBX['OBX.6']['OBX.6.1'].toString();
// Flag - Red if not N = normal
tr['td'][3] = mOBX['OBX.8']['OBX.8.1'].toString();
// Reference range
tr['td'][4] = mOBX['OBX.7']['OBX.7.1'].toString() + " " + mOBX['OBX.6']['OBX.6.1'].toString();
results[''] += tr;
}
channelMap.put("Results",results);
Note where I’m specifying an image to be used when a resultable item is abnormal. This path is relative to the root of the drive that you have Mirth installed on. If Mirth were installed on the C drive, so the path used (/mirth/graphics/flag_red.png) would mean C:\mirth\graphics\flag_red.png.
All of the transformations are happening on the Source. So heading into the Destinations, we have 10 different pieces of data in our Channel Map ready to be used in the HTML template used by the Document Writer. The channel map variables are:
- LastName
- FirstName
- MRN
- DOB
- Address
- TestName
- ResultStatus
- ResultDateTime
- OrderingProvider
- Results
All that’s left is to fill out the Document Writer destination to have our PDF files written to disk:
Stepping through the above screen…
Directory
In my example, I’ll be writing to/mirth/results_pdf/${date.get(‘yyyyMMdd’)}/${OrderingProvider}/. That first bit is the file system location (adjust to your needs). The second two pieces are potentially variable depending on the message.
- ${date.get(‘yyyyMMdd’)} → Will append the date (as in 20160701) to the end of the specified filesystem location.
- {OrderingProvider} → Appends the value of the Channel Map variable OrderingProvider which we set in the Source Transformer to the end of the filesystem location.
So for our example, the complete filesystem location where the PDF will be written will be something like /mirth/results_pdf/20160701/CARL STRANGE MD. Please note that you will need to be sure that Mirth Connect has rights to create directories in the filesystem you specify.
File Name
The name of the file that will be written into the directory specified by Directory. In this example I’m using LabResult-${SYSTIME}.pdf. This will result in a filename similar to LabResult-1282176369728.pdf.
Document Type
PDF of course.
Encrypted
I have set to No, you can of course set to Yes and then specify a password on the following line.
Template
The meat of it all. First the full template I’m specifying:
<div align="center"><h1>Laboratory Result Report</h1><hr /></div>
<h2 style="color: #990000;">${TestName}</h2>
<h3>Result Date: ${ResultDateTime}</h3>
<h3>Stage: ${ResultStatus}</h3>
<ul>
<li><u>MRN:</u> ${MRN}</li>
<li><u>Name:</u> ${LastName}, ${FirstName}</li>
<li><u>DOB:</u> ${DOB}</li>
<li><u>Address:</u> ${Address}</li>
</ul>
<table border="1">
<thead>
<tr>
<th colspan="2">Test</th>
<th>Result</th>
<th>Flag</th>
<th>Reference Range</th>
</tr>
</thead>
${Results}
</table>
<ul>
<li><u>Ordered By:</u> ${OrderingProvider}</li>
<li><u>Stage:</u> ${ResultStatus}</li>
</ul>
</html>
In every spot in the above template you see something surrounded by ${} we are substituting one of our Channel Map variables. Also, compare the above template with the final HTML output example earlier in this post to get an idea of what the channel map replacements will look like.
Notes
- This is a simple example. I’m not taking into account the potential for NTE segments in the results file. Could be added without much trouble.
- There is an assumption of one result per message (no multiple ORC segments for example).
If you haven’t had a need yet to create PDF documents using Mirth Connect, hopefully this post will give you a pointer. This should be a good starting point for anyone attempting to output PDF files from HL7 messages.
Wednesday, July 6, 2016
Simulating SMTP for a Testing Environment in Mirth
Recently I was writing and testing a channel that would send an email alerting a provider if one of their patients were admitted to an emergency room or urgent care clinic. While I was testing the channel I didn't want the emails to leave my sandbox, and I also didn't want to go through the set up of a whole email system just for a single channel.
As a solution I came across a really nifty java app called FakeSMTP.
FakeSMTP intercepts all email traffic sent through localhost and simulates a full smtp server. All I had to do was double click the jar and set my instance of Mirth to use localhost as the smtp server.
Once I had done that I was able to see all the emails Mirth was sending and even open them in outlook to see how they would actually appear.
You can get FakeSMTP here.
As a solution I came across a really nifty java app called FakeSMTP.
FakeSMTP intercepts all email traffic sent through localhost and simulates a full smtp server. All I had to do was double click the jar and set my instance of Mirth to use localhost as the smtp server.
Once I had done that I was able to see all the emails Mirth was sending and even open them in outlook to see how they would actually appear.
You can get FakeSMTP here.
Tuesday, July 5, 2016
Remote Failover in Mirth Connect
This is a script that polls a remote Mirth Connect server for the status of it's channels. If a channel specified in 'monitor_list' is not started (or starting), it will auto-deploy a local failover channel and then auto-undeploy the same channel once it detects the primary channel starting.
URL: 'https://localhost:8443',
user: 'admin',
pass: 'admin',
version: '3.0.3.7171',
timeout: 10000
};
function monitor(channel,state){
var channel_failover = channel+"_failover"
if(state=="Starting"){
logger.info("Primary Channel: "+channel+" starting. Undeploying failover channel.");
ChannelUtil.undeployChannel(channel_failover);
}
else if(state!="Started"){
if(!ChannelUtil.isChannelDeployed(channel_failover)){
logger.info("WARNING! CHANNEL FAILURE! Channel: "+channel+" Recorded @ "+DateUtil.getCurrentDate("yyyyMMdd@HH:mm:ss"));
ChannelUtil.deployChannel(channel_failover);
logger.info("Deploying Failover Channel");
}
else{
if(ChannelUtil.getChannelState(channel_failover)=="Started"){
}
else{
ChannelUtil.startChannel(channel_failover);
}
}
}
return;
}
var monitor_list = [];
monitor_list[0] = "Remote_Failover_Test";
var monitorLog = {"Remote_Failover_Test" : "FAILED"};
var client = new com.mirth.connect.client.core.Client(info.URL,info.timeout);
var loginStatus = client.login(info.user,info.pass,info.version);
var status = client.getChannelStatusList().toString().split("channelId=");
var statLen = status.length-1;
var subStatus;
var chaName;
var chaState;
for(var i=1;i<=(statLen);i++){
subStatus = status[i].split(",lifetimeStatistics=")[0];
if(subStatus.indexOf("deployedDate=<null>")<0){
chaName = subStatus.split("name=")[1].split(",state=")[0].toString();
chaState = subStatus.split(",state=")[1].split(",")[0].toString();
for(var k in monitor_list){
if(monitor_list[k] == chaName){
monitorLog[chaName]=chaState;
}
}
}
}
for(var k in monitorLog){
//logger.info(k+" "+monitorLog[k]);
monitor(k,monitorLog[k]);
}
return;
URL: 'https://localhost:8443',
user: 'admin',
pass: 'admin',
version: '3.0.3.7171',
timeout: 10000
};
function monitor(channel,state){
var channel_failover = channel+"_failover"
if(state=="Starting"){
logger.info("Primary Channel: "+channel+" starting. Undeploying failover channel.");
ChannelUtil.undeployChannel(channel_failover);
}
else if(state!="Started"){
if(!ChannelUtil.isChannelDeployed(channel_failover)){
logger.info("WARNING! CHANNEL FAILURE! Channel: "+channel+" Recorded @ "+DateUtil.getCurrentDate("yyyyMMdd@HH:mm:ss"));
ChannelUtil.deployChannel(channel_failover);
logger.info("Deploying Failover Channel");
}
else{
if(ChannelUtil.getChannelState(channel_failover)=="Started"){
}
else{
ChannelUtil.startChannel(channel_failover);
}
}
}
return;
}
var monitor_list = [];
monitor_list[0] = "Remote_Failover_Test";
var monitorLog = {"Remote_Failover_Test" : "FAILED"};
var client = new com.mirth.connect.client.core.Client(info.URL,info.timeout);
var loginStatus = client.login(info.user,info.pass,info.version);
var status = client.getChannelStatusList().toString().split("channelId=");
var statLen = status.length-1;
var subStatus;
var chaName;
var chaState;
for(var i=1;i<=(statLen);i++){
subStatus = status[i].split(",lifetimeStatistics=")[0];
if(subStatus.indexOf("deployedDate=<null>")<0){
chaName = subStatus.split("name=")[1].split(",state=")[0].toString();
chaState = subStatus.split(",state=")[1].split(",")[0].toString();
for(var k in monitor_list){
if(monitor_list[k] == chaName){
monitorLog[chaName]=chaState;
}
}
}
}
for(var k in monitorLog){
//logger.info(k+" "+monitorLog[k]);
monitor(k,monitorLog[k]);
}
return;
Tuesday, June 28, 2016
Passing Database Results to Outbound Messages in Mirth Connect
Recently I had an interoperability project that required reading from a database at regular intervals, and then feeding the information out through an ORU message. Because this was the first time in a while where I had to read FROM the database, it took me a minute before I was reminded that parsing the resultant data doesn't work quite the same as your typical 2.X/3.X/XML message.
On the plus side, Mirth Connect makes it very easy to handle database results. For a very simple example, start by creating a channel, set the source type to "Database Reader", and set the response to "Destination 1". In the SQL textarea put your query, and set up the rest of the source connector according to your system requirements.
Here is a screenshot of my example setup.
Once you have your source connector set-up, you can either choose to handle the message using source transformers, or pass the message to a destination transformer.
If you pass the results to a destination it is important to note that you will need to create a reference to the message that will be passed to the destination.
A simple way of doing that is to add a javascript step into the source transformer and include the following code:
tmp = msg;
This tells Mirth to send the results onward as a feeder message for the destination transformer.
Now comes the best part about handling database results.
You can now call all of your results in the destination using the column name as the reference!
For example, if I wanted to get the value from the "msg_id" column, I can write something like this:
var msg_id = msg["msg_id"].toString();
The basic syntax for getting the values is:
localVariableName = msg["columnName"].toString();
(This syntax will work in both source and destination connectors as long as somewhere in the source connector you add the tmp = msg; command.)
Now I can use that variable to insert a value into the outbound message, affect the logic for further processing, or output to a file.
On the plus side, Mirth Connect makes it very easy to handle database results. For a very simple example, start by creating a channel, set the source type to "Database Reader", and set the response to "Destination 1". In the SQL textarea put your query, and set up the rest of the source connector according to your system requirements.
Here is a screenshot of my example setup.
Once you have your source connector set-up, you can either choose to handle the message using source transformers, or pass the message to a destination transformer.
If you pass the results to a destination it is important to note that you will need to create a reference to the message that will be passed to the destination.
A simple way of doing that is to add a javascript step into the source transformer and include the following code:
tmp = msg;
This tells Mirth to send the results onward as a feeder message for the destination transformer.
Now comes the best part about handling database results.
You can now call all of your results in the destination using the column name as the reference!
For example, if I wanted to get the value from the "msg_id" column, I can write something like this:
var msg_id = msg["msg_id"].toString();
The basic syntax for getting the values is:
localVariableName = msg["columnName"].toString();
(This syntax will work in both source and destination connectors as long as somewhere in the source connector you add the tmp = msg; command.)
Now I can use that variable to insert a value into the outbound message, affect the logic for further processing, or output to a file.
Friday, June 24, 2016
What is an HL7 ADT Message?
Patient Admission Discharge and Transfer (ADT) messages are used to exchange the patient state within a healthcare facility. HL7 ADT messages keep patient demographic and visit information synchronized across healthcare systems.
ADT is the most commonly used HL7 messaging type, with most clinical applications enabled to receive key ADT messages.
ADT messages within the HL7 standard are typically initiated by the Hospital Information Systems (HIS), or a registration application, to inform ancillary systems that a patient has been admitted, discharged, transferred, merged, that other demographic data about the patient has changed (name, insurance, next of kin, etc.) or that some visit information has changed (patient location, attending doctor, etc.).
ADT Trigger Events
A trigger event is the underlying reason for transmitting a message, e.g. “Patient has been admitted to the hospital”, “Patient address has changed”, or “Patient has moved from room 11 to room 20”. As soon as a trigger happens, a message is sent to all systems that have an interest in that particular type of information, enabling the receiving application to synchronize it’s database with the data as known by the sender of the message.
Examples of ADT trigger events (coded A01 up to A62) include:
- A01: Admit notification – an inpatient encounter has started. The patient has been admitted and has been assigned to a location (room or bed)
- A02: Transfer notification – a patient has been transferred from one location to another one.
- A03: Discharge notification – the encounter has ended. The prior location assigned to the patient is made available for use by another patient.
- A04: Patient registration notification – an outpatient encounter has started.
- A05: Pre-admit a patient notification – the pre-admission process of a patient has started; registration of a non-admitted patient.
- A08: Update patient information notification – unspecified details of the encounter or the patient demographics data have changed. This trigger event represents a “other changes” category if a more suitable Axx trigger event doesn’t exist.
- A11: Cancel admit notification – the start of an inpatient encounter, for which a previous admit notification message was sent, has been cancelled.
- A12: Cancel transfer notification – the location transfer, for which a previous transfer notification message was sent, has been cancelled.
- A13: Cancel discharge notification – the end of an inpatient encounter, for which a previous discharge notification message was sent, has been cancelled.
- A40: Merge patient identifier list notification – two or more patient records, each identified using a different set of patient identifiers, have been merged.
Even though the standard itself doesn’t explicitly define a sequence in which these trigger events occur, it seems clear that normally a patient has to be admitted (A01) before he or she can be transferred (A02) and discharged (A03).
An “admit patient” message (A01 “event”) is used for “Admitted” patients only. These messages are sent as a result of patients beginning their stay in the healthcare facility. Normally, this information is entered in the hospital information system and broadcast to nursing units and ancillary systems. A admission message (A01 event) should be used to notify the pharmacy database of a patient’s arrival in the healthcare facility.
| Segment | Description |
| MSH | Message Header |
| EVN | Event Type |
| PID | Patient Identification |
| PV1 | Patient Visit |
| [{OBX}] | Observation / Result |
| [{AL1}] | Patient Allergy Information |
| [{DG1}] | Diagnosis Information |
Sample Message Sent From Hospital Information System:
MSH|^~\&|hmis|1|||20050110045504||ADT^A01|599102|P|2.3||| EVN|A01|20050110045502||||| PID|1||10006579^^^1^MRN^1||DUCK^DONALD^D||19241010|M||1|111 DUCK ST^^FOWL^CA^999990000^^M|1|8885551212|8885551212|1|2||40007716^^^AccMgr^VN^1|123121234|||||||||||NO NK1|1|DUCK^HUEY|SO|3583 DUCK RD^^FOWL^CA^999990000|8885552222||Y|||||||||||||| PV1|1|I|PREOP^101^1^1^^^S|3|||37^DISNEY^WALT^^^^^^AccMgr^^^^CI|||01||||1|||37^DISNEY^WALT^^^^^^AccMgr^^^^CI|2|40007716^^^AccMgr^VN|4|||||||||||||||||||1||G|||20050110045253|||||| GT1|1|8291|DUCK^DONALD^D||111^DUCK ST^^FOWL^CA^999990000|8885551212||19241010|M||1|123121234||||#Cartoon Ducks Inc|111^DUCK ST^^FOWL^CA^999990000|8885551212||PT| DG1|1|I9|71596^OSTEOARTHROS NOS-L/LEG ^I9|OSTEOARTHROS NOS-L/LEG ||A| IN1|1|MEDICARE|3|MEDICARE|||||||Cartoon Ducks Inc|19891001|||4|DUCK^DONALD^D|1|19241010|111^DUCK ST^^FOWL^CA^999990000|||||||||||||||||123121234A||||||PT|M|111 DUCK ST^^FOWL^CA^999990000|||||8291 IN2|1||123121234|Cartoon Ducks Inc|||123121234A|||||||||||||||||||||||||||||||||||||||||||||||||||||||||8885551212 IN1|2|NON-PRIMARY|9|MEDICAL MUTUAL CALIF.|PO BOX 94776^^HOLLYWOOD^CA^441414776||8003621279|PUBSUMB|||Cartoon Ducks Inc||||7|DUCK^DONALD^D|1|19241010|111 DUCK ST^^FOWL^CA^999990000|||||||||||||||||056269770||||||PT|M|111^DUCK ST^^FOWL^CA^999990000|||||8291 IN2|2||123121234|Cartoon Ducks Inc||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||8885551212 IN1|3|SELF PAY|1|SELF PAY|||||||||||5||1
A “transfer patient” message (A02 event) should be sent to the interface when a patient is transferred to another ward, room or bed.
| Segment | Description |
| MSH | Message Header |
| EVN | Event Type |
| PID | Patient Identification |
| PV1 | Patient Visit |
Sample Message Sent From Hospital Information System:
MSH|^~\&|hmis|1|||20050110114442||ADT^A02|59910287|P|2.3||| EVN|A02|20050110114442||||| PID|1||10006579^^^1^MRN^1||DUCK^DONALD^D||19241010|M||1|111^DUCK ST^^FOWL^CA^999990000^^M|1|8885551212|8885551212|1|2||40007716^^^AccMgr^VN^1|123121234|||||||||||NO PV1|1|I|IN1^214^1^1^^^S|3||PREOP^101^|37^DISNEY^WALT^^^^^^AccMgr^^^^CI|||01||||1|||37^DISNEY^WALT^^^^^^AccMgr^^^^CI|2|40007716^^^AccMgr^VN|4|||||||||||||||||||1||I|||20050110045253||||||
A “discharge patient” or “end visit” message (A03 event) should be sent when an inpatient’s stay in the healthcare facility is ended, or an outpatient or emergency room visit is ended. It signals that the patient’s status has changed to “discharged”, that a discharge date/time has been assigned, and that the patient no longer requires services normally provided through the pharmacy database.
| Segment | Description |
| MSH | Message Header |
| EVN | Event Type |
| PID | Patient Identification |
| PV1 | Patient Visit |
Sample Message Sent From Hospital Information System:
MSH|^~\&|AccMgr|1|||20050112154645||ADT^A03|59912415|P|2.3||| EVN|A03|20050112154642||||| PID|1||10006579^^^1^MRN^1||DUCK^DONALD^D||19241010|M||1|111^DUCK ST^^FOWL^CA^999990000^^M|1|8885551212|8885551212|1|2||40007716^^^AccMgr^VN^1|123121234|||||||||||NO PV1|1|I|IN1^214^1^1^^^S|3||IN1^214^1|37^DISNEY^WALT^^^^^^AccMgr^^^^CI|||01||||1|||37^DISNEY^WALT^^^^^^AccMgr^^^^CI|2|40007716^^^AccMgr^VN|4||||||||||||||||1|||1||P|||20050110045253|20050112152000|3115.89|3115.89|||
A “register patient” message (A04 event) signals that the patient has arrived or checked in as an outpatient, recurring outpatient, or emergency room patient. Note: Users may be able to configure their system to process, or not process (ignore), some (or all) outpatient and emergency room registrations; in either case an “application accept” acknowledgement will be returned to the sender.
This message uses the same segments as the “admit patient” (A01) message.
A “pre-admission” message (A05 event) is sent to notify the interface of a patient pre-admission process. This message can also be used to pre-register an outpatient or emergency room patient. Note: Users may be able to configure their system to process, or not process (ignore), this message type; in either case an “application accept” acknowledgement will be returned to the sender.
This message uses the same segments as the “admit patient” (A01) message.
A “change outpatient to inpatient” message (A06 event) is sent when an outpatient or ER patient is being admitted as an inpatient. This message should signal the interface to changes a patient’s status from outpatient/ER to inpatient/admitted. If a patient is pre-registered (not registered) as an outpatient and then admitted as an inpatient, an “admission” message (A01 event) should be sent instead.
This message uses the same segments as the “admit patient” (A01) message.
A “change inpatient to outpatient” message (A07 event) is sent when an inpatient becomes an outpatient and is still receiving care/services.
This message uses the same segments as the “admit patient” (A01) message.
This message (A08 event) is used when any patient information has changed but when no other ADT event has occurred. For example, visit information updates.
This message uses the same segments as the “admit patient” (A01) message.
For inpatients, the “cancel admission” message (A11 event) is sent when an earlier “admission” message (A01 event) is canceled, either because of an erroneous entry or because of a revised decision to not admit the patient. For outpatients/ER patients, the message is sent when an earlier “register outpatient” message (A04 event) is canceled for similar reasons. If the patient has orders on file, the patient will be discharged by the application. If no orders are on file, the patient’s record will be deleted.
This message uses the same segments as the “discharge patient” (A03) message.
The “cancel transfer” message (A12 event) is intended to reverse an earlier “transfer” message, either because of an erroneous entry or because of a revised decision to not transfer the patient. This message uses the same segments as the “transfer patient” (A02) message and, for inbound messages, is treated as a second transfer.
The “cancel discharge” message (A13 event) is sent when an earlier “discharge patient” message (A03 event) is canceled, either because of erroneous entry or because of a revised decision to not discharge, or end the visit of, the patient.
This message uses the same segments as the “admit patient” (A01) message.
The “swap patients” message (A17 event) is used to identify two patients that have exchanged beds. The interface will process inbound A17 events, but does not support this event for outbound messages.
| Segment | Description |
| MSH | Message Header |
| EVN | Event Type |
| PID | Patient Identification (patient #1) |
| PV1 | Patient Visit (patient #1) |
| PID | Patient Identification (patient #2) |
| PV1 | Patient Visit (patient #2) |
For inbound messages, the “merge records” message (A18 event) is used to combine two patient records into one. This may be used if a second, unwanted record for the same patient has been created accidentally by the other system. The interface does not support A18 events for outbound messages. [Note: To update patient medical record numbers, the interface sends outbound A36 event messages; to update patient account numbers, outbound A35 event messages are sent.]
| Segment | Description |
| MSH | Message Header |
| EVN | Event Type |
| PID | Patient Identification |
| MRG | Merge Information |
| PV1 | Patient Visit |
The “delete record” message (A23 event) is recognized by the interface for inbound messages and processed in the same manner as a “cancel admission” (A11 event) message. The “delete record” (A23) event is not supported for outbound ADT messages.
This message uses the same segments as the “discharge patient” (A03) message.
The “update person” message (A31 event) is recognized by the interface for inbound messages and processed in the same manner as a “update patient information” (A08 event) message. The “update person” (A31) event is not supported for outbound ADT messages.
| Segment | Description |
| MSH | Message Header |
| EVN | Event Type |
| PID | Patient Identification |
| PV1 | Patient Visit |
| [{OBX}] | Observation / Result |
| [{AL1}] | Patient Allergy Information |
The “change account number” (A35 event) is used to update the patient’s account number. This might be used if a patient record is entered with an incorrect account number.
| Segment | Description |
| MSH | Message Header |
| EVN | Event Type |
| PID | Patient Identification |
| MRG | Merge Information |
For inbound messages, the “change medical record no and account no” (A36 event) may be used to update the patient’s medical record number and/or account number. For outbound messages, the interface uses this event to update medical record number only. Outbound updates to patient account number are done via a “change patient account number” message (A35 event).
This message uses that same segments as the “change patient account number” (A35 event) message.
Subscribe to:
Posts (Atom)