Updating all specifications to make it easier to be updated

Initially, you will see few changes in the specifications of all data models,(it is in progress because it will last around 2 days to get it completed)

– The inclusion of the model for those attributes having it.

– Including the data type (when there is only one) for the attributes. ”

– A footer with some useful links, etc

Smart Data Models +++ Contribution Manual +++ About

but there is another hidden relevant change. The specifications are now divided into sections by these tags:

<!– section name –>

<!– /section name –>

It makes easier to update part of the specification without disrupting the rest of the content, and in most markdown viewers it is unnoticed. Besides this, it also allows the extension of the specification (if needed in a coming future) with new sections.

And, of course, everything can be done automatically. Thus we can keep being agile according to our principles.

Therefore, if you see that the specifications are presenting an update don’t worry, Initially, it is just the format and this new trick.

And welcome to the Chinese translation which is using this new format already.

 

New data model Account at the HL7 subject (health)

There is a new subject Hl7 mapping this standard. Hl7 is one of the main standards related to health, it defines more than 140 data models for the management of health information.

The next data model is the Account data model. In order to make it compatible with NGSI-LD some minor adjustments were necessary: 1) A limit in the recursive definition of data models has been applied (only 4 levels). 2) Change the ‘const’ clause in json schema by an enum of one value to make it compatible with YAML (open API 3.0). 3) the type attribute has been renamed to hl7type because otherwise conflicts with NGSI. Regarding the recursive definition of attributes, we expect that it would be more than enough for most of the practical applications. There are another 139 data models in the queue and we hope that soon they will be available.

See it in subject Hl7 in the Smart Health domain.

  • Account. A financial tool for tracking value accrued for a particular purpose. In the healthcare field, used to track charges for a patient, cost centers, etc.

logo fhir

 

New data model Patient for the new subject HL7 at Smart Health domain

There is a new subject Hl7 mapping this standard. Hl7 is one of the main standards related to health, it defines more than 140 data models for the management of health information.

The first data model is the Patient data model. In order to make it compatible with NGSI-LD some minor adjustments were necessary: 1) A limit in the recursive definition of data models has been applied (only 4 levels). 2) Change the ‘const’ clause in json schema by an enum of one value to make it compatible with YAML (open API 3.0). Regarding the recursive definition of attributes, we expect that it would be more than enough for most of the practical applications. There are another 140 data models in the queue and we hope that soon they will be available.

See it in the at subject Hl7 in the Smart Health domain.

  • Patient. Demographics and other administrative information about an individual or animal receiving care or other health-related services.

logo fhir

 

Release the script for subjects’ context consolidation.

The utils directory at the data models compiles some scripts we use internally.

Now you have available a script for consolidating several @contexts from several subjects.

It is the script called by the main menu options Home->tools -> Subjects’ @context merger

the help of the script

# This file takes several @contexts and merges them creating two files
# context.jsonld with the elements successfully merged
# and conflicts.json that shows those attributes clashing.
# clashing in conflicts file has to be solved manually
# INPUT PARAMETERS (merge_subjects_context.json, outputToFile)
# parameter merge_subjects_context.json
# it is the full path to a file where the path to the @contexts will be located
# See an example of the file below
# If not provided it merges all subjects in the smart data models program
# {
# “dataModel.Weather”: “https://raw.githubusercontent.com/smart-data-models/dataModel.Weather/master/context.jsonld”,
# “dataModel.Battery”: “https://raw.githubusercontent.com/smart-data-models/dataModel.Battery/master/context.jsonld”,
# “dataModel.Building”: “https://raw.githubusercontent.com/smart-data-models/dataModel.Building/master/context.jsonld”,
# “dataModel.Device”: “https://raw.githubusercontent.com/smart-data-models/dataModel.Device/master/context.jsonld”,
# }
# parameter ouputToFile
# when True it outputs two files conflicts.json and context.jsonld
# conflicts.json stores the conflict in the name of attributes (to be solved manually)
# context.jsonld has the attribute name and the Smart Data Models local IRI

New data model ResourceReportForecast mapped from OSLO ontology

There is 1 new data model coming from the collaboration with the GreenMov project. This is a mapping of the OSLO ontology for Personal transport hubs

They are located at the OSLO subject.

  • Resource ReportForecast. Resource Report Forecast Schema meeting Passenger Transport Hubs AP Schema specification. A summary of the expectations of the resources connected to mobility services based on defined filters by the person requesting the report.

Vista aƩrea de las colas de acceso a Gibraltar (9460862160) (5)