OpenIZ 2.0 / SanteDB Announcement

Well, it has been quite some time since the last OpenIZ blog post, and that is because we've been quite busy rolling our lessons learned into a completely new version of OpenIZ!

This new version separates the intelligent clinical data repository (iCDR) functionality of OpenIZ into a completely separate project. Starting with Version 2.0 several MEDIC open source projects will be built upon this underlying iCDR named SanteDB.

The following MEDIC open source products will be migrated to the SanteDB core:

• MEDIC CR 2.0 -> SanteMPI : The MEDIC CR 1.x codebase will no longer be maintained in the coming months. With the release of SanteMPI the CR will leverage the powerful RIM based datastore and other advanced features of SanteDB.
• OpenIZ 2.0 -> SanteEMR : OpenIZ 2.0 features will be rolled on top of SanteDB's CDR platform as well. While the bulk of OpenIZ features were rolled into SanteDB, OpenIZ itself will be refactored into a fully functioning disconnected EMR platform with EIR being a component of that EMR.
• AVIC (Visualizer 4.0) -> SanteGuard : SanteDB's persistence and security services are currently being implemented into a standalone security audit repository and identity provider named SanteGuard. SanteGuard already has support for IETF RFC3881 and DICOM format audits over TCP, STCP and UDP and we plan on integrating FHIR audits into the solution.

What are some of the features of SanteDB? Well, in addition to the full features of OpenIZ, SanteDB adds new features such as:

• Multiple Database Support : SanteDB can now operate using either PostgreSQL, SQLite or FirebirdSQL. This means that if you want to try the SanteDB HDSI server, you can just plug in one of our sample FDB databases and try it out! No configuration necessary!
• Clinical Decision Support Engine : The CDSS engine from OpenIZ has been expanded and can now create advanced care plans based on any health care event according to advanced when/then conditions.
• Chained Business Rules : The BRE from OpenIZ has also been expanded and now supports chaining (running rule after rule) as well as rule guards which greatly increases performance of business rule execution.
• Extensible HDSI Query Language Functions : It is now possible for SanteDB plugins to expose custom fuzzy functions to the HDSI query interface. This allows for clients to have access to even more matching functions.
• Probabilistic Record Matching : Using the new probabilistic record matching engine, SanteDB can detect duplicate records based on custom matching rules, and can score the strength or similarity to other records. These can then be classified and appropriate record quality actions undertaken. 
• Master Data Management (MDM) : One of the most powerful new features is the ability for SanteDB to run either as a single data repository (resource repository mode) or as a master data management (MDM) mode. In MDM mode, SanteDB will keep track of local copies of records and harmonize them into master records of truth. Data administrators can then merge/unmerge and create records of truth based on local copies of records. This also permits fine-grained privacy controls for data.
• Enhanced Privacy Controls : SanteDB builds on OpenIZ's policy based access controls and permits masking of both Acts and Entities. All data within SanteDB can be tagged and appropriately masked based on application, device, and user principal permissions. Additionally, SanteDB extends the provenance tracking on clinical data within the system and restricts editing (in MDM mode) to only those records which belong or are authored by a particular application/device/user. Additionally, SanteDB implements break the glass controls allowing users (with appropriate policy permissions) to elevate themselves and override the privacy controls on records.
• Extended HL7v2 Support : SanteDB builds on OpenIZ's flexible HL7v2 infrastructure by allowing custom processors for Z-Segments and message/segment handling. This means that SanteDB's execution of HL7v2 triggers can be infinitely customized.

The SanteDB community is diligently working to getting releases of our initial solution offerings ready for Q1 2019 including SanteMPI, SanteEMR, and SanteGuard. Keep your eyes open!

For more information visit the SanteDB community page at: https://github.com/santedb

Getting Started with the OpenIZ SDK

Ever wanted to get started developing your own plugins for OpenIZ but don't know how? Well, this handy video on YouTube guides you through the process of setting up your machine & toolchain for OpenIZ development.

There will be some more exciting news coming soon! OpenIZ is about to undergo a major transformation and we are very excited!

HL7 FHIR In OpenIZ

In the previous post, we discussed the rationale of using the HL7 Reference Information Model (RIM) for our primary information model in OpenIZ, in this post we'll explore how OpenIZ exposes core data via HL7 FHIR.

While the RIM is used as an information model in the solution, the RIM is (unfortunately) quite verbose for expression over the wire. Anyone who has implemented HL7 CDA or HL7v3 will tell you this. That is why we only expose the RIM over REST whenever another system requires 1:1 representation (like the disconnected client).

For most other interactions with the IMS, HL7 FHIR is quite capable. It allows third party developers to access the clinical information in the IMS without having to worry about the complexities of the RIM (what is a mood code anyways?).

The OpenIZ implementation of HL7 FHIR has focused primarily on read-only transactions. The rationale for read-first focus is that quite a bit of work has to be done to ensure that data written using FHIR will comply with the RIM.

Currently OpenIZ supports the following resources on our /fhir interface (all are STU3):

• Immunization - Which provides query access to vaccination events in the IMS
• ImmunizationRecommendation - Which allows FHIR clients to execute the care planning service
• MedicationAdministration - Which provides query access to non-immunization medication events such as supplements.
• Observation - Providing queries to observation events (both coded and quantitative)
• Patient - Allowing for the querying of patients in the OpenIZ system
• AdverseEvent - Which provides facilities for querying Adverse Events Following Immunization (AEFI) events
• AllergyIntolerance - Providing access to problem concern or allergy information in the IMS
• Condition - Which allows fetching of clinical conditions, reactions, symptoms, etc.
• Location - Providing complete access to places stored in the OpenIZ IMS
• Medication - Which allows querying for individual medication lots in the system
• Substance - We've mapped substances to the type of substances which can be encountered in the IMS.
• Provider - Which maps to the physicians or clinicians which provide care in the IMS

We hope to provide additional resources (especially infrastructure like conformance and value set) in the coming months. Look for OpenIZ at a FHIR connect-a-thon soon!

Why did OpenIZ use the HL7 RIM?

One of the questions you might be asking yourself is: Why on earth, would the designers of OpenIZ use the HL7 RIM (Reference Information Model) as the basis for the platform.

It is true, there are alternatives to using the RIM as an information model including HL7 FHIR, HL7 v2, OpenEHR, custom model, etc. So, I thought since it is Friday, it would be a good time to do some explaining of why the OpenIZ data model is the way it is.

So, why the RIM?

Good question, at a high level:

• The RIM is very expressive, it allows us to represent a variety of use cases outside of immunizations. Often, countries will try to leverage investments in one programme area for another purpose, and Immunization is no different. When you think about it, Immunizations are just a part of child care, and child care is really a part of maternal and child care, and maternal care is part of patient care. The key here is we wanted OpenIZ to be patient centric rather than programme centric .
• The RIM saved us time (that might sound like an weird statement given the common complaints about HL7v3). By leveraging the RIM, it already gave us a logical construct to work within, there are literally thousands of pages of documentation on the RIM, and this really saved us having to invent our own way of doing things.
• There are a ton (probably a metric tonne if we printed it out and weighed it) of documentation surrounding the RIM, and there are lots of training materials for the RIM. These training materials can be adapted for OpenIZ relatively easily.
• We probably would've come up with something not as good or similar anyways. Given the fact that we wanted a patient centric record for immunization, and the fact that there are probably millions of person-hours of effort put into developing the RIM, we felt that this analysis wasn't worth reproducing.
• We felt like we could simplify the RIM, since we have extensive expertise in HL7v3 we felt that the pain points of the RIM could be optimized and made less painful. Also the advent of better tooling and better wire level formats would assist in this.

Things we took out:
In order to make the RIM a little more bearable, we had to take some things out, this is a high level..

• Roles - This is perhaps the biggest change we made to the RIM. OpenIZ's data model is based on Entities Participating in Acts, whereas the RIM is Entities playing Roles Participating in Acts. Why did we take out roles? Well, after some careful discussion in the team we determined that there was really no need given the use cases to differentiate between Bob the Doctor and Bob the Patient, we just create two entities (even though they are logically the same entity, the benefit of this added join just added complexity).
• Procedures - One of the major classifications of Acts missing in OpenIZ is Procedures. The reason for not including these was simply a matter of resourcing, we didn't have sufficient resources to put into developing this Act type given the other pressing concerns. Procedures are on the roadmap for OpenIZ in the future, as we definitely want to allow people to record procedures done to the patient.

Things we added:

Not everything was an exercise in removal. We've adapted the RIM to include some concepts from FHIR as well.

• We added versioning to Acts and Entities which means that instead of using Replaces relationships, we just version the entity and  act independently of the entity or act relationships. We still have entity relationship of replaces but that is now used for merging.
• We added the concept of Extensions and Tags. These are taken from FHIR. An extension defines a versioned piece of data about an entity or act, that is creating a new extension creates a new version of the entity or act. Tags on the other hand, allow for non-versioned tags to be attached to an object.
• We added the OpenMRS concept dictionary data model to the RIM. This gives the information model a little more flexibility in terms of using concepts in the context of the RIM. This is a huge shout-out to the flexibility of the OpenMRS concept dictionary information model which separates the logical concepts from wire-level reference terms.
• We added some proprietary schema tables around consent and permissions. This was borrowed from IHE XDS' view on confidentiality. Rather than tagging a code as in the RIM for privacy, we allow the associating of security policies against an object.

OpenIZ SDK & Disconnected Client for Linux & MacOS

In case you didn't notice in the latest release: there are SDK and GTK+ based client for OpenIZ on Linux and MacOS. These two programs are currently under heavy development and we expect to be shipping them soon.

Currently there is a preview of the Linux & MacOS SDK in the Edmonton CTP4 install (https://github.com/MohawkMEDIC/openizdc/releases/tag/v0.9.7.4). These are distributed in tarball format for the time being, and work in a fashion similar to the Windows SDK. All you need is the Mono Framework installed and you're good to go.

We are also working on DEB packages for Ubuntu and derivatives (I personally use Xubuntu to develop on). Unfortunately due to the heavy focus on deployments at the moment by the core team, these packaging efforts have been put on the back burner, but we're hoping they'll be ready for the Edmonton release in September.

Ubuntu Packages

Starting with the 0.9.7.4 (Edmonton CTP4) release of OpenIZ Disconnected Client, there are now packages for Ubuntu. This package will install OpenIZ Disconnected Client in the appropriate directories with any prerequisites, and will also create a handy icon in your launcher.

Here are some screen shots of the Linux version in action running a prototype of an implementation of OpenIZ.

A sample of the encounter entry screen showing disease surveillance entry.

Clinic inventory graph grouped by total stock for each type.

Diving into the OpenIZ SDK

The Edmonton release of OpenIZ is fast approaching and there are now several iterations of the previews on our downloads page. Many have started to ask how to get started with developing OpenIZ applets and how to debug them. This post will hopefully provide a brief overview of what is in the new SDK.

For this post, I'm going to be using the Community Technology Preview (CTP) 4 of the OpenIZ SDK. This will be released around Aug 11, 2017. Once installed, you'll notice a new program group (or new icons in the existing Open Immunize program group):

Business Rule Debugger

The business rule debugger does exactly what it claims. It allows you to debug basic business rules on your system. The current iteration of the business rule debugger requires you to create an openiz.exe.config which is required to debug server side execution of business rules. In CTP 5 we plan to make this requirement optional by providing the SQLite version of storage by default.

Clinical Protocol Debugger

The clinical protocol debugger is used to debug the clinical protocols you can create in your application. It functions in an identical manner to the business rules debugger and also requires an openiz.exe.config file to be present (in the current version). There is a tutorial on how to write these business rules on the github page, it also introduces the debugger.

https://github.com/MohawkMEDIC/openizdc/wiki/Dev-Protocol-XML

Log Viewer

The log viewer is a tool that can be used to easily sift through the sometimes large log files that OpenIZ and OpenIZ Disconnected Client generate. It provides basic search functionality, filtering by source of the log and also allows you to look at "thread neighbors" (that is, log entries which were generated by the same thread only, so you can follow). 

Brain Bug

The brain bug tool provides a series of utilities that allow you to easily extract android data from tablets (yes it is named after the Starship Troopers "brain bug"). Using the brainbug tool you can easily extract adb backups on windows (not that easy since the backups are zlib compressed and aligned). 

Applet Compiler 

The applet compiler is used to compile your applet source code into a single PAK file which can then be uploaded to an active OpenIZ server and tested. The applet compiler allows for the generation of unsigned, and signed pak files using a variety of compression schemes (depending on the size of your applet source).

Mini IMS

The Mini IMS is a tool that allows you to easily debug your applet source code in an environment that exactly mimics the tablet and disconnected clients. Here, there is no need to compile your code into a PAK file, rather the Mini-IMS will simply read the directory structure of your applet source code as though it were compiled. 

A few things to note with the Mini IMS, first is that you should never accept updates when prompted (it will clobber the session loaded files). 

Compression / Optimization in OpenIZ

While deploying OpenIZ in a rural region of Tanzania, some of our users were noticing that initial synchronizations were taking quite a long amount of time. The users were attempting to download over 30,000 records over a 2g connection.

To begin with, the Edmonton CTP version of the OpenIZ IMS (0.9.6) did have some greedy database queries. After optimizing the server down to near 0 response times (using REDIS for example, first request for 5,000 facilities is about 20 seconds, second request for the same dataset is 1.5s), I decided it would be worthwhile to update the compression on the OpenIZ IMS.

After reading on the internet, I found some articles about SharpCompress (MIT licensed) which I could use to extend Edmonton CTP's compression providers. The deflate and gzip (compressors in SharpCompress were apparently faster than the default .NET ones). After some work, there are now four compression schemes supported for retrieving and sending data to the OpenIZ IMS:

• LZMA - The compression scheme used by 7z, which can heavily compress data however requires quite a bit more resources (decompression does not)
• BZIP2 - A burrows-wheeler compression algorithm which yields slightly higher compression rates than GZIP but is faster than LZMA
• GZIP - The GNU Zip format, this is standard HTTP GZIP compression
• Deflate - Again, standard deflate compression algorithm, OpenIZ uses the optimization for speed rather than compression.

Each one of these compression schemes is now supported in the Disconnected Client 0.9.7.3 (Edmonton CTP3, they will require a server running Edmonton CTP3 as well). The settings are found in the "Network Options" section of the configuration UI.

For those that are interested in the trade-offs in terms of speed and bandwidth usage, I setup a small facility with 500 patients and downloaded the data. Please note that these are very specific to this particular use case, however are a good guide. Below are the results:

Algorithm	Download Time			Size
	Broadband	DSL	56k (like 2g)
LZMA	0:18.50	1:14.50	5:30.00	1.8 MB
BZ2	0:18:50	1:18.50	6:01.00	1.94 MB
GZIP	0:19.00	1:20.50	6:30.00	2.1 MB
Deflate	0:10.00	1:40.50	6:45.00	2.2 MB
RAW	0:08.50	5:00.00	24:50.50	8.3 MB

The differences in these results are more marked when dealing with larger clinics with 10,000's of patients and 100,000's of results. This illustrates the need for connection compression. The OpenIZ IMS always supported the submission and querying of data in compressed format, with these new schemes, it makes downloading a lot faster on 2g connections!