The Blueprint incorporates a grouping of services, called the Longitudinal Record Services, to manage the complexities of managing and localizing that data within the EHRi. Theses services include the indexes that link the data held in the various repositories to a particular client, provider, and location of services, and to the points in time that data is observed. This set of services is responsible for parsing the information from the external sources, placing the data appropriately in the repositories, and conversely for retrieving, assembling, and returning data in response to external PoS requests. This set of services is also aware of peer infostructures that may hold additional data on clients, and is capable of forwarding local requests for data to those infostructures, and then consolidating the returned data with local information. Conversely, this set of services can also respond to information requests from its other peers.
The following table presents the public service interfaces expected to be supported as a set of functional requirements by the Longitudinal Record Services.
| EHRi Service Operation | Description | SCP EHR Standard |
|---|---|---|
| Put New Object | Allows registering a new data or controlling object class.
These can then be instantiated and used by orchestration
flows. |
N/A |
| Put New Orchestration Flow | Allows registering a new orchestration flow in the LRS. Each
type of EHR IP that focuses on listing or getting data from the EHR
is expected to have its own orchestration flow. |
N/A |
| Put New Business Rule | Allows registering a new business rule in the LRS. This assumes
the use of parameterised business rules engine. |
N/A |
| Put New Normalisation Rule | Allows registering a new normalisation algorithm. |
N/A |
| Put New Assembly Template | Allows registering a new response assembly template used to
create a standards-based formatted response when a transaction is
ending. |
N/A |
| Put New EHR Index Event | Allows invoking the EHR Index to record a new event entry in it. This transaction is triggered by a domain repository service as part of the process to complete a clinical data insert (or create) transaction and its goal is to make the EHR Index aware of the existence of the new piece of data relevant to a client’s EHR. Invocation parameters include all of the data and metadata maintained by the EHR Index. This data includes basic subject identifiers (client, provider, location, user, pos application, source id) as well as event typing data so that the event is adequately categorised and searchable in the Index. The data created as part of an Index entry also includes a Unique Resource Identifier (URI) acting as the callable address to be used later in the context of access transactions to this specific event. See functioning principles for details. The LRS will search for any existing duplicate to protect integrity of the EHR Index and proceed to create a new event with an active status. Any subsequent queries towards the LRS EHR Index would be able to find the newly available data in the person’s EHR. |
N/A |
| Put Update EHR Index Event | This transaction is triggered by a domain repository service as part of the process to complete a clinical data update transaction. This transaction pattern is used to complete a clinical data update transaction. The LRS will search for the existing original event, turn its status to inactive, create a new event and link the new and old events. Any subsequent queries towards the LRS EHR Index should only find the corrected and most up-to-date event as active. |
N/A |
| Put Deactivate EHR Index Event |
This transaction is triggered by a domain repository service as part of the process to complete a clinical data delete transaction. As a principle, data in the EHR is never deleted, rather, it is identified as being inactive or logically deleted. The LRS will search for the existing original event, turn its status to inactive, create a new special type of event to identify this data record in the client EHR as deleted along with the specific subject identifiers describing the context of the deletion including client, provider, location, user, PoS application, source ID. It would also link this new delete event to the EHR Index entry being inactivated. Any subsequent queries towards the LRS EHR Index not find this data as part of the EHR of the client. Special types of maintenance processes can be used to access these records for audit, archiving purposes. |
N/A |
| Put Health Profile | The health profile transaction is an advanced feature that would allow an application to publish a “freeze frame” representation of a client health information available in the EHR as used at a certain point in time to make decisions or conduct health service delivery activities. The idea is that by packaging together all the events of the EHR Index that correspond to the data used, the EHR Service would able to recognize a special type of event that records that the health profile of the patient has been used at a specific point in time. New clinical notes or observations would typically be apart of this health profile. This feature would allow caregivers to record the fact that they had used a certain representation of a client health state when making a decision and publish that as an event in the EHR of the client. |
N/A |
| List EHR Index Events | Allows a calling service to obtain a list of events from the
EHR Index. Parameters when invoking this service focus on search
parameters including client, provider, location ID, date range,
type or type(s) or events, type or types of medical acts tracked by
the EHR Index. The response includes basic data about each event
including URLs usable to query the details of any single event
found in the Index. |
N/A |
| List Data Quality Indicators | Allows a calling service to retrieve a list of different data quality indicators from the data quality service of the LRS |
N/A |
| Get Data Quality Indicator | Allows a calling service to retrieve a specific data quality
indicator from the data quality service of the LRS. |
N/A |
| Get Orchestration Flow Executed | Allows a calling service, normally the Broker Service of the
HIAL, to launch the execution of a given orchestration flow. The
EHR IP request data is passed as a parameter in its canonical
form. |
N/A |
| Get EHR Index Event | Allows a calling service to obtain the detailed metadata about
a single event in the EHR Index. Since events in the EHR Index can
be nested, this may return a structure containing the data of
multiple events. Parameters when invoking this service include the
specific Event ID of the event being accessed. EHR index data must
have been queried prior to this service being used. |
N/A |
| Get Health Profile | The get health profile transaction is a special kind of “Get EHR Index Event” transaction. It allows caregivers to retrieve form the EHR of a client, the detailed representation of all the health events that make up the specific representation of data used on a patient when making a certain decision. See “Put Health Profile” for more information. |
N/A |
| General Info | |
|---|---|
| Name | Longitudinal Record Services |
| Visibility | public |
| Active | false |
| Abstract | false |
| Leaf | false |
| Root | false |
| Owner | Classes |
| Relations | |||
|---|---|---|---|
| Name | Type | Begins | Ends |
| | generalization | Longitudinal Record Services | IIP Services Catalogue |
| | generalization | Business Services | Longitudinal Record Services |
| | generalization | Data Services | Longitudinal Record Services |