Nueva publicación

Encontrar

Pregunta
· 12 jun, 2023

Folks, did Anyone performed DB or Backend Automation on IRIS Dataplatform?

 DB or Backend Automation on IRIS Dataplatform performed?

3 comentarios
Comentarios (3)1
Inicie sesión o regístrese para continuar
Pregunta
· 12 jun, 2023

Performed API Automation on IRIS Dataplatform?

API performed API Automation on IRIS Dataplatform?

4 comentarios
Comentarios (4)1
Inicie sesión o regístrese para continuar
Artículo
· 12 jun, 2023 Lectura de 2 min

OEX mapping

Scenario

You all know Open Exchange (OEX) and the is no need for a detailed explanation.

It consists of a directory with various filters and detail pages for packages.

This is great for manual navigation. 
But the most interesting information for me is the content of the blue box on the right.
All content comes from a database somewhere in the background and is not accessible to me and you.

Navigating manually over more than 700 packages in the search of a particular entity is not funny.
So  I decided to have my own table with my criteria of interest.

  • url        // relative as in OEX directory; UNIQUE
  • label      // package name
  • author
  • technology
  • zpmmodul
  • review     // flag if review exists
  • page       // page in OEX directory
  • stars      // assigned in reviews
  • version
  • lastupdate //Date
  • IRIS       // flag for IRIS 
  • ZPM        // flag for support of IPM/ZPM 
  • xurl       // full URL of package

To fill this table I decided to use only methods in embedded Python
all projected as SQL procedures.
So there is no need for terminal access. Except for SQL shell.

Data Loading Strategy

  1. ​​​​​​Scan OEX directory pages to collect Labels and URL and PageNumber
    • This is an acceptable fast step to load and scan ~25 pages => ~730 records
  2. Based on the URLs load and scan detail pages review pages.
    • This results in loading and scanning of ~1500 pages
    • which consumes quite some time depending on your network capacity, 

And then you are free to navigate and query with SQL as you like.     

Video      

GitHub
 

2 comentarios
Comentarios (2)3
Inicie sesión o regístrese para continuar
Artículo
· 9 jun, 2023 Lectura de 15 min

EMPI installation and customization in Standalone - Customization of patient data

As we said yesterday... our EMPI can receive data from multiple sources, REST, HL7 messaging, etc. But it is possible that the standard fields are not enough and we want to expand the patient information to help discriminate and uniquely identify them. How could we customize patient data? Modifying the standard classes to our liking? NOOOOO!!!! Well, a little yes, but not like crazy, because if we modify standard classes carelessly we may find that in a future update we lose all these modifications.

Customization of patient data

Muy bien, continuemos con la configuración de nuestro EMPI en el que hemos introducido unos cuantos pacientes. Imaginad que hemos decidido incluir el grupo sanguíneo como un criterio para ayudar en el proceso del cálculo de pesos. Recordemos que clases definían los datos del paciente.

Por un lado tenemos el objeto que vamos a persistir y que lo encontramos en el Definition Designer:

On the other hand, we have the object that we are going to return in the searches and that corresponds to the "Composite Record" previously configured from the Configuration Registry option.

 

Let's take a look at HSPI.Data.Patient, specifically the class declaration:

Class HSPI.Data.Patient Extends (%Persistent, HSPI.Data.Type.Patient, %MPRL.Linkage.Base) 

We can see that its properties are inherited from HSPI.Data.Type.Patient, if we access to this class we will see that we have a series of values corresponding to the properties of the patient object. As we have said, we could add the fields here that we need... but that is NOT RECOMMENDED, we have a better option that will not be affected by version updates. If we go to the end of the HSPI.Data.Type.Patient class we find the following property:

Property Extension As HS.Local.SDA3.PatientExtension;

This property is what will allow us to add as many fields as we want to our patient object. As you can see, belonging to the Local will prevent this information from being lost in future version changes. Let's open HS.Local.SDA3.PatientExtension and include the BloodType property as a simple String:

Class HS.Local.SDA3.PatientExtension Extends HS.SDA3.DataType
{

Parameter HSDEPLOY = 0;
Parameter STREAMLETCLASS = "HS.SDA3.Streamlet.Patient";
Property BloodType As %String;
}

Perfect, our object is prepared to receive this information. How can we send this new information to our system? As we saw in the previous article, our EMPI has a default configuration that can receive HL7 messages and that we have already used to add patients.

Create new HL7 schema

In our example we will use an A28 message to which we will add a new segment with the blood type information. To do this we are going to create a new schema based on the 2.5.1 standard schema and we are going to create a new DocType for the A28 message type.

Here we have our new HealthShare_2.5 schema that, as you can see, extends the 2.5.1 standard and we have created a new message structure of type A28. To add a new segment we will first create said segment that we will call ZBT and add the field that will contain the blood type:

With the segment created, we only need to include it in the message structure and we can start working with these personalized messages:

Perfect, message set up with our ZBT segment. Now let's see an example of the type of message that we will receive with the new segment:

MSH|^~\&|HIS|HULP|EMPI||20230329085239||ADT^A28|72104|P|HealthShare_2.5
EVN|A28|20230329085239|20230329085239|1
PID|||1502935519^^^SERMAS^SN~424392^^^HULP^PI||CABEZUELA SANZ^PEDRO^^^||20160627|M|||PASEO JULIA ÁLVAREZ^395 3 E^MADRID^MADRID^28909^SPAIN||555710791^PRN^^PEDRO.CABEZUELA@GMAIL.COM|||||||||||||||||N|
PV1||N
ZBT|A-

In our example, the patient Pedro Cabezuela Sanz has a blood type A-.

EMPI Production Configuration:

As we saw in the previous EMPI configuration article, we have a production configured by default that allows us to immediately operate with our EMPI.

In our example we are using the Business Service EnsLib.HL7.Service.FileService that will capture files with HL7 messages from the specified route. To adapt it to the new type of messages that we are going to receive, we will modify the Message Schema Category to refer to the new schema created. Let's take a look at one of the examples of the messages that we sent in the example of the previous article to identify the Business Components through which our messages pass and to be able to identify them:

Our message enters through EnsLib.HL7.Service.FileService and it is redirected to HS.Hub.Standalone.HL7.Operation, here we have the configuration of said Business Operation:

We notice that we have an attribute called HL7ToSDA3Class configured with the class HS.Hub.Standalone.HL7.HL7ToSDA3. Let's open the class and check what its functionality is.

 
HS.Hub.Standaline.HL7.HL7ToSDA3

This class belongs to the standard and we have no interest in modifying anything in it, so we are going to create a new Local that will extend the standard class:

Class Local.Hub.Standalone.HL7.HL7ToSDA3 Extends HS.Hub.Standalone.HL7.HL7ToSDA3
{

ClassMethod GetTransformClass(msgType As %String, ByRef pTransformClass As %String) As %Status
{
	set tSC=$$$OK
	set pTransformClass=..OnGetTransformClass() 
	quit:pTransformClass'=""
	set pTransformClass = $CASE(msgType,
              "ADT_A01":"ADTA01ToSDA3", "ADT_A02":"ADTA02ToSDA3", "ADT_A03":"ADTA03ToSDA3",
              "ADT_A04":"ADTA01ToSDA3", "ADT_A05":"ADTA05ToSDA3", "ADT_A06":"ADTA01ToSDA3",
              "ADT_A07":"ADTA01ToSDA3", "ADT_A08":"ADTA01ToSDA3", "ADT_A09":"ADTA01ToSDA3",
              "ADT_A10":"ADTA01ToSDA3", "ADT_A11":"ADTA09ToSDA3", "ADT_A12":"ADTA01ToSDA3",
              "ADT_A13":"ADTA01ToSDA3", "ADT_A16":"ADTA01ToSDA3", "ADT_A17":"ADTA01ToSDA3",
              "ADT_A18":"ADTA18ToSDA3", "ADT_A23":"ADTA21ToSDA3", "ADT_A25":"ADTA01ToSDA3",
              "ADT_A27":"ADTA01ToSDA3", "ADT_A28":"ADTA28ToSDA3", "ADT_A29":"ADTA21ToSDA3",
              "ADT_A30":"ADTA30ToSDA3", "ADT_A31":"ADTA05ToSDA3", "ADT_A34":"ADTA30ToSDA3",
              "ADT_A36":"ADTA30ToSDA3", "ADT_A39":"ADTA40ToSDA3", "ADT_A40":"ADTA40ToSDA3",
              "ADT_A45":"ADTA45ToSDA3", "ADT_A47":"ADTA30ToSDA3", "ADT_A50":"ADTA50ToSDA3",
              "ADT_A60":"ADTA60ToSDA3", "BAR_P12":"BARP12ToSDA3", "MDM_T02":"MDMT02ToSDA3",
              "MDM_T04":"MDMT02ToSDA3", "MDM_T08":"MDMT02ToSDA3", "MDM_T11":"MDMT01ToSDA3",
              "OMP_O09":"OMPO09ToSDA3", "ORM_O01":"ORMO01ToSDA3", "ORU_R01":"ORUR01ToSDA3",
              "PPR_PC1":"PPRPC1ToSDA3", "PPR_PC2":"PPRPC1ToSDA3", "PPR_PC3":"PPRPC1ToSDA3",
              "RDE_O11":"RDEO11ToSDA3", "SIU_S12":"SIUS12ToSDA3", "SIU_S13":"SIUS12ToSDA3",
              "SIU_S14":"SIUS12ToSDA3", "SIU_S15":"SIUS12ToSDA3", "SIU_S16":"SIUS12ToSDA3",
              "SIU_S17":"SIUS12ToSDA3", "SIU_S26":"SIUS12ToSDA3", "VXU_V04":"VXUV04ToSDA3",
              :"Unsupported HL7 Message Type")

	set:pTransformClass="Unsupported HL7 Message Type" tSC = $$$HSError($$$HSErrUnsupportedHL7MessageType,msgType)
 	if $$$ISERR(tSC) quit tSC
 	if (msgType = "ADT_A28") {
 		set tTransformPackage = "Local.Hub.Standalone.HL7.DTL"
 	}
 	else {
 		set tTransformPackage = "HS.Hub.Standalone.HL7.DTL"
 	}
 	set pTransformClass = tTransformPackage_"."_pTransformClass
	
	quit tSC
}

}

Of all its classes, the one that interests us the most is GetTransformClass, which will indicate which transformation we must carry out depending on the type of message received. As in our case we have chosen the A28 message as the carrier of the new segment with the blood group information, we must find said transformation within the $CASE command:

"ADT_A28":"ADTA05ToSDA3"

Here we have our initial transformation, as we can see, the structure of the ADT_A28 message is that of ADT_A05, therefore it has said transformation configured by default, in our case we are going to create a new transformation copying the ADTA05ToSDA3 and we will call it ADTA28ToSDA3, replacing the value that had in the $CASE a:

"ADT_A28":"ADTA28ToSDA3"

As you can see from Local.Hub.Standalone.HL7.HL7ToSDA3 we have included an if to apply the proper transformation depending on the type of HL7 message received if the message is an ADT_A28 the package to be use is Local.Hub.Standalone.HL7.DTL.

With the class Local.Hub.Standalone.HL7.HL7ToSDA3 compiled we will open our production again and define the value of the HL7ToSDA3Class parameter in the Business Operation HS.Hub.Standalone.HL7.Operation with the newly implemented class Local.Hub.Standalone.HL7. HL7ToSDA3

Perfect, we have finished the configuration of our production. We only have one small detail left...we haven't created our ADTA28ToSDA3 transformation yet!

Creating custom transformation:

From the list of transformations menu we will look for the ADTA05ToSDA3.

Here we have it, let's open it and proceed to save it with another name to create a copy of it.

With the new class created we can start the transformation, we must perform the following tasks:

  • Change the Source Doc Type from 2.5.1:ADT_A05 to HealthShare_2.5:ADT_A28. Remember that we have created a new message structure A28.
  • Assign the value of the BloodType field of the ZBT segment of our message to the BloodType field that we find inside the Extension property included in Patient. This BloodType field is available by adding the BloodType property to the HS.Local.SDA3.PatientExtension class.

The transformation would be like this:

Alright, let's review what we've done so far:

  • Creating the BloodType field in the HS.Local.SDA3.PatientExtension class to store the custom information.
  • Extension of HL7 2.5.1 schema to add a custom Z segment to A28 messages.
  • Extension of the HS.Hub.Standalone.HL7.HL7ToSDA3 class to indicate the transformation to perform when receiving the A28.
  • Creating the ADTA28ToSDA3 transformation.

With all of the above we can now send messages with the blood group in the new segment and store it with the patient's data as an extension. What would we need to complete the customization? The Local.CompositeRecord.Transient.Definition! We are saving the data correctly but we have not modified the class used to load blood group in the relevant patient data.

CompositeRecord Setup

Let's see how the data is displayed in the CompositeRecord:

<propertyGroup name="Gender" trustBlock="base" description="Gender - base: all tier 5">
<property>Gender</property>
</propertyGroup>

 We define the group to which the new data will belong and its ownership in the patient object. In our case the BloodType property is hanging from the Extension property, so our new pool will be like this:

<propertyGroup name="Extension" trustBlock="base" description="Extension - base: all tier 5">
<property name='Blood Type'>Extension.BloodType</property>
</propertyGroup>

In our case we have called it Extension, but it could be any other name.

Once our Local.CompositeRecord.Transient.Definition class has been edited, we can launch tests with our custom A28 messages starting production.

Testing

Let's check the trace of one of the messages entered:

There we have our ZBT segment with the value B+. Let's see how it is mapped to the object:

There we have our Extension field with the new BloodType property. Let's launch a search for that patient registered with MPIID 100000350.

Here is the Extension field and its B+ value. We could rename the tag and call it Blood Type without any problem.

Well, this would be all, we have configured our EMPI to receive personalized fields, to register them as patient data and to return them.

If you have any questions or suggestions, do not hesitate to write a comment about it.

Comentarios (0)1
Inicie sesión o regístrese para continuar
Artículo
· 9 jun, 2023 Lectura de 16 min

Instalación y adaptación de EMPI en modo Standalone - Personalización de datos de paciente

Empezaré como dice la leyenda que empezó su clase Fray Luís de León tras varios años de condena:

Como decíamos ayer...nuestro EMPI puede recibir datos de múltiples fuentes, vía REST, mensajería HL7, etc. Pero es posible que los campos estándar no sean suficientes y querramos ampliar la información del paciente para ayudar a discriminarlo e identificarlo unívocamente. ¿Cómo podríamos personalizar los datos de paciente? ¿Modificando las clases estándar a nuestro gusto? ¡¡¡¡NOOOOO!!!! bueno, un poco sí, pero no a lo loco, ya que si tocamos clases estándar sin cuidado podremos encontrarnos que en una futura actualización perdamos todas estas modificaciones.

Personalización de los datos de paciente

Muy bien, continuemos con la configuración de nuestro EMPI en el que hemos introducido una serie de pacientes. Imaginad que hemos decidido incluir el grupo sanguíneo como un criterio para ayudar en el proceso del cálculo de pesos. Recordemos que clases definían los datos del paciente.

Por un lado tenemos el objeto que vamos a persistir y que lo encontramos en el Definition Designer:

Por el otro lado tenemos el objeto que vamos a retornar en las búsquedas y que corresponde al "Composite Record" configurado previamente desde la opción de Configuration Registry.

 

Echemos un ojo a HSPI.Data.Patient, en concreto a la declaración de la clase:

Class HSPI.Data.Patient Extends (%Persistent, HSPI.Data.Type.Patient, %MPRL.Linkage.Base) 

Podemos observar que sus propiedades son heredadas de HSPI.Data.Type.Patient, si accedemos a dicha clase veremos que disponemos de una serie de valores correspondiente a las propiedades del objeto paciente. Como hemos dicho, podríamos añadir aquí los campos que necesitáramos...pero eso NO ES RECOMENDABLE, tenemos una opción mejor que no se verá afectada por las actualizaciones de versiones. Si vamos hasta el final de la clase HSPI.Data.Type.Patient nos encontramos la siguiente propiedad:

Property Extension As HS.Local.SDA3.PatientExtension;

Esta propiedad es la que nos permitirá añadir tantos campos como deseemos a nuestro objeto paciente. Como véis, al pertenecer al Local evitará que en los futuros cambios de versión esta información se pierda. Abramos HS.Local.SDA3.PatientExtension e incluyamos la propiedad BloodType como un simple String:

Class HS.Local.SDA3.PatientExtension Extends HS.SDA3.DataType
{

Parameter HSDEPLOY = 0;
Parameter STREAMLETCLASS = "HS.SDA3.Streamlet.Patient";
Property BloodType As %String;
}

Perfecto, nuestro objeto está preparado para recibir dicha información. ¿Cómo podemos enviar esta nueva información a nuestro sistema? Como vimos en el artículo anterior, nuestro EMPI dispone de una configuración por defecto que puede recibir mensajería HL7 y que ya hemos utilizado para añadir pacientes.

Creación de nuevo esquema de HL7

En nuestro ejemplo usaremos un mensaje A28 al que añadiremos un nuevo segmento con la información del tipo sanguineo. Para ello vamos a crear un nuevo esquema basado en el esquema estándar 2.5.1 y vamos a crear un nuevo DocType para el tipo de mensaje A28.

Aquí tenemos nuestro nuevo esquema HealthShare_2.5 que como véis, extiende del estándar 2.5.1 y hemos creado una nueva estructura de mensaje del tipo A28. Para añadir un nuevo segmento crearemos primeramente dicho segmento al que llamaremos ZBTy le añadiremos el campo que contendrá el tipo sanguíneo:

Con el segmento creado sólo necesitamos incluirlo a la estructura del mensaje y podremos empezar a trabajar con estos mensajes personalizados:

Perfecto, mensaje configurado con nuestro segmento ZBT. Veamos ahora un ejemplo del tipo de mensaje que vamos a recibir con el nuevo segmento:

MSH|^~\&|HIS|HULP|EMPI||20230329085239||ADT^A28|72104|P|HealthShare_2.5
EVN|A28|20230329085239|20230329085239|1
PID|||1502935519^^^SERMAS^SN~424392^^^HULP^PI||CABEZUELA SANZ^PEDRO^^^||20160627|M|||PASEO JULIA ÁLVAREZ^395 3 E^MADRID^MADRID^28909^SPAIN||555710791^PRN^^PEDRO.CABEZUELA@GMAIL.COM|||||||||||||||||N|
PV1||N
ZBT|A-

En nuestro ejemplo el paciente Pedro Cabezuela Sanz tiene un tipo sanguíneo A-.

Configuración de la producción del EMPI:

Como vimos en el anterior artículo de configuración del EMPI, disponemos de una producción configurada por defecto que nos permite operar inmediatamente con nuestro EMPI. 

En nuestro ejemplo estamos usando el Business Service EnsLib.HL7.Service.FileService que capturará ficheros con mensajes HL7 de la ruta especificada, para adaptarlo al nuevo tipo de mensajes que vamos a recibir modificaremos el Message Schema Category para hacer referencia al nuevo esquema creado. Echemos un ojo a uno de los ejemplos de los mensajes que enviamos en el ejemplo del artículo anterior para identificar los Business Components por los que pasan nuestros mensaje y poder identificarlos:

Nuestro mensaje entra por EnsLib.HL7.Service.FileService y este se redirige a HS.Hub.Standalone.HL7.Operation, aquí tenemos la configuración de dicho Business Operation:

Observamos que tenemos un atributo llamado HL7ToSDA3Class configurado con la clase HS.Hub.Standalone.HL7.HL7ToSDA3. Abramos la clase y comprobemos cual es su funcionalidad.

 
HS.Hub.Standaline.HL7.HL7ToSDA3

Esta clase pertenece al estándar y no tenemos interés en modificar nada de la misma, por lo que vamos a crear una nueva Local que extenderá de la clase estándar:

Class Local.Hub.Standalone.HL7.HL7ToSDA3 Extends HS.Hub.Standalone.HL7.HL7ToSDA3
{

ClassMethod GetTransformClass(msgType As %String, ByRef pTransformClass As %String) As %Status
{
    {
	set tSC=$$$OK
	set pTransformClass=..OnGetTransformClass() 
	quit:pTransformClass'=""
	set pTransformClass = $CASE(msgType,
              "ADT_A01":"ADTA01ToSDA3", "ADT_A02":"ADTA02ToSDA3", "ADT_A03":"ADTA03ToSDA3",
              "ADT_A04":"ADTA01ToSDA3", "ADT_A05":"ADTA05ToSDA3", "ADT_A06":"ADTA01ToSDA3",
              "ADT_A07":"ADTA01ToSDA3", "ADT_A08":"ADTA01ToSDA3", "ADT_A09":"ADTA01ToSDA3",
              "ADT_A10":"ADTA01ToSDA3", "ADT_A11":"ADTA09ToSDA3", "ADT_A12":"ADTA01ToSDA3",
              "ADT_A13":"ADTA01ToSDA3", "ADT_A16":"ADTA01ToSDA3", "ADT_A17":"ADTA01ToSDA3",
              "ADT_A18":"ADTA18ToSDA3", "ADT_A23":"ADTA21ToSDA3", "ADT_A25":"ADTA01ToSDA3",
              "ADT_A27":"ADTA01ToSDA3", "ADT_A28":"ADTA28ToSDA3", "ADT_A29":"ADTA21ToSDA3",
              "ADT_A30":"ADTA30ToSDA3", "ADT_A31":"ADTA05ToSDA3", "ADT_A34":"ADTA30ToSDA3",
              "ADT_A36":"ADTA30ToSDA3", "ADT_A39":"ADTA40ToSDA3", "ADT_A40":"ADTA40ToSDA3",
              "ADT_A45":"ADTA45ToSDA3", "ADT_A47":"ADTA30ToSDA3", "ADT_A50":"ADTA50ToSDA3",
              "ADT_A60":"ADTA60ToSDA3", "BAR_P12":"BARP12ToSDA3", "MDM_T02":"MDMT02ToSDA3",
              "MDM_T04":"MDMT02ToSDA3", "MDM_T08":"MDMT02ToSDA3", "MDM_T11":"MDMT01ToSDA3",
              "OMP_O09":"OMPO09ToSDA3", "ORM_O01":"ORMO01ToSDA3", "ORU_R01":"ORUR01ToSDA3",
              "PPR_PC1":"PPRPC1ToSDA3", "PPR_PC2":"PPRPC1ToSDA3", "PPR_PC3":"PPRPC1ToSDA3",
              "RDE_O11":"RDEO11ToSDA3", "SIU_S12":"SIUS12ToSDA3", "SIU_S13":"SIUS12ToSDA3",
              "SIU_S14":"SIUS12ToSDA3", "SIU_S15":"SIUS12ToSDA3", "SIU_S16":"SIUS12ToSDA3",
              "SIU_S17":"SIUS12ToSDA3", "SIU_S26":"SIUS12ToSDA3", "VXU_V04":"VXUV04ToSDA3",
              :"Unsupported HL7 Message Type")

	set:pTransformClass="Unsupported HL7 Message Type" tSC = $$$HSError($$$HSErrUnsupportedHL7MessageType,msgType)
 	if $$$ISERR(tSC) quit tSC
 	if (msgType = "ADT_A28") {
 		set tTransformPackage = "Local.Hub.Standalone.HL7.DTL"
 	}
 	else {
 		set tTransformPackage = "HS.Hub.Standalone.HL7.DTL"
 	}
 	set pTransformClass = tTransformPackage_"."_pTransformClass
	
	quit tSC
}

}

De todas sus clases la que más nos interesa es GetTransformClass la cual nos va a indicar que transformación debemos realizar dependiendo del tipo de mensaje recibido. Como en nuestro caso hemos escogido el mensaje A28 como el portador del nuevo segmento con la información del grupo sanguíneo deberemos encontrar dicha transformación dentro del comando $CASE:

"ADT_A28":"ADTA05ToSDA3"

Aquí tenemos nuestra transformación inicial, como podemos ver, la estructura del mensaje ADT_A28 es la de ADT_A05, por ello tiene dicha transformación configurada por defecto, en nuestro caso vamos a crear una nueva transformación copiando la ADTA05ToSDA3 y la denominaremos ADTA28ToSDA3, remplazando el valor que tenía en el $CASE a:

"ADT_A28":"ADTA28ToSDA3"

Si véis hemos incluido una condición para que cuando se reciba un ADT_A28 está utilice la transformación con el package Local.Hub.Standalone.HL7.DTL

Con la clase  Local.Hub.Standalone.HL7.HL7ToSDA3 compilada abreremos nuevamente nuestra producción y definiremos el valor del parámetro HL7ToSDA3Class en el Business Operation HS.Hub.Standalone.HL7.Operation con la nueva clase implementada Local.Hub.Standalone.HL7.HL7ToSDA3

Perfecto, hemos concluido la configuración de nuestra producción. Sólo nos queda un pequeño detalle...¡aún no hemos creado nuestra transformación ADTA28ToSDA3!

Creación de transformación personalizada:

Desde el menú de las lista de transformaciones buscaremos la ADTA05ToSDA3.

Aquí la tenemos, abrámosla y procedamos a guardarla con otro nombre y Package para crear una copia de la misma.

Con la nueva clase creada podemos empezar la transformación, deberemos realizar las siguientes tareas:

  • Modificar el Source Doc Type de 2.5.1:ADT_A05 a HealthShare_2.5:ADT_A28. Recordar que hemos creado una nueva estructura de mensaje A28.
  • Asignar el valor del campo BloodType del segmento ZBT de nuestro mensaje al campo BloodType que encontramos dentro de la propiedad Extension incluida en Patient. Este campo BloodType está disponible al haber añadido la propiedad BloodType en la clase HS.Local.SDA3.PatientExtension.

La transformación quedaría tal que así:

Muy bien, repasemos lo que hemos hecho hasta ahora:

  • Creación del campo BloodType en la clase HS.Local.SDA3.PatientExtension para almacenar la información personalizada.
  • Extensión del esquema 2.5.1 de HL7 para añadir un segmento Z personalizado a los mensajes A28.
  • Extensión de la clase HS.Hub.Standalone.HL7.HL7ToSDA3 para indicar la transformación a realizar al recibir el A28.
  • Creación de la transformación ADTA28ToSDA3.

Con todo lo anterior ya podemos enviar mensajes con el grupo sanguíneo en el nuevo segmento y almacenarlo con los datos del paciente como una extensión. ¿Qué nos faltaría para concluir la personalización? ¡El Local.CompositeRecord.Transient.Definition! Estamos guardando los datos correctamente pero no hemos modificado la clase usada para cargar grupo sanguíneo en los datos relevantes del paciente.

Configuración del CompositeRecord

Veamos como se muestran los datos en el CompositeRecord:

<propertyGroup name="Gender" trustBlock="base" description="Gender - base: all tier 5">
<property>Gender</property>
</propertyGroup>

 Definimos el grupo al que van a pertenecer los nuevos datos y la propiedad del mismo en el objeto paciente. En nuestro caso la propiedad BloodType está colgando de la propiedad Extension, por lo que nuestro nuevo grupo será tal que así:

<propertyGroup name="Extension" trustBlock="base" description="Extension - base: all tier 5">
<property name='Blood Type'>Extension.BloodType</property>
</propertyGroup>

En nuestro caso lo hemos denominado Extension, pero podría ser cualquier otro nombre.

Una vez editado nuestra clase Local.CompositeRecord.Transient.Definition ya podemos lanzar una batería de pruebas con nuestros mensajes A28 personalizados arrancando la producción.

Pruebas:

Comprobemos la traza de uno de los mensajes introducidos:

Ahí tenemos nuestro segmento ZBT con el valor B+. Veamos como se mapea al objeto:

Ahí tenemos nuestro campo Extension con la nueva propiedad BloodType. Lancemos una búsqueda de dicho paciente registrado con el MPIID 100000350.

Aquí está el campo Extension y su valor B+. Podríamos cambiar el nombre de la etiqueta y llamarlo Blood Type sin ningún problema.

Pues esto sería todo, hemos configurado nuestro EMPI para recibir campos personalizados, para registrarlos como datos del paciente y para devolverlos.

Si tenéis alguna pregunta o sugerencia no dudeis en escribir un comentario al respecto.

Comentarios (0)1
Inicie sesión o regístrese para continuar