Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hl7v2 templates - [Quantity/Timing] Explicit Time Interval subfield correct format. #513

Open
shabanlushaj opened this issue Jan 9, 2024 · 4 comments
Assignees

Comments

@shabanlushaj
Copy link
Contributor

Issue:

For any segment that contains Quantity/Timing -> Explicit Time Interval subfield when time is represented in HHMM format, FhirJsonParser fails to parse to HL7 Fhir Bundle.

Is there any standard that current implementation is based on for Quantity/Timing?
https://hl7-definition.caristix.com/v2/HL7v2.5.1/Fields/ORC.7.2.2 based on this and some EHR providers time format is represented in HHMM format.

How to reproduce:

POST azure-server/$convert-data

Body
{
    "resourceType": "Parameters",
    "parameter": [
        {
            "name": "rootTemplate",
            "valueString": "ORM_O01"
        },
        {
            "name": "templateCollectionReference",
            "valueString": "microsofthealth/fhirconverter:default"
        },
        
        {
            "name": "inputData",
            "valueString": "MSH|^~\\&|X||Y|Z|20240107111232|123|ORM^O01|1234|T|2.5.1|||||||||||
PID|1||ID||TEST^TEST1|
PV1||I|A^A0^A01^AA^A^^^^^^|||||||
ORC|CA|01^X||||
OBR|1|01^X||^XC^^^XCDE||20240107111210|||||||||||||||||||||^Daily&0730^^20240107111215^^^^|||||||||20240107111215|||||||||"
        },
        {
            "name": "inputDataType",
            "valueString": "Hl7v2"
        }
    ]
}

Response:

{
  "fullUrl": "urn:uuid:d52f37bf-51e0-cf5f-24bd-e94f721c2ba2",
  "resource": {
	"resourceType": "ServiceRequest",
	"id": "d52f37bf-51e0-cf5f-24bd-e94f721c2ba2",
	"status": "revoked",
	"intent": "order",
	"identifier": [
	  {
		"value": "01",
		"system": "http://example.com/v2-to-fhir-converter/Identifier/X",
		"type": {
		  "coding": [
			{
			  "code": "PLAC",
			  "system": "http://terminology.hl7.org/CodeSystem/v2-0203"
			}
		  ]
		}
	  }
	],
	"occurrenceTiming": {
	  "code": {
		"coding": [
		  {
			"code": "Daily"
		  }
		]
	  },
	  "repeat": {
		"timeOfDay": [
		  "0730"
		],
		"boundsPeriod": {
		  "start": "2024-01-07T11:12:15Z"
		}
	  }
	},
	"code": {
	  "coding": [
		{
		  "display": "XC"
		},
		{
		  "display": "XCDE"
		}
	  ]
	},
	"subject": {
	  "reference": "Patient/ce70c2f5-6815-f01e-0fe8-7b6252df819c"
	},
	"encounter": {
	  "reference": "Encounter/6b998f4e-0be1-9273-fe3e-d6ebb9ecc4ec"
	},
	"specimen": [
	  {
		"reference": "Specimen/b1e099e8-ba4f-39d5-62c5-ecfef65fa04f"
	  }
	]
  },
  "request": {
	"method": "PUT",
	"url": "ServiceRequest/d52f37bf-51e0-cf5f-24bd-e94f721c2ba2"
  }
},

When trying to parse it throws exception:

var bundle = new FhirJsonParser(parserSettings).Parse<Bundle>(str);

Hl7.Fhir.ElementModel.StructuralTypeException: 
'Type checking the data: Literal '0730' cannot be parsed as a time. (at Bundle.entry[9].resource[0].occurrenceTiming[0].repeat[0].timeOfDay[0])'

Possible fix:

Converting to HH:MM format (which I believe should be done with a liquid filter when dealing with time).

@namalu
Copy link
Member

namalu commented Jan 9, 2024

Thank you for creating this issue. We are looking into it and I can update you in the next few days.

@wi-y
Copy link
Contributor

wi-y commented Jan 17, 2024

@shabanlushaj thanks for reporting this. agree - the templates seem to return a value which is not valid per the FHIR spec. The spec seems to indicate that HH:mm:ss should be used https://build.fhir.org/datatypes.html#time, so I have created a PR that adds a filter to format the time with a colon and adds the zero'd out seconds if they are not present. After the filter is available the templates can be updated

@shabanlushaj
Copy link
Contributor Author

@wi-y Thanks for pushing this forward. I've added a comment since I've encountered same issue when trying to parse ORU segments which contain OBX segment with time type. OBX|1|TE|X^Time Observation^L||12210000|||||F|||20240117100100|

@wi-y
Copy link
Contributor

wi-y commented Jan 30, 2024

thanks for the feedback - that makes sense. I've updated the linked pull request to handle other HL7v2 time formats

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants