Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

Assignment: Python FHIR Resource

Due Monday, April 8 (2024) at 11:59 PM for B01 and B02 – Extensions Possible!

Assignment’s General Specifications

Your final Pair Assignment will be to upgrade the Python code for generating a FHIR JSON format Patient Resource that you worked on in Exercise #10 to allow user input to fill in the Patient Resource. A fully defined code will allow the Python user to populate anywhere from an empty record to a complete one. Consider the Structure tab:

User Defines the Extent of the Record

An empty record would have only the resource type (Patient). Since every other field below can be used ‘0’ times your code should allow that for each item within the Patient record, the user can choose not to enter data.  The choice should manifest at the line entry. They must not be asked ahead of time which fields they want to add.

For the purposes of the Assignment, it’s up to you whether to code as an empty JSON line, utilize a logical predefined value, or skip printing the line into your record entirely. For example: if your User does not enter a gender, there are three possible things you could do: enter nothing, drop the field, or use the ‘unknown’ value allowed for that field.

Implementing Minimum and Maximum Cardinality

Minimum cardinality (to the left of the two dots):

· 0 means they can be left out (or left blank)

· 1 means two things: it must be included, but only if its parent is included!

· But having a ‘Parent’ is only the case for the last one. If and only if this Patient is linked to another Record:

o You must specify the name of that other Patient or Related Person

o And you must define the code (replaced-by, replaces, refer, or see-also)

o You cannot just have one or the other.

o To code this case, you’ll need a guard condition: if the user insists on having a link, you must specify both the Reference Patient and the link code.

Maximum cardinality (to the right of the two dots):

· 1 means that the field can only be used once. For example:

o a patient, logically, can only be active or inactive and not (1) active and (2) inactive!

o a patient only has one administrative gender. Multiple gender expression is not an administrative exception, they fall under the single field as ‘other’. More sophisticated systems will then have ways to annotate that field to explain preferred specification(s) in encounters with the Patient!

o A patient naturally has only one birthdate (even if only parts of it are known). And so on…

· The asterisk is typical object-oriented shorthand for ‘many’. These fields can be repeated but must only repeat different uses of that field to avoid violating Python’s rule that all Dictionary keys are unique. E.g.:

o A patient can have more than one name, where each name has a different use.

o Or a patient could have more than one contact where the system varies (phone, email, and so on)

o Or if the same system (for example telephone), the value, the use, or the rank differs.

Recommended order of coding

It’s your choice whether to use the Exercise 10 method of creating a JSON-style Python Object, or the one for constructing, or the one for factory constructing. However, beware that methods that add the “resourceType”: “Patient” tuple might result in a later conversion to XML not working quite as intended – it’s supposed to be the root, but the typical JSON-to-XML library script might not set Patient as the root, and instead as one of the child elements of the XML document. To fix this, in XML, Patient is the root (you leave the resourceType word out).

For your first round of coding, ignore all the fields that have the greater-than-one maximum cardinality. Create a Python code that lets the user specify values for each of the (0…1) fields and outputs a Python-code equivalent to a JSON Object that only contains those fields. Look at the JSON code on the website again.

· Click here: https://www.hl7.org/fhir/patient.html 

· Scroll down and look at the Structure Tab

· Switch to the JSON Tab

· Compare what you see on the two Tabs!

Notice that the 0-to-1 fields are all coded as key/value paired tuples. Whereas all the 0-to-Many fields are list objects, themselves containing one or more dictionary objects. To properly code these values you’ll need to create an empty list, then code a loop that collects each dictionary object from the User and appends them to the list until the user stops adding new ones. A that point it moves entirely on to the next field.

One of our Lab Exercises in the Loop/Guard week involved collecting a list of values (of a correct type) up to when the user hit Enter twice. This ‘break’ condition is one way to implement the move to the next field. Another way (which I’ll accept as well) is to ask the User if they want to add another entry – so that while they indicate positively, the loop repeats itself until they input a negative, at which point it breaks onto the next data collection!

Note that the order of the fields doesn’t have to exactly match the JSON Template. So, if you did all the above coding then didn’t put the fields back into their order (i.e., left it so it’s still 0-to-1 first and 0-to-Many after) it would be totally well-formed code. I’d like you to reorganize your code so that it matches the template after you get both parts working in the one JSON Object, but I won’t mark it down if you don’t.

Submission & Grading

Submission Expectations (Yours and Mine)

On the second-to last Lab date I’ll make the Assignment Submission form visible (with witnesses to prove that it was done correctly) and set it to accept multiple files and keep rather than overwrite all submissions!

Submit your Python code as a PY file and a sample of the output Patient file where all optional non-repeatable fields have been filled in once, and all repeatable fields have been used at least once.

Expected Python Code OUTPUT and Formatting the Output File

Your Python code should be able to print the constructed Patient Record object to an external text file.

Because Python Objects and JSON Objects share functionally identical syntax, you have the option of exporting to a file with PY or JSON filetype rather than a TXT: PY and JSON files can be opened in any program that can open a TXT file so it shouldn’t matter which file extension you use – the main difference with a program like Notepad++ or VSCode is they recognize a .JSON file as JSON Object and color-code to make reading and checking it easier.

However, you should “clean it up”: utilize line breaks and indentation to lay out the output more like the Template style, rather than just one long line of text that wraps to new lines only because of the screen width.

Grading Scheme

Your grade is 5% of the Course mark, which is in other words 20% of the Lab Grade. The 20 points will be achieved through a weighted average of the following:

1. A thoroughly and correctly coded Python file including extensive application of user input, with slightly more weight to the repeatable fields than the ones that can only be filled at most once (15/20)

· Even though there are fewer of them, their loops (and potentially guards as well) make them individually more complex and indicative of higher-level application of learned coding skill!

2. Nicely formatted and easily readable FHIR Python Object output as a PY, JSON or TXT file (5/20)

Addendum: Converting Python collections to XML

There are some complex scripts available for converting the very specific FHIR JSON Object (including as represented in Python) into a FHIR XML Object, as well as several web tools that do it more automatically.

Using an automated site provides little educational value added, but on the other hand the code for converting a complex FHIR JSON object into the equally complex well-formed and valid FHIR XML Object is (in fact) way beyond the scope of this Lab or Course – it’s less a beginner-intermediate application of Python and more advanced-intermediate. If you’re interested look up the concept of serializing Python FHIR Objects as XML and vice-versa deserializing from XML to JSON Objects (which can then be parsed as Python Objects).

In fact, this is a solid lesson for programming in any web and/or big-data markup or programming language. Why reinvent impractically complex code when others have done it for you? That’s the whole point of calling up classes and objects as often as we have for examples. Assuming your Python code is complete and valid, if you run it in the right side of the following automated translation engine, you should see a reasonable FHIR XML equivalent on the left of the page: https://fhir-formats.github.io 

It’s not a perfect translation, because the XML structure of the current FHIR standard versus the slightly older one this was written in are mildly different, but it should give you a fairly accurate XML document example.