Deploying EHRBase to AWS in 5 minutes

 To create an EHRBase deploy in AWS ECS you must follow these steps

• Launch an empty Linux 2 or Linux image
• Configure specs according the expected use (you can probably leave most of the options as is)
• edit: Don't forget to add 8080 to the instance firewall (keep port 22 for SSH)
  
• Generate key (and save it!)
• Run container
• Connect by SSH to the instance
• Url: instance IP
• User: ec2-user
• Password (empty, provide pem/ppk file)
• Install docker
• Update packages
• sudo yum update -y
• Install most recent docker version  (for Linux 2 AMI)
• sudo amazon-linux-extras install docker
• Install most recent docker version  (for Linux AMI)
• sudo yum install docker
• Open docker service
• sudo service docker start
• Add ec2-user to docker group so it can execute docker commands without using sudo
• sudo usermod -a -G docker ec2-user
• Close session so permissions are applied
• Test that ec2-user can indeed execute docker
• docker info
• If a daemon error is thrown then you probably need to restart the instance (or the docker service is actually down)
• Run database docker image
• docker network create ehrbase-net
• docker run --name ehrdb --network ehrbase-net -e POSTGRES_PASSWORD=postgres -d -p 5432:5432 ehrbaseorg/ehrbase-postgres:latest
• Run ehrbase docker image
• docker run --name ehrbase --network ehrbase-net -p 8080:8080 ehrbaseorg/ehrbase

And that’s all. You can test EHRBase server with swagger, which is available at

{your IP}:8080/ehrbase/swagger-ui.html

 

PS: This AWS configuration is inside the free tier :)

Sources:

https://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/docker-basics.html

https://github.com/ehrbase/ehrbase

Archetyping CDISC ODM

Every standard or specification with the notion of clinical document (or even the more visual metaphor of "form") is a potential candidate to be used in a dual model way (reference model + archetypes). CDISC ODM is not an exception. In fact, CDISC kind of mimics this by including both the study information (the "archetype") and the collected data in the instance sent to the server. This is something we will explore a little further later on.

First, to create CDISC ODM archetypes, CDISC ODM reference model must be included in LinkEHR. The reference model can be imported from CDISC ODM XML Schemas, in a similar way we imported HL7 FHIR XML Schemas. As we have already imported the schemas into LinkEHR you can also import directly the RM file in LinkEHR Reference Model Manager. For convenience, the RM file is available in LinkEHR downloads page. By creating CDISC archetypes we can take advantage of all the capabilities and tooling available for working with archetypes.

Archetypes are constraints over data, in reality CDISC ODM archetypes should replicate what is already going in the <Study> part of the ODM and store them as constraints over clinicalData. Good think is that this process can be completely automated. We created a method that traverses the XML study info and generates the corresponding constraints.

Original XML study

Transformed ADL

Same methodology could be used to generate the inverse process (going from clinicalData in ADL to XML study definition). The use of archetypes in this context has several advantages, such as multilinguality (study could be exported to any given language), terminology binding, more powerful constraint and rule definition (for data validation and generation), and of course, the automatic generation of transformation programs from mappings to other standards or models. Probably I will need to create in the future a blog post or video tutorial about this last point, as it seems to be quite an unknown part of LinkEHR :)

Another interesting use case could be the automatic transformation of openEHR or ISO13606 archetypes into CDISC ODM archetypes (or XML studies), which seem to be feasible as long as the user can define which parts of the archetype wants to include in the study, probably selecting Sections as different FormDef/ItemGroupDef. In the same way, CDISC data could be transformed into ISO13606 or openEHR Integration Information Model to allow archetype-based queries and import it into an organization workflow.

By the way, the use of archetypes with CDISC ODM is something we have been exploring since before 2014. I really recommend you to take a look at that presentation if you are interested. Everything told there still holds today. Maybe you have to change mentally the mentions to HL7 v2 and CDA to FHIR to update it to currently used standards :)  

Diabetes mellitus workflow example

 

Generating FHIR Logical Models from archetypes: Transform and roll out!

Transforming archetypes to specific resources (like Observation or Questionnaire) can be useful for quick integrations. However, most of the remaining Resources are not as generic, and thus a specific transformation will not always be reusable enough to justify an specific transformation process. For this case, one thing we can do is to generate FHIR Logical Models. These are not intented to represent new Resources, but could be used to represent any archetype or template in a way that FHIR tooling can understand.

Generating Logical Models from archetypes or templates is a direct process, but in the end generation process differs a little from the already defined transformations to Observation or Questionnaire.

One of the main differences is that while the Observation transformation is based in generating the 'differential' part of the StructureDefinition, for Logical Models we actually generate the 'snapshot' part of the StructureDefinition.¹

Another interesting thing is that this transformation process works regardless of the input archetype reference model. This is because process in completely based on the Archetype Object Model (AOM). ²

What this means is that this process can generate Logical Models not only from openEHR EHR Reference Model, but also from openEHR demographic model, ISO13606, HL7 CDA, or even CDISC ODM. In principle, generating archetypes works for any standard or local structures that are expressed as either XML Schemas or BMM and has the notion of "building block". The only real development needed to support a new reference model is to define a set of data types equivalences.

It is also worth noticing that this will work also for any kind of artifact that LinkEHR can import (OPT, OET, and even ADL2 archetypes), as they are all transformed to AOM structures in the end.

Process is quite straightforward:

• As similar to other StructureDefinition generation, first the metadata part of the Logical Model is generated from the archetype/template.
• Nodes in the archetype are traversed in order to generate the corresponding id, path, short text, definition, and min/max occurrences. Other attributes such as mustSupport, isModifier, and isSummary are also added.
• Archetype internal references are transformed to contentReference
• For types of Element and above, their type is transformed to BackboneElement.
• Objects of type Element and their corresponding data type are fused as a single entity with the text, description, etc. of the Element and type of the transformed data type. 
• Data type alternatives are added to the element path to create unique paths. Probably an invariant would be needed to show that they are actually alternatives.

There is still a few useful things missing in this transformation that could be added:

• Probably mappings to the actual archetype paths can be defined, like it's already included in the Observation profiles. Currently they could be reverse engineered from the generated FHIR paths, but there is no reason to not include them as mappings (or even bindings).
• Multilinguality is lost in this transformation. This probably differs quite a bit between STU3 and R4. Needs more examples on how it is usually done in FHIR.
• Add the option to complete with reference model: Archetypes also define some kind of 'differential' view over the reference model, but it's easy to complete the archetype with the underlying reference model to get all constraints.
• ArchetypeSlots are a completely different approach to using References to profiles. As far as I know, References can only be defined to point to specific profiles, while archetypes typical use case includes pointing to multiple ones (e.g. a given archetype or any of its specializations). This means that there is no direct mechanism to transform ArchetypeSlots for the moment.

All this process was already available on last week's LinkEHR release. Support to more data types has been added in this week's release. All feedback is welcome.

1. This wasn't always the case, as the original intent for Observation transformation was to let users choose if they wanted to define the differential or the snapshot+differential. This second option was discarded because it was really time consuming and FHIR tools can already generate the snapshot+differential from the differential

2. For FHIR Observation transformation the input could also be a ISO13606 archetype, but this was possible because the process looked for specific openEHR or ISO13606 classes.

Generating FHIR Questionnaire resources

These days of quarantine (we are literally more than 40 days now here in Spain) have not been the most productive days of all, but I wanted to put a little effort in helping in the great effort that is the COVID openEHR template. Seriously, take a lot at it, it's impressive the quality and how fast deployment in real systems has been.

In any case, as I don't have a clinical background, I couldn't help much other than translating some not-so-clinical archetypes (occupation record, etc.) to Spanish. But one thing I could do was to finally work on another idea of generating Questionnaire instances from a given template/archetype. For that, openEHR COVID template seemed like the perfect use case: It would require fast iterations and no (human) time should be spent in the generation of the equivalent FHIR Questionnaire for each revision.

With that in mind, I looked at the available FHIR Questionnaire examples and took the common meta attributes and tried to relate them to the archetype ones. Some are always put as constants in any case (e.g. even if it was a published archetype, the autogenerated questionnaire always should be a 'draft').

After that two main big tasks were detected:

1. Transform a given object in the archetype to the corresponding item in the questionnaire instance.
2. Flatten the archetype hierarchy as much as possible to obtain all possible questions

For 1) the process was more or less direct: Generate a linkid from the template/archetype path, get the text from archetype, get the object occurrences to give value to the repeat attribute if necessary and finally transform the archetype rmtype to the corresponding questionnaire item type. For this, it was assumed that any remaining hierarchy objects should be treated as questionnaire "group". Data types are translated to the closest type. If an implicit value set is defined in a coded text of the archetype, the corresponding FHIR ValueSet is generated and the item points to it. In this case the type "choice" is selected.

For 2) an specific traverse algorithm for openEHR Reference model was designed. This algorithm traverses the template tree and only generates the items that are interesting (e.g. it avoids generating the History, Item_tree, etc. levels). This process also merges both Element and data type objects, so the same FHIR question item can have a question text and a data type.

Snippet of openEHR COVID-19 Pneumonia Diagnosis and Treatment (7th edition) template transformed into a FHIR Questionnaire

Besides these tasks, there were a few little challenges:

• Even if you usually create profiles for each Resource, in case of questionnaires you define an instance of Questionnaire resource. Then your QuestionnaireResponse instances relate to that instance of the Questionnaire resource. This does not make the process more difficult, but means that not all the already developed methods to deal with the transformation of an archetype to a FHIR Observation Resource could be reused directly (e.g. different data types being allowed as parts of Observation and Questionnaire, which has already been discussed by Thomas Beale in the past).
• Another thing that was available for the FHIR Observation transformation that is not available for Questionnaires is the mapping part. It should be very interesting to point to the exact archetype paths where a question comes from, but as far as I know this is not possible in vanilla questionnaires.
• As already happened with the FHIR Observation transformation, FHIR doesn't really support the alternatives in monovaluated attributes. This is also true for FHIR Questionnaries and is also present in the COVID template (e.g. having an data value alternative of DV_TEXT and DV_CODED_TEXT, or DV_DURATION and DV_CODED_TEXT). As far as I see it there isn't a satisfactory solution to this yet, so for the moment only one of the alternatives is generated.
• Archetype slots provide a challenge as they potentially reference an open set of archetypes, which as far as I understand the FHIR Reference Resource cannot handle. For the time being, ArchetypeSlots will be ignored in the transformation.
• In case of openEHR COVID template, having the Symptom/Sign name as another element complicated things a little, as this should end merged with the corresponding values or presence absence. Luckily it was a pattern that could be easily implemented in step 2.
• Archetypes are multilingual, but Questionnaires are not (maybe there is one extension out there that deals with it). In any case, getting the texts from a given language in the archetype vocabulary should be trivial, so multilingual questionnaires could easily become a reality with very little effort.

This functionality is part of LinkEHR since 2020-04-22. Try it and suggest improvements if you want :)

Next blog post will talk about the other new functionality introduced in that LinkEHR version, the generation of FHIR Logical Models from archetypes