ash wrote:
> Andrew McIntyre wrote:
>
>> Standard Encryption/signature is not enough and the digitally signed
>> data must not be encrypted. The format that has been developed embeds
>> the signature within the HL7 message and this satisfies all the Medicare
>> requirements.
>
> run that by me again ?
>
> it is possibly illegal (or at least unethical and forbidden in the ama
> guidelines for privacy) to send patient data unencrypted
>
> i hope that was a typo, 'cos it won't fly in the real world with anyone
> with a hint of technical literacy
>
Don't worry, it has wings, and flys quite well.
This is the long term storage format, or the payload and has nothing to
do with the messaging, which also encrypts and signs the whole thing.
The signature for Medicare purposes lives in the HL7 with the data,
where it should be. That way the data and signature are bound together
and the data in unencrypted. The signature can be stripped away from the
rest of the data if you don't want it.
When you send that message you use encryption and digital signature on
the whole thing.
For those with Technical literacy, here is the overview used for a
standards Australia meeting in April 2004. It can be used for Orders as
well.
Andrew McIntyre
----------------------------------------------------------------------
Problem: Signatures and ORU/Order messages
To Quote from the Electronic Transactions Act 1999
1.1 Where a medical practitioner:
Refers a patient to a specialist or consultant physician: or
Requests a pathology service; or
Requests a diagnostic imaging service,
by electronic means, HIC requires that the referral or requests:
a) Consist of either a standard e-mail message* , or a recognised EDI
format,
that is transmitted using HIC’s PKI standards;
b) Meet all the requirements for a Referral or Request provided in the
Act, the
regulations and the HI(PS) regulations; and
c) Be digitally signed by the referring/requesting practitioner using an
individual
private key for which there is a current public key certificate
recognised by the
HIC (in accordance with HIC’s PKI standards), to allow a specialist,
consultant physician, or Approved Pathology Practitioner or medical
practitioner to verify the authenticity of the Referral or Request upon
receipt.
While individual messages can be signed, it makes batch transmission
and passage through interface engines very difficult unless the message
is sent as a single message and the whole message is archived. This also
means that being able to verify the authenticity of a message requires
this file to be made available.
It would be much better to embed the signature in the message so that
only the data in the message was required to verify the authenticity at
any stage in the future. By using standard structures already in the
standard this data could reside in a message and be ignored if
verification was unavailable of not desired. Old applications would
simply process the data in the standard way without being able to
interpret it but without the need for any changes.
>From the point of view of the doctor and the HIC the important data is
content of the message, who it was on and what date it was created.
Data, such as name data is volatile over time and should be encapsulated
within the message so that the document can be sent under eg a married
name without invalidating the signature.
This is a scheme to do that. It is a tested and proven schema. It covers
PKI signatures and MD5 and SHA1 hashes. Hashes do not meet the ETA
requirements but may be useful when you wish to protect the integrity of
the data for other reasons.
The basic algorithm is to add 2 OBX segments to the end of an ORU
message. The first added OBX if FT (freetext) and contains the important
PID and OBR data such as the patient name, the test name and the date of
the test. This can be extended at will as it has to be generated prior
to signing the message and its actual content is not critical, basically
whatever data you wish to preserve over time. The second OBX contains
the actual signature data, which in the case of the HIC PKI is
encapsulated in a ED segment as it is binary. what is actually signed is
all the OBX data above the Last segment. This will include the first OBX
that was added.
eg: A simple Message:
MSH|^~\&|TEST^TESTAPP^L|Buderim GE
Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID|||20040410141133||ORU^R01...
PID|1||||PATIENT^Test^^^^^^L||20000101||||139 King
Street^^BUDERIM^QLD^4556^AU^C|AU
PV1|1|O||||||0341615J^WHITE^MELISSA^^^DR^^^AUSHICPR^L^^^UPIN|0341615J^WHITE^MELISSA^^^DR^^^AUSHICPR^L^^^UPIN|||||||N
ORC|CE||F71DEE61-D19E-4571-AF7B-BF8C74597CAB^Buderim GE
Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID||CM|||||||0341615J^WHITE^MELISSA^^^DR^^^AUSHICPR^L^UPIN^^UPIN
OBR|1||F71DEE61-D19E-4571-AF7B-BF8C74597CAB^Buderim GE Centre^7C3...
OBX|1|FT|28655-9^^LN||This a simple \H\Test Message\N\ To demonstrate
signing a...
OBX|2|SN|5048-4^ANA titre^LN||<^40|titre|||||F
now it is signed by a PKI key:
MSH|^~\&|TEST^TESTAPP^L|Buderim GE
Centre^7C3E3681-91F6-11D2-8F2C-444553540000^GUID|||20040410141133||ORU^R01|
PID|1||||PATIENT^Test^^^^^^L||20000101||||139 King
Street^^BUDERIM^QLD^4556^AU^C|AU
PV1|1|O||||||0341615J^WHITE^MELISSA^^^DR^^^AUSHICPR^L^^^UPIN|0341615J^WHITE^MELISSA^^^DR^^^AUSHICPR^L^^^UPIN|||||||N
ORC|CE||F71DEE61-D19E-4571-AF7B-BF8C74597CAB^Buderim GE
Centre^7C3E3681-91F6-11D2-8F2C-4445535400.....
OBR|1||F71DEE61-D19E-4571-AF7B-BF8C74597CAB^Buderim GE
Centre^7C3E3681-91F6-11D2-8F2....
OBX|1|FT|28655-9^^LN||This a simple \H\Test Message\N\ To de....
OBX|2|SN|5048-4^ANA titre^LN||<^40|titre|||||F
OBX|3|FT|SIGNATURE_HEADER^^L||PKI Signed Message\.br\Patient: PATIENT,
Test DOB:01.01.2000\.br\Report: Physician Discharge Summary Dated:
10.4.2004\.br\Signed: 10/04/2004 2:28:57 PM||||||F
OBX|4|ED|AUSETAV1^PKI
Signature^L||AUSHICPKI^AP^Octet-stream^Base64^MIIKTgYJKoZIhvcNAQcCoIIKPzCCCjsCAQExCzA..............||||||F
OBX 3 and 4 have been added. OBX 3 is simply to store relevant
ORC/OBR/PID data that needs to be signed. An application that doesn't
understand the signature should still cope with these segments.
To look at what is signed - which is where the algorithm comes in: (see
file 'SDataETA.txt')
FT.28655-9..LN......F..This a simple \H\Test Message\N\ To demonstrate
signing and \H\ORU\N\ message\.br\\.br\Another Line \.br\\.br\A few
encoded characters \F\\S\\T\//\.br\\.br\The end.
SN.5048-4.ANA titre.LN..titre....F...<.40...
FT.SIGNATURE_HEADER..L......F..PKI Signed Message\.br\Patient: PATIENT,
Test DOB:01.01.2000\.br\Report: Physician Discharge Summary Dated:
10.4.2004\.br\Signed: 10/04/2004 3:05:10 PM.
What is extracted are all the fields in OBX that affect display. The
reason for doing it this way is to overcome problems with and errors in
formatting (eg unneeded Field sperators) that may be in the original
message and to allow any system that stores the data to reconstruct this
at will so the signature can be validated at any time.
The exact same algorithm is used for MD5 hash and SHA1 hash versions.
You can run a seperate MD5 hash checker over the 'SDataMD5.txt' file and
get the same hash value as in the message (eg
http://www.whitsoftdev.com/md5/)
A similar process could be used for orders. What was ordered and who it
was ordered by can be added to the SIGNATURE_HEADER and an OBX added to
the order message that signs this data. Then you can "verify the
authenticity of the Referral or Request" at any time. The signature data
can be stored in the same way existing data is stored.
The required Identifiers are
AUSHICPKI - To indicate that this is a HIC PKI signature - used in
ED segment
AUSETAV1 - To indicate that this OBX contains PKI signature data -
should have a version number to indicate algorithm (ED Segment)
AUSSHA1HASH - To indicate that this is a SHA1 hash of the message
(Base 64 encoded in ST segment as short)
AUSMD5HASH - To indicate that this is a MD5 hash of the message (in
ST segment as usually Hex encoded)
Example files are included that show the 3 variations.
The algorithm treats each OBX in a standard way, obviously each datatype
has to be treated differently but basically every field is seperated by
a '.' (Fullstop) and each OBX segment by a <CR><LF> sequence. If a field
is blank then the fullstop is still written. A few fields of some
datatypes have been ommitted, usually because of optional, non critical
values in these fields. In general ST/FT and SN will cover 99% of the
segments but it is possible to encode any datatype. The order of the
fields in the specification is used to write the values, with the one
exception of the Observation value in OBX which is written last for
every OBX. Pseudo code for this is detailed below.
Build a string to sign or hash
For each OBX in order add these values (include SIGNATURE_HEADER OBX)
{
OBX.Value_Type
'.'
OBX.Observation_Identifier.Identifier
'.'
OBX.Observation_Identifier.Text
'.'
OBX.Observation_Identifier.NameOfCodingSystem
'.'
OBX.Observation_SubID
'.'
OBX.Units.Identifier
'.'
OBX.Units.Text
'.'
OBX.Units.NameOfCodingSystem
'.'
OBX.References_Range
'.'
for each OBX.Abnormal Flags
OBX.Abnormal_Flags[i]
'.'
OBX.Status <-or 'F' if blank
'.'
OBX.Date_Of_Observation
'.'
Then add all field values for Result values
Depends on value type but for example
SN - Structured Numeric
SN.Comparator
'.'
SN.Num1
'.'
SN.Separator
'.'
SN.Num2
'.'
Now add <CR><LF>
}
Now check or create detached signature/hash on resulting string
SubType Handling
SN as above
FT/ST/DT/TS
for each observation value
Add Text
Add '.'
These are less comon but could appear
XCN
for each observation value
Add IDNumber
Add '.'
Add FamilyName
Add '.'
Add GivenName
Add '.'
Add MiddleName
Add '.'
Add Suffix
Add '.'
Add Prefix
Add '.'
XPN
for each observation value
Add FamilyName
Add '.'
Add GivenName
Add '.'
Add MiddleName
Add '.'
Add Suffix
Add '.'
Add Prefix
Add '.'
ED
for each observation value
Add SourceApplication.NameSpaceID
Add '.'
Add SourceApplication.UniversalID
Add '.'
Add SourceApplication.UniversalIDType
Add '.'
Add MainTypeData
Add '.'
Add DataSubType
Add '.'
Add Encoding
Add '.'
Add Data
Add '.'
RP
for each Observation value
Add Pointer
Add '.'
Add TypeOfData
Add '.'
Add ApplicationID.NameSpaceID
Add '.'
Add ApplicationID.UniversalID
Add '.'
Add ApplicationID.UniversalIDType
Add '.'
Add SubType
Add '.'
EI
for each Observation value
Add EntityIdentifier
'.'
Add NameSpaceID
'.'
Add UniversalID
'.'
Add UniversalIDType
'.'
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
