Hello, I need to export the data generated in the MUMPS system with a unique key for each appointment made. Data needs to be exported in XML, can I do that in MUMPS? Can anyone help me? The data I need to export in XML format is accession_number Each exam has a unique identifier, if the patient performs more than one exam on the same day, each one will have a different Accession Number.

patient_id - Unique identifier of the exam

accession_number - Patient identifier

patient_name - Patient's name

patient_birthdate - Patient's date of birth Example: YYYYMMDD

patient_sex - Patient's gender

patient_weight - Patient weight

Thx

Are you sure the meanings of patient_id and accession_number are not interchanged?
Anyway, with the above specification, I'd end up with a code-snipper like this:
(please note that this medium reduces multiple spaces to single ones...)

;
Set xmlfile="...destinstionfolder.../filename.xml"
Open xmlfile:newfile ; If you're using GT.M
Open xmlfile:"wns" ; If you're using Caché or IRIS
Use xmlfile
Write "<!DOCTYPE ...>",! ; Fill in whatever document type is needed for your applicatiom
Write "<xml ...>",! ; Fill in whatever XML header is needed for your application
; let's assume for this example that your appointments
; are stored in a global variable named ^Appointment(date,...)
; Of course, in your system, that name will be different
Set startdate="???" ; fill in your startdate
Set enddate="???" ; fill in your enddate
Set date=startdate For Do Set date=$Order(^Appointment(date)) Quit:date="" Quit:date>enddate
. Set appointment="" For Set appointment=$Order(^Appointment(date,appointment)) Quit:appointment="" Do
. . Write " <appointment>",!
. . Set value="..." ; extract the Unique identifier of the exam from the appointment data
. . Write " <patient_id>"_value_"</patient_id>",!
. . Set value="..." ; extract the Patient identifier from the appointment data
. . Write " <accession_number>"_value_"</accession_number>",!
. . Set value="..." ; extract the Patient's name from the appointment data
. . Write " <patient_name>"_value_"</patient_name>",!
. . Set value="..." ; extract the Patient's date of birth from the appointment data and reformat it as YYYYMMDD
. . Write " <patient_birthdate>"_value_"</patient_birthdate>",!
. . Set value="..." ; extract the Patient's gender from the appointment data
. . Write " <patient_sex>"_value_"</patient_sex>",!
. . Set value="..." ; extract the Patient weight from the appointment data
. . Write " <patient_weight>"_value_"</patient_weight>",!
. . Write " </appointment>",!
. . Quit
. Quit
Write "</xml>",!
Close xmlfile
;

Em quinta-feira, 12 de maio de 2022 às 16:55:42 UTC-3, ed de moel escreveu:
> Are you sure the meanings of patient_id and accession_number are not interchanged?
> Anyway, with the above specification, I'd end up with a code-snipper like this:
> (please note that this medium reduces multiple spaces to single ones...)
>
> ;
> Set xmlfile="...destinstionfolder.../filename.xml"
> Open xmlfile:newfile ; If you're using GT.M
> Open xmlfile:"wns" ; If you're using Caché or IRIS
> Use xmlfile
> Write "<!DOCTYPE ...>",! ; Fill in whatever document type is needed for your applicatiom
> Write "<xml ...>",! ; Fill in whatever XML header is needed for your application
> ; let's assume for this example that your appointments
> ; are stored in a global variable named ^Appointment(date,...)
> ; Of course, in your system, that name will be different
> Set startdate="???" ; fill in your startdate
> Set enddate="???" ; fill in your enddate
> Set date=startdate For Do Set date=$Order(^Appointment(date)) Quit:date="" Quit:date>enddate
> . Set appointment="" For Set appointment=$Order(^Appointment(date,appointment)) Quit:appointment="" Do
> . . Write " <appointment>",!
> . . Set value="..." ; extract the Unique identifier of the exam from the appointment data
> . . Write " <patient_id>"_value_"</patient_id>",!
> . . Set value="..." ; extract the Patient identifier from the appointment data
> . . Write " <accession_number>"_value_"</accession_number>",!
> . . Set value="..." ; extract the Patient's name from the appointment data
> . . Write " <patient_name>"_value_"</patient_name>",!
> . . Set value="..." ; extract the Patient's date of birth from the appointment data and reformat it as YYYYMMDD
> . . Write " <patient_birthdate>"_value_"</patient_birthdate>",!
> . . Set value="..." ; extract the Patient's gender from the appointment data
> . . Write " <patient_sex>"_value_"</patient_sex>",!
> . . Set value="..." ; extract the Patient weight from the appointment data
> . . Write " <patient_weight>"_value_"</patient_weight>",!
> . . Write " </appointment>",!
> . . Quit
> . Quit
> Write "</xml>",!
> Close xmlfile
> ;

Hello, I need to generate an xml file for each request in a folder on my corporate network and I must ensure that XMLS files are not generated for the already integrated schedules, is it possible?
The patient_id field refers to the patient's medical record number. It is a unique number for each patient. The accession_number field refers to the identification number of the exam that the patient is performing, if the patient performs 2 exams on the same day, the accession_number must be used to identify the 2 different exams.

It is possible?
Of course: just modify the above example accordingly.

Em sexta-feira, 13 de maio de 2022 às 12:21:14 UTC-3, ed de moel escreveu:
> It is possible?
> Of course: just modify the above example accordingly.

Perfect, I will carry out the tests..
Thank you very much friend..

I hope this project will go well for you.
There are some questions to consider still, though:
You mentioned that you should not create multiple XML files for the same appointment, but what do you do when an appointment gets changed or canceled?
- leave it as is, because you already created the file?
- create a new file with the same name with the updated information?
- create one or two new files, one to reflect the cancellation of the old appointment, and if the appointment was changed, a second one for the new appointment?

Now, how you actually implement it has much more to do with the internal workings of your application than with the programming language.
For some applications, it is possible to tie a "trigger" to the event that creates the appointment, and that "trigger" could be used to create the XML file (if that's an option, you'd automatically be sure that only one XML file gets created for each appointment).
For some application, you'd have to implement the creation of these files as a regular background task (hourly? daily? weekly?), in which case you may hae to keep a log of the appointments for which you have already created a file.

I'm sure that, the longer you think about this, the more questions will arise.
Good luck!
Ed

Em sexta-feira, 13 de maio de 2022 às 14:56:30 UTC-3, ed de moel escreveu:
> I hope this project will go well for you.
> There are some questions to consider still, though:
> You mentioned that you should not create multiple XML files for the same appointment, but what do you do when an appointment gets changed or canceled?
> - leave it as is, because you already created the file?
> - create a new file with the same name with the updated information?
> - create one or two new files, one to reflect the cancellation of the old appointment, and if the appointment was changed, a second one for the new appointment?
>
> Now, how you actually implement it has much more to do with the internal workings of your application than with the programming language.
> For some applications, it is possible to tie a "trigger" to the event that creates the appointment, and that "trigger" could be used to create the XML file (if that's an option, you'd automatically be sure that only one XML file gets created for each appointment).
> For some application, you'd have to implement the creation of these files as a regular background task (hourly? daily? weekly?), in which case you may hae to keep a log of the appointments for which you have already created a file.
>
> I'm sure that, the longer you think about this, the more questions will arise.
> Good luck!
> Ed

Good afternoon friend, at first I would keep the same file, because the data that are recorded in the file are used to assemble a worklist.
I will explain to you the purpose of this need.
We need to export in XML the exam scheduling data of a given patient on the day from our MUMPS system so that another system can read the XML and make the data available in a service for consultation.
What I need to ensure is that XML files are not generated from schedules that have already been integrated, I'm thinking about how to do this in MUMPS..

Em sexta-feira, 13 de maio de 2022 às 15:10:44 UTC-3, ti.h...@gmail.com escreveu:
> Em sexta-feira, 13 de maio de 2022 às 14:56:30 UTC-3, ed de moel escreveu:
> > I hope this project will go well for you.
> > There are some questions to consider still, though:
> > You mentioned that you should not create multiple XML files for the same appointment, but what do you do when an appointment gets changed or canceled?
> > - leave it as is, because you already created the file?
> > - create a new file with the same name with the updated information?
> > - create one or two new files, one to reflect the cancellation of the old appointment, and if the appointment was changed, a second one for the new appointment?
> >
> > Now, how you actually implement it has much more to do with the internal workings of your application than with the programming language.
> > For some applications, it is possible to tie a "trigger" to the event that creates the appointment, and that "trigger" could be used to create the XML file (if that's an option, you'd automatically be sure that only one XML file gets created for each appointment).
> > For some application, you'd have to implement the creation of these files as a regular background task (hourly? daily? weekly?), in which case you may hae to keep a log of the appointments for which you have already created a file.
> >
> > I'm sure that, the longer you think about this, the more questions will arise.
> > Good luck!
> > Ed
> Good afternoon friend, at first I would keep the same file, because the data that are recorded in the file are used to assemble a worklist.
> I will explain to you the purpose of this need.
> We need to export in XML the exam scheduling data of a given patient on the day from our MUMPS system so that another system can read the XML and make the data available in a service for consultation.
> What I need to ensure is that XML files are not generated from schedules that have already been integrated, I'm thinking about how to do this in MUMPS.

Hi!

You're in safe hands with these M developers and I agree with all of them, they are the best!

I'm from Belo Horizonte and I have a lot of experience with MSM Unix as well others M implementations and relational databases.

Feel free to contact me if you need help or exchange ideas.

Regards,

Em sexta-feira, 20 de maio de 2022 às 19:15:46 UTC-3, flaviof...@hotmail.com escreveu:
> Em sexta-feira, 13 de maio de 2022 às 15:10:44 UTC-3, ti.h...@gmail.com escreveu:
> > Em sexta-feira, 13 de maio de 2022 às 14:56:30 UTC-3, ed de moel escreveu:
> > > I hope this project will go well for you.
> > > There are some questions to consider still, though:
> > > You mentioned that you should not create multiple XML files for the same appointment, but what do you do when an appointment gets changed or canceled?
> > > - leave it as is, because you already created the file?
> > > - create a new file with the same name with the updated information?
> > > - create one or two new files, one to reflect the cancellation of the old appointment, and if the appointment was changed, a second one for the new appointment?
> > >
> > > Now, how you actually implement it has much more to do with the internal workings of your application than with the programming language.
> > > For some applications, it is possible to tie a "trigger" to the event that creates the appointment, and that "trigger" could be used to create the XML file (if that's an option, you'd automatically be sure that only one XML file gets created for each appointment).
> > > For some application, you'd have to implement the creation of these files as a regular background task (hourly? daily? weekly?), in which case you may hae to keep a log of the appointments for which you have already created a file.
> > >
> > > I'm sure that, the longer you think about this, the more questions will arise.
> > > Good luck!
> > > Ed
> > Good afternoon friend, at first I would keep the same file, because the data that are recorded in the file are used to assemble a worklist.
> > I will explain to you the purpose of this need.
> > We need to export in XML the exam scheduling data of a given patient on the day from our MUMPS system so that another system can read the XML and make the data available in a service for consultation.
> > What I need to ensure is that XML files are not generated from schedules that have already been integrated, I'm thinking about how to do this in MUMPS.
> Hi!
>
> You're in safe hands with these M developers and I agree with all of them, they are the best!
>
> I'm from Belo Horizonte and I have a lot of experience with MSM Unix as well others M implementations and relational databases.
>
> Feel free to contact me if you need help or exchange ideas.
>
> Regards,

Hi Flavio, I'm from Brazil too. Can you provide your email or whatsapp so we can exchange an idea?

Em segunda-feira, 23 de maio de 2022 às 08:51:20 UTC-3, ti.h...@gmail.com escreveu:
> Em sexta-feira, 20 de maio de 2022 às 19:15:46 UTC-3, flaviof...@hotmail.com escreveu:
> > Em sexta-feira, 13 de maio de 2022 às 15:10:44 UTC-3, ti.h...@gmail.com escreveu:
> > > Em sexta-feira, 13 de maio de 2022 às 14:56:30 UTC-3, ed de moel escreveu:
> > > > I hope this project will go well for you.
> > > > There are some questions to consider still, though:
> > > > You mentioned that you should not create multiple XML files for the same appointment, but what do you do when an appointment gets changed or canceled?
> > > > - leave it as is, because you already created the file?
> > > > - create a new file with the same name with the updated information?
> > > > - create one or two new files, one to reflect the cancellation of the old appointment, and if the appointment was changed, a second one for the new appointment?
> > > >
> > > > Now, how you actually implement it has much more to do with the internal workings of your application than with the programming language.
> > > > For some applications, it is possible to tie a "trigger" to the event that creates the appointment, and that "trigger" could be used to create the XML file (if that's an option, you'd automatically be sure that only one XML file gets created for each appointment).
> > > > For some application, you'd have to implement the creation of these files as a regular background task (hourly? daily? weekly?), in which case you may hae to keep a log of the appointments for which you have already created a file.
> > > >
> > > > I'm sure that, the longer you think about this, the more questions will arise.
> > > > Good luck!
> > > > Ed
> > > Good afternoon friend, at first I would keep the same file, because the data that are recorded in the file are used to assemble a worklist.
> > > I will explain to you the purpose of this need.
> > > We need to export in XML the exam scheduling data of a given patient on the day from our MUMPS system so that another system can read the XML and make the data available in a service for consultation.
> > > What I need to ensure is that XML files are not generated from schedules that have already been integrated, I'm thinking about how to do this in MUMPS.
> > Hi!
> >
> > You're in safe hands with these M developers and I agree with all of them, they are the best!
> >
> > I'm from Belo Horizonte and I have a lot of experience with MSM Unix as well others M implementations and relational databases.
> >
> > Feel free to contact me if you need help or exchange ideas.
> >
> > Regards,
> Hi Flavio, I'm from Brazil too. Can you provide your email or whatsapp so we can exchange an idea?

Hi!

Feel free to contact me via whatsapp 31989460853

Regards,