Support Document Template
Total Page:16
File Type:pdf, Size:1020Kb
The University of Sydney ICT
FRB! Web Service Document
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney. TABLE OF CONTENTS
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney. Page 3 of 16 FRB! Web Service Document
1* DOCUMENT CONTROL 1.1 Revision History Version Date Author(s) Reason for Change 0.1 03/11/2010 Julines Liong Initial draft 0.2 05/11/2010 Julines Liong Added the Getting Set Up section 0.3 08/11/2010 Julines Liong Added handling request and responses section 0.4 11/11/2010 Julines Liong Added the appendices 0.5 13/11/2010 Marco Garcia Added the examples 0.6 10/03/2011 Julines Liong Added 4.3.3 Selected Values For Validations. 0.7 15/03/2011 Julines Liong Added standard HTTP status compliance in 4.4. Added more information on the include-in-audit flag in 4.3.2. 0.8 18/03/2011 Julines Liong Added the audit definition in 2.1. Added a paragraph to stipulate request can handle multiple patients and visits for each of those patients. Added an example to connect to the web service via CURL. Added the description of attributes in the FRB! application. 0.8.1 18/03/2011 Julines Liong Added the ethnic list 0.8.2 31/03/2011 Julines Liong Changed the http status from 500 to the more appropriate 422. 0.8.3 29/05/2012 Suraj Added treatment types. Earlier there Wijethunge was only one treatment type. 0.8.4 31/05/2012 Julines Liong Amended the list of ethnicities
2* DOCUMENT PURPOSE 2.1 Introduction The purpose of this document is to provide the specification details of the web service provided by the FRB! Application. FRB! web service is a set of operations designed to send (anonymous) patient and visit data from you system or application to the FRB! Application. This document is designed to help you understand how to make requests to the FRB! web service, and present examples of how the web service can be used.
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney. An AUDIT in the FRB! application defines the monitoring of certain condition(s) in an eye. The AUDIT itself is not confined to a special condition but rather to the monitoring of that condition(s). The eye that is included in the audit is monitored for the treatment of the condition(s) the audit was created for. For example: For a macular degeneration audit, eyes that have wet AMD (+/- concomitant conditions such as glaucoma) are treated for the wet AMD. The monitoring refers to the wet AMD independent of the treatment type. Since eyes can have several conditions and several different treatments it has to be specified to which audit the data are to be added. For example, for an eye with multiple conditions such as glaucoma and wet AMD, data is recorded for the Macular Degeneration Audit if wet AMD treatment was given to the eye. If an eye is treated for glaucoma, then data will be recorded for the Glaucoma Audit, if such audit exists in the FRB! application. 2.2 Intended Audience This document is intended for developers and technical teams of the Electronic Management Record (EMR) vendor of your practice to provide data for the FRB! group for research purposes. 2.3 Required Knowledge and Skills This document assumes you are familiar with the following: XML Basic understanding of web services
3* GETTING SET UP In order to use the FRB! web service, you must first register your practice and the list of users to the FRB! group. This can be done by direct consultation with the FRB! group, or a request can be made to [email protected] and further information will be provided to you. 3.1 Assumptions This document assumes the availability of connection to external Internet traffic from the user’s Internet connection, as well as having the necessary ports available for that connection. If you require further clarification, please contact your network administrator. The EMR system or application must also be able to handle basic HTTP authentication and post requests to the FRB! application. It must also be able to handle the responses from these requests. The responses are specified further in the document. 3.2 Initial Setup The following information is the minimal set of data required, and must already be registered to the FRB! application for connection to the FRB! web service: Practice Name (Case sensitive) Practice user email (must be valid) User password (initially given and can be changed directly through the FRB! application)
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney. Page 5 of 16 FRB! Web Service Document
3.3 Authentication The following information is required and must be registered in the FRB! application as part of the authentication process: Practice user email Password
4* HANDLING REQUESTS AND RESPONSES The following describes the specifications of the valid request the EMR will need to output, as well as the responses the EMR will need to handle. It should be noted that the request is designed to handle one or more patient records. It will also handle multiple visits for each one of those patients.
4.1 XML Schema The patient XML Schema (XSD) is located at the following URL: https://frbresearch.org/patient.xsd The content of the XSD is also available in the appendix of this document. 4.2 XML Request The EMR must package the data in XML according to the XSD provided. The XML data can be posted to the following URL, and it also includes the authentication details: https://user_email:[email protected]/visits/create_with_xml.xml where user_email is the registered user email user_password is the password for the FRB! application for the user_email For example, below is the command to post an XML data with CURL. curl -H 'content-type: text/xml' -d @filename -X POST -u user_email:user_password https://frbresearch.org/visits/create_with_xml.xml Please note that there is no restriction on the filename. However, it is expected that the filename must conform to individual system so that the filename is callable. For example, it is prefereable that there are no spaces on the filename. 4.3 FRB! Application Attributes The attribute list can be found the in patient XSD specified above. The description of these attributes are below. 4.3.1 Patient Date of Birth Initial Identifier
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney. Ethnicity Gender 4.3.2 Visit Date Audit Status 4.3.3 Eye Side Greatest Linear Dimension (gld) Angiography Lesion Criteria Ocular condition Pre treatment 4.3.4 Treatment Include in audit Visual acuity IOP (pressure) CNV activity Treatment types Adverse event Discontinue treatment Reason for discontinue treatment 4.4 FRB! Application Validations There are a number of data validations the FRB! application will undergo to determine whether the data sent can successfully be received by the FRB! application. The following are the validations required for a baseline visit and followup visit. 4.4.1 All Visits Validation The data below are validated when any visit is sent: Presence of audit – In this case, Macular Degeneration Presence of patient identifier Presence of practice name Presence of visit date Presence of both eyes if visit is a baseline visit
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney. Page 7 of 16 FRB! Web Service Document
4.4.2 Baseline Visit Validation The data below are validated when sending a baseline visit and for the eye included in the audit: Presence of eyes Presence of eye side Presence of include-in-audit - this is the flag that determines whether the eye will be included in the audit, in this case, the eye details such as treatments, visual acuity, and adverse events to be collected as part of the Macular Degeneration audit. Presence of pre-treatment/s Presence of ocular condition/s Presence of CNV Activity Presence of visual acuity Presence of treatment type 4.4.3 Followup Visit Validations The data below are validated when sending a followup visit for the eye included in the audit: Presence of the eye-side of the treatment Presence of the visual acuity Presence of the CNV Activity Presence of the treatment type Presence of the adverse event/s 4.4.4 Selected Values for Validations There are selected values that are expected by the FRB! application for the validations above. These values must be entered exactly as described according to each attributes in the XML request. 4.4.4.1 Pre-Treatment values The following is the list of values available in the FRB! application for the
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney. 4.4.4.2 Ocular Condition values The following is the list of values available in the FRB! application for the
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney. Page 9 of 16 FRB! Web Service Document
Pseudoendophthalmitis Endophthalmitis 4.4.4.5 CNV Activity values Active Inactive Unsure 4.4.4.6 Treatment Type values The following is the list of values available in the FRB! application for the
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney. Standard HTTP statuses apply by the response when it is sent back to the EMR. For example, A ‘200 Ok’ response will be sent back to indicate the data are successfully inserted in the FRB! application. A ‘422 Unprocessable Entity’ response may indicate validation errors inside the FRB! application. All other HTTP statuses are as per standard HTTP protocol set out in the W3C HTTP/1.1. If the validation/s have not passed in the FRB! application, a response will be sent back and it includes the error messages of those validations. For example, Validation error when a patient’s birthdate is not included:
When a visit for the same patient on the same day already exists in the FRB! application:
When a treatment is discontinued but the reason for the discontinuation is not included:
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney. Page 11 of 16 FRB! Web Service Document
5* XML EXAMPLE The following is an example of a valid baseline visit XML and a valid followup visit XML. 5.1 Baseline visit example
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney.
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney. Page 13 of 16 FRB! Web Service Document
6* APPENDICES 6.1 XSD content
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney.
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney. Page 15 of 16 FRB! Web Service Document
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney.
This document is protected by Australian copyright law and the law of confidentiality and the comparable laws of other countries. It contains valuable information proprietary to the University of Sydney. No part of this material may be copied, stored or transmitted in any form, electronic or otherwise, without the prior written consent of the University of Sydney.
© Copyright 2010 The University of Sydney.