Smart Electronic Medical Records
1 Background
An interface is required between a forms provider and the practice management system to enable a form to launch in patient context, to pre-populate forms and to save information back to the patient record in the PMS database. The HISO 10014.2 Online Forms Architecture seeks to meet the need for an agreed standard interface between the PMS and electronic forms used by third party applications, such as a forms provider. This standard has significant limitations because data concepts are exposed via web services, which requires either:
- opening a port from the PMS to the internet, resulting in security risks and application fragility secondary to network and firewall configurations, or
- opening a local port from the PMS and installation of a client side component of the interacting application, resulting in maintenance and deployment burden
This document describes a variant of the Online Forms Architecturewhich uses the same data concept mappings but exposes these via the PMS embedded browser, enabling a web forms application such as a forms provider to interact with the PMS securely without requiring the installation of any client side applications.
1? Technical Specification
There are three components to the technical solution:
- Query string parameters passed in the URL from the PMS to a forms provider
- PMS online forms JavaScript API data concepts used to populate a web based form from the PMS database.
- PMS JavaScript API for saving forms to the PMS.
1.1 Data concepts used to populate a forms provider forms
At the core of the PMS online forms Javascript API is a function “?GetConcept”? which returns data based on the “getDataRequest” ?in the HISO 10014.2 Online Forms Architecture specifications.? A full list of the data concepts available to a forms provider is included in <url>
The getConcept function uses the following syntax:
function GetConcept(conceptName,[order],[startPosition],[numRows],[minValue],[maxValue],[minDateTime],[maxDateTime],[searchString],[searchConcept],[conceptQualifier],[referenceId])
conceptName refers to a concept within the Online Forms Architecturedata concepts list and may reference a list concept or a value property.
The full list of concept names can be found here:
https://staging-1.mypractice.co.nz/developer/implementedconceptlist
order ? specifies the order that the items are returned in. The options datedescend, dateascend, valuedescend and valueascend.Ã? The default value is datedescend:
startPosition specifies the starting row to return items from
numRows specifies ? specifies the maximum number of items to be returned.
minValue the value of the concept must equal or exceed this value to be returned.
maxValue ? the value of the concept must equal or be less than this value to be returned.
minDateTime the timestamp of the concept must equal or exceed this value.
maxDateTime the timestamp of the concept must equal or be less than this value to be returned.
searchString the item must contain this sub string to be included in the information returned.
searchConcept not implemented yet..
Qualifier is an optional parameter to request a subset of data from the concept using fully qualified SNOMED concept names or in specific cases a code from another code set. Where the code system is not SNOMED then the code system is identified in the concept list. This is used for requesting specific patient measurements such as the patient’?s blood pressure, height, weight etc.? a forms provider uses the following SNOMED concepts to extract measurements from the PMS
- ‘blood pressure (observable entity)’
- ‘body height measure (observable entity)’
- ‘body weight (observable entity)’
ReferenceId is an optional parameter to request a specific item in a concept list matching the PMS reference id.? This avoids iteration through the list to get a specific list item.? The reference id could be a GUID or primary key that is generated by the PMS
Data is returned in the JSON format as in the following example.
{“Patient_MedicationRegular_Exists”:[
{
“Patient_MedicationRegular_Exists”:”True”,
“Date”:”2014-05-14T10:05:17.000″,
“ReferenceID”:”00000000-0000-0000-0000-000000000000″
}
]}
There is no validation of the data at the time of extraction from the PMS.Ã? All validation is performed when the user attempts to save the form.Ã? This allow for any data to be extracted from the PMS regardless of format/content and for it to be corrected as necessary within the forms interface.Ã? Changes to data made within a form are not persisted back to the PMS.
1.2 Example Form with Javascript
This form shows the use of the java script calls:
https://staging-1.mypractice.co.nz/wp-content/uploads/2014/08/Javascript-Test-form.html
For Concept list.
The table below contains all the concepts that have been implemented within myPractice:
https://staging-1.mypractice.co.nz/developer/implementedconceptlist