SYNAPSES

1
SYNAPSES

• Siyamed Seyhmus SINIR
• SRDC

2
OVERVIEW

• Designed the generic specification for middleware
  servers which can enable authorized healthcare
  professional to access clinical information from
  diversity of repository servers.
• Objectives
• Sharing of health data between different
  information systems.
• Produce aids and guidelines that can be used in
  the migration from legacy healthcare system (?).

3
OVERVIEW

• A three year project within 4th Health Telematics
  RTD Framework of EC concluded in 1998
• Synapses is based on the PreEnv 12265
• Before that most detailed review of Health domain
  has been published by GEHR
• GEHR requirements has informed the subsequent
  work within CEN resulting in foundation EHCR
  architecture standard PreENV 12265
• Therefore the Synapses approach to EHR is very
  similar to GEHR approach.
• Synex is an improvement on Synapses

4
OVERVIEW
5
OVERVIEW - Consortium
6
Methodology
Scenarios User Requirements
IEEE Software Requirement Specifications
WP1
Information Model
ENV 12265, GEHR, Doculive, OMT
WP1
Server Specification (Computation Model)
IDL
WP2
Engineering Solution
O-O, CORBA, COM, WEB
WP3
Necessary revision Impact Assessment
KAVAS
WP4
7
Architecture

• It includes a Federated Healthcare Record Server
• Data sharing between systems is accomplished via
  this server.

Synapses Server
Get...
Server routes the request
Client clinical workstation
Feeder systems networked to Synapses server
8
Architecture
Synapses Server
Processes Acting as Synapses feeder systems
Processes Acting as Synapses clients
Synapses
API
Server to feeder
Processes acting as server administrator clients
Server to client
Server to Server
9
Architecture
(a,b), (a,e,f), (a,c,d) are possible information
retrieval scenarios
Legacy system
Server containing health data
Server that contain only references to legacy
system data
10
Architecture

• Combining records from diverse record stores
  implies federation
• In this distributed environment where federation
  takes place, there is need for an agreed record
  architecture
• Here comes the Federated Healthcare Record (FHCR)
  on the stage
• Standardization efforts on record architectures
  by CEN TC251 and GEHR is the starting point for
  FHCR.

11
FHCR

• It is based on an object model
• In Synapses named as Synapses FHCR (SynFHCR)
• Each SynFHCR is the complete logical set of
  record component objects relating to a single
  subject of care within the federation domain of
  one or more Synapses Servers
• Synapses Object Model (SynOM) defines a set of
  base classes for the SynFHCR
• In that way SynOM is equivalent to GOM in GEHR
  and RIM in HL7.

12
ENV 12265 Inheritance Hierarchy
Record component
Record Item
Record Item Complex
OriginalRIC
View RIC
View RIC1
View RIC2
13
Synapses Inheritance Hierarchy
Record component
Record Item
Record Item Complex
OriginalRIC
View RIC
View RIC1
View RIC2
14
The Synapses Object Modelclass inheritance
Blue boxes are used during EHR construction
SynEHCR
PatID
RecordComponent
RecordItemComplex
RecordItem
RC_UID Feeder_UID Name RevisedVersion Authorisatio
nStatus SubjectOfCareId RecordIngDateTime HealthCa
reAtivityBeginTime HealthCareActivityEndTime Obser
vationBeginTime ObservationEndTime HealthCareActiv
ityLocation RecordingHealthcareAgent ResponsibleHe
althcareAgent LegallyRespHealthcareAgent Informati
onProvider AccessAmendRights Comment Presentation
Link HomeRic
SucceedingRic
OriginalRIC
ViewRIC
EnclosedRic
ViewRIC2
ViewRIC1
ContextRIC
RecordItem
FolderRIC
DataRIC
ComRIC
CompoundItem
ElementItem
RecordFolder
DataType Value
15
(No Transcript)
16
The Synapses Object Model

• FolderRIC
• Highest level of organization
• Used to group record entries within departments
  or sites, over periods of time
• Example An episode of care, an inpatient stay
• RecordFolder
• The root folder of within a single patients
  healthcare record
• Special sub-class of FolderRIC
• ComRIC
• Set of record entries required by the author to
  be kept together when information is physically
  moved or copied to another persistent store.
• In other words smallest meaning full autonomous
  set of ordered information in the record
• Corresponds to Transaction in GEHR.
• Example Data entered at one date

17
The Synapses Object Model

• DataRIC
• Grouping observations under headings of ComRIC.
• Does it correspond to Content in GEHR ?
• Example Symptoms, investigations, drug
  description
• ViewRIC1
• Contains a query procedure for Synapses feeder
  system
• ViewRIC2
• Contains a link to a RIC in another part of the
  same record or part of an other related record.
• RecordItem
• Contains the data in its most basic unstructured
  form

18
Example
Demographics
Social
19
SynOd

• The classes of SynOM have been defined at a high
  level of abstraction to provide an information
  model that can be applied to any potential
  healthcare record entry.
• There is a need for client applications to
  generate precise requests fro named aggregates
  from a given patients federated healthcare
  record, and to receive these back from the server
  as objects in a predetermined form.
• Synapses Clinical Object Dictionary (SynOD)
  provides the formalism by which the specific
  clinical data sets and aggregates normally found
  in healthcare records and in contemporary feeder
  systems can be defined.
• SynOD corresponds (almost) to the Archetype
  Server in GEHR.

20
server
Archetype server
GOM server?
Classes defined by users
Return functions
Create new class
Foundation classes
Get class
Create new obj
Records
Client to Server object retrieval
Users of server
Server to Server object retrieval
21

• Now we know how data is categorized in record.
• But where is it stored?

22
Record

• The most clean and powerful result is achieved
  when a federated record is build from native
  Synapses components
• This reference enables the DataRic of the other
  server to appear to the user as a part of the
  ComRic of a federated record.

23

• What are we going to do with legacy systems?
• Encapsulation

24
Encapsulation

• Encapsulation is a method for making a legacy
  system compliant to the Synapses interfaces.
• Defining appropriate ViewRic1s (query mechanism)
  as encapsulation components make information from
  the legacy system available via a Synapses
  server.

25
Encapsulation inside the server

• The legacy system appears as providing record
  components from the clients point of view.
  However, the DataRic of the server is supplied
  with methods providing a proprietary
  communication mechanism to the legacy system.
• Appropriate for legacy systems that conforms to
  the standard interfaces (i.e. TC251, HL7 )

26
Encapsulation outside the server

• The legacy system appears to the Synapses server
  as storing record components
• Through encapsulation the data in legacy system
  appears as RecordItems to the Server.

27
Message based connection

• In many situations it is more convenient to
  transfer information from the legacy system to
  the Synapses server each time the information
  within the legacy system change
• Server keeps a copy of data

28
Synapses impl

• Implemented in 5 different clusters
• Dublin (LIS, HIS, Blood Gas Datastore, PMS
  Datastore, Vital Signs Monitor Datastore)
• London (Two Royal Marsden Hospital in two
  different part of the city)
• Oslo (Integration of DocuLive with legacy
  systems)
• Amsterdam (Academic Medical Center)
• Geneva (University Hospitals Geneva deployed to
  new app DOMED and DOSSI)

29
OSLO
30
Geneva
31
THE END
(Further) Questions ?