miércoles, 30 de septiembre de 2020

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

martes, 15 de septiembre de 2020

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