Formal Specification of Wireless and Pervasive Healthcare Applications

1. Formal Specification of Wireless and Pervasive Healthcare Applications Antonio Coronato and Giuseppe De Pietro Presented by Fred Maurer December 5, 2011

2. Background • Wireless technology has enabled the creation of pervasive computing environments. • Smart rooms, active spaces • Technology without distraction • Context and location sensitivity are essential to these systems • Monitor / control entity movements

3. Problem • Pervasive computing systems in healthcare settings • Safety and dependability are critical • Requirements and constraints must be rigorous • Verification and Validation • Prevent potential faults

4. Formal Methods • Cardelli and Gordon, 2000 • Ambient Calculus • Models nesting and moving agents • Ambient Logic • Extends temporal logic with operations regarding location • Shortcomings • Cannot specify real-time constraints or conditional movements

5. Ontology • Establish names in the system • Entities • Classes • Relationships • Inheritance, containment, composition… • Resembles a domain model (UML class diagram)

6. Ambient Calculus • Derives from π-calculus (Milner, 1998) • Models concurrent processes • An ambient is a named process which can contain other processes • in and out operators for movement • Example expression

7. Ambient Calculus, continued

8. Foundations of Ambient Logic • Propositional logic • First-order logic • Temporal logic • eventually (◇), always (◻) • Real-time extension • Variable represents the current time • Timestamps on atomic operations

9. Ambient Logic • somewhere (▽), everywhere (△) • Process satisfies formula at location • Reduction with exactly one rule • Contains (directly)

10. Design-by-Contract • Meyer, 1992 (implemented in Eiffel) • Formal contracts are specified for operations • Preconditions and postconditions • If the preconditions are satisfied when the operation is executed, the postconditions are guaranteed to hold afterward

11. Workflow

12. Case Study • Nuclear Medicine department • Radioactive substance injection • Radiation is isolated • Acceptance, Injection, Hot waiting, Diagnostic rooms • But nurses are exposed when escorting patients • A pervasive system can track and direct patient movements • RFID tags and wireless messaging devices • Relieves the nurses of the risk

13. Define the Entities

14. Design Principles • Every instance of the Ontology becomes an ambient

15. Define the Domain Department[ AcceptanceR[0] | InjectionR[LongRangeReader[P] | ShortRangeReader[P]] | HotWaitingR[LongRangeReader[P] | ShortRangeReader[P]] | DiagnosticR[LongRangeReader[P] | ShortRangeReader[P]] | Corridor[0] ] HealthcareOperator[P] HealthcareOperator[P] | RFIDTag[P] Patient[P] Patient[P] | MobileDevice[P] | RFIDTag[P] AcceptanceR[HealthcareOperator[P] | Patient1[P] | | PatientP[P]] InjectionR[HealthcareOperator1[P] || HealthcareOperatorL[P] | Patient[P]] HotWaitingR[Patient1[P] || PatientP[P]] DiagnosticR[HealthcareOperator1[P] || HealthcareOperator1[P] | Patient1[P] || Patient1[P]].

16. Define the Movements, Activities, and Operations • Example movement • Patient[in AcceptanceR.W] |AcceptanceR[RFIDTag[P] |MobileDevice[P] | 0] → AcceptanceR[Patient[W] | RFIDTag[P] |MobileDevice[P]] → AcceptanceR[Patient[W]] • Activities • Injection, Examination • Elementary Operations • read_tag, write_tag, call_in_room

17. Design Principles • Every instance of the Ontology becomes an ambient • Define the elementary operations with the right degree of generality • Specify the user activities as a composition of elementary operations

18. Specify the Activities • Injection • CallPatientInRoom(InjectionR) = (AcceptanceR).(InjectionR).(dev).call_in_room • PerformInjection = (JustInjected).write_tag • CallPatientInRoom(HotWaitingR) = (InjectionR).(HotWaitingR).(dev).call_in_room • Examination • CallPatientInRoom(DiagnosticR) = (HotWaitingR).(DiagnosticR).(dev).call_in_room • VerifyPatient= <S>.read_tag • PerformExam = (Examined).write_tag • CallPatientInRoom(HotWaitingR) = (DiagnosticR).(HotWaitingR).(dev).call_in_room

19. Example ExpansionEach atomic operationtimestamped CallPatientInRoom(InjectionR) : → InjectionR[(Vmessage)message[out InjectionR.in AcceptanceR.indev.M]] | AcceptanceR[dev[!open message | !show(M)]] : → InjectionR[0] | (Vmessage)message[in AcceptanceR.in dev.M] |AcceptanceR[dev[!open message | !show(M)]] : → InjectionR[0] | AcceptanceR[(Vmessage)message[in dev.M] |dev[!open message |!show(M)]] : → InjectionR[0] | AcceptanceR[dev[!open message | !show(M) |(Vmessage)message[M]]] : → InjectionR[0] | AcceptanceR[dev[!open message | !show(M) | openmessage | (Vmessage)message[M]]] : → InjectionR[0] | AcceptanceR[dev[!open message | !show(M) | M]] : → InjectionR[0] | AcceptanceR[dev[!open message | !show(M) |show(M) | M]] : → InjectionR[0] | AcceptanceR[dev[!open message | !show(M)]]

20. Design Principles • Every instance of the Ontology becomes an ambient • Define the elementary operations with the right degree of generality • Specify the user activities as a composition of elementary operations • Apply Design-by-Contract to elementary operations

21. Contracts

22. Design Principles • Every instance of the Ontology becomes an ambient • Define the elementary operations with the right degree of generality • Specify the user activities as a composition of elementary operations • Apply Design-by-Contract to elementary operations • Define the properties canEnter and canLeave for mobile entities with respect to relevant locations • Define the property canHost for critical locations

23. Properties and Constraints

24. Conclusions • By clearly specifying requirements and constraints in a formal manner, we can: • Verify and validate them • Prevent potential faults • Recognize necessary architectural elements • e.g., RFID tags and readers • It is hoped that the straightforward workflow and design principles will promote and ease the design, development and deployment of pervasive healthcare applications