Smart Electronic Medical Records
HISO On line Form Standard Interface
MyPractice exposes an API which will return data using the method (getData) specified by the HISO standard 10014.2 – Online Forms Architecture Technical Specification. What follows has been adapted from that standard. It has been updated to reflect actual concepts that have been implemented.
getData() Method
| Parameter Name | Data Type | Mandatory | Description |
| sessionKey | String | Yes | Form session identifier |
| dataContainer | formData | Yes | Form data container to be populated |
Table 1: getData() – Input Parameters
| Parameter Name | Data Type | Mandatory | Description |
| dataContainer | formData | Yes | Form data container populated with data from the user application. The returned data structure must be identical to that of the dataContainer input parameter |
Table 2: getData() – Output Parameters
This method populates the provided formData container as defined below with data stored in the UserApplication component. The session identifier is used by the method to relate the request to the correct data context of the UserApplication. This data context can contain information specific to the particular user, a particular patient and/ or a particular episode of care (e.g. a patient consultation).
The getData() method identifies the fields using concept identifiers embedded in the submittedData portion of the formData container. The concept identifiers are encoded as conceptID XML attributes of the form data container’s XML elements that require data to be filled in by the getData() method.
This method may be called multiple times over the duration of a forms session to retrieve various data items defined in the XML within the submittedData portion of the formData container.
The resulting populated form data container is returned by this method.
FORM DATA
Data Concepts
When a form requires extraction of data from the Subscribing System, it needs to reference each piece of information using data concepts from an agreed concept repository which defines the prescribed structure of each entry.
The proposed New Zealand health and disability sector repository of concepts conforms to the ISO/IEC 11179 standard and its structure and business processes are described in HISO 10014-1, Data Concept Repository Processes Standard. That standard does not prescribe technical details as to how Concepts and Attributes are to be referenced. The purpose of this section is to provide such a specification.
Framework for Concept and Attribute References
This section describes a framework for the usage of these concepts within the Online Forms systems interoperability environment. A definitive list of concepts however is outside the scope of this document.
Each concept can have a set of properties and modifiers in the form of attributes which may be used to alter the nature of the values returned by the user application or determine the expected behaviour of the system returning the concept data values.
Concept Properties
The following table describes the properties associated with each concepts. Collectively the define how a concept may be used and the values returned.
| Property | Type | Definition |
| name | string | The concept name. |
| description | string | A detailed description of the concept including the meaning and units of the returned value. |
| conceptID | string | This is the identifier allocated to the concept in the concept repository. It is the actual value used as an attribute by the Online Form interfaces to exchange data. |
| version | decimal | This defines the data dictionary version number of the concept. |
| Type | Concept Value Type as defined in Table 5 | A specifically defined return value type of the concept.In the case of ‘list’, it may be a list of identical concepts with different contexts (eg. dates); or a list of different concepts define the detailed elements that make up a complex concept. |
Table 3: Concept Properties
The dictionary of concepts may include references to equivalent codes in other coding systems.
conceptID Returned Value
Extensible markup language (XML) is used to define the values in the concepts dictionary. All concepts return a XML complex element structure including the conceptID attribute and either singularly or in a list consisting of three fields defined in the table below.
| Returned Field Name | Type | Description |
| referenceID | string | A subscribing system identifier identifying the source of the returned value which can be used to facilitate further searches eg internal patient ID or a unique row identifier in a table. This is a conditional field that must be sent if it exists. |
| dateTaken | dateTime | The date and time that the value was taken from a clinical context eg encounter date or specimen collection date. This is a conditional field that must be sent if it exists. |
| value | List structure or Concept Value Type as defined in Table 6 | The actual value of the concept or a list of values as defined in the concept dictionary |
Table 4: Concept Returned Values
Concept Value Types
The applicable unit of each concept value is specified at the time of definition of that concept. Each concept may also have a specific valid value type pre-defined in the format as defined in the table below. With the exception of “list” they are all part of xml primitive datatypes.
| Value Type | Valid Value/Format |
| decimal | Any numeric value represented by decimal numerals. |
| integer | A numeric whole number |
| string | A list of human readable text characters |
| boolean | “True” or “False” |
| date | yyyy-mm-dd |
| dateTime | yyyy-mm-ddThh:mm:ss:sss |
| base64Binary | Represents MIME encoded binary data in Base64 encoding |
| list | List of concept identifiers |
Table 5: Concept Value Types
Concept Modifiers
The following table describes general modifier attributes that may be used with concepts. They may not all be applicable to all concepts.
| Modifier Name | Value | Description |
| refresh | boolean | “True” if value is to be refreshed from the user application.“False” if original stored value is to be returned.Default of “false” if no value specified’ |
| order | string | Must be one of four values in the following list (dateAscend; dateDecend; valueAscend; valueDecend)This specifies the order of a list. If no value is specified then it is dateDescend |
| startPosition | positive integer | This specifies the start point (ordered as above) from which to return rows in the array. The first value is 0 (the default), the next is 1, then 2… |
| numRows | positive integer | If not zero (unlimited), maximum number of rows to return in the return array. (Default=0) |
| minValue | decimal | If specified, exclude values less than this value |
| maxValue | decimal | If specified, exclude values greater than this value |
| minDateTime | dateTime | If specified, exclude items recorded before this date/time |
| maxDateTime | dateTime | If specified, exclude items recorded after this date/time |
| searchString | list of acceptable values for the specific concept | If specified, exclude values not in this comma delimited list. Can use “*” for wildcards. Intended to augment the above search criteria by reducing the number of hits returned.Not intended as a way to inject SQL queries to the UserApplication. |
| referenceID | string | If specified, include only information related to this referenceIDUsed to get further details on items specified by the referenceIDs returned on previous searches |
Table 6: Modifier Attributes
Concept Modifiers Examples
Most recent value:
<modiferExampleconceptID=”modifier_example” referenceID=”AF015EC19892” />
or
<modiferExampleconceptID=”modifier_example” referenceID=”AF015EC19892” refresh=”false” order=”dateDescend” startPosition=”0” numRows=”1” />
First 2 values
<modiferExampleconceptID=”modifier_example” referenceID=”AF015EC19892” order=”dateAscend” numRows=”2” />
Second to last value
<modiferExampleconceptID=”modifier_example” referenceID=”AF015EC19892” startPosition=”1” />
Highest Value in last 12 months
<modiferExampleconceptID=”modifier_example” referenceID=”AF015EC19892” minDatetime=”2009-04-01T00:00” maxDatetime=”2010-03-31T23:59” />
All values greater than 8.2 in the last quarter of 2009
<modiferExampleconceptID=”modifier_example” referenceID=”AF015EC19892” numRows=”0” minValue=”8.2” minDatetime=”2009-09-01T00:00” maxDatetime=”2009-12-31T23:59” />
Treatment of Concepts by User Application
The data concept repository will classify concepts into groups which are processed differently by the user application. Some examples are:
Simple concepts that refer to a simple data element in the user application database or a simple lookup based on the element.
Repeating elements which represent repeating nodes in the XML document, such as medication lists.
Form instance and version numbers. These are populated by a unique number process within the user application.