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
;
It is possible?
Of course: just modify the above example accordingly.
I hope this project will go well for you.appointment).
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
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:appointment).
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
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 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.
Good luck!
Ed
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:each appointment).
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
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.
Hi!I'm sure that, the longer you think about this, the more questions will arise.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.
Good luck!
Ed
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.
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:each appointment).
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
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.
Hi!I'm sure that, the longer you think about this, the more questions will arise.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.
Good luck!
Ed
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.
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?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 399 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 101:25:47 |
| Calls: | 8,363 |
| Calls today: | 2 |
| Files: | 13,165 |
| Messages: | 5,897,912 |