Preamble
This case study has been used to illustrate the OPM/ISO19450 modeling method.
Changes to the notation concern:
- The use of stereotyped icons.
- Structural links, which are figured by containers when participants are of different nature.
- Functional links, which are stereotyped with regard to associated content (logical or physical) and effect on states (thunderbolt).
Overview
Given that health services are supported by distributed and heterogeneous systems in continuous evolution, it’s safe to assume that parties and technologies are bound to change.
As a consequence, the interoperability of the healthcare infrastructure services must be defined independently of nature, parties, or technologies. To begin with, objects, agents, and systems must be classified with regard to their communication requirements, namely what is exchanged (physical or logical), and subsequent changes in the state of objects, processes, or expectations:
- Organizations (non physical agents with authority on rules): hospital, pharmacy, regulator, provider, … (1a)
- Humans (physical agents with identity and responsibility on changes): nurse, patient, physician, … (1b)
- Information systems (2a)
- Devices: ambulance, medical devices, … (2b)
- Logical payload: medical record, money, … (3a)
- Physical payload: medicine, blood, tissue, organ, … (3b)
Blood Sample and Medical Record
Interoperability requirements can then be specified according to that taxonomy, e.g for the exchanges associated with blood samples and medical records:
- Blood samples are exchanged between nurses and laboratory workers through services, with possible changes in objects states.
- Patients are identified (#) as the source of blood samples but have no role in the exchange.
- Patients receive and send information through logical mobile devices (e.g smartphones) without changes in objects states.
- Medical records are exchanged between services and health services management systems with possible changes in objects states.
- HS providers and their staff can only access services through their own management systems.
The next step is to introduce activities, which may entail some assumptions regarding the functional architecture.
Some activities can be unambiguously associated with the environment or identified systems:
- Interoperability domain (environmental): interconnection of services, blood sample transportation.
- HS management systems: requests handling and record distribution
- Mobile devices: service requesting, record querying, diverse healthcare applications
Others (treatment, blood sample yielding and analyzing) are better left pending lest too hasty decisions interfere with functional requirements.
With regard to blood samples, requirements are:
- Nurses control treatments, possibly using blood samples. States of processes, patients, and expectations may be modified.
- Laboratory workers analyse blood samples. States are left unchanged.
- Patients use healthcare applications and identify and contribute to blood sample yielding.
With regard to medical records the medical information interconnectivity will have to be compatible with treatment scheduling, services requesting and record querying (changes in state of expectations are signaled by thunderbolts).
As illustrated by blood sample yielding, it’s worth to note the importance of decisions regarding functional architectures: the operation can be carried out by mobile devices owned by patients (as in the referenced article), or left pending (as in the model above).