-
Notifications
You must be signed in to change notification settings - Fork 7
HL7v2 Implementation Notes
SanteDB support HL7v2.5 messages, and will convert other message versions to 2.5 before continuing processing. HL7v2.5 was selected because it retains useful features while maximizing compatibility.
SanteDB has additional security measures which require special profiling of v2 messages. For HL7v2 messaging, SanteDB establishes a userless session (Device/Application principal only). The method which SanteDB uses for this depends on the configuration option (see below):
<marc.hi.ehrs.svc.messaging.hapi security="None|Msh8|Sft4">
...
Note that unless security="None" you must configure SecurityDevice and SecurityApplication instances according to the instructions below.
When using SLLP transport, the configuration is as follows:
| Property | SecurityDevice | SecurityApplication |
|---|---|---|
| Name | MSH-3 | MSH-4 |
| Secret | X509 Thumprint | SFT-4 when Sft4 security is used |
| MSH-8 when Msh8 security is used |
When using LLP or regular TCP transport for HL7v2 messages, the configuration properties are as follows:
| Property | SecurityDevice | SecurityApplication |
|---|---|---|
| Name | MSH-3 | MSH-4 |
| Secret | MSH-8 | SFT-4 when Sft4 security is used |
| MSH-8 when Msh8 security is used |
For example, if you have device TEST_HARNESS|TEST with secret DEVICESECRET and application TEST_HARNESS with secret APPLICATIONSECRET your HL7v2 message at minimum would be:
MSH|^~\&|TEST_HARNESS|TEST||||DEVICESECRET|||
SFT||||APPLICATIONSECRET
If you already have an established user session (from OAUTH or some other mechanism), you can contact the SanteDB instance using either SLLP or LLP with a session identifier in MSH-8. Note the session must be valid and must be the value of access_token in the OAUTH response.
MSH|^~\&|TEST_HARNESS|TEST||||sid://E126DB753B3E044D8E80371E00A8170155989B0C5CF1BEB28BBD528F75146D65294289D97EE7EB6AD13EBBC301A16CA6|||
In an HL7v2 message the PID-23 segment allows for the specification of a plain-text (ST) birthplace. Unfortunately this field in SanteDB requires an actual Place or Organization to be linked. In order to overcome this, it is recommended using the official name of the birthplace or the UUID of the birthplace to be linked.
For dedicated service delivery locations, the PD1-3 information should be specified. For example, if we use the Elbonia sample dataset, and we wanted to indicate that BABY JOE was born at GOOD HEALTH HOSPITAL and his primary delivery location is GOOD HEALTH HOSPITAL we would represent as:
PID|||TC-2^^^TEST||BABY^JOE^^^^^L|MURRAY^^^^^^L|20180923|M|||1220 Main St.^^MAIN^ON^L8K5N2||||||||||||Good Health Hospital|||CA
PD1|||Good Health Hospital^^^^^SanteDB1^^^^fd0d2a08-8e94-402b-84b6-cb3bc0a576a9|||||||||Y