AIST PICA Implementation Guide
0.1.0 - STU1
AIST PICA Implementation Guide - Local Development build (v0.1.0). See the Directory of published versions
What is PICA?
PICA is an implementation guide that details how the conformance of processes conducted in a medical setting can be validated compared to an existing guideline or process description. It does so by providing guidance on how to do correct logging via the FHIR® AuditEvent resource. The IG also provides guidance on how to conduct performance auditing based on this log with tools from the process mining domain, and including this in existing software architectures.
What isn’t PICA?
PICA does not deal with mining processes, or enriching existing audit logs.
PICA can be applied to any FHIR® based audit logging. It is aligned with concepts from the IHE RESTful Audit Trail and Node Authentication (RATNA) profile.
To be applicable as an addition in existing infrastructures, it is recommended to implement PICA as an Audit Record Repository. An example for this, specific to the radiology domain, is outlined in IHE Standardized Operational Log of Events (SOLE) profile.
The PICA Project hosts a reference implementation of the Audit Record Repository on GitHub FHOOE-AIST-PICA-Server. This is a HAPI based FHIR® server, supporting all profiles, extensions, and FHIR® Operations this IG has to offer.
The PICA Implementation Guides for both FHIR versions are identical, however, since the standard has expanded in R5, several extensions are not necessary anymore. If you are browsing one of the two IG versions, the only difference between them is the Profiles and Extensions necessary to make this work. The remainder of the IG is identical.
The following table shows the possible options PICA can be applied for conformance purposes. Based on the core, which is required at all times in a patient centric view, each view can be applied individually or joined with each other. These perspectives are based on the work Process Mining on FHIR - An Open Standards-Based Process Analytics Approach for Healthcare
ae references the AuditEvent resource in FHIR R4B or FHIR R5 respectively.
Perspective | Description | Outcome | R4 | R5 | |
---|---|---|---|---|---|
core | AuditEvent resources are created on server and refer to a Patient resource (see https://build.fhir.org/auditevent.html#patient) | We can mine process(es) for a specific patient | ae.entity.what & ae.period | ae.patient & ae.occuredDateTime | |
conformance (code) | Tasks that were conducted were documented with machine readable codes in the AuditEvents. The codes refer to a value-set defining a standardized log of operational events (e.g. http://radlex.org/RID/RID45812) | We can mine only relevant activities, and know what those activities are | Extension: PICACode | ae.code | |
patient-visit (encounter) | An Encounter resource is referenced by the AuditEvent. It refers to a patient visit grouping multiple AuditEvents (e.g. one interaction between patient and healthcare provider) | We can analyze the patient pathway during an encounter (e.g. hospital stay) | Extension: PICAEncounter | ae.encounter | |
care-pathway (based-on) | A pathway that was defined or recorded for the patient (CarePlan) was followed and documented in the AuditEvents. | We can analyze a specific process | Extension: PICABasedOn | ae.basedOn | |
actor (agents) | Agents that participated in process steps were identified in specific AuditEvents | We can mine the process from multiple perspectives (actors) | ae.agent.who | ae.agent.who |
Data quality is the principal requirement for any form of data science, especially conformance checking, as this can only be done with sufficient quality of the process documentation. The PICA profiles and extensions define how logging should occur, via different optional profiles, to achieve specific outcomes in conformance checking.
The main goal of this implementation guide is to keep the profiles as simple as possible, thus only using one FHIR resource, to keep the effort minimal for organizations which wish to conduct a conformance check. What PICA does not do is deal with enriching existing audit logs. This is one of the core reasons why no resources that are referenced in the AuditEvent are considered for loading information for the conformance checking.
The following considerations explain why the selected fields are required for the different process perspectives, and why other fields were not chosen. They may hint how one may enrich an existing audit log for conformance checking, but an enrichment is complex, and where the necessary information may be found in existing systems will vary highly in different software systems, or even across different processes.
Simply: all of them, to get the best results. As minimal requirement to at least reconstruct a human readable process the core and conformance perspectives are needed, as they identify what (conformance) happened when (core) to which patient (core). The care-pathway resource allows you to check which events were recorded for a specific treatment plan, which is what is needed for conformance checking. The patient-visit allows viewing (one or more) treatments in the scope of one or more visits to a care provider, or alternatively allows to view how patients progress through their stay. Finally, actor can give an overview about who did what with the patient.
The PICA Core Profile is the minimum necessary perspective to reconstruct processes. It contains the two primary attributes:
The core perspective alone, allows one to view all changes (create, update, delete) concerning information related to a patient. Without any other perspectives, this does not concern a specific disease, hospital stay, etc, but the entire patient history.
It is also not clear what happened to the patient with the core perspective alone, because this is covered in the conformance perspective. In case you wish to simply reconstruct patient pathways without covering the other perspectives, you may wish to use ae.entity.what to show which resources were accessed, as this is the lowest common denominator.
General:
Considerations for Event Time:
Core perspective to enable conformance checking. Requires the tasks that were conducted to be documented in a machine readable format:
This perspective is the minimal requirement to enable conformance checking of processes. As every task that is done for a patient is documented with a machine readable code, reconstructed processes contain what has happened when for which patient. During conformance checking the processes can be filtered only to tasks relevant for the checked process.
Note that it is possible that one task is part of multiple processes. For example, a blood test (snomed code 396550006), could be part of a general health screening, or for checking the iron content before a blood donation. Thus, it is recommended to also consider the care-pathway perspective.
The patient visit perspective, enables documenting interactions between patients and healthcare providers:
This perspective enables two scenarios:
Care pathway documents which care plan was followed for the patient:
The care pathway follows a specific treatment plan for a patient. As these CarePlans in FHIR represent the treatment plan, based on a guideline, this allows conformance checking of a process.
In FHIR there are several types of CarePlan. If the care plan you want to conformance check is made for a group (CarePlan.subject), you are able to process mine and conformance check for a group of patients. Otherwise, the care plan will be specific to one patient, and allows only to check the conformance of that one patient’s process. In case you want to check the conformance for a specific process (e.g. Treatment for Burn Victims in specific Hospital), all of the care plans that were made for a patient need to be selected from the Audit Log. This depends massively on how FHIR is treated in the hospital, and could be one of the following options (among others):
The actor perspective enables viewing processes in the form of who (person, role, deparment, organization, or machine) was involved in which process step:
The actor perspective allows viewing the process from the viewpoint of a specific person, deparment, or organization. Alternatively, it allows viewing who was involved in the process at which specific step(s). For example, this can help identify bottlenecks with machines, or movement of patients between departments.
Note that the patient can be an actor as well, for example if they filled a questionnaire, or took their own vital signs.
In addition to PICA being this IG, it is also a project at the University of Applied Sciences Upper Austria going until December of 2025. If you have requirements concerning conformance checking of processes that are not covered in this implementation guide, or have questions on how to apply this IG, please contact the AIST research team, specifically Oliver Krauss (oliver.krauss@fh-hagenberg.at) or Andreas Pointner (andreas.pointner@fh-hagenberg.at).