Thanks for the clarification, I think I was a bit confused.  I was working from an existing SOP which may be wrong, but as it is based on the assumption that we don't have a CA. (Our organisation is the client sending messages to the vendors server)

The SOP (summarised) is:

1. Client generates private key(a) and certificate request(b)
   (openssl req -new -keyout privatekey.pem -out request.crs -days 9125 -newkey rsa:2048 -sha1  [2])
2. the certificate request(b) is sent (securely) to vendor
3. the vendor signs the certificate request and and returns both the client certificate(c) and their ceritficate(d)
4. we create a SSL/TLS configuration that our service will use to connect to the vendors server: we populate the following fields: 
   1. trusted Certificate Authority X.509 certificate(d) - supplied from the vendor
   2. client certificate(c) - returned by the vendor after we sent our certificate request
   3. client private key(a) we created initially.

In this case I think the vendor is acting as the CA by signing our certificate request. (I've tried inspecting the certificate they provided but I'm not sure how to tell if it is self-signed, or signed by one of the big CA's)

I think this is fine for testing, and maybe while we have a small number of interfaces, but in the longer term I believe we need to manage this properly: use the cache Certificate Authority server, and 'Caché Credential Sets'.

---

[1]simplified summary of Mutual Authentication from https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication 

1.A client requests access to a protected resource.
2.The server presents its certificate to the client.
3.The client verifies the server’s certificate.
4.If successful, the client sends its certificate to the server.
5.The server verifies the client’s credentials.
6.If successful, the server grants access to the protected resource requested by the client.

---

[2]  we know we shouldn't use sha1 but are limited to what the vendor supports.
 

Thanks,

My 2013 instance of Ensemble seems to lack the filter drop down.  Time for an upgrade.

S.

Thanks for responding. My apologies for the delayed response.

>does not conform to FHIR's RESTful Search specification;
> it appears to be a custom REST call

you are right!

>it sounds like you are seeking to implement a message transformation interface >that enables a PDQ (Patient Demographics Query)-type transaction.

yes.

> I think you should take a look at our existing support for IHE PDQ (v2) and PDQm (FHIR-based) profiles

Can you provide a link?

>If the client system could be made to conform to the FHIR RESTful Search standard,
> then it may be easier to make direct use of our existing PDQm capabilities.

Can you provide a link?

Thank you for taking the time to respond.

Stephen

Hi,

My apologies for the delay getting back to you.

Is the QBP^Q21 actually an IHE PIX or PDQ query request or just a plain HL7 V2 QBP^Q21?

it is just a ' just a plain HL7 V2 QBP^Q21'

What is the workflow?

1. Client system sends a FHIR PDQ using a patient identifier.
2. Healthshare FHIR server web application receives from the client system
3. FHIR PDQ converted to HL7v2 Q21 ans sent to PAS
4. PAS responds with patient demographics (or fails)
5. response converted to FHIR response
6. FHIR response containing patient demographics sent to client system in FHIR response.

What is the triggering event for this workflow?

A user searching for a patient in the client system. (standard clinical workflow app)

You don't have to use SDA as an intermediary to translate HL7 V2 <--> FHIR. You can also do this directly using DTL

Can you provide more details about how this should work?

If the QBP is being sent to you instead of being sent by you

No, we are making the QBP^Q21 HL7v2.4 message to the PAS as it is the only way to query our PAS in real time.

Thanks again for taking the time to respond.

Stephen

Thanks for responding. My apologies for the delayed response.

does not conform to FHIR's RESTful Search specification; it appears to be a custom REST call

you are right!

it sounds like you are seeking to implement a message transformation interface that enables a PDQ (Patient Demographics Query)-type transaction.

yes.

I think you should take a look at our existing support for IHE PDQ (v2) and PDQm (FHIR-based) profiles

Can you provide a link?

If the client system could be made to conform to the FHIR RESTful Search standard, then it may be easier to make direct use of our existing PDQm capabilities.

Can you provide a link?

Thank you for taking the time to respond.

Stephen

(formatting corrected)

Worked !

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

D:\Certificates\>D:\InterSystems\HealthShare\bin\openssl x509 -in cacer
t.der -inform der -outform pem -out cacert.pem
WARNING: can't open config file: ././openssl.cnf

D:\Certificates\>

Thanks John,

I thought about that but it fails- even if I copy/paste the class path reference '##class(LNWDeploy.RoutingRules.Utility).' from the successful compile:

set tTempVars("SendToEaling")=##class(LNWDeploy.RoutingRules.Utility).SendToEaling((pContext.HL7))

error text

Compilation started on 09/06/2018 14:43:45 with qualifiers 'cuk /checkuptodate=expandedonly'
Compiling class LNWTIEPackage.iCSADTHL7MainRouterRoutingRuleDUP
ERROR <Ens>ErrParsingExpression: Error parsing expression '##class(LNWDeploy.RoutingRules.Utility).SendToEaling(HL7)': ERROR <Ens>ErrInvalidName: Invalid name at offset 1
  > ERROR #5490: Error running generator for method 'evaluateRuleDefinition:LNWTIEPackage.iCSADTHL7MainRouterRoutingRuleDUP'
ERROR: Ens.Rule.Definition.cls(evaluateRuleDefinition) of generated code compiling subclass 'LNWTIEPackage.iCSADTHL7MainRouterRoutingRuleDUP'
    > ERROR #5030: An error occurred while compiling class 'LNWTIEPackage.iCSADTHL7MainRouterRoutingRuleDUP'
Detected 1 errors during compilation in 0.086s.)

Is my only option is to delete LNWDeploy.RoutingRules.Utility and recompile?  

(it would be nice to be able to specifiy the full class path - but if routing rules don't support it I don't want to keep 'banging my head against a brick wall')

Thanks again

Stephen

We are using Health Connect  15.03

Cache for Windows (x86-64) 2017.2.1 (Build 801U) Wed Dec 6 2017 09:07:51 EST [HealthShare Modules:Core:15.03.9901 + Linkage Engine:15.03.9901]

There hasn't been a HealthShare Connect release on HS Core 16.

I'll update the question

>Could you provide more information on what you want to do with the PDF?

Newer vendors want to interface with the FHIR standard, but older systems are typically using Filedrops or HL7v2.4 MDM^T01 to send PDF documents.  I'm being asked to forward documents from old systems to new systems, hence the necessity to create FHIR interfaces.

Note:

The 'About Health Connect FHIR® Support' in the inbuilt HealthConnect documentation states 'The FHIR object model: Implements all FHIR DSTU 2 (1.0.2) resources.', but makes no mention of FHIR STU 3: http://your-server-here:57772/csp/docbook/DocBook.UI.Page.cls?KEY=FOVW_fhir#FOVW_fhir_intro

Please note the Health Connect product page specifically states it supports FHIR STU3:

‘In addition to supporting FHIR STU3 and DSTU2, Health Connect conforms to IHE standards and supports HL7 Version 2, HL7 Version 3, CDA® and CCD®, C-CDA®, DICOM, X12, ADHA (Australia), ASTM, DMP (France), EDIFACT, ITK (United Kingdom), NCPDP, and xDT (Germany).’ [https://community.intersystems.com/post/fhir-documentationtutorials#comment-61731]

Awesome - thank you!

Good point. I have added the code snippets to the question.

I should add the interface is actually working (I wasn't the original author)- but I am keen to fix this.

I have! 

Thank you - you code works beautifully.

Kind regards, 

Stephen

Thats exactly what I have but instead of a daily CSV extract from the departmental system, it is an A19 query

Thanks.  I hope they introduce a web interface . I feel like I'm stepping back in time trolling through the menus in ^MONMGR and ^%SYSMONMGR