SPECIFICATION. Hospital Report Manager Connectivity Requirements. Electronic Medical Records DRAFT. OntarioMD Inc. Date: September 30, 2010

HRM EMR Cnnectivity Requirements Publicatin Date: September 30, 2010 Cntents INTRODUCTION... 3 Purpse and Scpe... 3 References... 3 EMR CONNECTIVITY AND REQUIREMENTS... 4 EMR and Physician Registratin... 4 SFTP Server Client Sftware... 5 SFTP Server Client Authenticatin... 5 SFTP Server Flders, Files and Authrizatin... 6 Netwrk Cnnectivity... 7 Lgging and Auditing... 8 DRAFT Page 2

HRM EMR Cnnectivity Requirements Publicatin Date: September 30, 2010 INTRODUCTION PURPOSE AND SCOPE The purpse f this dcument is t detail the interface between the OntariMD Hspital Reprt Manager and the Electrnic Medical Recrd systems (EMR) that will cnnect t it t cllect reprts. The scpe f the dcument includes the sftware cmpnents, cnnectivity prtcls, message frmats and cntent, errr handling, etc. REFERENCES The fllwing dcuments are referred t within this dcument: OntariMD CMS Specificatin 3.0 Appendix B - Data Prtability Requirements: https://www.ntarimd.ca/imageserver/omdcntent/cms/dcuments/cms%20specificatin%20v 3.02_Appendix%20B_Nv212008.pdf OntariMD CDS XML Schema Definitin: https://www.ntarimd.ca/cms/xml/ntarimd_cds.xsd OntariMD CDS XML Schema - Data Types: https://www.ntarimd.ca/cms/xml/ntarimd_cds_dt.xsd DRAFT Page 3

HRM EMR Cnnectivity Requirements Publicatin Date: September 30, 2010 1 EMR CONNECTIVITY AND REQUIREMENTS EMR vendrs nly technical interface with OntariMD will be with the OntariMD SFTP Server. This Server will be expsed ver the Internet during testing but ver the ehealth Managed Private Netwrk (MPN) r Internet fr prductin. EMR AND PHYSICIAN REGISTRATION Registratin fr the Hspital Reprt Manager invlves tw steps: 1. Registratin f EMR instance with OntariMD 2. Enrllment f Physicians with participating Hspital Registratin f EMR instance with OntariMD An EMR Instance must be registered with OntariMD t participate. The EMR Instance administratr must supply the fllwing infrmatin t OntariMD: Name f EMR Instance (i.e. Barrie FHT) IP address f the Instance EMR lcatin name, Street Address, city, pstal Cntact Name 1 lead physician Cntact Name 2 lcal technical supprt Cntact Number 1 lead physician Cntact Number 2 lcal technical supprt EMR Cntact Email 1- lead physician EMR cntact Email 2 lcal technical supprt Physicians assciated with using the EMR (CPSO IDs, name, clinic address, email address, phne number) Vendr Name (i.e. Clinicare, Practice Slutins, HealthScreen, etc ) Vendr Cntact Name Vendr Cntact Email Vendr Supprt Phne Number Upn receiving this infrmatin, OntariMD will: Create the EMR Instance user name n the SFTP server Create the EMR Instance flder structure fr the EMR (including sub-flders fr ASP clients) Register the EMR Instance with the mydds database server Assciate the physicians with the EMR Instance Prvide the EMR Instance vendr and/r administratr with the user name and required keys Enrllment f Physicians with Participating Hspital Physicians that are using the same EMR instance must cmplete a batch spreadsheet t start receiving electrnic reprts frm a particular hspital. The physician ffice will prvide the fllwing infrmatin t the hspital: First Name Last Name CPSO# OHIP Billing Number Office Address City DRAFT Page 4

HRM EMR Cnnectivity Requirements Publicatin Date: September 30, 2010 Pstal Cde Office Number Fax Number Once the hspital has cmpleted enrllment, the hspital will send a ntificatin t OntariMD. OntariMD will then d the fllwing: Setup prvider in the Hspital Reprt Manager directry Cnfirm implementatin date fr Hspital Reprt Manager interface SFTP SERVER CLIENT SOFTWARE Once registered, an EMR Instance s nly technical interface with OntariMD will be an SSH client cnnecting t an SFTP Server. OntariMD will nt prvide nr dictate which SSH client the EMR Instance chses t use. Regardless f the client chsen, the EMR Instance is respnsible fr autmatically plling the SFTP server fr new messages and remving messages frm the SFTP server nce dwnladed. This prcess shuld ccur n mre ften than every 30 minutes and n less ften than every 24 hurs. Aut-plling functin shuld autmatically re-cnnect withut errring ut t accunt fr any OntariMD maintenance windw, sftp server unavailability, r files nt fund issues. EMR Instance will cnnect t the SFTP server frm a secure netwrk with a fixed IP address. IP Lckut will be enabled n the SFTP Server meaning nly the registered EMR Instance s IP address will be recgnized as valid. Please see Netwrk Cnnectivity Sectin n page 7. SFTP SERVER CLIENT AUTHENTICATION OntariMD Hspital Reprt Manager will expse an SFTP Server t the Internet r ehealth MPN as apprpriate. The Registered EMR vendr s must authenticate against the SFTP server using the SSH prtcl. The server used will be the WS_FTP server with DSA hst key with SSH frm IPSWITCH (http://www.ipswitchft.cm/prducts/ws_ftp_server/) r a similar prduct. SSH (Secure Shell) is a prtcl fr encrypting and securing varius kinds f data transfers ver a netwrk r the Internet. SSH wrks by pening a secure channel between the SSH server and an authenticated user's cmputer. Many kinds f data may be sent r retrieved thrugh this channel. SSH can be understd as a large pipe: its purpse is t carry whatever is passed thrugh it frm ne place t anther withut letting anything leak in r ut. WS_FTP Server with SSH uses SFTP (Secure File Transfer Prtcl) ver SSH2 t transfer files. SFTP perates nearly identically t FTP, but all transmissins are secured under the SSH prtcl. When an SSH client cnnects t the SSH server, the client and the server each send a key t the ther. If the keys are trusted, the client and server then negtiate a secret key which is used t encrypt all data exchanged between the tw. Public key authenticatin will be the authenticatin methd used fr SSH. Clients authenticate by sending a key which the server matches t the key assciated with the user. If the match is successful, the client is authenticated. OntariMD will prvide the necessary EMR Instance Key. DRAFT Page 5

HRM EMR Cnnectivity Requirements Publicatin Date: September 30, 2010 Once the secure channel is negtiated and the user is authenticated, files can be transferred thrugh the secured SSH pipeline using SFTP. IP Lckut will be enabled n the SFTP Server meaning nly the registered EMR Instance s IP address will be recgnized as valid. N Encryptin/Decryptin keys r SSH keys t be hardcded in the applicatin. Keys will be changed annually and anytime if a security issue rises r systems envirnment changes. An advance ntice will be sent t related parties. Only authrized and named EMR ASP vendr r EMR user shuld be able t change the new keys with minimum effrt. All Encryptin/Decryptin keys and SSH keys shuld nly be expsed t a single named user with a secnd backup named user wh are respnsible fr them. SFTP SERVER FOLDERS, FILES AND AUTHORIZATION Each registered EMR will have a dedicated flder hierarchy similar t the fllwing: /EMR1/Prductin/ /EMR1/Test/ The registered EMR (EMR1 as depicted abve) flder will be cnfigured as the rt fr the authenticated EMR user. ASP implementatin may have mre sub-flders t match each physician grup t the EMR instance. Each EMR instance r implementatin t each physician grup will have a restricted access t its wn flders r cntainers at the HRM servers. The authenticated EMR user will be granted Read, List, Delete, and Rename rights t the files in their flders. All files awaiting EMR dwnlading will be encrypted. OntariMD will prvide the necessary EMR Instance Un-encryptin Key (128-bit AES). All files awaiting EMR dwnlading will take the fllwing frmat: <PrcessedDate> _<sendingfacility>_<reprttype>_<reprtnumber>_<messagedate>_<cpsid>.xml Where: PrcessedDate Date message is prcessed by Rhapsdy. Will be in frmat YYYYMDDHHMISSsss sendingfacility Retrieved frm MSH.4 field in incming message (variable length). reprttype Retrieved frm OBR.20 field in incming message (variable length). reprtnumber Retrieved frm OBR.3 field in incming message (variable length). DRAFT Page 6

HRM EMR Cnnectivity Requirements Publicatin Date: September 30, 2010 messagedate Retrieved frm MSH.7 field in incming message. Will be in frmat YYYYMMDDHHMM. cpsid CPSO number f the dctr t whm the message is delivered (variable length). Example: 20090904234559123_ ABC _DI_1234567_200909041234_4321.xml Files will cnfrm t the OntariMD EMR specificatin as dcumented in Appendix F f the CMS Specificatin 4.0. SFTP Flders will be mnitred by OntariMD. In rder t supprt a cnsistent apprach t the SFTP flder management and audit lgging, we recmmend the fllwing prcess t be fllwed as part f the EMR s message retrieval prcess. SFTP plling autmated prcess t by set at 30 minute intervals EMR als requires a manual plling and retrieval functin fr administratr supprt File t be retrieved in the SFTP flder are t be renamed by the EMR vendr with an apprpriate file name extensin t mark the files that will be retrieved (additinal files can be added t the flder during prcessing) EMR system will retrieve nly renamed files EMR system t check t see file is successfully retrieved EMR system t delete renamed files The SFTP audit lg will lg fllwing events: by user/system, time, date, Plling and Access t the flder File save t the flder File rename File retrieve File delete Lg ff Flder N limits will be placed n number f files r disk qutas within the flder structure. NETWORK CONNECTIVITY Each registered EMR will have a netwrk access t ehealth Ontari Managed Private Netwrk (MPN) r Internet cnnectivity t reach OntariMD HRM servers, with sufficient bandwidth. A minimum f 5 Mbps dwnlad speed is required fr new EMRs cnnectivity r using the existing ehealth prvided circuit dwnlad bandwidth which may vary. Netwrk cnnectivity t be prtected with prper firewall that supprts Universal Threat Management (UTM) and Deep Packet Inspectin (DPI). This is recmmended fr existing lcal EMR implementatin but mandatry fr ASP and new EMR implementatins. Firewalls must be mnitred and updated n regular basis. Any machine accessing HRM servers ver SSH must be physically secure and accessed nly by limited authrized persns. Such machine is expected t be with business-class OS and prtected with prper firewall (see abve pint) and anti-malware sftware with regular updates. DRAFT Page 7

HRM EMR Cnnectivity Requirements Publicatin Date: September 30, 2010 ASP Vendr t prvide mre details in advance abut their EMR cnnectivity t the different instances they supprt frm any single IP address. Changes t netwrk cnnectivity may require up t 6 weeks turnarund t be adjusted by OntariMD. LOGGING AND AUDITING OntariMD is respnsible fr the lgging and auditing f all messages frm the hspital t the EMR. EMR vendrs are required t lg enugh infrmatin t assist OntariMD if and when requested. EMR Instances must understand and be in cmpliance with the Persnal Heath Infrmatin Prtectin Act (2004) f Ontari. A subset f these requirements states that: The prvider shall t the extent reasnably practical, and in a manner that is reasnably practical, keep and make available t each applicable health infrmatin custdian, n the request f the custdian, an electrnic recrd f, i. all accesses t all r part f the persnal health infrmatin assciated with the custdian being held in equipment cntrlled by the prvider, which recrd shall identify the persn wh accessed the infrmatin and the date and time f the access, and ii. all transfers f all r part f the infrmatin assciated with the custdian by means f equipment cntrlled by the prvider, which recrd shall identify the persn wh transferred the infrmatin and the persn r address t whm it was sent, and the date and time it was sent. This culd be a request t assist with the tracking f a reprted missing message, imprperly ruted message, etc The full Act can be accessed at: http://www.e-laws.gv.n.ca/html/regs/english/elaws_regs_040329_e.htm At a minimum, all IDs received by the EMR Instance (i.e. Message IDs, Hspital IDs and CPSO IDs) are critical t this requirement as well as dates and times when messages were handled by the EMR Instance. The SFTP Server perfrms lgging and auditing supprt including, but nt limited t: Bth successful and failed lgin attempts Files upladed, dwnladed, and renamed Administrative functins DRAFT Page 8