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

Extracting (all) CKM ValueSets

A derived results from the latest developments on the openEHR -> FHIR transformation is that I end up developing a method to analyze all the contents of an archetype to identify potential elements to end in a profile, regardless of the source class of the archetype. With that method developed, there was only a sensible thing to do...

Based on the CKM github mirror I applied the process to generate the profiles for each archetype, which in the end generates the ValueSets for each DV_CODED_TEXT, DV_ORDINAL, and even DV_QUANTITY units.

So this is the result. A set of 1023 ValueSet profiles where generated. This shows how much knowledge and effort has been put into developing CKM archetypes. For example, "location of measurement" ValueSet provides a set of 15 terms translated to 15 languages, which is something I've never seen before in a given subset.

Extract from locationofmeasurement ValueSet

I plan on regenerating this from time to time, so check the date for getting the latest version.

(and as a remainder, unless stated otherwise everything I put in this website has a CC-BY-SA license, so take it, try to break it and tell me if it actually breaks ;)

Using LinkEHR to generate FHIR Observation profiles

After my last 'summer challenge' post one of the missing things was to make it publicly available in a simple way. This post shows how that algorithm was actually implemented in LinkEHR. This functionality is available in LinkEHR version that can be downloaded from linkehr.com

The process is quite straightforward:

1. Open a given archetype (or import OPT)
1. Process is NOT limited to openEHR Observation archetypes, any archetype can be feed as an input. Output will always be FHIR observation profile/s
2. Launch the wizard in Advanced utilities -> Transform openEHR to FHIR observation
3. Select an output path
4. Select the archetype paths to be exported
1. The process lists all paths with a leaf node, regardless of where are they included in the archetype (data, protocol, etc.)
5. Select the type of the element in the FHIR profile (as Observation.component, as Observation.value or as a new extension)
6. Check the suitable options from the bottom and press Finish

Process should provide a observation profile + a set of ValueSets coming from the coded values of the archetype. It also provides the Extension profiles from nodes selected as extension (if any)

What is currently supported via UI

• Add translations to ValueSets
• Support to OPTs as input 
• Presented OPT paths are not as readable as in normal archetypes, but the process should work Ok anyway
• Generate mapping file
• Creates a LinkEHR mapping file containing the mapping the openEHR source paths to the target FHIR XML paths
• Generate empty FHIR archetype
• This creates an empty FHIR archetype for being use with the above mapping file. This allows the automatic generation of an XQuery program to transform openEHR data instances into FHIR data instances

 What is currently supported by code (hopefully soon in the UI)

• Generate a set of observation profiles from a single openEHR archetype. 
• Still evaluating how to create a simple UI for this functionality
• Deal with underlying openEHR Reference Model
• Some RM attributes are probably interesting to be included in profiles, which means some kind of merge of RM + archetype must be done
• Generating STU3 profiles
• It is supported to generate both R4 and STU3 "flavours"of FHIR. However, needs more testing to ensure everything is still correct after latest changes.

Currently working on

• Dealing with DV_IDENTIFIER. 
• No support for Identifier type in Observation.component.value[x] means that either identifiers are put in some specific paths in the FHIR profile or we create extensions. Trying to identify all these possible paths to ask users what they want to do with them

Potential improvements

• Support other reference models
• ISO 13606 would be almost trivial, but probably other RM such as HL7 CDA are interesting to tackle
• Create Bundles to group the observations
• Evaluate other classes (openEHR Composition with FHIR Composition resource)

Please tell me any doubt, problem, or error you found with the process so I can fix it. Probably best channel is by twitter (@yampeku)

PS: This functionality has actually been a month included in the tool, but only a few selected people knew it was already there to get their feedback

openEHR Observations to FHIR profiles, my 2019 summer challenge

This personal challenge started with a tweet from @siljelb asking for tooling for transforming openEHR archetypes to FHIR profiles. This was something I've always wanted to prove, so why not turn this into a personal summer challenge?

FHIR to openEHR 

 

My first thought was to generate an archetype from all the different components and extensions included in a FHIR profile. The rationale being that we already have systems capable of supporting arbitrary archetypes and archetypes have little problems when you want to include an unknown/big set of data values. After a little bit of profile analysis and a little trial and error I ended with a method that received an observation profile (with all the definitions of the extension it contained) and outputted a single observation archetype. As an example, here is the algorithm applied to the genomics profile.

Original genomics profile

Output observation archetype

(I would found later on that this particular example is not really accurate of how complex observations should be modeled in FHIR, but algorithm should stay more or less the same).

Although it seemed like a good idea at first, this transformation has a big issue: Two slightly different profiles will give us two different archetypes that will have to rely fully on terminology bindings to know they are talking about the same, which kind of goes against the philosophy of one archetype per concept. Archetypes are supposed to represent a universal use case (aiming to a max data set instead of a 80/20). These FHIR to openEHR transformations could work well enough in isolation or a single project but not a CKM-type environment. FHIR embraces local profiles and extensions, which could make their governance quite an issue.

openEHR to FHIR

One important lesson to get from this first experience is that a set of profiles will transform into a single archetype, but also a single archetype will end as a set of profiles! So while the FHIR → openEHR way only generates a single archetype and doesn't need any further user input besides choosing the set of profiles, the openEHR → FHIR transformation needs more information. Specifically, we need to tell the algorithm three things:

• Select the Element that would go into the value part of the Observation profile (if any)
• Select the list of elements that will end as components (they can go without value, they can also be an empty list)
• Select which Elements of the original archetype are suitable to be transformed into extensions.

For first two, openEHR Clusters can give an idea of pieces of an observation that make sense as a group. So from there users should be able to choose what constitutes the value and what parts constitute the components. Clusters in Clusters are an interesting use case that probably needs that users choose directly how it should be generated. If we consider that every part in the archetype is equally important, then everything could end in profiles with values constraint to [0..0] and every archetype part modeled as components, which could make this process completely automatic.

For knowing what could be an extension, archetype slots provide an excellent indication. We could also analyze all archetypes in one go and create the different parts that could be reused as extensions (Can we create some default Protocol-like profiles? Do we need to take into account default parts from RM and always include them as extensions?)

Once we decide that, the generation of the Observation, Extension, and even ValueSet profiles is quite straightforward. For data types equivalences, I built this transformation based on the openEHR wiki page about data types equivalence. For the moment only the most usual data types have been translated (namely DV_TEXT, DV_CODED_TEXT, DV_DATE_TIME and DV_QUANTITY), but adding new ones should be easy (with maybe the exception of DV_ORDINAL alternatives).

Snippet of State of Dress valueset

The profile differences between STU3 and R4 aren't too many, so I've included support for both generations. User can choose which one generate as a parameter.

The generated profiles were adjusted thanks to the Hammer tool, so they should be correct for STU3. After a bit of tweaking I got rid of the unknown error that was preventing me to import them into Forge R4, so they should also be R4 compliant.

Weight profile from openEHR weight observation archetype

What's next

• More testing! 
• Do you have any archetype you want to test?
• Could be interesting to process all CKM in one go? (at least for ValueSets)
• Should we put all generated ValueSets in our FHIR terminology service?
• More data types!
• Some data types are still missing. I think that it is possible that some data types, such as openEHR Ordinals alternatives will provide bigger challenge if they have additional optional elements.
• Make it more configurable, e.g. change base uris, etc.
• Put the algorithm into LinkEHR Editor and provide a minimal user interface to ease the element selection process.
• Use the process to generate the mapping that will generate automatically a transformation program to generate the different FHIR Observation instances.
• Mapping seems that could be bidirectional, as it seems that all mappings are atomic.

Lessons learned

• It is feasible to create a semiautomatic translation from openEHR to FHIR. We can make global assumptions to make this process automatic.
• FHIR to openEHR transformation is straightforward, however to take advantage of the big amount of high quality clinical models already avaliable in openEHR it seems preferable to use openEHR archetypes as a basis and generate profiles for them.
• The differences in StructureDefinition between STU3 and R4 that matter to this transformation are manageable.

Bonus for those of you getting to the end, the good ol' Blood pressure archetype as a FHIR observation profile